Adding internal messages I_HEARTRATE_REQUEST and I_HEARTRATE_RESPONSE
-
Hello everyone.
Now that the heartbeat concept is embebbed in mysensors core, what do you think about adding two variables, I_HEARTBEAT_REQUEST and I_HEARTBEAT_RESPONSE?The way I intend to use them explained below:
I_HEARTBEAT_REQUEST: When a new or already existing node boots up, it sends this message expecting a I_HEARTBEAT_RESPOSE from the controller with a number as payload. This number represents the frequency in minutes at which the node should send a I_HEARTBEAT_RESPONSE to the controller. A '0' as payload means auto-heartbeat feature disabled. Heartbeat should be answered only if explicit I_HEARTBEAT message receive at the node.
We should add at the core of MySensors, maybe at process(), a method checking if the time since last heartbeat response has exceed the defined HEARTRATE.
With this feature, the node will handle the hearbeat on its own. The controller will not need to send I_HEARTBEAT_REQUEST periodically to everynode to check it's status and new nodes will get HEARTBEAT configuration as soon as they bootup.
Let me know what you think.
-
This concept would only work on nodes that are awake all the time. Sleeping nodes doesn't have any knowledge of passed time when waking up from pin interrupts.
Hi @hek. I get what you mean, but nevertheless it may be intereting having this feature for non-sleeping nodes, such as those nodes monitoring motion for a security system or many other critical examples.
Don't get me wrong. I know this could also be achieved with the actual mysensors library and some rules in the controller side but it would be nice to have this extra feature.
-
Hello everyone.
Now that the heartbeat concept is embebbed in mysensors core, what do you think about adding two variables, I_HEARTBEAT_REQUEST and I_HEARTBEAT_RESPONSE?The way I intend to use them explained below:
I_HEARTBEAT_REQUEST: When a new or already existing node boots up, it sends this message expecting a I_HEARTBEAT_RESPOSE from the controller with a number as payload. This number represents the frequency in minutes at which the node should send a I_HEARTBEAT_RESPONSE to the controller. A '0' as payload means auto-heartbeat feature disabled. Heartbeat should be answered only if explicit I_HEARTBEAT message receive at the node.
We should add at the core of MySensors, maybe at process(), a method checking if the time since last heartbeat response has exceed the defined HEARTRATE.
With this feature, the node will handle the hearbeat on its own. The controller will not need to send I_HEARTBEAT_REQUEST periodically to everynode to check it's status and new nodes will get HEARTBEAT configuration as soon as they bootup.
Let me know what you think.
@gonzalonal said:
With this feature, the node will handle the hearbeat on its own. The controller will not need to send I_HEARTBEAT_REQUEST periodically to everynode to check it's status and new nodes will get HEARTBEAT configuration as soon as they bootup.
I'm trying to wrap my head around your idea - what is the advantage of your suggestion over controller-driven heartbeat requests? For example, what shall happen if a node does not send an expected heartbeat? I assume the controller will try to contact the node by sending a heartbeat request and flag it if no response is received...
IMHO, this adds complexity with no additional benefit. Also, due to limited HW resources, we better shift the network "sanity" logic to the more powerful controller. -
@gonzalonal said:
With this feature, the node will handle the hearbeat on its own. The controller will not need to send I_HEARTBEAT_REQUEST periodically to everynode to check it's status and new nodes will get HEARTBEAT configuration as soon as they bootup.
I'm trying to wrap my head around your idea - what is the advantage of your suggestion over controller-driven heartbeat requests? For example, what shall happen if a node does not send an expected heartbeat? I assume the controller will try to contact the node by sending a heartbeat request and flag it if no response is received...
IMHO, this adds complexity with no additional benefit. Also, due to limited HW resources, we better shift the network "sanity" logic to the more powerful controller.Hi @tekka.
I appreaciate your answer and share your opinion.
Lets focus our efforts in other topics.
