- Tue Oct 25, 2016 8:11 am
#57090
Just a thought Bugs, cos I don't know your circumstances - but if you are not already using Timer for other things, perhaps you could get your 2 nodes to have a slow game of ping/pong with each other using udpreply, Perhaps have them inititially 'serve' a 'RETRIES' ball to each other using udpwrite at bootup, then every specified timeout they would send the ball to each other using udpreply, Whenever either of them 'dropped the ball' they could start counting down from the specified RETRIES value, and if not receiving another RETRY update before reaching zero they could reboot themselves.
Moderator: Mmiscool
- Tue Oct 25, 2016 12:05 pm
#57095
Hmm ... that's a thought.
The two units are an IR receiver and a transmitter a couple of rooms away. Basically to control 3 media devices in the lounge from a remote control in the bedroom.
I am already using udp from the master to the slave and the master expects a udpreply to acknowledge every button press. I could possibly set a timer to send a dummy press every 10 seconds but without a ping function there is no way of telling which unit has lost its place so both would have to re-connect.
I would not normally want to reboot because of the time it takes.
Both units have a web page available so that I can reboot either from a browser on a mobile phone - provided they are still on the network.
Thanks for the suggestion.
The two units are an IR receiver and a transmitter a couple of rooms away. Basically to control 3 media devices in the lounge from a remote control in the bedroom.
I am already using udp from the master to the slave and the master expects a udpreply to acknowledge every button press. I could possibly set a timer to send a dummy press every 10 seconds but without a ping function there is no way of telling which unit has lost its place so both would have to re-connect.
I would not normally want to reboot because of the time it takes.
Both units have a web page available so that I can reboot either from a browser on a mobile phone - provided they are still on the network.
Thanks for the suggestion.
- Wed Oct 26, 2016 3:03 am
#57139
@Mmiscool: Yes, I could shorten up the code but I do use RV handle info back from the server upon a successful connection. Wouldn't need it otherwise.
@Electroguard: Yes, this is intended to be generic code. I was thinking about simply using REBOOT but I don't always know that I'll have autorun turned on. I test some nodes on one router before they go out in the field with a different router and IP settings, so I wanted the reconnect routine to function automatically, discerning when the alternate WIFI.CONNECT() syntax was necessary too.
I am intrigued by the use of UDP for a couple reasons: It is one way that I can develop logic to ascertain whether a server connection attempt failed due to server or internet connection issues versus router disconnection. Also, it gives me a way to slip a packet to another node that might connect to a router when the first one can't. I've toyed with this a little but I end up with a lot of code because it involves direct node to node connections that I have to manage somewhat intelligently. One more go-around and I'll either simplify it or have a functioning mesh network. Not sure which....
@Electroguard: Yes, this is intended to be generic code. I was thinking about simply using REBOOT but I don't always know that I'll have autorun turned on. I test some nodes on one router before they go out in the field with a different router and IP settings, so I wanted the reconnect routine to function automatically, discerning when the alternate WIFI.CONNECT() syntax was necessary too.
I am intrigued by the use of UDP for a couple reasons: It is one way that I can develop logic to ascertain whether a server connection attempt failed due to server or internet connection issues versus router disconnection. Also, it gives me a way to slip a packet to another node that might connect to a router when the first one can't. I've toyed with this a little but I end up with a lot of code because it involves direct node to node connections that I have to manage somewhat intelligently. One more go-around and I'll either simplify it or have a functioning mesh network. Not sure which....
