Integrating GE Concord alarm system

anderson110 · December 11, 2017, 9:37pm

I have just ordered a Superbus 2000 automation module to attempt to integrate my 10 year old GE Concord alarm system.

I see there’s a component for this submitted by @JasonCarter80, but there doesn’t seem to be much discussion when I google for information about it.

Anyone else been down this road? I will try to chronicle my experience getting this set up.

JasonCarter80 · December 11, 2017, 9:57pm

Yes, I wrote it and it work(s)ed great… until I blew out my system during construction. So I’m pretty much useless for testing/support of any issue you may find.

anderson110 · December 11, 2017, 10:27pm

Oh no! Any mistakes I should not repeat?

anderson110 · December 22, 2017, 7:11pm

Update:

TLDR: Make sure you have a working INSTALLER code before attempting this (not master code or user code), AND a touchpad model that allows system programming (which does not include the common FTP-1000, see page 9: https://github.com/douglasdecouto/py-concord/blob/master/docs/GEITIConcord4%20-%20Install%20Manual.pdf). You can get yourself in a pickle if you do not. If you can do 8-<code>-0-0 and get into SYSTEM PROGRAMMING, you are good to go. If you can’t, you are probably asking for trouble to mess with your system. The default installer code is 4321.

I received the automation module. I followed the installation instructions, and was greeted by an “AM03, bus error” upon powering up. This meant the automation module, device 3 (I have two keypads) is not communicating properly over the bus. Well, of course not, I had not hooked anything up to the serial port yet.

So I set up a laptop running linux, connected to the serial port via a USB-serial cable, and fired up the concord_server as described in the README here: https://github.com/JasonCarter80/concord232.

This seemed to work. Sort of. I only showed two zones, when I knew I had quite a few more than that. It seems the zones started to show up once I tripped each sensor in turn. So I guess after a power down, the system needs to “relearn” the sensors. Fine. At this point it was getting late and I needed my laptop back for other things, so I disconnected it. This was a problem, as this now triggered another “bus error”, and made the alarm inoperable. No problem, I thought, I’ll just unwire the automation module for now, and resume when I can. Well, that didn’t work either. The system has “learned” that module, and expects it to be there now, even if it is entirely unwired from the system. Ok, no problem, I thought, I can just delete that bus device, and wait until I can work on this again. Well, this requires having a working installer code and being able to get into system programming mode. I apparently cannot, because I have FTP-1000 touchpads, which do not allow you to enter system programming mode, even if you have the installer code.

The next step is to see if I can reattach the server and hopefully things come back up and are recognized properly. Will update.

anderson110 · December 23, 2017, 6:50am

Dodged a bullet with needing the installer code so far.

When I rewired the automation module, and attached a raspberry pi running Jason’s concord232 server, everything seemed to come up without trouble. The alarm panels no longer show any bus (or other) errors, the keypads operate as normal, and I can get a listing of the status of all the sensors using:

% concord232_client summary

I added the configuration to HA and restarted (https://home-assistant.io/components/alarm_control_panel.concord232/). I see that I get one new entity, alarm_control_panel.concord232, which has a state which reflects, say, armed or disarmed. I don’t see any entities for the sensors of the alarm system. Looking now into the code of the alarm_control_panel component, it looks like this is all this component provides.

I was really hoping to expose all of my alarm system’s sensors as new sensors in HA with which to trigger automations. Looks like more research and possibly some new development is still needed to accomplish this.

anderson110 · December 23, 2017, 6:20pm

I see now that you can access the sensors by using the binary_sensor component with platform concord232. I think this completes the installation.

Recapping for future travelers:

Things Needed:

Concord Automation Module, part 60-783-02.
USB to DB-9 RS232 cable.
Server that can connect to the automation module via the RS232 cable. (I used a Raspberry Pi Zero W for this)
Stranded 22-gauge or larger hookup wire
Some (very) basic wiring skills and tools
The concord232 client/server code installed on the server: https://github.com/JasonCarter80/concord232

I was able to get by so far without it, but it’s also advised to have system programming access to your alarm system, which requires an installer code. If you can do 8-<installer code>-0-0 and get “system programming”, you’re good. Otherwise, tread carefully because many programming functions are only accessible that way.

Basic steps:

Install concord232 software on server you will attach to automation module.
Remove wall power, then unhook battery from alarm panel to power down.
Wire in the automation module. It’s a simple 4 wire screw terminal hookup.
Attach server to automation module with serial cable.
Power up alarm system, first at the battery, then wall power. Ensure there are no errors at panel.
Fire up concord232_server, and test with concord232_client.
Configure HA with alarm_control_panel and binary_sensor components with platform concord232.

Finish with any desired customizations. Done. In the end, quite simple.

anderson110 · December 29, 2017, 11:31pm

I was really missing the ability to arm the alarm silently, which is accomplished on the Concord 4 by pressing 5 (silent) and 2 (stay). This feature isn’t exposed to HA, and indeed the underlying client/server package doesn’t seem to support it. Listening to a lot of warning beeps late at night when the kids are trying to sleep is no bueno.

After quite a lot of research and trial and error, I was able to make the feature work through the automation module at a low level. The upshot is that sending the key sequence “5” “2” doesn’t work, you have to instead send the key “5” followed by the code for “keyfob arm”. Why, I have no idea. But that does the trick. So the low level command is:

06 40 01 00 05 21 6D

06: msg length
40: keypress command code
01: partition # (always 1, I guess)
00: area # (always 0, I guess)
05: keypress “5” for silent
21: keypress “keyfob arm” (who knows why)
6D: checksum

I plan to integrate this through the various layers to bring it back to HA. First job is extending the client/server package. Then extending the HA interface to that.

anderson110 · December 30, 2017, 1:23am

Pull request submitted to add this to the client/server code.

@JasonCarter80 Are you willing to take a look at this? I have a working system that I’m relying on, so I’d also be willing to maintain a fork and point the HA docs there. Let me know what you think.

https://github.com/JasonCarter80/concord232/pull/4

jesuscmartinez · February 1, 2018, 9:08pm

HI, I’m looking for some help with this setup as well. I’ve got a raspberry pi 3 with a serial to usb connected to the automation module. Initially, I started out with Jason’s fork and ran the concord232_server. When running this it threw an UTF-8 exception so I started to debug and trace the code a bit. Doing this brought me to the py-concord repo and I found the concord_test script:

github.com

douglasdecouto/py-concord/blob/master/ConcordAlarm.indigoPlugin/Contents/Server Plugin/concord/concord_test.py

"""
Test code for interfacing to the Concord panel.

Can be run from the command line.
"""

import sys
import threading
import time

import concord


class FakeSerial(object):
    def __init__(self, msg_list_):
        self.msg_list = msg_list_
        self.curr_msg_idx = 0
        self.curr_char_idx = 0

    def ck_msg_avail(self):

This file has been truncated. show original

I ran that then tried to do a ‘r’ cmd which output this:

{code}
pi@raspberrypi:~/py-concord/ConcordAlarm.indigoPlugin/Contents/Server Plugin/concord $ python concord_test.py /dev/ttyUSB0 --debug
Wait for message start, byte_read=’\xf6’
Wait for message start, byte_read=’\xc2’
Wait for message start, byte_read=’\xf6’
Wait for message start, byte_read=’\xc2’
Wait for message start, byte_read=’\xf6’
Wait for message start, byte_read=’\xc2’
r
SEND REFRESH
Sending message (retry=1) ‘022022’
write_message: ‘\n022022’
Wait for message start, byte_read=’\xfe’
Wait for message start, byte_read=’\xfe’
Resending message, attempt 2: ‘022022’
write_message: ‘\n022022’
Wait for message start, byte_read=’\xfe’
Wait for message start, byte_read=’\xfe’
Resending message, attempt 3: ‘022022’
write_message: ‘\n022022’
Wait for message start, byte_read=’\xfe’
Wait for message start, byte_read=’\xfe’
Unable to send message (timeout), too many attempts (3): ‘022022’
Wait for message start, byte_read=’\xf6’
{code}

The write message looks correct, but the read_bytes are off from the documentation.

I’m using the following cable with a stock raspbian install:

I’m hoping you all could help me tweak some configuration or maybe point me to the specific cable you are using with your setup.

Thanks for the help.

anderson110 · February 2, 2018, 10:13pm

I think that cable is equivalent to the one I’m using. I doubt that is a source of your issue.

can you paste the exact error you’re getting? Which version of concord232_server are you running? Which version of home assistant?

jesuscmartinez · February 2, 2018, 11:26pm

I’ve not setup Home Assistant yet as I wanted to run concord232 locally before moving up to that layer.

I’ve installed concord232 via:

sudo pip3 install concord232

The following is an output of the concord232_server cmd.

pi@raspberrypi:~ $ concord232_server --serial /dev/ttyUSB0
2018-02-02 23:18:16,789 main INFO Ready
2018-02-02 23:18:16,838 _internal INFO * Running on http://0.0.0.0:5007/ (Press CTRL+C to quit)
Exception in thread Thread-1:
Traceback (most recent call last):
File “/usr/lib/python3.5/threading.py”, line 914, in _bootstrap_inner
self.run()
File “/usr/lib/python3.5/threading.py”, line 862, in run
self._target(*self._args, **self._kwargs)
File “/usr/local/lib/python3.5/dist-packages/concord232/concord.py”, line 407, in message_loop
and self.serial_interface.wait_for_message_start() == MSG_START:
File “/usr/local/lib/python3.5/dist-packages/concord232/concord.py”, line 92, in wait_for_message_start
byte_read = self._read1()
File “/usr/local/lib/python3.5/dist-packages/concord232/concord.py”, line 104, in _read1
c = self.serdev.read(size=1).decode(‘utf-8’)
UnicodeDecodeError: ‘utf-8’ codec can’t decode byte 0xfe in position 0: invalid start byte

Thanks

JasonCarter80 · February 6, 2018, 9:24pm

Run that same command with the --debug and lets see what you get.

JasonCarter80 · February 6, 2018, 9:29pm

Regarding the installer code, I never had an installer code prior to a week ago when I got my system back working. However, if you ever need your installer code, its pretty easy to get.

Get one of these:

And follow instructions here:

I used this process to remove my blown panel and the system worked fine. I then found a used system for $50 and used the panel on mine. Being curious I extracted their master code and it worked as well after putting their chip in my system.

silfa718 · February 9, 2018, 7:51pm

I’m running Hassio, can I run the concord server on a different pi?

anderson110 · February 9, 2018, 8:39pm

Yes, I run the server on a different pi. Works great.

silfa718 · February 9, 2018, 8:50pm

Thanks, I’m getting the automation module on tuesday.

Do you have to define the component in the config file differently have the server on a different pi?

anderson110 · February 9, 2018, 9:11pm

If I remember you specify the URL of the server. So you’ll just use the IP of your pi on your local network, rather than localhost.

jesuscmartinez · February 10, 2018, 6:59pm

Okay here is was i get:

pi@raspberrypi:~ $ concord232_server --serial /dev/ttyUSB0 --debug --log concord.txt
2018-02-10 18:56:35,904 main INFO Ready
2018-02-10 18:56:35,909 concord DEBUG SerialInterface Starting
2018-02-10 18:56:35,914 concord DEBUG Starting
2018-02-10 18:56:35,916 concord DEBUG Message Loop Starting
2018-02-10 18:56:35,918 concord DEBUG Sending message (retry=1) ‘03020308’
2018-02-10 18:56:35,982 _internal INFO * Running on http://0.0.0.0:5007/ (Press CTRL+C to quit)
Exception in thread Thread-1:
Traceback (most recent call last):
File “/usr/lib/python3.5/threading.py”, line 914, in _bootstrap_inner
self.run()
File “/usr/lib/python3.5/threading.py”, line 862, in run
self._target(*self._args, **self._kwargs)
File “/usr/local/lib/python3.5/dist-packages/concord232/concord.py”, line 407, in message_loop
and self.serial_interface.wait_for_message_start() == MSG_START:
File “/usr/local/lib/python3.5/dist-packages/concord232/concord.py”, line 92, in wait_for_message_start
byte_read = self._read1()
File “/usr/local/lib/python3.5/dist-packages/concord232/concord.py”, line 104, in _read1
c = self.serdev.read(size=1).decode(‘utf-8’)
UnicodeDecodeError: ‘utf-8’ codec can’t decode byte 0xfe in position 0: invalid start byte

Looks like I’m not getting valid data from the serial.

silfa718 · February 13, 2018, 6:08pm

I got everything working perfectly…thanks for the help

anderson110 · February 13, 2018, 6:46pm

I didn’t run into this so I’m not sure. Are bytes getting sent to the port? I used minicom to see the raw bytes getting sent to the port. You might be able to just cat /dev/ttyUSB0 or even tail -f /dev/ttyUSB0 but I’m not sure. It won’t be human readable, but you’ll be able to tell that there’s a regular pattern to it of status updates.