search

maxwellhadley / node-red-contrib-rfxcom

node-RED nodes to access an RFXtrx433 transceiver
BSD 2-Clause "Simplified" License
22 stars 13 forks source link

X10 heartbeat #80

Closed Strixx76 closed 4 years ago

Strixx76 commented 4 years ago

Hi,

Would it be possible to add a function so that the rfx-detector-node output the heartbeats ? I would like to handle the "built in" silent check by myself in my flow, to get better controll of when the batteries are about to go flat.

maxwellhadley commented 4 years ago

The rfx-detector-out node already generates a Node-RED message if it receives a heartbeat packet with battery low status, if that is what you are looking for?

Strixx76 commented 4 years ago

No. I wish for all heartbeats to be passed on by rfx-detector-out, or an option to pass them.

That way I always can see when the sensor was last seen on the "front end". I have sensors where I sometimes misses one or two heartbeats (I could see this when I used Domoticz). And when these misses comes often, it usually means it is time to change the battery. So I had an "automation" in Domiticz that kept track of how often these single or double misses occured, and if they came to often I would get an notification about it.

maxwellhadley commented 4 years ago

If you miss a heartbeat transmission, you will get a message with a payload of 'Silent' with additional related information, including when the last transmission was received and the device status (including battery level) of the last transmission. The timeout period is 90 minutes for X10 detectors, and 20 minutes for Powercode detectors. I think you should be able to do what you describe with this?

Strixx76 commented 4 years ago

Well, I have looked at the "silent" messages, but they didn't make sense to me. But I will take a new look into them. And go about it the other way around then. But it will still mean I can't get a correct "last seen" value in the "front end" which is Home Assistant.

And then I am also considering what you wrote in issue #24 : "The list of sensors known to node-RED is not persisted across restarts or redeploys, so if a sensor should fall silent just after a restart, unfortunately you won't get a warning." But it will of course be possible to build a flow that check if no messages at all has been received from a sensor, and then notify. But then there is the possibility that a sensor is sending heartbeats but no other messages for a long period (motion sensor placed where no one normally walks) and then I will be notified that that sensor is off-line, when it's not.

maxwellhadley commented 4 years ago

This corner case was complicated by the existence of some Chinese 'X10 compatible' sensors which don't send heartbeat messages, but are otherwise indistinguishable from the genuine article. I'm trying hard to be compatible with everything!

If you want to keep track of the actual time of the last message, I will need to add the facility you suggest. I'll put it on the to-do list

Strixx76 commented 4 years ago

Well I haven't had the time yet to investigate the "silent" messages enough. And my mind is still set to the way I handled this in Domticz. So maybe I am going at it all the wrong way... But isn't my way the "safest" way? I know the addresses of all my nodes. And I can easily then check if they are alive (even if I have the bad luck and restart Node-Red at the same time a node goes dead) by checking the time since last heart beat was sent. And at the same time I can see in the front end at any time when the sensor last was heard from. The only other way I otherwise can get this function (as I can see it right now) is that I put a inject node that sends a messages to Home Assistant every 90 minutes unless there is a silent message. And this just seems very backwards to me. But, then again, maybe my mind set is stuck in "Domoticz-mode".. :-)

maxwellhadley commented 4 years ago

New version 2.9.0 published to npm including this option - please try it out!

Strixx76 commented 4 years ago

It seems to be working exactly as I want it to work. This will be perfect! Thanks for your work! And one more advantage with this feature is that I now get an "No motion" from my X10 PIR devices. Before I had to set them to "No motion" after a "Motion" was sent. Now I get a "Heartbeat" 10-15 seconds after the "Motion" message telling me it's back to normal.

But I have one questions. In the "Heart beat" message object there is a status.state attribute. I have seen 4 different values, that I have figured out to be the following: 1 = Normal (DOOR) 3 = Alarm (DOOR) 4 = Motion (PIR) 5 = No motion (PIR)

It seems to be the actual state of the sensor when the heartbeat is sen't. Is that correct?

maxwellhadley commented 4 years ago

The state code is indeed the detector state as contained in the heartbeat message. The state codes are listed in the SDK as:

0 = normal 1 = normal delayed 2 = alarm 3 = alarm delayed 4 = motion (PIR only) 5 = no motion (PIR only)

Obviously, the alarm & motion states can never appear in a "Heartbeat" message, as they would generate an "Alarm" or "Motion" message instead. If the tamper bit is set, 128 is added to each status code, but in that case you will get a message with payload "Tamper" instead of "Heartbeat" (This applies even if the underlying state is motion or alarm - Tamper has the highest priority, Heartbeat the lowest, even lower than Low Battery).

I don't know what "delayed" actually means, not having any of these sensors. Maybe something to do with exit zones?