Ajax alarm system

Feature Requests
226

Hi all,
I’m trying to integrate HESA alarm to HA. HA is running in docker in a raspberrypi.
I configured the SIA alarm integration via HACS and activated the logger. It seems that the incoming messages are correctly interpreted:

2020-10-31 08:07:02 DEBUG (MainThread) [pysiaalarm.base_sia_server] Parsed event: Content: #123456|Nri3OP1^AREA FINESTRE   ^]_08:01:19,10-31-2020, Zone: 3, Code: OP, Message: 1^AREA FINESTRE   ^, Concerns: User number, Type: Opening Report, Description: Account was disarmed, Account: 123456, Receiver: None, Prefix: L0, Timestamp: 2020-10-31 08:01:19, Length: 004D, Sequence: 0037, CRC: 7E70, Calc CRC: 7E70, Message type: Opening Report, Encrypted Content: None, Full Message: "SIA-DCS"0037L0#123456[#123456|Nri3OP1^AREA FINESTRE   ^]_08:01:19,10-31-2020.
2020-10-31 08:07:02 WARNING (MainThread) [pysiaalarm.base_sia_server] Event timestamp is no longer valid: 2020-10-31 08:01:19

For now I’m trying wiht CL, NL and OP message code.
But I get two issues;

  1. it seems that the HESA alarm doesn’t receive the ACK message since I get a communication error message in the central alarm unit.
    I had a similar problem with iobroker. I solved it increasing the ACK time out in the SIA instance configuration. But in this case perhaps it could be a routing problem. How can I see if the SIA integration responts with the ACK message? Any suggestion?
  2. None of the entities in HA is updated
    Can someone help me?

Thanks in advance

227

Hi @corby, thanks for giving it a try, the timestamp message means that it will not acknowledge the message since it was later than allowed (40 seconds), please check the time settings (time and timezone) of both devices and make sure they’re in sync.

228

Hi Eduard,
thanks for your answer. It’s possible that the devices have different time since the alarm is not able to sync with ntp server. I’ll check as soon as possible and I’ll give you a feedback.
Thanks

1 Like
229

Hi, I tried to sync the time but it doesn’t work

2020-10-31 23:05:18 DEBUG (MainThread) [pysiaalarm.aio.sia_server] Incoming line: A21F004D"SIA-DCS"0037L0#123456[#123456|Nri2OP0^AREA SCURI      ^]_23:05:20,10-31-2020
2020-10-31 23:05:18 DEBUG (MainThread) [pysiaalarm.base_sia_server] Parsed event: Content: #123456|Nri2OP0^AREA SCURI      ^]_23:05:20,10-31-2020, Zone: 2, Code: OP, Message: 0^AREA SCURI      ^, Concerns: User number, Type: Opening Report, Description: Account was disarmed, Account: 123456, Receiver: None, Prefix: L0, Timestamp: 2020-10-31 23:05:20, Length: 004D, Sequence: 0037, CRC: A21F, Calc CRC: A21F, Message type: Opening Report, Encrypted Content: None, Full Message: "SIA-DCS"0037L0#123456[#123456|Nri2OP0^AREA SCURI      ^]_23:05:20,10-31-2020..
2020-10-31 23:05:18 WARNING (MainThread) [pysiaalarm.base_sia_server] Event timestamp is no longer valid: 2020-10-31 23:05:20

2020-10-31 23:05:20 DEBUG (MainThread) [pysiaalarm.aio.sia_server] Incoming line: A21F004D"SIA-DCS"0037L0#123456[#123456|Nri2OP0^AREA SCURI      ^]_23:05:20,10-31-2020
2020-10-31 23:05:20 DEBUG (MainThread) [pysiaalarm.base_sia_server] Parsed event: Content: #123456|Nri2OP0^AREA SCURI      ^]_23:05:20,10-31-2020, Zone: 2, Code: OP, Message: 0^AREA SCURI      ^, Concerns: User number, Type: Opening Report, Description: Account was disarmed, Account: 123456, Receiver: None, Prefix: L0, Timestamp: 2020-10-31 23:05:20, Length: 004D, Sequence: 0037, CRC: A21F, Calc CRC: A21F, Message type: Opening Report, Encrypted Content: None, Full Message: "SIA-DCS"0037L0#123456[#123456|Nri2OP0^AREA SCURI      ^]_23:05:20,10-31-2020..
2020-10-31 23:05:20 WARNING (MainThread) [pysiaalarm.base_sia_server] Event timestamp is no longer valid: 2020-10-31 23:05:20

I think that the time in the message is not the time of the message itself but the time of the event. The system takes some second to send the message. (The alarm central time is some seconds in andance).

Is it possible to skip testing the time diff (or increase the timeout)? Just to see the ACK message.

Thanks

230

