Let me try to explain what we are seeing on our end.
The Google Home integration is working for the most part. Meaning that we are seeing a large number of success connection and streaming.
BUT… we have seen a series of issues related to oAuth. oAuth is the mechanism that allows us to establish a trust between the user, Google and Wyze that the user is who is says he is and allowing to google to connect to the camera that belongs to the user. Because oAuth relies on tokens with expiration, a lot of the failure where because the tokens were expiring without the users being informed. There is an automatic renewal mechanism that was not working properly. That’s why a lot of the recommendations, and success, was to reconnect the account so those tokens can be valid again.
Now for people, that are still experiencing the problem of connecting, I’m not sure what the problem can be. I know that we have an open issue with Google where, inside the Nest Hub, there is an error being produced. It’s been several weeks that Google has been investigating and they still not have been able to tell me what the problem is and how we (Google and/or Wyze) can fix it. I’m pinging them every week to make sure that it is not ignored.
We are not changing the implementation that much so this is a service that should be stable. The report I’m seeing are saying that this is varying quite a lot. That’s not good and we need to figure out. Believe it or not but it is as frustrating for us than it is for you when you cannot use a feature we spent months developing and heavily tested.
Now, I would like to recommend the following. It won’t fix the issue but it will raise awareness on our side of problems. If you are still facing an issue trying to connect, please go in the mobile app and send feedback (log). The log from the mobile will not help BUT it will give us some information like identifiers. also put some information about the time you tried to connect and the camera you tried to connect to. This would give us enough data to start looking into a potential problem and if the problem is on our side or the google side.
For WebRTC, yes. This is something that I’m betting a lot on. Several reasons:
- Yes it’s a standard used in browser but it is a basic technology, it’s not limited to web browsers and could be used in pretty much anything.
- For the moment, we are using an RTMP stream to a server in the cloud and then transcoding using the Dash protocol and sending the newly formatted stream to the hub.
- RTMP and Dash are file based so we have to create a file with about 4 seconds of video and then create another one and so on. The files are sent as soon as they are complete.
- Google Nest Hub (but almost all the players are doing the same) requires at least 2 files in their device before starting to play the first one. So it’s only when the 3rd file is starting to be uploaded to the device that it would start playing.
- Depending on the resolution, the amount of movement in the frame, the bandwidth of the connection at the time of the upload, it can take a little bit of time (ie. a few seconds) to upload the files to the servers.
- the players when playing the files do not skip frames. Think about it like watching a movie. If the connection is too slow, should they skip part of the movie and try to stay on time or pause the movie until they have all the frames to continue so the viewer is not missing anything? Well, Dash, HLS and a few other protocols want to make sure you see everything.
- WebRTC happened to have also a data channel where we can pass information directly from one device to the other. This could open up a few cool feature.
Soo all those things considered, you can see that you have at least 2 * 4s delays to create the initial file, about 1 seconds of transcoding, about 2 to 5s of moving the files around, about 1 second to do all the security verification and you are at 15 to 20s of delay before the first frame could be shown.
WebRTC is different. It does not care to show all the frames. It cares to show you the latest frame even if it means skipping one or two in the process. WebRTC is frequently used for two way communications (think something like Zoom). There is no transcoding required because what comes out of the camera is what is expected on the other side. The results is a significant improvement in the experience where we can expect latency no greater than 2s and most likely less. Connection time is also a little easier because there is no files to carry around. We have to establish credentials, create a networking path back to the devices and connect them together. So again we are most likely in the 5s to max 8s range also maybe better.