The TL;DR is that we are chaining a lot of tech together and it is failing on us somewhere in that chain and we are having a hell of a time finding exactly where the problem is happening. The problem is specific to our implementation.
We are going from sensor → file for 4s block → RTMP → DASH → Google Display Decoding → Google Display Rendering.
The first two are in the camera, the next two are in the cloud, the next two are in the display. Problem is something is not happening properly in that overall chain.
We have been told that the issue was that the segment inside the files were coming out of sequences. We fixed that despite the fact that VLC was able to play our stream without any problem. Google said that they might have a super strict interpretation of the DASH protocol.
We have been told that we had an issue also with oAuth and that some of the failures to establish the connections were coming from that. We fixed that.
Google thought that the problem was coming from the packets were not coming fast enough and that the display was actualling resetting something and asking for new packets but after investigating further they found out that it was not a problem.
We have been told that the codec we were using was not the right one and was rejected by the player. We mentioned that it was working before so a change in the player might explain why it was not working anymore. But at the same time, we still have some success to streaming so that can’t be a codec issue. Google verified and acknowledge that the codec was not the issue but it was an unsupported one. We updated the codec to a supported version.
We have been told that resolution was an issue and that Chromecast was working properly because it is supporting 1080p and the problem of the caching was because the device was not able to handle the amount of information an could not render in time. I got yelled at in this forum because that is not the case and Chromecast is also showing some failures. I have communicated that information back.
We have created also some special version of the camera broadcasting 720p signal only and we are seeing also caching problems. So that has been communicated back excluding the possibility of a simple resolution problem also and we are waiting to get some feedback about those failures.
If it had been purely a resolution issue, then we would have to downscale the stream to 720p, which is creating also its own set of problems on our side because the only resolution we have out of the camera is 1080p.
Google has also started the work to improve the support of 1080p streams in the Google Nest Hubs. This could only help but we know it won’t solve the issue totally.
Google then mentioned that they have seen a pattern where a cold start to the streaming leads to more caching issues and asking to stream the same device again while it is caching tends to show more successes. But we are not sure what part is exactly impacted and I’m suspecting that this is something in the Wowza server.
More info I have just received is that the audio segment has a duration that is not right and that it might be fooling the system that the caching requirement is already fullfilled when it is not. The audio segment size is not the same during cold start vs hot start too, Something we will start investigating immediately.
I know that my list seems to put the blame on Google, this is not the case. It is a top priority for them as much as it is for us and they have one engineer that took the lead and is testing the different scenario mentioned above. We have two engineers on our side that are following up on any lead and trying to validate the hypothesis and make some of the changes recommended.
Wowza (receiving the RTMP traffic and encoding to DASH) has been a pretty big black box for us and their tech support was not helpful. The standard answer we got from them was: change the configuration, restart and see if that fixes the problem… No. It doesn’t we tried many times over.
Each of those steps went from a couple of days to several months of back and forth, between teams that are 15 hours apart with 2 different spoken languages in 5 different companies.
The doorbell does not support the voice assistant for remote viewing at this point. We are working on that but have no ETA yet and I’m (accent on I) not sure we can ever make it work.
We have two problems to address: the portrait mode instead of landscape and the non standard resolution.
@Frederik, not the answers we wanted to hear, but I appreciate the open communication. A lot of us here are probably geeks and it’s neat to see all that goes into what seems like a simple plug and play device.
Please don’t be discouraged by responses here. I’m personally not happy with the performance of what I bought, but as long as we keep getting meaningful updates on progress that’s all I can really ask for
@Frederik@UserCustomerGwen several clear and concise points to make, and they really need to be communicated to the top:
your products should not be advertised as “works with Google” because they don’t
I own many wyze cams, sensors, pre-ordered the doorbell, etc… but am rethinking all of this and considering tossing it all in the garbage because you simply cannot get the Google hub integration functioning… this is a key part of the larger system and to not funnel more effort into this massive issue could be your demise
we see you releasing new products constantly this part year (headphones, doorbell, wrist band, thermostat, etc): unless you fix your existing issues, your customers will lose faith in your ability to support your products… releasing new products while your existing ones don’t serve their intended purpose feels like a slap in the face
it’s been YEARS since the wyze cam / google hub integration “launched” yet it hasn’t reliably worked a day since… if your team can’t solve it, poach employees that have solved google integration issues from another wifi camera company
It is completely inappropriate for Wyze to be issuing statements from the lead on this issue saying that WebRTC is the fix and then to ALSO say(some months later) that Google doesn’t officially even support WebRTC. You may want to rethink your involvement on this forum. Let Gwen do the spinning to the customers. All you do is make us more confused and angrier.
I have a suggestion for you Fred. Hire an engineer from Nest or Kasa or Yi. They already know what needs to be done. Their cameras work. Nobody cares to read your 10000 word essays on why Wyze continues to mislead.
I would seriously consider sending that back. Get a Nest Hello. They are more expensive, but they actually work. I have 4 displays throughout the house and when someone rings the doorbell, all 4 immediately stream the camera feed and announce who is at the door(by name if they have been at my house before).
I don’t have to find my phone, unlock it, open the Wyze app, then click on the doorbell to see who is there. And according to ole Freddy Badnews, it doesn’t appear that you will ever be able to see who is at the door without your phone.
I just cancelled my order for the doorbell. Unfortunate that this hasn’t been solved after years of being promised it would work. I know Nest cams and Nest doorbells are more expensive, but they work flawlessly with Google assistant (obviously). Sometimes you have to pay the price for quality products. If Wyze would focus their engineering efforts on this problem instead of building new products (that also won’t work with Google), that effort would return larger business gains in the end.
@Frederik I have some interesting observations I thought I would share. I’m not sure if it has been mentioned before since this thread is super long or if it will be helpful at all but here goes:
Today after seeing some discussion about the google assistant integration I figured I would retest streaming to my google home hub to see if it was working. First I tried my two WCO cameras running firmware 4.17.0.181/base 4.16.0.183. Both streamed successfully but it took a farly long time to load and would sometimes re-buffer after loading. Next I tried a V2 running 4.9.6.199, it would not load even if I decreased the resolution to 360p.
I though about what was different between the WCO’s, The V2 and the Hub connection wise and the only things that stuck out was that the WCO’s connect via wire to the router.
My single router (TP-Link Archer C9 V1) is outputting 4 SSID’s: Regular 2.4/5 Ghz and Guest 2.4/5Ghz. The google hub was connected to regular 5 Ghz and the V2 was connected to 2.4 Guest.
What I found out was that the V2 will ONLY successfully connect and stream to the google hub IF the google hub is also on either the 2.4 or 5 ghz GUEST network. The V2 will NOT stream to the google hub if the hub is connected to either the 2.4/5ghz regular network. The connection to the V2 when it works is still fairly slow and does re-buffer but it does seem to work. The WCO camera’s appear to be able to stream to the hub regardless of which SSID the hub is connected to.
Perhaps anyone reading this with a similar setup and similar problems can also test this theory.
I definitely understand the frustrations since I’m in the same boat and patiently waiting for a functioning Google home integration before I buy into the full Wyze eco system.
Has anyone ever possibly considered the idea that Google is the one being stubborn on integrating Wyze cams. I can assure you that Google would lose money on Nest cams if Wyze was fully functioning. At $20… It’s a no brainer as THE camera to buy over the competition.
Sidenote: I’ve seen 2 YouTube reviews of the v3 can and they seemed to work just fine on a Google home hub even though it took about 7 seconds to load.
Yes that idea has been tossed around in several threads before and there is probably some truth to it. But in the end, these devices are listed as “works with Google Assistant” and they do not work 99.9999% of the time for the very important case of displaying a Wyze cam to a Google/Nest Hub display. Years ago when I purchased several Wyze cams and the Google Hub display, it was with the thought that “ok so maybe it doesn’t work right now, but they’ll figure this out soon… no worries” but here we are years later and it’s still a no-go.
If they cannot solve this integration, their products are almost useless to me and I know I’m not alone.
I was able to load a V2 stream to a google hub last night around 7 out of 10 times after making some changes. It’s certainly not 100% and when it works it is pretty slow to load but some users are able to get it to work.
It would be incredibly helpful to share what changes you made. What version is your firmware on the cam? What was the resolution of the cam when it worked? Etc etc etc.
Just want to step in here and say I appreciate how incredibly transparent you are being here.
I see a lot of hate being thrown around and the fact that there’s a technical person (not customer support) answering these questions in the forum with remarkable directness is very refreshing.
Please stop being so dismissive to someone who’s actively working to fix the technical issues with the product and is clearly frustrated that it isn’t working.
I imagine there is zero discussion between this person and the marketing team that designs the boxes and branding.
Save your breath, these kids, or far from mature adults, could care less about empathizing with anyone they consider ‘responsible’ for ruining their lives due to not being able to voice control their $20 camera. For this reason or that, it all boils down to a ‘me me me’ attitude, assumptions that everyone in the world suffers the same issue as they do and stands behind them, and they could care less to read or learn anything if it contradicts the war path they feel entitled to. Watch, here come the self-righteous & smug responses, I can hardly wait lol
Wow JD2005 you certainly are the little [MOD EDIT]. You just love to come in here and throw gasoline on the fire. Didn’t your mom ever teach you, “If you can’t say anything nice, then don’t say it”. People are allowed to voice their opinion, just like you. Go find something productive to do and let it go dude.