hmm strange becuase they look right, so it might be a UTC/timezone thing. You can try to change this line in the custom_component folder: https://github.com/eavanvalkenburg/sia/blob/70d2a1751c8b118b2774391feb3b77f4d87c4648/custom_components/sia/hub.py#L85

to say:
SIAAccount(a[CONF_ACCOUNT], a.get(CONF_ENCRYPTION_KEY), allowed_timeband=None)

231

done but now I get this error:

2020-11-01 10:57:31 DEBUG (MainThread) [pysiaalarm.aio.sia_server] Incoming line: 9B15004D"SIA-DCS"0037L0#123456[#123456|Nri1OP0^AREA VOLUMETRICI^]_10:57:17,11-01-2020
2020-11-01 10:57:31 DEBUG (MainThread) [pysiaalarm.base_sia_server] Parsed event: Content: #123456|Nri1OP0^AREA VOLUMETRICI^]_10:57:17,11-01-2020, Zone: 1, Code: OP, Message: 0^AREA VOLUMETRICI^, Concerns: User number, Type: Opening Report, Description: Account was disarmed, Account: 123456, Receiver: None, Prefix: L0, Timestamp: 2020-11-01 10:57:17, Length: 004D, Sequence: 0037, CRC: 9B15, Calc CRC: 9B15, Message type: Opening Report, Encrypted Content: None, Full Message: "SIA-DCS"0037L0#123456[#123456|Nri1OP0^AREA VOLUMETRICI^]_10:57:17,11-01-2020..
2020-11-01 10:57:31 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/pysiaalarm/aio/sia_server.py", line 55, in handle_line
    event, account, response = self.parse_and_check_event(line)
  File "/usr/local/lib/python3.8/site-packages/pysiaalarm/base_sia_server.py", line 98, in parse_and_check_event
    if not event.valid_timestamp(account.allowed_timeband):
  File "/usr/local/lib/python3.8/site-packages/pysiaalarm/sia_event.py", line 157, in valid_timestamp
    if not allowed_timeband[0]:
TypeError: 'NoneType' object is not subscriptable

maybe it requires a numeric range
if I set 3600 or 0 instead of none I get this:

2020-11-01 11:11:25 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/pysiaalarm/aio/sia_server.py", line 55, in handle_line
    event, account, response = self.parse_and_check_event(line)
  File "/usr/local/lib/python3.8/site-packages/pysiaalarm/base_sia_server.py", line 98, in parse_and_check_event
    if not event.valid_timestamp(account.allowed_timeband):
  File "/usr/local/lib/python3.8/site-packages/pysiaalarm/sia_event.py", line 157, in valid_timestamp
    if not allowed_timeband[0]:
TypeError: 'int' object is not subscriptable
232

That should be (3600, 3600), give that a shot. The none should work so I’ll fix that.

233

Hi Eduard, now I don’t get the error in the log.
I don’t know if the alarm system receives the response message but it stops sending messages after two shots and it log “failed connection”. Anyway the zone entities are updated.
Is it possible to log the ACK/NAK response message in the log of HA?
I notice that if I set the ping interval to 1440 the entities doesn’t update theirs staus when HA receive an event message during that period. On the other side, if I set 1 minute, the entities become unavailable if nothing appens in 1 minute and 30 sec.

234

The ping interval is only used to mark the entities as unavailable in HA, should have no impact on the connection with your alarm. So if the ping_interval is set to 10 minutes in HA and the alarm doesn’t send a message for more than that (+30 seconds to allow for latency) it will go offline in HA, so make sure those settings are in sync between your alarm and HA. But, any message that comes into HA is handled regardless of the ping_interval!

235

Thanks a lot for your quick support, I’ll do more tests. The alarm system is setted up to send the automatic test report once a day, so I’ll set the ping at 1440 min. I’ll give you a feedback in next days.
Do you think is it possible to log the ACT/NAK message? I think that the alarm system receives a NAK or perhaps it doesn’t receive any message.

236

So it did the same thing tonight. At 05:08:32 the alarm status in HA changed to armed away, then at 05:19:03 it switched back to disarmed. From the full log-file in HA:

2020-11-02 05:08:08 DEBUG (MainThread) [pysiaalarm.aio.sia_server] Incoming line: 95E60039"SIA-DCS"7655L0#XXX[#XXX|Nri0/RP0000]_04:08:27,11-02-2020

2020-11-02 05:08:08 DEBUG (MainThread) [pysiaalarm.base_sia_server] Parsed event: Content: #XXX|Nri0/RP0000]_04:08:27,11-02-2020, Zone: 0, Code: RP, Message: 0000, Concerns: Unused, Type: Automatic Test, Description: Automatic communication test report, Account: XXX, Receiver: None, Prefix: L0, Timestamp: 2020-11-02 04:08:27, Length: 0039, Sequence: 7655, CRC: 95E6, Calc CRC: 95E6, Message type: Automatic Test, Encrypted Content: None, Full Message: "SIA-DCS"7655L0#XXX[#XXX|Nri0/RP0000]_04:08:27,11-02-2020..

