I was able to crack the "track state change while armed" nut over the last week, at least for RF devices, using a different approach. It turns out the Home Assistant binary_sensor in the alarmdecoder component was written to track all 8 bits in the AD RFX messages. While the main sensor state is linked to the Honeywell panel tracked by AD and doesn't change when the panel is armed home/stay, the sensor's attributes are updated every time a RFX message for the sensor is received. To track those, you make a sensor based on the relevant bit in the sensor's attributes.
For example, if the Honeywell panel is tracking the RF sensor on loop1, and the binary_sensor created by the alarmdecoder component in HA is:
- Code: Select all
binary_sensor.rear_door
you can create the following sensor to track RFX state changes of loop1 using templates:
- Code: Select all
#configuration.yaml
binary_sensor:
- platform: template
sensors:
rf_rear_door:
friendly_name: "RF Rear Door"
value_template: >-
{{ states.binary_sensor.rear_door.attributes.rf_loop1 }}
If you need the sensor to be in the reverse state, e.g., "true" when RF message is "false" and visa-versa, you accomplish that with:
- Code: Select all
{{not states.binary_sensor.rear_door.attributes.rf_loop1 }}
You can then trigger on state changes in the automatons from the new binary sensor this creates:
- Code: Select all
binary_sensor.rf_rear_door
The available attributes tied to a sensor in HA related to AD RFX messages are:
rf_supervised
rf_loop1
rf_loop4
rf_loop3
rf_bit0
rf_loop2
rf_low_battery
rf_bit3
This is pretty nice because you can also track other things like battery state in HA.
My approach at this point is to let the AD WebApp do all the tracking and notifying it can, and use HA to track the things the AD WebApp wasn't designed to see.
I've also just solved being able to track alarm key-fob presses, which are also not reported by the AD WebApp (or by ADT Pulse). These are trickier because a) they aren't reported by the Honeywell panel to AD, b) if a particular key on the fob isn't used, it isn't even programmed in the Honeywell panel and so isn't assigned a zone, and c) the fob only sends "true" when the key is pressed; there is no follow-up "false" so there is no state change for HA to track.
I managed to find the right spot in the HA binary_sensor alarmdecoder.py code to add in a "return state to false" 0.5sec after a fob key press. This lets you track the key presses using sensor attributes as per above. You can track all press combinations on the fob, including for loops and SNs that aren't even registered in the Honeywell panel. I'm no programmer, and at the moment it's a hardwired kludge for the SNs on my fobs, but I'll post it on the HA forums later this week for anyone that might find it useful.
I think you may be correct about the paint being dried on AD. Makes me think I'd better order backup hardware while it's still available because it really is the critical link between my security system and home automation. It is noted in the AD news section that they won a z-wave alliance award not too long ago. Perhaps they're working to link AD with z-wave (though HA does this), or are just off onto z-wave. AD is a great product. I only found HA because I wanted the z-wave link with AD. It will be interesting to see what develops.
.
