Heartbeats

[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! :smiley:

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.