Heartbeats

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?

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.

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.

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

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.

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

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.

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.

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.

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

Thanks @electrik for the update
I got it running.
However I think I should make some work on the sensors.
As it seems the Ethernet GW are running 2.1.1 but I think the sensors are running 1.5.x (seen in MysController)
But I get plenty of :
2020-05-28 19:29:47 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:30:22 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:30:57 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:31:32 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:32:07 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:33:17 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:33:51 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:34:26 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:35:01 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:35:36 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:36:11 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:36:46 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:37:21 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:38:31 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:39:06 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:39:41 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
2020-05-28 19:40:50 WARNING (MainThread) [mysensors] Not a valid message: value must be float between 0.0 and 100.0 for dictionary value @ data['payload']
Trying to get my dev environment correct to be able to recompile.
EDIT: Since it have been so stable for a long time I am not up to date with the Arduino environment. My experience from the past is not without issues

@Joerideman said in home Assistant and OTA support and node to node:
@MatiasV BTW why did you switch to mqtt? The wifi GW accepts multiple connections.
I was experiencing problems when starting the HA "server" (AKA Old laptop) and GW, or while the WIFI was temporary off for any cause. We had some rough weeks with our electricity company.
The GW would disconnect from HA and I had to restart the GW or sometimes even HA to get it working again.
It was a mayor headache while I was out of the house, the MQTT GW is way more reliable for me.

@electrik
Thanks, I'll have a look at those updates.
Do you mean the code I am using for my appdaemon app? I got everything I use from here: https://github.com/eifinger/appdaemon-scripts
This is much cleaner and easier to understand than my code, but let me know if you want it anyway