2020-11-02 05:08:32 DEBUG (MainThread) [pysiaalarm.aio.sia_server] Incoming line: 0ED40038"SIA-DCS"7656L0#XXX[#XXX|Nri1/CL502]_04:08:51,11-02-2020

2020-11-02 05:08:32 DEBUG (MainThread) [pysiaalarm.base_sia_server] Parsed event: Content: #XXX|Nri1/CL502]_04:08:51,11-02-2020, Zone: 1, Code: CL, Message: 502, Concerns: User number, Type: Closing Report, Description: System armed, normal, Account: XXX, Receiver: None, Prefix: L0, Timestamp: 2020-11-02 04:08:51, Length: 0038, Sequence: 7656, CRC: 0ED4, Calc CRC: 0ED4, Message type: Closing Report, Encrypted Content: None, Full Message: "SIA-DCS"7656L0#XXX[#XXX|Nri1/CL502]_04:08:51,11-02-2020..

Then the disarmed event:

2020-11-02 05:18:08 DEBUG (MainThread) [pysiaalarm.aio.sia_server] Incoming line: 41240039"SIA-DCS"7666L0#XXX[#XXX|Nri0/RP0000]_04:18:27,11-02-2020
2020-11-02 05:18:08 DEBUG (MainThread) [pysiaalarm.base_sia_server] Parsed event: Content: #XXX|Nri0/RP0000]_04:18:27,11-02-2020, Zone: 0, Code: RP, Message: 0000, Concerns: Unused, Type: Automatic Test, Description: Automatic communication test report, Account: XXX, Receiver: None, Prefix: L0, Timestamp: 2020-11-02 04:18:27, Length: 0039, Sequence: 7666, CRC: 4124, Calc CRC: 4124, Message type: Automatic Test, Encrypted Content: None, Full Message: "SIA-DCS"7666L0#XXX[#XXX|Nri0/RP0000]_04:18:27,11-02-2020..

2020-11-02 05:19:03 DEBUG (MainThread) [pysiaalarm.aio.sia_server] Incoming line: 072C0038"SIA-DCS"7667L0#XXX[#XXX|Nri1/OP502]_04:19:22,11-02-2020

2020-11-02 05:19:03 DEBUG (MainThread) [pysiaalarm.base_sia_server] Parsed event: Content: #XXX|Nri1/OP502]_04:19:22,11-02-2020, Zone: 1, Code: OP, Message: 502, Concerns: User number, Type: Opening Report, Description: Account was disarmed, Account: XXX, Receiver: None, Prefix: L0, Timestamp: 2020-11-02 04:19:22, Length: 0038, Sequence: 7667, CRC: 072C, Calc CRC: 072C, Message type: Opening Report, Encrypted Content: None, Full Message: "SIA-DCS"7667L0#XXX[#XXX|Nri1/OP502]_04:19:22,11-02-2020..

Any ideas why it acts like this? It does not seem to happen at a specific time since it changes from day to day… but seems to happen only during night time.

237

No idea why, but CL and OP are the most generic Armed and Disarmed command sent by Ajax, user, spacecontrol or keypad all emit that code when arming or disarming, so there should be something in your ajax log that shows what’s going on. You could reach out to Ajax to see if the 502 message has any special meaning.

238

This is where the response is created and a warning is thrown on anything by the ACK, so a NAK or DUH will put a warning in the log. So if you have debug setup like mentioned here: HA SIA Debug you will see anything that isn’t acknowledged.

239

Hi Eduard, I found out that the valid_timestamp function checks the utc time but the alarm system sends the current time (CET) since it doesn’t have a timezone setting, so the timediff is 1 or 2 hours (Standard or DLS time). Furthermore, it’s quite difficult for me to set manually the correct time in the system. The best for me is to avoid the check with an option in the SIA config. For now I skip the error setting the allowed_timeband = (180, 7380) in the line #85 of the custom_components/sia/hub.py as you suggested.
Thanks a lot.

240

Might have found the root cause. My outdoor siren has been turned off since I have not mounted it yet. So it has been unreachable. This in combination with me turning on the option “System Integrity Check” might have caused the strange behavior. Yesterday I unpaired the siren, and tonight there has been no switching on/off. Hopefully this solved it…

241

Fantastic, thanks for making sure and reporting back!

242

According to the SIA spec the timestamp should always be submitted in GMT (pretty much the same as UTC), so check if your alarm system does that accurately!

244

Unfortunately not (there may be in a newer FW, don’t know). Anyway now it’s running pretty well.
Thanks for your help and your great job.

245

I’ve had 4 days/nights without any strange behavior now - so avoid having unreachable/turned off units in combination with the “System Integrity Check” enabled will solve this issue.

246

Thanks @freland for checking!