Making a 31 year old burglar alarm smart!

I thought I’d write up my recent project to integrate an Optima 2 Plus burglar alarm into Home Assistant as it may be of interest to others with unconnected devices with data ports. The alarm has performed flawlessly for 31 years so I wanted to keep it but didn’t want to go down the Konnected route as I would lose use of the remote keypad.

My plan was to see if I could reverse engineer the communications protocol between the main panel and the remote keypad and then use a D1 mini to send and receive messages to control the alarm.

There were six connections to the remote keypad of which two were power, two were a tamper circuit and two were data. I started by checking the voltage on the two data lines and one was 5 volts and the other around 0.2 volts so I knew I was safe to connect a logic analyser. I used one of these (£8.90) along with this software. All I needed to do was connect the two keypad data connections to two of the 8 available channels on the analyser plus a ground line and press a few keys on the alarm keypad to generate some traffic.

In pulse view I could see that one data line was held high and dropped to 0 volts as data was transmitted and the other data line was a mirror image from 0 volts up to 5 volts. This suggested that the interface was using RS485. By measuring the smallest time between pulses (0.1 milliseconds in this case) the baud rate could be calculated as 1,000 / 0.1 = 10,000 baud.

Pulse view has a wide variety of protocol decoders that can be applied to the captured signal. A visual inspection suggested that each byte contained 10 bits, so I tried the UART decoder with 8N1 (1 start bit, 8 data bits, no parity & 1 stop bit) and this gave meaningful data with no frame errors. From the captured data, I could see that the keypad was sending one byte of data (0xF8) every 38.9 milliseconds and when a key was pressed, a second byte would be sent 0.15 milliseconds later. I now had everything I needed to try connecting to the panel.

I ordered an RS485 to TTL adapter(£1.59) to feed the data to a D1 mini (£1.55).

To manage communications, the D1 mini runs OpenMQTTGateway with the RS232 option enabled and set to 10,000 baud 8N1. I made a small modification to the MQTT to serial code to ensure that any outgoing data would be sent 0.15 milliseconds after an 0xF8 heartbeat was received to match my observations above. I made a second small modification to the serial to MQTT code to exclude sending the 0xF1 messages to the MQTT server as it is only a timing signal and would cause unnecessary traffic.

After pressing each key on the remote keypad I looked on the MQTT server to see which code had been sent and then it was just a matter of setting up all the MQTT sensors in Home Assistant. I then added a series of scripts to publish each code to MQTT and triggered them from button cards which replicate the keyboard layout. I also added a custom feed card to display recent alarm panel events and custom button cards for status updates with state dependant colour and icon changes.

Example:

  - name: "Alarm Interface Message"
    state_topic: "serial2MQTT/OpenMQTTGateway/RS232toMQTT"
    value_template: |-
      {% if value == "M" %}
        {{ "Reset" }}
      {% elif value == "L" %}
        {{ "Omit Zone" }}
      {% elif value == "N" %}
        {{ "Part Set" }}
      {% elif value == "K" %}
        {{ "Chime" }}
      {% elif value == "O" %}
        {{ "Set" }}
      {% elif value == "1" %}
        {{ "Keypad used" }}
      {% else %}
        {{ states(entity_id) }}
      {% endif %}
    icon: 'mdi:book'

The only thing I couldn’t get from keypad messages was whether the alarm had actually been triggered. On the alarm panel was a terminal block labelled “digicom” intended to add an old fashioned dialler. One of the four terminals was marked “intruder” and it was held high, dropping to 0v if the alarm was triggered. To send the status of this pin, I added a voltage divider to feed 3.3v to the D1 mini on pin D7 and added the GPIO option to OpenMQTTGateway. This then sends MQTT messages on a separate GPIO topic, which I could also bring into Home Assistant with another MQTT sensor.

Example:

  - name: "Alarm triggered"
    state_topic: "serial2MQTT/OpenMQTTGateway/GPIOInputtoMQTT"
    value_template: "{{ value_json['gpio'] }}"
    icon: 'mdi:security'

I haven’t shown all MQTT sensors, just a couple of examples as they are highly specific to the Optima 2 Plus panel, but this approach should be easily adapted to any legacy device with a data port.

11 Likes

Is it possible that the baud rate is really 9600? An even 10,000 is a very peculiar speed for something serial. There is only ~4% difference between 10,000 and 9600. And that difference is perhaps “small enough” to not actually matter. :thinking:

That said, it is also possible that whatever clocking crystal in the Optima 2 Plus has drifted and the baud is for real 10,000.

I’ve set up the OpenMQTTGateway serial to use 10,000 baud and I’m sending and receiving messages perfectly. As you say, it is an unusual rate but it is what the sample I took was showing.

Your question did get me thinking about the sample rate I used, so I looked back at the recording I took. Although the logic analyser is capable of 24 MHz, the default setting I had used was 1 MHz. This would give a resolution of 1 micro second. The sample was showing a pulse width of 100 microseconds, which gave the 10,000 baud rate. To be 9,600 baud I should be seeing a pulse width of just over 104 microseconds and as my sample has a resolution of 1 microsecond it should have had enough resolution to show this difference.

Great detective work Martin.
The control panel I assume will also be sending messages in order to update the keypad display and leds. This info could also be sent to your control panel. Did you see and try to decode these messages?
Thanks.

1 Like

By mimicking the remote keypad messages, the main panel then updates the display on the keypad without further messages required

Hi. I had an idea that it would be helpful to be able to remotely see what the keypad was displaying in order to get feedback from keypad messages sent. This would also enable some more remote functionality - eg to be able to remotely see the history of alarm events.

1 Like

That’s a great idea and should be straight forward by capturing the data that follows a keypad message