I have 2 vdb duos that do not operate the same. 1 duo loads livestream without issue, the second duo begins loading upon opening then freezes at step 3 of the load. I have to do a restart to unfreeze it. Hoping for a fix, I set up an automation cycle for 3.a.m., 9a.m., 3p.m. and 9p.m. It did not work. The db continues to freeze unless I open it within a short period of time after the automation restart. I have reported this to support and have a log id: 1707182. The duos were in favorite groups so I removed the 1 that was the problem and the issue continued. The other doorbell was left in its favorite group because there are no issues with it. FW up-to-date with 1.0.24.11. I am using the v2 chime controllers and the transformer is 24v/40vac. Same one that worked for 2 v2’s and initially for the 2 duo’s. I cannot pinpoint when this issue began. Definitely not interested in setting up automation restarts for every hour on the hour and should not have to do so.
I’m hoping for a solution before involving support and requesting a replacement.
Sort of long shot but check your router/wifi access point and see if it has “universal beamforming” enabled, when the camera restarts it “grabs” the signal causing the router to focus more there, then gradually moves it away to more active devices. Overall I’ve found UB to be more harm than good.
Other than that it still sounds like a possible signal strength issue where for whatever reason it is stronger at first then possibly the cam goes into a lower power mode and it is no longer strong enough (I don’t have one so I can’t see if it is sending the power saving flag or not, but most things do support it).
Of course it could just be a dud camera but the fact that the automation runs tells me it isn’t totally locking up, just not getting enough bandwidth to load the stream. You can try loading it at 360P and see if it comes up then? That would almost certainly confirm a signal problem.
Thanks @dave27. Both duos were set at sd, and have 2 bars for wifi signal strength, Beamforming is enabled in the mesh. The only distinction I can see is that the duo with no issue is connected to the main router node and the problem duo is assigned to a satellite node which it is closest to. I don’t want to disable the beamforming for fear it may disrupt the performance of my other over 125 devices. What I can do is reassign the problem duo to the main router node to see it that improves or eliminates the issue. I’ll switch to 360p as a last resort. I should be able to report results within 24 hrs
UPDATE: Both duos are connected to the 5ghz band of the dual 2.4/5ghz band signal. Mesh assigns automatically. I do have a separate iot 2.4 network band but would reassign only if needed.
Today my Duo took a long time to connect. It has been OK up to this point and the battery is holding up longer than I expected. When it returned with unable to connect, the app started showing the welcome video. After I killed the video, the Duo started working again.
When you see the unexpected welcome video, you know the app has crashed and recovered. My take, this Duo firmware still has bugs.
Have not seen the welcome video since the update. Am frustrated over the load freezing. Both duos ordered and received at the same time, with SN’s in close # range. Another indication of production quality and testing inferiority.
Universal beamforming with 125 devices is doing nothing but causing you problems, can almost guarantee it.
Explicit beamforming can be beneficial, but hardly anything supports it.
It could be the 5ghz signal just is too weak at that spot, can try it on 2.4 for a while to see if that helps at all. If your main node is close enough that the doorbell can pick either one, that could be part of the problem too, too much overlap on a mesh setup causes instability, especially if it is one of the mesh setups that uses the same wifi channel for all nodes.
The node with the strongest wifi signal to the device is how the automatic assignment works based on the device’s capability. In this case it was the satellite node closest to the doorbell. I have switched the duo to the main router node and kept the 5ghz band along with the SD streaming. I can switch to 2.4 in that dual band without doing a network reconnect to my separate iot specific network. I have not had any real issues that I could point to UBF being a root cause and I’m into year 2 with it being enabled by default in my mesh. Interesting that this is the first time UBF has been addressed with any previous issues. Wyze cams and various brand smart plugs account for probably 75% of my smart wifi devices.
Time will tell in the next 24 hour restart cycle and later when I turn off all the restart automations. If the loading issues are resolved, it’ll point to the node switching as the solution. The signal strength remains at 2-bars for the duos on 5ghz and with the switch, both are about equal distance from the main node with about the same amount of wall obstructions.
Obviously can’t guarantee that beamforming is the problem but the symptom you describe of the camera working right after reboot then performance dropping off is a classic one. “Airtime fairness” is another one that can manifest like that sometimes, but usually that will come and go, so would probably be more sporadic than what you’re seeing.
With the typical home setup having just a few antennas, beamforming is pretty useless unless you only have a few devices and only one mainly active at a time. As you add more devices and spread them out in multiple directions, it becomes a hindrance rather than a help.
Some of the other features of mesh systems (band steering, forced roaming, etc) also can become problematic when the nodes overlap too much, but sounds like for the most part your other stuff has been working ok. They’ve gradually gotten better over the years at handling that, but since they rely on “hacks” essentially to do those things, there’s always potential for glitches to crop up.
When I set up a wifi router/AP, airtime fairness and universal beamforming are immediately disabled (along with various other tweaks depending on the environment and devices being served).
Another thing you may want to consider, if you are using a single subnet/VLAN for all those devices, the amount of broadcast traffic is pretty high. Devices with a weaker wifi signal and/or IOT devices with low end chipsets are going to be impacted by that. If you haven’t already, may want to consider dividing it up into multiple networks with a router between them. May or may not have any relation, it would be odd if one doorbell was struggling with it and the other wasn’t, but it could be a contributing factor along with something else.
Although my Duo is close to a mesh node, I still set it up on 2.4ghz band. I got burned with the floodlight pro. It, too is close to a node but the 5ghz connection sometimes failed. I moved it to 2.4ghz and it’s been stable ever since. Until the buggy firmware update messed it all up.
Moving the duo from a satellite node to the main mesh node appears to have fixed the freezing issue. All opening request for the doorbell are loading without the freeze. Next step is to disable all restart automations except the previous daily a.m. restart that covers both doorbells. 5gHz network and system UBF remain connected.
@dave27 - Another option/feature I have in my mesh is QoS (Quality of Service), where a device can be prioritized in the network and signal is focused to it. I thought about trying it but stayed with the node switch instead. If issues surface again, I’ll consider the QoS option.
Thanks for the input, especially on UBF. I am currently researching and reading everything I can find on the web concerning it. Main recommendation so far is to test both with it enabled and disabled. Seems to imply positive performance for 5gHz capable devices. Also a strong recommendation to separate 2.4 and 5 networks into separate bands which cannot be done with native dual band. Technically, I could by assigning all devices to my specific IoT network and all 5gHz enabled devices to the dual band, but then I would have to be concerned about overload and performance of the 2.4 IoT network.
For now, I think I have found the best path and solution.
To clarify, QoS won’t do anything for the signal, it can do some prioritization of bandwidth when there are limitations but a healthy network shouldn’t need it. The only time I’ve set it up for people is when they have pretty low upload bandwidth and need to prioritize work from home video calls etc, and even then it is a partial solution since you only control one end of the equation.
Note that often Beamforming on 5ghz is going to be Explicit Beamforming (also called AC or AX beamforming) so that may be what you’re seeing where they say positive results on 5ghz. There aren’t a lot of devices that support that, and typically not IOTs, so leaving that enabled generally is fine. But in reality, any beamforming on these routers with at most 4 antennas (typically less) is going to be pretty useless anyway, and as mentioned can do harm.
Generally I see very little issue with having the same SSID on both bands and allowing band steering (or device drivers) to choose the best. But given the number of devices you have, it might make sense to have both set up, a main SSID that can roam between both as needed, and then two band specific SSIDs so you can lock a device to one or the other as needed.
As I mentioned though, if you haven’t carved that network into subnets, you may want to start considering that. 125 devices constantly broadcasting ARP requests and responses is a lot of traffic for everything to handle.
I understand the QoS feature and prioritization and may have stated it incorrectly. Besides I did not see a benefit in my situation. I am broadcasting a dual band 2.4/5 on a specific ssid and unique IoT 2.4 on a different ssid. Not being a network tech, I presume the 2.4’s are ending up on the same bandwidth in the mesh router. My mesh does not allow me the option of setting up separate ssid 2.4 and 5 networks except for the separate 2.4 IoT ssid.
Regardless, today I was met with a major disappointment as the freezing returned. I moved the duo to 2.4 in the dual band nerwork but not the separate IoT 2.4, and disabled and enabled beamforming in all the combinations moving between 2.4 and 5 and different mesh nodes. What little success there was, was short-lived. A few hours later and I was bad to my issue. I thought about reinstalling the duo, but have decided on another option; uninstall and reinstall the Wyze app, but in between, turn off my phone completely for 10-15 mins. If this does not get results, then I’ll uninstall the doorbell and do a new setup.
Next step will be to pursue a replacement with the log id I created.
“I thought about reinstalling the duo, but have decided on another option; uninstall and reinstall the Wyze app, but in between, turn off my phone completely for 10-15 mins.”
This appears to have been the needed solution. Along with switching to 2.4 of the mesh dual band and moving the duos to the main mesh node with beamforming enabled. Instant livestreaming and no hangups.
