I have had my DSC alarm panel working with home assistant for years through alarmdecoder. It seems some time after the integration was switched to GUI only configuration, the binary sensors stopped changing state with the opening and closing of zones. The “Alarm Panel Display” will show “Secure System Before Arming <>” whenever a zone is opened. This proves that there is communication between my alarmdecoder and home assistant.
The messages being sent from alarmdecoder, as captured from the serial port are as follows…
zone 2 opened = !CRC:!EXP:00,02,01,0be1
zone 2 closed = !CRC:!EXP:00,02,00,38d0
I’ve run into the same issue. I’ve tried adding/removing the integration, restarting everything, changing the device symlinks (though I’m able to confirm through serial the device is communicating). Additionally from the Lovelace alarm panel I can arm/disarm the system with my pin however no sensors or the Alarm Panel Display sensor will show anything other than their default state of “unknown” or “closed”. Would appreciate any suggestions or if there’s just a bug that’s been introduced.
I discovered my issue that may be worth trying for others. I purchased my AD2USB device several years ago, however I had never updated the firmware. There have been several revisions of the firmware and after updating to the latest 2.8.8 I believe, and re-configuring (the firmware update erased my alarm settings), everything is working well. I can arm/disarm, read all sensors, and read the panel messages. Hope this helps others that ran into a similar issue!
Thanks for checking and reporting back. I too am running v2.2a.8.8 on my AD2PI, which seems to be the latest stable version. I’m running HA v2021.8.8 in Docker. Still no luck in getting zone changes to show in HA.
I had to configure the “Config Bits” on my AD2PI from c08e to the default of ff04. I don’t know how the config bits changed from the default, but my limited understanding is that this is what controls the format of the messages from the AD2PI that HA reads for zone state changes.
After changing the “Config Bits” back to the default of ff04, I noticed the zone state change message for zone 2 changed from:
!CRC:!EXP:00,02,01,0be1
to:
!EXP:00,02,01
Note the missing !CRC prefix and what looks like a checksum at the end of the message.
I find it takes 4-6 seconds for the zone status update. Documentation is vague on how to use RF Loop? Anyone has any idea how to make the response time quicker?
I ran into this problem lately. I tried a clean HA install w/ the latest version (this was in Dec 2021) and it worked perfectly. But when I added all my other integrations back in, then it would start failing again and the RF sensors would get stuck in incorrect states. This leads me to believe that as HA is more loaded, AD starts having errors. I looked at the alarmdecoder library and the network code it uses is (IMO) not very good. From what I could see, it only reads one character at a time from the socket which is very inefficient so I’m guessing that in a more loaded HA env, it’s falling behind and missing messages. Unfortunately there is no logging in the alarmdecoder library or in the alarmdecoder component so there is no way to tell where/why that’s happening.
As a test, I wrote an alarmdecoder->mqtt wrapper that reports state changes as MQTT sensors and I’ve been running that along side the built in alarmdecoder component. The mqtt version is always correct - the built in one is usually wrong. Whether this is because my network coding is better or because the mqtt conversion is done as a separate process (or both) I don’t know.
Sure: https://github.com/TD22057/ad-mqtt
It’s not that well tested yet and I didn’t build a fancy yaml config system for it. It uses MQTT discovery to auto-create all the sensors and alarm panel. It also creates a “last faulted” sensor in HA so there is a record of the zone that tripped the alarm (useful for notification automations). I’d like to rework how the attributes are managed but it get’s the job done so far.
To use it you’ll have to run it as a separate process somewhere and edit the run.py file to have all your zone definitions in them. If you don’t know the RF sensor ID’s, you can set the debug to screen flag on and then trip each zone to see the message come in w/ the sensor ID.
Just to clarify, the AlarmDecoder integration within Home Assistant can be removed, correct?
While running this, all that’s needed is the MQTT interface to capture the updates from your work?
My setup consists of the AlarmDecoder to Raspberry Pi board and so the only thing to add is to ensure that your script is a service so that everytime the Pi needs a restart, it will run itself again.