Glad to hear!
Been waiting for this for a long time.
Alexa makes me feel sad. Google makes me feel glad. When I’m glad, I generally purchase SOOOO many Wyze cameras… Yeah… So, really that should be enough to put this one at the top of this list. If not, try and read it, only this time with a British accent… Go ahead… Serious… Told ya.
Oh, don’t anybody fool themselves… We’re all at the mercy of Google in some way or another… EVERYONE!!! (please queue the scary music)
I do this as well.
However, I’ve created a routine so I can say.
“Hey Google, show the front door”
And it opens up TinyCam on my Shield TV
Routine in Google Home
I say “show the front door”
My Assistant should…
open tinycam pro on the shield tv
I had enough awkward moment with google for this week… so no comments!
Meeting at CES and hear the biz dev talking about that article on Nest and Wyze was enough. Especially when I think the comparison was not completely fair.
Thanks for the explanation. It’s probably worth mentioning this detail on the RTSP thread too.
What is the format in which the camera ships video to the cloud?
(I’m wondering if it’s anything that could simply be served out from the camera without incurring excessive cost in the default firmware. I suspect most people asking for RTSP would actually be happy with any format that ffmpeg can understand over any streaming protocol, because most of the things consuming the RTSP stream are based on ffmpeg.)
The format is the same for HLS and RTSP and many other: H.264.
The problem comes from the protocol used to connect and transfer and who initiates the connection.
The standard coming out of the camera is RTMP, which is ideal for talking to a server and that’s why we are using it for Alexa and Google Assistant. We send an RTMP signal to a server that then transform the stream into RTSP or/and HLS.
“package the stream in a new protocol ( <nerd alert>HLS instead of RTSP</nerd alert>).”
Interesting, so does this mea that one type of stream will be able to be opened faster than the other?
I hope this HLS protocol will be much faster than the RTSP because the stream takes forever to open in alexa ,if it opens at all
Would it be acceptably cheap for you to let the regular firmware act as an RTMP source? (I don’t know how much resources are required to serve over RTMP, but I guess you probably have the code to support the protocol already.)
Ffmpeg supports retrieving from RTMP sources, and Blue Iris (which is probably a good fraction of what people want to use with Wyzecam) definitely supports it. I beleive Kodi and vlc do too.
Having RTMP will not cover 100% of the RTSP requests, but if it would be cheap enough to put into the regular firmware, it would cover a good fraction of them, and maybe the rest can pester the maintainers of their clients to add support for RTMP sources.
I’m not 100% sure about what follows but my understanding is that you cannot initiate a connection to the camera using RTMP. Instead, the camera is initiating the connection to the server. This connection is requested through an IoT command also containing some code to validate the requester and a token for the server to authenticate the request.
As you can see, this is fairly complicated and the reason is that we are using that infrastructure for Alexa. So the endpoints are clearly identified and certificates are in place to serve Alexa and Google Assistant.
Again, I’m not 100% sure so it is possible that I have some or even everything wrong.
Awesome! Google Home Assistant integration would be awesome. This would be really cool on google hub.
HLS has significantly more latency than RTSP.
Would love to be a beta tester for Google Assistant integration. Just ordered a couple of camera and looking forward to seeing this come to fruition. Until it does will have to checkout the IFTTT integration capabilities.
Would love to be able to see streams on my Home Hub.
Here’s how you can become a beta tester:
Thanks again. I greatly appreciate that you are responding at all, even if you’re not sure of all the details. (I wish the forum would actually let me know when you respond though … It does on some threads, but apparently not on this one.)
It’s true that RTMP is most commonly used for live-streaming video upload to a server, but an rtmp client can use it to fetch data too . This was commonly done in flash-based video players, I believe.
Also, Nest uses rtmp to serve the video data from their cloud to clients. NVR software like Blue Iris and Foggycam supports fetching data via rtmp urls to get the data, and can thus retrieve video from the Nest cloud. (As a minor detail, it’s actually rtmps:// in the case of Nest, but it would work just as well if it were rtmp://)
If you think the costs of having the camera listen on a port and act as an RTMP server might be acceptable, perhaps you can consider this as an alternative that could be supported in the main firmware, and see if enough people would be okay with it. I’d LOVE to see something that wasn’t only restricted to an alternative firmware.
The biggest problem that I see with our implementation of RTMP is that the camera is initiating the connection and not the other way around. Meaning, that this is not the client calling the device. Getting any client that is not controlled by Wyze is going to be near impossible for the moment and I don’t think that a lot of clients are able to just listen for an incoming RTMP connection.
I understand that this is less than ideal for the moment and we are trying to see how we can open up some of those options…
I’ve searched around and haven’t seen a direct answer to this, so I’ll ask it here:
Now that the Google Assistant integration is confirmed to be in development, do we know if this will require new hardware? Or is it only going to be pushed via a firmware update?
I am ready to press the button to buy a few more more v2’s and possibly a Pan, but I don’t want to if they won’t be compatible.
I know you have stated that most if not all of you are prior Amazon personnel. Are you still affiliated with Amazon and thus resistant to supporting a direct competitor?