Heartbeats

[iLusion]

Thanks for such a wonderful platform.

I am trying out HA with My Sensors GW on RPi. My sensor node publish heartbeats at regular interval. How do I see the last heartbeat time in HA? Without this, there is no way to know if the node is alive. I have two nodes, which are offline and HA simply shows the last status, which is misleading.

Also, how do I configure HA to force process updates from nodes even if the new state is same as previous state?

[Boots33]

@iLusion Does Home Assistant now support heartbeats? On the controllers list it says not supported

[iLusion]

@Boots33 Duh! Should have read the comparison chart. Well, now search for another controller begins, unless any of the brilliant minds have any workarounds.

[martinhjelmare]

Hi!

Home assistant supports the heartbeat response message type but not heartbeat requests. Smartsleep is supported.

Sleep/awake state is not currently exposed.

Please describe a detailed use case and I can see if it's possible to implement something.

Home assistant shows the last known state of the device. If you have a sleeping actuator, using smartsleep, home assistant will send the last future state, that has been requested, to the device when the heartbeat comes in. Eg if a device has three states, and it's current state is 1, if the user first requests state 2 and then state 3, only state 3 will be sent to the device to actuate. Devices should always feedback any state updates to home assistant.

[martinhjelmare]

Regarding forced state updates that is used by default for all home assistant mysensors sensor platform types. Ie only pure sensor types, not binary sensors or actuators.

I think this is overridable by using customize and an entry for your entity and property name in the home assistant config. If that doesn't work, we can try to make it customizable.

[iLusion]

Thanks @martinhjelmare. My use case is as follows. I have nodes with binary sensors for door/window. These nodes send status information 1 or 0 upon events, say door opened or closed. They also send the heartbeat message at regular interval. I'd like to see the time when last heartbeat was received by the HA. This way, when I see the status of the Node in HA, I could determine if the Node is active or not. As of now, if the node crashed, I have no idea as HA simply shows the last status.

[dpressle]

@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.

[martinhjelmare]

@iLusion

I see the use case. I'll think about a solution.

[martinhjelmare]

@dpressle

As the heartbeat will change each update but state might not, the current last changed time is not enough.

Please stay on topic, and open a new thread if there are other issues.

[dpressle]

@martinhjelmare

1. Well it depends on the type of sensor you have, so its a partial solution for him, only he knows his sensors and if its helping him.
   I know that for me its good enough.
2. I think i was right on the topic with my message, the solution might be different but its the same basic problem.

But any way, @iLusion should answer this...

[martinhjelmare]

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.

[iLusion]

@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.

[dpressle]

@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
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]

@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!

Sending the same state over and over again won't be ideal. Here is why -

Assumptions

1. Node is not interrupt driven

Scenario

1. Loop 0 - Door closed, send state Door close as of T
2. Loop 1 - Door open, send state Door open as of T+1
3. 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.

[martinhjelmare]

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.

[iLusion]

@martinhjelmare

The NodeID could be the least common denominator here, I'd think.

[martinhjelmare]

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.

[koen01]

@martinhjelmare
Any new developments regarding this topic?

[martinhjelmare]

@koen01

No, but it's on my todo list. PR is also welcome.

[flyswiftly]

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.

[martinhjelmare]

@flyswiftly

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_id is available among the state attributes so that will be a help.

[flyswiftly]

Seems the node id would server that tracking need.

[martinhjelmare]

Yes, with some imagination, you could probably make a template that would match the correct criteria, and use eg for a notification.