In your alarm or HA? Or both?
I have the same problem. Some time after the alarm is turned on or off, the status becomes unavailable. As soon as any sensor sees something or I change the alarm status in the ajax application, the problem disappears. Then after a few minutes it becomes unavailable again
Hi, I have the same issue and investigated with Ajax R&D with a ticket, their answer is quite clear:
"The CMS sends NAK in encrypted mode. NAK messages (according to the description of SIA protocol) shouldnt be encrypted. When Hub receives encrypted NAK, it cant synchronize the time with the CMS. "
seems thats global issue, any view on fix?
hi,
i removed all settings added it from scratch but i dont have following sensor?
also inside ajax i create 5 zones… do i have to set in HA number of zones to 5 or 1?
The zones management is terrible in ajax… u cant have sensors in multiple zones, u cant arm whole system with nfc key just moving around ajax keypad plus … 
Good work.
One question… How is the battery life that is in the Space control Ajax command and which powers the ESP8266?
Wouldn’t it be better to power the Wemos D1 directly via USB, for example?
The space control is powered by the 3v pin and Gnd on the Wemo board which in turn is connected to a USB PSU.
Is it just me that had all ajax-entities go to unavailable with the last update? I didn’t see anything regarding this integration in breaking changes.
Ajax app still reports monitoring station as “Connected”
That’s right, I reported that too.
Same with me. As a matter of fact, when a zone is armed or disabled, the state is set accordingly and after a short while, the state is set to unavailable
just noticed this as well, I’m on it!
Fix submitted as a PR, hopefully that can be included in 2022.2.1!
2 Likes
Just upgraded to 2.1 and it’s working. Thank you
Hello, there is an unwanted side effect to this new version . Every minute or so, while state of the zone stays steadily its previous state, timestamp is updated and triggers an action (rest command), thus generating unwanted network trafic. It should noted as well that last_zone is set to 0 which is another side effect.
EDIT
I continued to troubleshoot and I discovered that arming/disarming a specific zone, does not trigger any events anymore. An event is triggered for zone 1 only when arming the whole system. I’m afraid that this update broke the zone mechanism. Having 4 zones, before this update, arming the whole system triggered indeed 4 events, one for each zone
Herebelow the automation
- id: '1642926428231'
alias: Alarm integration with dz
description: ''
trigger:
- platform: state
entity_id: alarm_control_panel.5656_ccc_zone_4_alarm
to: 'on'
- platform: state
entity_id: alarm_control_panel.5656_ccc_zone_4_alarm
to: 'off'
- platform: state
entity_id: alarm_control_panel.5656_ccc_zone_4_alarm
to: 'on'
- platform: state
entity_id: alarm_control_panel.5656_ccc_zone_4_alarm
to: 'off'
- platform: state
entity_id: alarm_control_panel.5656_ccc_zone_3_alarm
to: 'on'
- platform: state
entity_id: alarm_control_panel.5656_ccc_zone_3_alarm
to: 'off'
- platform: state
entity_id: alarm_control_panel.5656_ccc_zone_2_alarm
to: 'on'
- platform: state
entity_id: alarm_control_panel.5656_ccc_zone_2_alarm
to: 'off'
- platform: state
entity_id: alarm_control_panel.5656_ccc_zone_1_alarm
condition: []
action:
- service: rest_command.ajax2dz_event
data:
state: '{{states(trigger.entity_id)}}'
zone: '{{state_attr(trigger.entity_id,''last_zone'')}}'
deviceClass: '{{state_attr(trigger.entity_id,''device_class'')}}'
someValue: nil
mode: single
This was already the behavior before the bug before, someone else in the thread was able to fix in his automation. Once the connectivity sensor is added I can change this because then I have a place to show you that the RP message arrived, the zone is therefore also correct because that is the zone used for RP!
Hello, please review my edit, it was just posted when you posted. Thank you
Hello. I have two zone in Ajax alarm.
If one zone go in alarm, when I disarming it, continue to remaining triggered.
I see this error in HA log
‘’'Logger: homeassistant.components.websocket_api.http.connection
Source: components/alarm_control_panel/init.py:152
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 16:20:31 (1 occurrences)
Last logged: 16:20:31
[547570878976]
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py”, line 190, in handle_call_service
await hass.services.async_call(
File “/usr/src/homeassistant/homeassistant/core.py”, line 1630, in async_call
task.result()
File “/usr/src/homeassistant/homeassistant/core.py”, line 1667, in _execute_service
await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
File “/usr/src/homeassistant/homeassistant/helpers/entity_component.py”, line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File “/usr/src/homeassistant/homeassistant/helpers/service.py”, line 668, in entity_service_call
future.result() # pop exception if have
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 921, in async_request_call
await coro
File “/usr/src/homeassistant/homeassistant/helpers/service.py”, line 705, in _handle_entity_call
await result
File “/usr/src/homeassistant/homeassistant/components/alarm_control_panel/init.py”, line 156, in async_alarm_disarm
await self.hass.async_add_executor_job(self.alarm_disarm, code)
File “/usr/local/lib/python3.9/concurrent/futures/thread.py”, line 52, in run
result = self.fn(*self.args, **self.kwargs)
File “/usr/src/homeassistant/homeassistant/components/alarm_control_panel/init.py”, line 152, in alarm_disarm
raise NotImplementedError()
NotImplementedError ‘’’
As is documented unfortunately you can’t arm/disarm your alarm with SIA.
In order to get rid of the unwanted zone 0 trigger, a condition template has been added to the automation
condition:
- condition: template
value_template: '{{ (state_attr(trigger.entity_id,''last_zone''))
| int != 0 }}'