Sensor Bridge Failover

This is a scenario I keep running into:

The Wyze Cam that my Sensor Bridge is plugged into goes offline frequently. When this happens, it takes with it all of the sensors that were connected to it.

Meanwhile, I have a second cam nearby that also has a Sensor Bridge plugged into it. It is alive and well, ready to assume the duties of its fallen comrade.

In this case, the ability to assign a secondary/failover Bridge could save the day, bring the orphaned sensors back online. I don’t want to miss any opportunity to release the hounds.

I agree, I’m all about redundant systems with automatic failover.

Yeah, this.
The problem is, Wyze made a conscious choice to not do mesh like Zigbee or others.
The problem you describe is one of the many benefits of mesh.
With zigbee/mesh, the network will fix itself by having the children detect when their parent has had something go bad with it, or has died, and will go hunt for a new parent.
It is very unfortunate that they didn’t go with something like Zigbee… Granted, Zigbee can be harder to set up, but that is offset by the reliably you can get with mesh networking.
I hope their custom/proprietary protocol is extensible enough where they may be able to add in partial mesh support someday.

Note: I realize after reading this I basically just said what you just did, albeit far more wordy, lol. Sorry! But at least you were into something.

Well, in this sense, even without an actual wireless protocol of its own like Zigbee, I could imagine a pretty simple way to accomplish this. The cameras send a heartbeat out to the Wyze servers. It could be done at this level, or far better– locally.

The cameras should be able to talk to each other on the same LAN (discounting any firewall policies/AP isolation). The cameras would discover the IP addresses of all others on the network (the Wyze app knows what they are, obviously) and add it to their internal table of known peers. If the cameras sent out a heartbeat type “check-in” with the other cameras at some regular interval (simply just pinging them would even do the trick) and one goes unresponsive, that means it’s either not responding to network requests or the latency is so bad those pings time out.

In either case, we can assume that camera is having connectivity problems, and thus, if the camera has no wireless communication, neither does the bridge.

And yes- what I just described is exactly as you suggested - a mesh type network. You don’t necessarily need another protocol such as Zigbee to incorporate this type of thing as long as there is a communications medium otherwise, which there is. There may be certain benefits of that over the typical WiFi standards, but beggars can’t be choosers.

I can personally think of several ways right off the top of my head in which this could be implemented, so barring some unforeseen technicality, I believe it to be entirely possible to do this.

And if it’s not a mesh type, it could be a simple peer to peer between the camera defined as primary and the one as secondary. They just need to check in with each other at some interval to see if the other is still online. If not, then they take over.

This check would also have to be done by the sensors themselves too. If the bridge they’re reporting to goes down, they have no more wireless connection. They must also know “if I can’t contact my primary, then I need to talk to my secondary”.

Problem maybe becomes this - there would have to be a connection to both bridges or the ability to hot-switch since if the primary goes down, there’s no way for them to cry for help otherwise. They’d have to be paired with two devices in a sense, and I don’t know the technical workings of these to really continue with my suggestions. I had fun thinking it out. Maybe someone else can chime in and suggest how they think it would best be done. I’d definitely be interested.

P.S. this was all under the presumption that the Bridges communicate with the sensors via TCP/IP - until I re-read your post, I hadn’t considered that they would or could use some proprietary standard. Hmm. Would seem the most obvious to use existing WiFi standards with existing protocols, rather than reinvent the wheel, but that’s only my thought.