Sensor Bridge Redundancy/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.

It would be great if contact and motion sensors could be paired to more than one bridge. This would eliminate the bridge as a single point of failure and would also help reduce issues caused by a weak signal from the remote device.

1 Like

Scenario: I put a wyze motion sensor in car.
Purpose: If car is entered/broken into/stolen I get notified immediately.
Limitation: It only works when wyze camera(at home) is connected to sensor.
Architecture: I have a wyze camera in/near garage that has the sense bridge in it to communicate to the Wyze sensor in my car.
Problem: I want it to work at home and at cabin.
Issue: The sensor is married to a single camera, rather than any(multiple)wyze account cameras.

WorkAround: To get it to work at cabin, I have to have 2 motion sensors in car. One for home and one for cabin. Each sensor is married to a camera at that location(Home, Cabin).

Solution: Allow a wyze sensor to not be married to a given camera.

BIG PICTURE: It would be nice to be able to move sensors around your home and be able to attach to another wyze camera around your home without marrying it to a given camera/sense bridge.

1 Like

Yes I requested this feature when the Sense kit came out. Redundancy/backup… if one cam is offline or signal sucks it could hop to another. I have many cams with the bridge but only 1 is being used. The rest could be put to use but aren’t. Hope this is added in the future. Bridge polygamy. Spread the love around. I smell what your rock is cooking.

EDIT: oh wait, lol… this is the original request thread I posted, lmao.

1 Like