AlarmDecoder to MQTT bridge created

[TD22057]

FYI - I was having a lot of problems getting the Alarm Decoder module in Home Assistant to work properly. Sensors would work, then not work for awhile, then work again. I believe this is because of inefficiencies in how the AD code base reads data from the network (bug filed here).

To fix this issue and give me more control over how the alarm system appears, I decided to write an Alarm Decoder -> MQTT bridge application. It uses the Python Alarm Decoder code and a few pieces from my Insteon->MQTT bridge package to convert all notifications to MQTT messages. This has the advantage (at least to me) that it's completely separate from HASS and by using the retain flag, the last sensor state of every device is always available. This means that restarting HASS doesn't lose any of the sensor information and everything just works. Devices in HASS are create through the discovery process so once things are configured in the script, nothing needs to be done in HASS (except organizing the front end display).

Docs are rough but there is enough there to figure it out if you're interested: https://github.com/TD22057/ad-mqtt

[mathewss]

I would love your input on the IoT firmware for MQTT integration and Home Assistant I have been tinkering with. It supports auto discovery and other cool things. Where do I send the AD2IoT appliance for testing and feedback

https://github.com/nutechsoftware/AlarmDecoder-IoT/tree/dev#mqtt-client-component

Best
Sean M.

[TD22057]

On one hand I'd love to help you but I don't really have time and AD+MQTT has solved all my problems. At least for me, the big advantage of MQTT + Home Assistant is that all the notifications and automations are done on the Home Assistant side so my motivation would be pretty low too.

[jcacavias]

I'm having this exact same issue. I ran the Alarm Decoder integration in home assistant for several years without issue. Once I moved to a larger home and added more integrations, this problem appeared.

I'm happy to test the IoT device/firmware, but will there be an official Alarm Decoder fix for this issue?

[TD22057]

Why don't you try out my MQTT bridge? I've been running it for a month or so and it's worked great.

[mathewss]

I believe the existing HA AlarmDecoder driver supports direct serial such as an AD2USB or AD2Serial or a remote device such as an AD2Pi appliance or AD2IoT. The device that receives the messages has to then decode and monitor all of the state changes from the AlarmDecoder protocol stream directly. If a problem exists when adding more devices maybe the HA system is overloaded or something else is going on but I do not see how it is an issue on the AD2* side unless maybe it is related to ser2sock?

Best
SM

[TD22057]

@mathewss - did you take a look at the bug report I filed in the first post? I believe the problem is that the AD python software reads one character at a time when the socket triggers. That's extremely inefficient. When it's run by itself it's not a problem but in Home Assistant (HA), that time is split with other processes. So in an unloaded HA, it never has a problem. But when HA is doing a lot of stuff, it falls behind and starts missing messages. It's hard to prove that because there isn't any logging messages that can be turned on to trace messages moving through the system but it's the one explanation that fits all the data. I included a link in that bug to software that reads as much data as possible whenever the socket trips which I believe would fix this issue. I didn't try and make a PR since it would be a rewrite of some low level code inside AD and I didn't want to spend my time on that unless I know it would be accepted.

[jcacavias]

@TD22057 - On my list of things to do, just haven't made it that far yet. I assume by using this code that HA will auto-create a new set of sensors via MQTT and that's what you're using for automation?

To the extent that it's helpful, I'm running the AD2PI software on a Pi that has nothing else on it (Home Assistant is hosted elsewhere). I've looked at the code as well and while I don't have a great understanding of the AD architecture, if the read method (as opposed to read_line) is being used, I could see how slowly writing characters to the network socket could get missed by HA.

If this truly is an HA issue, I'm happy to run that back up the HA flagpole with the devs to get it corrected, but it would be really helpful is someone more familiar with the AD code could ensure that AD is not the issue before I do that. I've looked at the HA code for the AD integration as well and it appears to be very simple, so I have a harder time believing that is the cause.

[TD22057]

There are really 3 layers involved with the bug I reported. The HASS core, the HASS AD add-on, and the AD Python library. The HASS AD add on does almost nothing - it's very small and doesn't do anything that would affect this. And the HASS code works fine for every other integration so it's very unlikely it's an issue in that. I'm 95%+ sure that the issue is in the AD Python library and is what I talked about in the bug. Reading 1 character at a time from any device/file/stream is hugely inefficient. It's a fairly simple fix to just not do that - read as many characters as you can from the socket when it has data available. Examples of doing that are in the links I put in the bug report.