Integrating GE Concord alarm system

I assumed you had the correct hex codes listed against each function. Is it working for you now.

The codes are wrong in the documentation.

http://old.homegenie.club:8080/www.homegenie.it/forum/GE-Concord%3DRS-232%3DProtocolacad.odt?action=dlattach;topic=1722.0;attach=2507

https://docs.google.com/file/d/0B2YZbA-Smf2WMW9udFZJUVZ4YTg/view

That’s why the codes are also wrong in the Concord232 server. Only reason I came around the correct code was by looking in the code for this project;
http://code.mios.com/trac/mios_ge-concord#no1

Anderson110,

If we change Concord232 so its possible to implement ‘alarm_trigger’ in Home Assistant I assume that would be a breaking change since HA specifically calls for version 0.15, Is that a correct assumption?

Besides having Panic Trigger implemented, in which other ways is it superior?

Did note that they have the correct Panic codes :slight_smile:

The Concord server used in HA is polling based rather than real-time which effectively leaves out so many other features available from the automation module’s comms with the Control panel.

That link you reposted was my original link to the protocol docs. That’s a copy of the original protocol docs from GE so if you’ve found revised codes they must have been a revision doc released.

I’ve setup the GE automation module with most of the home automation applications out there. MiOS is used with Vera and again is polling based and very unreliable. The most stable standalone server is the Concordd I linked to and the one in HomeSeer which is written in VB.

It’s unfortunate that Jason Carter referenced incorrect hex codes when writing his program but as most of these programs are supplied free of charge via the GitHub I don’t see anyone wanting to beat themselves up over it.

Hopefully you are now on the right track. Maybe you could fork Jason Carters project if you want to continue developing Concord232. Good luck with that.

Well can’t really blame Jason Carter since he probably just looked at the same documentation as I did.
Are you positive Concordd is event driven? Looked to me like you had to poll it for status changes etc.
I have setup Home Assistant to pull Concord232 often enough that it’s not really a problem for me. But if there is some extra functionality I’m missing out on I would love to know. Maybe it could convince me to look into implementing it in HA.

Yes it’s event driven.

It includes a virtual keypad and emulates an LCD display panel among other features. There’s a lot going on in the panel/AM that Concord232 can’t exploit as well.

If you haven’t already used it fire it up and see for yourself. It will give you an idea what features are missing in Concord232. Its only 20 minutes work to get it going.

Hopefully at some stage the author may write a Python wrapper for it. Maybe another HA user familiar Python using the Concord panel could take this on too.

Seem like 3rd party programs like HA would have to use their dbus api to connect and that seems poll based:

Looks like a nice system though if you completely want to eliminate your panel

Just to be clear here. Where did you verify that the Panic Codes were incorrect. Bear in mind that many of the features mentioned in the Lua code are not implemented so are not tested and verified.

I verified it by testing it. When I send those 3 new codes to Concord it fires the 3 correct alarms.

I looked in the code of both mios and concordd and they both use the working code as well.

I assume you sent the commands from the Concord client via the CLI. What format did that command take.

The reason I ask is I’m talking with a former UTC/GE engineer and he’s very surprised to hear that official printed protocol codes are incorrect. I wanted to try and verify this before pursuing this any further.

Ok, I did some more testing and the documentation is indeed correct. The Concord Alarm System does send 0x0c, 0x0d, 0x0e for Police Panic, Aux. Panic and Fire Panic respectively.
You just can’t trigger those Commands by sending those codes. In order to trigger those you have to send 0x4c, 0x4d & 0x4e respectively.
Apologize for any confusion.

As to your other question.
No, I had to change the server itself to do it. I also changed the client so you can call the alarms with the following:

$ concord232_client alarm-police
$ concord232_client alarm-auxiliary
$ concord232_client alarm-fire

Or you can talk to the Server directly like this:

http://127.0.0.1:5007/command?cmd=alarm&option=police
http://127.0.0.1:5007/command?cmd=alarm&option=auxiliary
http://127.0.0.1:5007/command?cmd=alarm&option=fire

You can see the code changes here:
https://github.com/AZDane/concord232/tree/AZDane

Ok. It appears that there are indeed a list of codes not published in the original protocol document and for very good reason I believe that could open up other possibilities here. The fact that UTC no longer manufacture GE equipment may have a bearing on this.

I’ve had a look at your forked GitHub code just for comparison purposes.

I wonder was there a good reason that previous requests for changes to Jason Carters work refused.

Not sure I follow. Could you please clarify what changes you are interested in?
If it’s a change to an event based model it requires a significant rewrite, so that’s out of the question.

Yes, it is definitely a loop based system and rewriting it to eventing would be a bit of an undertaking.

As the readme of this component says, this is a mashup of two projects, one for the HomeAssistant framework, and the other py-concord, so if there is an issue with the underlying codes in the upstream project, that is an issue with that project, but anyone is certainly able to create pull request for updates and changes to my project or the upstream py-concord project.

The integration I presented works for MY needs at the time, but now I don’t even own a Concord232 thus I don’t even have a way to test any changes I’ve made. I granted admin permissions to the repo to others whom have made changes and accepted pull request, but as of now, I’m basically completely out of the loop on the maintenance of this module.

I assumed that was the situation.

The panel is showing its age now. As you say you no longer own a Concord 4 panel so there’s no way of testing any new mods to your work and as there are fewer Concord 4 panel owners around I don’t see many wanting to invest the effort bringing it on any further.

It covers the basics required to interact with HA so I imagine that’s good enough for most. Of course it can always be modified on a local install as I’ve done from time to time as and when the need arose.

Nice work @JasonCarter80 and remember you’re the only one who attempted it for HA. Thanks.

Hi everyone - Recent convert from Vera here and using the Concord232 plugin. I’m running HA in a Proxmox VM and have the concord232_server running in a different container. Noting that update times were very slow (default is 10s IIRC), I set the scan_interval to 1 second.

Ping time is lightning fast. Calling the URL directly comes back fast. However, I get the following message all through my logs.

“Updating concord232 alarm_control_panel took longer than the scheduled update interval…”

I’ve now got it set to 3 seconds, but still get this error.

The biggest side effect is that the state of the alarm panel isn’t getting updated when I disarm. It won’t changed from armed_home to disarmed until I restart HA. I have a number of scenes that run based on the panel state so I’d love to get this right.

Anyone else see this and find a way to solve it?

I do see similar messages in my logs, but I don’t have the issue with alarm state not getting updated.
I have my concord server running on a separate pi and get updates with in seconds.