The RP code is just the link test, so that makes sense. So depending on which code is sent after the reset I can check the behavior. It already goes to the previous state when coming off night mode for instance.
I actually tried registering “RP” code as PREVIOUS_STATE in my case & it worked - it reverts Ajax zones to previous state. Not sure if it’s technically correct, but there are no other Codes except this one coming after STATE_ALARM_TRIGGERED.
“RP” code is being sent by Ajax quite frequently, so I decided to utilize it as reset code.
RP is sent with the frequency that you set as the ping interval, so use at your own risk!
Would be pretty cool to see this.
Im really missing the option to arm and disarm the alarm from HA.
I’ll write something up at the weekend. I want to make sure I credit the original designers. I have in effect taken two separate ideas, and in my opinion improved it to the point it is now fully integrated into HA!
4 Likes
Hopefully this will be some use to others. The total cost is approximately £50 GBP. This will allow full and total control of your Ajax Alarm harnessing the SIA intergration and MQTT. This guide assumes that you have a MQTT server and ESPHome setup.
I started by following this guide (Bitbucket) which details the process of connecting a Ajax space control to an Wemo D1, however you could also use a ESP8266 or 32 and amend the code as required. The guide requires basic soldering skills, but is fairly straightforward. The solution also removes the need to battery power the Space Control, so should be more reliable. If you really felt the need you could probably remove the reliance of the device on Wi-Fi using an ESP32 Ethernet module.
Once the Ajax Space Control is soldered you need to open ESPHome and build a device using the below code which I have created with inspiration from @fireon, who produced Arduino code. There are some changes from his initial code to ensure wider compatibility.
Obviously you will need to ensure the relevant pin is connected the the relevant area of the Space Control.
esphome:
name: ajaxcontroller
platform: ESP8266
board: nodemcuv2
# Enable logging
logger:
api:
ota:
password: "**********************" # This will be created automatically
wifi:
ssid: “*********" # Wi-Fi SSID
password: "****************" # Wi-Fi password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Ajaxcontroller Fallback Hotspot"
password: "************"
captive_portal:
mqtt:
broker: # MQTT server up
username: # your MQTT username
password: # your MQTT server password
client_id: AjaxAlarmControl # What you want to call your device in your MQTT broker
topic_prefix: ajax/alarm/control
on_message:
- topic: ajax/alarm
payload: arm_zone1
qos: 1
then:
- switch.turn_on: arm
- topic: ajax/alarm
payload: disarm_zone1
qos: 1
then:
- switch.turn_on: disarm
- topic: ajax/alarm
payload: arm_zone1_night
qos: 1
then:
- switch.turn_on: arm_night
switch:
- platform: gpio
pin:
number: D2
inverted: true
id: "disarm"
on_turn_on:
- delay: 300ms
- switch.turn_off: disarm
- platform: gpio
pin:
number: D6
inverted: true
id: "arm"
on_turn_on:
- delay: 300ms
- switch.turn_off: arm
- platform: gpio
pin:
number: D7
inverted: true
id: "arm_night"
on_turn_on:
- delay: 300ms
- switch.turn_off: arm_night
Once uploaded you will in effect have a device on your network that will arm, arm night mode and disarm Ajax when the correct MQTT payload is received.
The next stage is to setup the MQTT alarm intergration within HA. This is setup with config.yaml, below is the code.
mqtt:
alarm_control_panel:
state_topic: ajax/alarmstate
command_topic: ajax/alarm
payload_arm_away: arm_zone1
payload_arm_night: arm_zone1_night
payload_disarm: disarm_zone1
qos: 1
Once added, restart HA. Please note do not set the MQTT alarm to retain, as due to a design limitation it will retain all messages, not just the state messages, meaning if your ESP device restarted it would react on the last payload on the command topic. The MQTT alarm intergration listens on the state topic to set its state, and uses the command topic to send a payload to arm which the ESP responds to.
At this point you now have ability to arm and disarm your Ajax alarm from within HA, however it would be possible for HA to fall out of sync with Ajax if the alarm is set locally using the keypad or Ajax app, or HA is restarted (because we can’t use the retained message feature with the MQTT alarm system). This is where SIA comes in. Assuming you are using arm, arm night and disarm you will to produce three automations, which are below -
Automation for if the alarm is armed locally -
alias: (Alarm) Alarm Automation Armed Locally
description: ''
trigger:
- platform: state
entity_id: ******** #change this to your SIA entity that reports your alarm state
to: armed_away
- platform: mqtt
topic: ajax/alarm
payload: arm_zone1
condition: []
action:
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- service: mqtt.publish
data:
topic: ajax/alarmstate
qos: '1'
retain: true
payload: armed_away
mode: single
Automation if night mode is armed locally -
alias: (Alarm) Alarm Automation Night Locally
description: ''
trigger:
- platform: state
to: armed_night
entity_id: ******** #change this to your SIA entity that reports your alarm state
- platform: mqtt
topic: ajax/alarm
payload: arm_zone1_night
condition: []
action:
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- service: mqtt.publish
data:
topic: ajax/alarmstate
qos: '1'
retain: true
payload: armed_night
mode: single
Automation if alarm is disarmed locally -
alias: '(Alarm) Alarm Night Automation Disarmed Locally '
description: ''
trigger:
- platform: state
to: disarmed
entity_id: ******** #change this to your SIA entity that reports your alarm state
- platform: mqtt
topic: ajax/alarm
payload: disarm_zone1
condition: []
action:
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- service: mqtt.publish
data:
topic: ajax/alarmstate
qos: '1'
payload: disarmed
retain: true
mode: single
What these three automations do in effect is watch the SIA intergration and the MQTT state topic, if a state change is recorded it waits 5 seconds and then publishes a retained MQTT message to ensure that the alarm state survives restarts and the MQTT alarm panel is up to date with any local changes to Ajax.
From a security perspective I would considering putting the ESP on an none external facing VLAN.
Once all setup you can then use the MQTT alarm to arm and disarm your Ajax based on your presence, I personally set it to arm when I leave, but leave it to me to disarm when I return home. You can also use the alarm card using the below.
type: alarm-panel
states:
- arm_away
- arm_night
entity: alarm_control_panel.mqtt_alarm
name: House Alarm
Apologies it’s a long write up, not sure if I should put this on its own Repo. If people find it useful I will. @kernest let me know how you get on.
@eavanvalkenburg any issues with this post let me know, appreciate all the hard work you’ve put into SIA.
11 Likes
This looks awesome, thanks for sharing, I’m thinking about doing this now as well! One additional thought, if you add something like this:
async def async_alarm_disarm(self, code: str | None = None) -> None:
"""Send disarm command."""
self.hass.bus.async_fire(
event_type=SIA_EVENT.format(self._port, event.account),
event_data={"type": "disarm"},
)
and similar functions for the arm and arm_night, and probably some small tweaks in the rest of the code here: sia/alarm_control_panel.py at master · eavanvalkenburg/sia (github.com).
Then you can add automations on those events to call the ESP through MQTT, then you don’t need the MQTT entities (and maybe not even MQTT, just direct to ESP, perhaps?), but in any case then the SIA entity does all of the work in displaying status etc!
My coding abilities are fairly limited, but i could definitely see the advantages of using the ESPHome API and your control panel, which would reduce the need for the additional automations, I just don’t have the knowledge to achieve it 
Hi there, newbie to Ajax, well I dont have it yet Im toying up between Ajax and Texecom.
With Ajax, from within HA the only thing Im interested in is if the alarm is set or not, from what I can tell this can be done with the SIA component and its quite stable (right?).
Now second question, if I have my alarm monitored by a monitoring company , am i correct in saying I wont be able to detect the state changes?
thanks
There is no way without some further work (see my above post) to arm and disarm Ajax within HA. The SIA intergration is purely a listening protocol that reports state changes.
Ajax only supports one SIA Monitoring Station at a time, so if you pay a provider you couldn’t then also use the integration.
It depends on how the alarm monitoring company connects, if they use the SIA protocol then that means you can’t also use HA for the status.
1 Like
thanks guys,
I probably wont go for monitoring to start with but I want to make sure I have the option later…
In my old Guardsec system there was a board pin I put an opto isolator to , it worked well and told me alarm set/unset… Looking at pictures of the ajax board I dont think thats viable…
The only other solution I can think of is to buy a ajax smart socket, add a ESP to it, when its powered, alarm=on, not powered alarm=off… bit of an expensive hack as I think each plug is like €80 but it would work
@eavanvalkenburg thats strange, why there are 2 sections in the sia protocol conf?
primary ip address
secondary ip address
I assume if i can mock in HA same ip as use monitoring station and same object number then it should work? or am i wrong and secondary ip is only in case first ip die?
thanks…
In that case there is no option to monitor ajax status via sia to monitoring station and simultaneously to HA? ;-(?
As far as I know that is indeed for failover, so if the primary IP doesn’t respond it will try the secondary, pretty normal for IP based communications since you don’t have DNS in between in that case!
Thank you so much for this extension. I set it up and it is basically working (hub+, with one range extender, firwmare 2.12). 4 zones are declared. In readme it is said that 3 entity types are created upon setup: binary_sensor, alarm_control_panel and sensor. As you may see in the screenshot, no sensor type are reported. Is it what is expected ?
I noticed there is an entity for power sensor for the hub. Could we have the same for range extender?
I have one fire tracker in zone 3. I’m wondering how to identify it among the two binary sensors?
I’m running HA latest version as well as for SIA integration.
Thank you
I have a similar problem.
In my case I have 4 motion sensors in the same area and I don’t see any sensor-type entity for these devices. In fact, in my case, I can’t even be notified when the alarm goes off. I can only see if it is Armed or Unarmed 
Can anyone help please?
1 Like
couple of things:
- the sia protocol doesn’t pass individual sensors (motion) on, only the state of the system per zone.
- smoke and moisture sensors are disabled by default in HA so check under the entities of the integration to enable them
- if you don’t see the state change your expect please turn on logging, there might be codes used that aren’t known so then we can include them
Thanks @eavanvalkenburg. So I guess there is no way to tell without activating both binary_sensors of zone 3, which one is Fire detector, isn’t it?
As for sensor that is supposed to report heartbeat, why there is none shown in the screenshoot above?
And last question, is there a way to report Rex power failure?
No actually what is supposed to happen is that once is named smoke and the other moisture instead of none, so I’m not sure what’s happening with that in your case…
@eavanvalkenburg is there a way to troubleshoot? Could it be that the fire sensor belongs to zone 3, and there is none in zone 1?