I have a Honeywell alarm panel with an AD2PI Network Appliance snuggled into it. That’s plugged into Ethernet, which is plugged into the same LAN my OH2 (on a different RPI) is. (The Network Appliance is just a Raspberry Pi with the AD2PI board and the right software. I’m going to call it an Appliance, even if you supplied your own Pi.)
The alarmdecoder binding says it will talk to Ethernet, and even has the default port (10000) listed.
I was never getting messages from the alarm. If I opened the AD2PI Appliance’s web page, I saw data being sent, but it never got to openhab.
Eventually, I figured out that I’d configured the AD2PI Appliance to use an SSL-encrypted channel for the serial output, and that the alarmdecoder binding wasn’t aware of this.
I could have removed the SSL security, but I wasn’t really happy with the idea of anyone on my network being able to mess with the alarm. You can get to my network via wifi, so someone could break that, find the alarm decoder, and shut the alarm off. Not a good idea. With SSL, they can’t connect to the port without the right cert.
Instead, I installed a local proxy to remove the SSL and let OH2 access the encrypted data. I did it all with things already installed on my RPI, and probably on most Linux distributions. This is “safe” because the proxy only listens to the localhost port on your OH2 machine. Well, safer. Safe enough, at least for me.
What we want to do is create a service that listens on a port and when that port is polled connects us to the RPI, but without that pesky SSL in the way.
Here’s how:
First, let’s listen on the port. We’ll ask systemd to do it for us. (If you don’t have systemd on your OH2 machine, I’m assuming you know enough to manage your own init script.)
As root or with sudo, create a file: /etc/systemd/system/addecoder.socket
Put this in it:
[Unit]
Description=The Alarm Decoder Decoder Socket
[Socket]
ListenStream=[::1]:9999
ListenStream=127.0.0.1:9999
Accept=true
MaxConnections=16
KeepAlive=1
FreeBind=1
[Install]
WantedBy=multi-user.target
That tells systemd to listen on port 9999 on both IPv6 and IPv4, and when a connection comes in it will automatically run a systemd service called addecoder@.service
So, we have to create that too. Create (as root or with sudo) /etc/systemd/system/addecoder@.service containing:
[Unit]
Description=The Alarm Decoder Decoder
After=network.target
[Service]
WorkingDirectory=/etc/addecoder
ExecStart=/bin/bash -c "/usr/bin/openssl s_client -CAfile AlarmDecoder\ CA.pem -cert AlarmDecoder\ Server.pem -k
ey AlarmDecoder\ Server.key -connect alarmdecoder.local:10000 2>/dev/null"
StandardInput=socket
StandardOutput=socket
RestartSec=30
Restart=always
Type=simple
[Install]
WantedBy=multi-user.target
The @ at the end of the name is important, and means this is a template definition. Your shell might make it hard to type.
The magic is in the command given in ExecStart. That uses the openssl command line tool to connect to the real alarm decoder port, using the proper certificates, and then routes it in and out of it’s standard in and standard out. Which we’ve hooked to a socket via our first systemd configuration.
That ExecStart needs to be all one line if it is broken up by the post here.
You may need to change the “alarmdecoder.local:10000” in the ExecStart line to be the name or IP address of where your ser2sock is running; mine is different than that.
What this does is to launch the openssl client, and have it do an SSL connection to your AD2PI that’s on the network with ser2sock - that’s what the Network Appliance is - and connects it to that socket we had the first systemd configuration open.
It won’t quite work yet: We need the SSL certificates and keys to be in the right place. I called that /etc/addecoder, so, as root:
mkdir /etc/addecoder
chown 0700 /etc/addecoder
Then, you’ll need the cert and key files that the AlarmDecoder apps created when they set themselves up. If you’re using the stock configuration, they’ll be on your Network Appliance in /etc/ser2sock/certs.
Connect to your AD2PI pi, and cd to /etc/ser2sock/certs, then scp AlarmDecoder CA.pem, AlarmDecoder Server.pem and AlarmDecoder Server.key back to your OH2 machine, and then get them into /etc/addecoder
You may have to scp them to /tmp, and then use sudo to mv them, as I had you tighten up the security on /etc/addecoder already.
Once all that is done, do these commands on your OH2 machine as root or with sudo:
systemctl daemon-reload
systemctl enable addecoder.socket
systemctl start addecoder.socket
Also, change your alarmdecoder.cfg to connect to:
connect=tcp:localhost:9999
Once that is done, you should be able to restart OH2 and your alarm decoder will work.
If not, look at the system logs with journalctl and see what they’re complaining about.
Good luck, and safe alarmdecoding.
EDIT: 28November2018 - something changed so that the original addecoder.socket was no longer valid. Remove the After= line, or make it match the updated one above to get it to install properly.