Backup Router

[MichaelLachmann]

Hi - this is a really cool project.

How do you deal with hardware failures of repeater nodes? In this case you might loose an great number of sensors and controllers.

Would it be possible to add a second repeater in parallel as a backup in case one breaks?

Another thing I just find: Is it possible to create tree structures with the routers?

Kind regards,
Michael

[timmbogner]

Thanks Michael!

I guess I'd say that resilience is the main protection. In software, I think the best we can do in case of a failure is to reboot and resume as quickly as possible. The only thng that gets lost on reset is the list of registered ESP-NOW controllers. These are set to re-register periodically, so the loss of service should be brief. You can also set up a timed transmission of stats like battery and solar panel output.

From the hardware end... keep it well-powered with a solar panel with an 18650 battery, perhaps a nice big cap to ground if it's powered from a wall (never hurts either way).

Since you mentioned it I've been thinking up a scheme for a backup repeater and I think there is a way... The backup gateway would be configured identically to the main gateway, but it would wait in the setup() function while it pings the main gateway. If it stops receiving replies from the main gateway, the backup gateway will then move on to the loop() function and take over routing duties. @aviateur17 I don't think we have the ability for the user to ping from a gateway yet. Any idea if that will be tricky? There might also be issues with hanging between beginFDRS() and loopFDRS() and callbacks still running. This is only a preliminary idea.

There are ways to create a tree structure. There's not an ideal way, however:

Currently there are two configurable "neighbors" for each interface on a gateway. This allows traffic to be routed upstream or downstream based upon which gateway it was sent from. However, if you are at a gateway where data is changing between different protocols (example: a UART->ESP-NOW gateway), you actually could route data to both neighbors (from Serial to ESPNOW1 and ESPNOW2) creating two branches with identical data. It would be better to have three, which is what I hope to add soon.

In ESP-NOW, you can also use sendESPNow(0xNN); to route packets directly to a gateway that isn't a neighbor. This can be useful for some things, but it's limited.

[aviateur17]

Gateway pings should be pretty easy to code. All the code might be there already.

Probably would want to also add some code where the backup reboots to give priority back to primary if the primary starts responding.

[MichaelLachmann]

I was looking into the code already and I believe we could have four neighbors. That way we could easily create tree nodes with three clients and one uplink or even generate a router with two clients and two upstream nodes. I think when we send an ESP-NOW message to a kown target we would at least know it is available and received the message on network level. If not we could use the second upstream neighbor as backup.

Another thing I was thinking: The way we configure the nodes via codes is not so fine if you want to change the network. At the moment we would need to reprogram every single controller. What about a "reserved messages" which carry the neighbor numbers. The receiving instance (like a router or controller) could store and retrieve the neighbors from EEPROM instead of hardcoding them. Unfortunately it's not a solution for sensors ,,,,

[timmbogner]

Good call, four neighbors will be a good even number. I'm not sure about being able to switch between neighbors based on non-reception of a packet. That might work out in a future addition, and I'll keep it in mind. 
Your second point brings up a couple excellent concepts. We've discussed having the configurations saved in an EEPROM structure and configurable even after the user flashes the device. Then we could use built-in system packets to configure the gateway from another device with get/set commands. I've also thought about having the nodes broadcast a ping, then "pair" with the gateway that has the lowest ping. That would hopefully allow for changes to gateways without affecting nodes.