Unexpected AD benefit with RFX events

[trialnerror]

I have Alarmdecoder feeding into Home Assistant. I did this so Alarm events could control z-wave devices. A side benefit is that I can see my sensor RFX signals. I look at them so I can receive notifications when certain interior RF sensors trip while the panel is armed STAY, something the AD WebApp doesn't currently support.

Anyway, I noticed one of my sensors acting oddly. I use loop 1 and it's loop 2 was tripping, loop 1 also tripped when I operated the door it was attached to, but the loop 2 toggling behavior was inexplicable. The supervision bit was also toggling, and my sensor doesn't have a supervision setting (all its brothers in the house show supervision=false). At first I thought maybe it was a code bug, but there was another remote possibility - that there was another sensor in the area with the same SN. Since that remote possibility was easier for me to test, I did. I removed the sensor from my panel, pulled its battery, and captured the AD ser2sock output from a putty telnet connection for several hours. Sure enough, someone else in the area has a sensor with the same SN! Apparently the only reason we weren't setting off each other's alarms is because we're monitoring different loops. with 7 digits in the SN, there are 10,000,000 possible SNs. I also found over 380 unique SNs. Alarm salesman must have really made out when they passed through this area (I inherited from prior owner).

Troubleshooting this gremlin would have been impossible without AD's ability to see all RF sensors within range of the system's receiver. What a great product. Kudos to the developers as well as to whoever wrote the component for Home Assistant that talks to AD's ser2sock. With this kind of luck, I'm heading out to buy a lottery ticket right now.

[paul.aviles]

So did you win the lotto? LOL..

Having something similar I guess or not... On my keypad I have been seeing 0194323 Low Battery. I only have 3 wireless devices and none of the codes I have is that unit. If I get you correctly the AD will see all the wireless units close by?

In the log below, only 3 are mine, the rest are neighbor?

2/27/2018 11:15:06 PM !RFX:0573458,24 <-
2/27/2018 11:16:49 PM !RFX:0723198,04
2/27/2018 11:34:06 PM !RFX:0787944,04
2/27/2018 11:36:17 PM !RFX:0761989,14
2/27/2018 11:37:29 PM !RFX:0686499,04 <-
2/27/2018 11:58:31 PM !RFX:0107409,04 <-
2/27/2018 11:59:06 PM !RFX:0471803,80
2/27/2018 11:59:09 PM !RFX:0471803,00

If so, I think this may be a security loophole as my understanding was that the RF Keypad will encrypt the communication with the devices and will only talk to those that you enable with the system.

If that is not the case, then it will also imply someone may be able to perform then a DDOS against the wireless units as they are also talking/reporting to unregistered keypads.

I also have HA, what other values can you read from it? I have a fire/smoke wireless sensors and would love to be able to measure temperature in HA.

Thanks!

Paul

[trialnerror]

No lotto. Guess I used up my luck on duplicate sensor SNs. Typical .

I've seen the low battery indication you've mentioned too, but only on the AD WebApp keypad, not the alarm panel keypad. I infer from this that the alarm panel is only looking at my sensors. The AD WebApp may be looking at all reporting sensors when it displays that message, but I haven't looked at their code so can't say for sure.

I haven't come across anything that suggests the 5800 series RF sensors (what I use) are encrypted. I have an old set of bi-directional 5804 key-fobs and the manual mentions nothing about encryption for them. Those are in my cars and I've set the panel to only recognize their arm keys. I also have a newer set of 5834 fobs which offer both encrypted and unencrypted modes. My original 5881L receiver didn't support them in encryption mode. I upgraded it to the 5881enh (a drop in replacement that let me remove the old 5881L and 5800 series xmitter and gave me as many wireless zones as my panel can support) to get encrypting working with them.

I've collected data for a longer period of time and found over 530 'foreign' sensor transmitters within range. My transceiver is up in my attic and I've read it can have a range of up to a mile. That's a lot of sensors. I get one or two every few seconds showing up in the telnet session to AD. My guess is the alarm panel can handle a lot more than that before DOS becomes an issue. I've never seen any problems.

I think your panel only looks for SNs registered with it, and ignores all the others. The receiver doesn't know what SNs you have, so just sends all it sees to the panel. The duplicate SN is where I'd imagine problems can arise. I'm guessing when I removed my battery and my panel gave the tamper/check alert, someone else in my area got it too. In theory, setting off the loop that they use could trigger their alarm too (and visa versa). I'm assuming we used different loops because that didn't happen. I simply retired that senor and put in another one.

As for the HA implementation of alarmdecoder, it only looks at the AD ser2sock output. Since the panel itself only trips when a loop is triggered (true/false) transition, my guess is that's the only kind of data sensors and fobs send. I've got a few temperature sensors, but they trigger on threshold, e.g., above/below a set temperature. If you've got a newer pad, and newer sensors, it's possible that more data would show up on your panel. Whether AD would see that and decode it I don't know.

I also came across another oddity. My fobs seem to transmit true for the low-battery bit even with a fresh set of batteries. The alarm panel isn't reporting this as a low battery condition. For now I've set the HA battery sensor to consider rf_low_battery=T as a good battery, and a bad battery as F. Time will tell if that's correct.

[paul.aviles]

Sorry was referring to the 6160RF keypads. According to the documentation they support High Security Mode which only accepts encrypted devices, not sure though my wireless devices support that, but I can try enabling it to see what appears in the logs.

According to the link below, the RF distance for this panel should be around 200 feet. Not sure how you are getting that large range, sound insane
https://www.alarmgrid.com/documents/hon ... etup-guide


Also, I think I have seen the low bat on the keypad display itself, not sure though, you are making me doubt. According to the keypad doc here, they are supposed to show it. http://library.ademconet.com/MWT/fs2/61 ... -Guide.PDF

I guess *67 and *75 must be enabled for that to happen too.

[trialnerror]

My panels aren't RF, so my system needs that transciever to use 5800 series RF devices. Their range can be over a mile and I'm pretty sure they aren't encrypted. Encrypted fobs needed to be enrolled. Regular 5800 series sensors don't. Tech from the good old days.

https://www.slideshare.net/mobile/alarmgrid/honeywell-5800serieswirelesstechnicalspecifications

RF devices with low bat that are registered with a panel should show up on it. I just think the AD WebApp keypad temporarily displays low bat for other peoples sensors too. I usually only see a transient low bat message when first going into the app. I know my alarm panel isn't showing them, and RFX messages from my neighbors show they need to replace some batteries.

[paul.aviles]

Yeah, but something does not add up. AD is just a hardware interface, it has no radio.

The only way it will be able to show the Low Batt from a device 1 mile away is if one of the Keypad Panels can read them and somehow AD is displaying them. All the serials I get are not mine and are not registered so they should not appear.

[kevin]

The RF in the keypad or add-on to the panel do indeed listen to and see all of the rf sensors in your home and around your home. It only reacts to ones it knows. This is not something we are doing, this is just something we are exposing.