Heartbeats
-
@iLusion You can see the last update in the node details, for example i have temp node and i can see when it last updated HA:
I hope it helps.
BTW: i do agree that it is annoying that nodes that no longer exists but was issued a node id by the gateway will stay forever in HA until you change that in the GW or assigning this ID to another node.
I was referring to this, which is not connected to heartbeats.
@dpressle said:
BTW: i do agree that it is annoying that nodes that no longer exists but was issued a node id by the gateway will stay forever in HA until you change that in the GW or assigning this ID to another node.
-
I was referring to this, which is not connected to heartbeats.
@dpressle said:
BTW: i do agree that it is annoying that nodes that no longer exists but was issued a node id by the gateway will stay forever in HA until you change that in the GW or assigning this ID to another node.
@martinhjelmare @dpressle Thanks guys for keeping the thread active.
The last time stamp of state change is not sufficient, e.g. The node status in HA shows as door closed as of T days ago but the node may have crashed at T+1 and door may have opened after that.
The force update of binary sensors may partially solve this but not really a good alternative as if HA processed force updates, information would be lost about when exactly the state had changed.
If HA shows last time stamp of Heartbeat then we could deterministically display the last status time stamp as well as last known state of the node itself. This needs to be configurable for nodes which do not generate heartbeats.
-
@martinhjelmare @dpressle Thanks guys for keeping the thread active.
The last time stamp of state change is not sufficient, e.g. The node status in HA shows as door closed as of T days ago but the node may have crashed at T+1 and door may have opened after that.
The force update of binary sensors may partially solve this but not really a good alternative as if HA processed force updates, information would be lost about when exactly the state had changed.
If HA shows last time stamp of Heartbeat then we could deterministically display the last status time stamp as well as last known state of the node itself. This needs to be configurable for nodes which do not generate heartbeats.
@iLusion i am just trying to help here so i hope no one is med about me for saying what i have to say and where i have to say it :smiley:
So i am thinking out load here, if you want to send heartbeat and assuming your node is time sleeping (not interrupt) otherwise how would you send heartbeat right? why dont you send your current status (even if its not changed) so HA will be updated as i suggested before.I mean , unless i missed something here, whats the difference between heartbeat and sending the status??? they both use radio and node needs to be awake...
-
@iLusion i am just trying to help here so i hope no one is med about me for saying what i have to say and where i have to say it :smiley:
So i am thinking out load here, if you want to send heartbeat and assuming your node is time sleeping (not interrupt) otherwise how would you send heartbeat right? why dont you send your current status (even if its not changed) so HA will be updated as i suggested before.I mean , unless i missed something here, whats the difference between heartbeat and sending the status??? they both use radio and node needs to be awake...
@dpressle ofcourse! I appreciate your help and I am sure, so does anyone who'd benefit from this thread. This is the power of open source and community supported projects! :smiley:
Sending the same state over and over again won't be ideal. Here is why -
Assumptions
- Node is not interrupt driven
Scenario
- Loop 0 - Door closed, send state Door close as of T
- Loop 1 - Door open, send state Door open as of T+1
- Loop 2 - Door open, send state Door open as of T+2
Now, the door was actually, open at T+1, if HA processes, force updates then HA would show that door is open as of T+2 - We cannot now determine that the door was actually open since T+1 as oppose to T+2.
Hope this helps.
-
I think forced updates should only be used for pure sensor types. Using it for binary sensors is not a good solution, as mentioned.
The built in last changed time report in home assistant is only applied when the state is changed, so will not come in play in cases when the state is not changed even though a device sent an update. Using forced updates circumvents this, but as said is not a good solution in all cases.
We could report heartbeats as a regular sensor value which could then be checked in an automation/script. A problem might be what sensor ID to use, cause the heartbeat is for the node, not only for a sensor. I'll think about this.
-
I think forced updates should only be used for pure sensor types. Using it for binary sensors is not a good solution, as mentioned.
The built in last changed time report in home assistant is only applied when the state is changed, so will not come in play in cases when the state is not changed even though a device sent an update. Using forced updates circumvents this, but as said is not a good solution in all cases.
We could report heartbeats as a regular sensor value which could then be checked in an automation/script. A problem might be what sensor ID to use, cause the heartbeat is for the node, not only for a sensor. I'll think about this.
The NodeID could be the least common denominator here, I'd think.
-
No, each entity needs node and child ID. Another option would be to report heartbeat as a state attribute for all children of a node. But I have to look into how that would affect last changed/updated time stamps and if there's a difference between state and state attributes in this context.
-
@martinhjelmare
Any new developments regarding this topic?No, but it's on my todo list. PR is also welcome.
-
I wonder if a 'virtual child' of the sensor might be a solution? Just define a second child of the node that periodically sends the opposite status. It would simply be defined in the sketch on the sensor, not tied to actual hardware. First interval, it sends 'true' or 'open' or 1, next interval it sends 'false' or 'closed' or 0. Since it's programmed to change every interval, looking at the last update of the virtual child will let you know the sensor is functional or not.
-
I wonder if a 'virtual child' of the sensor might be a solution? Just define a second child of the node that periodically sends the opposite status. It would simply be defined in the sketch on the sensor, not tied to actual hardware. First interval, it sends 'true' or 'open' or 1, next interval it sends 'false' or 'closed' or 0. Since it's programmed to change every interval, looking at the last update of the virtual child will let you know the sensor is functional or not.
Yes, this is already possible today. Downside is that the user has to keep track of what other sensors (entities) this information applies to. The
node_idis available among the state attributes so that will be a help. -
Seems the node id would server that tracking need.
-
Yes, with some imagination, you could probably make a template that would match the correct criteria, and use eg for a notification.
