I have a somewhat unusual situation. I have x number of Raspberry Pis in a node group. The first Pi is designated as the parent pi. Its job is to alert the remaining Pis of an event that needs to take place, and the other children Pis report acknowledging receiving the messages over a websocket that the Parent Pi controls.
This works fine.
Edge case #1 if a Pi goes offline I retry to connect x number of times before sending an alert. This is working fine.
Edge case #2 If the master goes offline I need to somehow select another parent and create a new socket and I need to alert the other Pis to switch to that new socket. Since the socket is no longer available, communication between the Pis is non existent.
Each Pi is setup in the beginning to be either a parent and a child and stored in a collection, but not activated. The first Pi in the list is selected as the Parent, and all are activated correctly as parent and children.
It is only when the parent goes offline for 30 seconds that a new parent has to be selected, but since the socket is gone they cant communicate, so based on which one makes the switch first it is the parent, but none of the other Pis would know that a new parent is selected and try to create their own socket, which wont work.
So my question is what is the best way to handle this situation? I have tried several methods to try to determine which is the new Parent but they all come up with different choices creating a mess.
I greatly appreciate any suggestions you might have.
Thank you!
Do you use static or dynamic IP addresses?
In case of static IPs you can store a list of all IPs on each PI and define an order which they will try to connect to a new parent when the real one goes offline.
In case of dynamic IPs you can collect all client IP addresses on the master parent and send them to all clients with a note which one should be the new parent in case the master parent goes down. Something like a last will of the parent.
A third option would be using WebRTC which enables you to communicate between each Pi directly. But I think that would be too complicated just for a fallback plan.