Is there an inbuilt way to tell that a node is "off network" from the nodes perspective?
-
HI,
I have a node that is my central heating thermostat, does all sorts of nice to have stuff, in conjunction with the controller and other nodes.
In the event that the controller is completely off line, for what ever reason, it would be good to KNOW this from the nodes perspective, after all I still need the thermostat to perform it's basic function. I already make periodic receive requests, and can set my own flag based on this, but is there a MySensors internal library call I can make to retrieve the state of the transport system?Something like "isTransportuplinkOk()"
In the case that the node is offline, I should prefer to not keep sending and asking stuff for a period of time, and perhaps skip parts of code and perhaps display a much simpler screen, with setpoint and actual temperature only.
Many thanks in advance for your knowledge.
-
It's something I'm looking for as well
-
HI,
I have a node that is my central heating thermostat, does all sorts of nice to have stuff, in conjunction with the controller and other nodes.
In the event that the controller is completely off line, for what ever reason, it would be good to KNOW this from the nodes perspective, after all I still need the thermostat to perform it's basic function. I already make periodic receive requests, and can set my own flag based on this, but is there a MySensors internal library call I can make to retrieve the state of the transport system?Something like "isTransportuplinkOk()"
In the case that the node is offline, I should prefer to not keep sending and asking stuff for a period of time, and perhaps skip parts of code and perhaps display a much simpler screen, with setpoint and actual temperature only.
Many thanks in advance for your knowledge.
-
@Nigel31 could isTransportReady() give you the information you need? Or transportCheckUplink() if you need to trigger a new check.
@mfalkvidd
If I understand correctly, isTransportReady() relates to the transmitter (rfm69 in my case) and the setup / interfacing with the mcu, rather than the connection or lack thereof with the gateway / controller?transportCheckUplink() looks like it might do the trick, if I poll the check periodically.
I already check for ack's ( send(msg,true) ) as part of my coping mechanism for often failed coms , so I can use this to set a flag myself (say 3 failed sequential attempts ), I was wondering however if there is an inbuilt register / boolean responce from the library, where it keeps track of the connection, or lack of to the gateway. It seems to me that reading through things, that the library will re-ititialise finding a parent for example, subject to some seeming loss of coms. I was hoping I could simply tap into this, recovering this "coms / uplink" status, rather than "re-inventing the wheel". Space and memory isn't an issue for me in this instance, as I am using a Teensy as the MCU, so I can just add a bit more code, Just wondering if there was a way to "retrieve" the info that almost certainly exists within the library somewhere.
Many thanks for the thoughts.
Regards Nigel
-
@mfalkvidd
If I understand correctly, isTransportReady() relates to the transmitter (rfm69 in my case) and the setup / interfacing with the mcu, rather than the connection or lack thereof with the gateway / controller?transportCheckUplink() looks like it might do the trick, if I poll the check periodically.
I already check for ack's ( send(msg,true) ) as part of my coping mechanism for often failed coms , so I can use this to set a flag myself (say 3 failed sequential attempts ), I was wondering however if there is an inbuilt register / boolean responce from the library, where it keeps track of the connection, or lack of to the gateway. It seems to me that reading through things, that the library will re-ititialise finding a parent for example, subject to some seeming loss of coms. I was hoping I could simply tap into this, recovering this "coms / uplink" status, rather than "re-inventing the wheel". Space and memory isn't an issue for me in this instance, as I am using a Teensy as the MCU, so I can just add a bit more code, Just wondering if there was a way to "retrieve" the info that almost certainly exists within the library somewhere.
Many thanks for the thoughts.
Regards Nigel
@Nigel31 MySensors does not maintain a connection, so it is impossible to get the status of a connection.
All MySensors keeps track of if there have been any recent successful transmits (indicating that a connection was possible when the last message was sent) or if there have been recent failed transmits (indicating that no connection was possible).
-
@mfalkvidd
If I understand correctly, isTransportReady() relates to the transmitter (rfm69 in my case) and the setup / interfacing with the mcu, rather than the connection or lack thereof with the gateway / controller?transportCheckUplink() looks like it might do the trick, if I poll the check periodically.
I already check for ack's ( send(msg,true) ) as part of my coping mechanism for often failed coms , so I can use this to set a flag myself (say 3 failed sequential attempts ), I was wondering however if there is an inbuilt register / boolean responce from the library, where it keeps track of the connection, or lack of to the gateway. It seems to me that reading through things, that the library will re-ititialise finding a parent for example, subject to some seeming loss of coms. I was hoping I could simply tap into this, recovering this "coms / uplink" status, rather than "re-inventing the wheel". Space and memory isn't an issue for me in this instance, as I am using a Teensy as the MCU, so I can just add a bit more code, Just wondering if there was a way to "retrieve" the info that almost certainly exists within the library somewhere.
Many thanks for the thoughts.
Regards Nigel
-
@Nigel31 From my understanding you could send periodically a message with auto acknowledge request to the gateway and check in your node for this response. Then you know that the gateway is up and responsible.
-
@virtualmkr MySensors acknowledge only covers the first hop, so if repeaters are used the acknowledgement will only mean that the message reqched a repeater, not the gateway.
@mfalkvidd Yes, you are right. Acknowledge only checks the first hop. I mean the requestEcho parameter in the send function, see: API doc send().
bool send(MyMessage &msg, const bool requestEcho = false) -
I actually created a message queue for this. It will go on retry when it gets a didn't reach parent. So I know when the communication is gone. I'll add a communication up event to it. And I should be done. I won't know it it reaches the gateway. But I can add a visual indicator for when the repeater is out. That's sufficient for me.
-
I actually created a message queue for this. It will go on retry when it gets a didn't reach parent. So I know when the communication is gone. I'll add a communication up event to it. And I should be done. I won't know it it reaches the gateway. But I can add a visual indicator for when the repeater is out. That's sufficient for me.
