Not receiving X10_DOOR messages on return from 'Alarm' to 'Normal'

[rholmesa]

Hi Max. Currently building a new RPi /Node-Red/RFXCOM for non critical alarms in my house.

I have the latest software, having built all from from scratch this week. I have set up an RFXTRX transceiver (latest firmware v243 ext) which is communicating nicely in most instances.

I have x10 security devices (Marmitek DS90) detecting the opening of the Garage doors, front and back. The OPENING of the doors works fine, however no signal is recognised when the doors are closed. The LEDs on the devices are showing that transmissions are taking place on opening AND closing, so I don't believe it is the devices.

This would be a status of 'Alarm' is correctly detected and reported, but a return to 'Normal' never appears. I use a debug node to detect the raw input and send it to the debug in the node-red side panel. 'Alarm' always appears, but never 'Normal'. This is true for all the DS90's.

The necessary 'Normal' status can be seen when RFXMGR is used with the RFXTRX.

Is this a set-up problem, or is there something not quite right with the rfxcom nodes?

Thanks Ron Holmes

[maxwellhadley]

It seems I designed it that way! The sensor message with a status of normal is received from the RFXtrx & passed through the node-rfxcom library to node-red-contrib-rfxcom, but the rfx-detector-in node doesn't do anything with it...

I didn't have any of these devices when I was developing the package (and I still don't) so it was a bit difficult to decide what to do. Now you have described the problem, and I can see that only door/window type sensors ever send the normal status, it seems pretty obvious that normal means the door/window is in the normal, closed state. However, these sensors send a repeat message every 90 minutes or so, with the current state, to check they haven't been nefariously disabled. If I handle the normal status in the simplest way, you will get a node-red message with payload normal every time the repeat arrives. Is this OK? Otherwise I could remember the last message status for each sensor, and only send a node-red message if the status has changed.

Any thoughts?

[rholmesa]

Hi Max,

I would prefer to receive the regular messages. It is confirmation that devices are working, and batteries have not died.

I guess it could be included as part of the node set up if others disagree. Allowing users to receive ALL messages as I would like, or just when it changes as per your other suggestion.

Thanks for the prompt reply by the way, the nodes are central to my system.

Do you have the old RFXLAN device on your future plans? I found that useful also.

Regards Ron Holmes

Sent from my iPad

On 24 Oct 2017, at 17:39, Max Hadley notifications@github.com wrote:

It seems I designed it that way! The sensor message with a status of normal is received from the RFXtrx & passed through the node-rfxcom library to node-red-contrib-rfxcom, but the rfx-detector-in node doesn't do anything with it...

I didn't have any of these devices when I was developing the package (and I still don't) so it was a bit difficult to decide what to do. Now you have described the problem, and I can see that only door/window type sensors ever send the normal status, it seems pretty obvious that normal means the door/window is in the normal, closed state. However, these sensors send a repeat message every 90 minutes or so, with the current state, to check they haven't been nefariously disabled. If I handle the normal status in the simplest way, you will get a node-red message with payload normal every time the repeat arrives. Is this OK? Otherwise I could remember the last message status for each sensor, and only send a node-red message if the status has changed.

Any thoughts?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[maxwellhadley]

Ron,

To clear up a misunderstanding - the rfx-detector-in node does handle the regular device messages: for device types that are known to send regular messages, if one fails to arrive within the scheduled time (which is the sensor repeat time plus a safety margin), you will get a node-red message with a payload of Silent (along with other properties including lastMessageStatus = what the status last received from the device was, and lastHeardFrom = when this was received). This message will repeat at intervals of the scheduled time until the device re-appears. The scheduled time is 90 minutes for the X10-type sensors, and 20 minutes for the Powercode sensors: the other sensor types don't send these 'heartbeat' messages.

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.

I wasn't planning to do anything with the old RFXLAN units - thy don't seem to be available any more & I haven't got any documentation for them. There also seems to be - possibly - an 868MHz variant in the works, as one or two of the documented protocols are specific to 868MHz devices (these are currently not supported in the node-rfxcom library because I cannot test them!)

I will modify the node, when I get some spare time, so you will receive a Normal message once when the sensor changes from any other state (or when it is first heard from after a node-RED restart). Hopefully this will meet your needs, if you modify your flow to handle the Silent messages appropriately.

Max

[rholmesa]

Hi Max,

Thanks again. Yes I have seen the ‘Silent’ messages a couple of times so I agree if one goes offline I would know about it (e.g. flat battery). Thanks for clarifying that.

Receipt of the ‘normal’ message would be very advantageous to me, and would give some form of persistence across reboots. I guess if others don’t want to use it they could just ignore it?

I woke one morning to find the garage doors were open. Checking the logs I found they had been opened at about 5.30am. After that - I used the ‘Alarm’ setting to advise when the door opened (rings a doorbell) AND turn the lights on in the garage. I used the return to ‘Normal’ to switch the lights off. I now have a separate standard burglar alarm also, but kept the original set-up as it had proved extremely useful.

As for the RFXLAN – yes I realised it is no longer available, and even that there is no support on the RFXCOM site. I will find another way of extending range I’m sure (stone properties are very good at blocking signals!!). Thanks for your thoughts on it anyway.

I look forward to hearing from you.

Regards Ron

Sent from Mail for Windows 10

From: Max Hadley Sent: 25 October 2017 09:33 To: maxwellhadley/node-red-contrib-rfxcom Cc: rholmesa; Author Subject: Re: [maxwellhadley/node-red-contrib-rfxcom] Not receiving X10_DOORmessages on return from 'Alarm' to 'Normal' (#24)

Ron, To clear up a misunderstanding - the rfx-detector-in node does handle the regular device messages: for device types that are known to send regular messages, if one fails to arrive within the scheduled time (which is the sensor repeat time plus a safety margin), you will get a node-red message with a payload of Silent (along with other properties including lastMessageStatus = what the status last received from the device was, and lastHeardFrom = when this was received). This message will repeat at intervals of the scheduled time until the device re-appears. The scheduled time is 90 minutes for the X10-type sensors, and 20 minutes for the Powercode sensors: the other sensor types don't send these 'heartbeat' messages. 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. I wasn't planning to do anything with the old RFXLAN units - thy don't seem to be available any more & I haven't got any documentation for them. There also seems to be - possibly - an 868MHz variant in the works, as one or two of the documented protocols are specific to 868MHz devices (these are currently not supported in the node-rfxcom library because I cannot test them!) I will modify the node, when I get some spare time, so you will receive a Normal message once when the sensor changes from any other state (or when it is first heard from after a node-RED restart). Hopefully this will meet your needs, if you modify your flow to handle the Silent messages appropriately. Max — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[maxwellhadley]

Ron,

Is this the sensor you are using? https://www.uk-automation.co.uk/marmitek-door-or-window-sensor-for-security-systems-ds90-ds91/ When you receive an 'Alarm' message, what does the topic look like? I'm now thinking of fitting one to my garage!

Max

[maxwellhadley]

As for the RFXLAN – yes I realised it is no longer available, and even that there is no support on the RFXCOM site. I will find another way of extending range I’m sure (stone properties are very good at blocking signals!!). Thanks for your thoughts on it anyway.

Maybe you could use one of the various gadgets that extend USB over CAT5 wiring, to relocate your RFXtrx433? They are cheap enough. I use one here to remote connect a USB audio device.

[maxwellhadley]

This should now be fixed: please update to version 2.1.1