search

eavanvalkenburg / pysiaalarm

A python package to connect to a SIA DC-09 based alarm system.
MIT License
37 stars 30 forks source link

Aritech - ATS1000A - test connection #49

Open RPJacobs opened 1 year ago

RPJacobs commented 1 year ago

We have a php sia pac script but trying to switch to pysiaalarm for HA intergration.

If I start run.py with the same port and key, my alarm generates the following error

Config:  {'host': '0.0.0.0', 'port': 12300, 'account_id': '123456', 'key': 'xxxxxxxxxxxxxx'}
DEBUG:pysiaalarm.sync.client:Starting SIA.
----------------------------------------
Exception happened during processing of request from ('x.x.x.x', 1203)
Traceback (most recent call last):
  File "/usr/lib/python3.8/socketserver.py", line 683, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/lib/python3.8/socketserver.py", line 360, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python3.8/socketserver.py", line 747, in __init__
    self.handle()
  File "/home/jacobs/github/Kiwatt/pysiaalarm/tests/pysiaalarm/sync/handler.py", line 44, in handle
    raw = self.request.recv(1024)
ConnectionResetError: [Errno 104] Connection reset by peer
----------------------------------------

I think this is due to the fact that the alarm first needs a (scrambled) 48 hex key send to it before it gives the sia message. After the alarm connects to the port my php script send the key to the alarm:

    function connect($socket){
        $client = new pacClient($this, $socket, $this->clientNr++);
        $this->clients[(int)$socket] = $client;
        $this->sockets[] = $socket;

        socket_getpeername($socket, $addr);
        $this->clients[(int)$socket]->ip = $addr;
        $this->log('#'.$client->id.': client connected '.$socket.' ('.$addr.')', 'light_green');
        $client->sendKey();
    }

    function sendKey(){
        $scramble = hex2bin('xxxxxxxxxxxxxxxxxxxxxxxxxxxx');
        $keyLength = strlen($scramble);

        $key = openssl_random_pseudo_bytes($keyLength);
        $this->key = $key;

        for($i = 0; $i < $keyLength; $i++){
            $key[$i] = $key[$i] ^ $scramble[$i];
        }
        $this->server->log($this->key, 'light_red');
        $this->send($key);
    }

    function send($message, $encrypt = false){
        if($this->server->debug){
            $this->server->log('#'.$this->id.": send\n".hexdump($message), 'red');
        }

        if($encrypt){
            $message = $this->encrypt($message);
        }
        socket_write($this->socket, $message, strlen($message));
    }
[Wed, 10 May 2023 15:03:59 +0200] #21: client connected Resource id #33 (x.x.x.x)
[Wed, 10 May 2023 15:03:59 +0200] #21: send
0000: 79 59 BB 2A 21 F0 20 58 C6 DE 85 2D 02 B8 94 CA  yY.*!..X...-....
0010: E8 6F FF 0B 16 9F 2F D4                          .o..../.

[Wed, 10 May 2023 15:03:59 +0200] #21: recv
0000: 53 52 30 30 30 31 4C 30 30 30 31 20 20 20 20 31  SR0001L0001....1
0010: 32 33 34 35 36 58 58 20 20 20 20 00 00 00 00 00  23456XX.........

[Wed, 10 May 2023 15:03:59 +0200] #21: send
0000: 41 43 4B 0D 00 00 00 00                          ACK.....

please advice

RPJacobs commented 1 year ago

I got the decoding working but it seem te be a different SIA protocol:

0101002F"SIA-DCS"0013R0001L0001[#123456|NNR003]

bjornmorsman commented 1 year ago

ik neem aan dat je in jou ats een pac hebt geprogrammeerd met het ip adres en poort van system wat pysiaalarm draait?

RPJacobs commented 1 year ago

Dat klopt

ThaSteef commented 10 months ago

I would love to see the Aritech ATSx000 and ATSx500 series work with this integration.

I have total access to both systems of you guys need anything to test. Im a Installer. And we also install the alphatronics UNii systems, which work with DC09 protocol, havent tested that.

If i can be of any assistance... Let me know.

sanderpleijers commented 8 months ago

NL: Zou mooi zijn als dit gaat werken!

Back to English: @RPJacobs; did you get anywhere with this? I have the same ATS1000A-IP-MM board. If you look at the UTCAR parser.go you can see some example regex patterns. If you need to test something, please let me know.

Can you share the php files you have?

A github user wichers also made an interesting pull request: https://github.com/eavanvalkenburg/pysiaalarm/pull/44 with support for our panels/alarms. @eavanvalkenburg is there anything we can do to get this installed for testing?

wichers commented 7 months ago

Due to time constraints and too many projects I was putting this on hold, would be great if someone would pick this up. fyi. I did get my implementation working with my ATS after hacking it into HA.

sanderpleijers commented 7 months ago

Hi @wichers; any instructions/hints on how to set it up in HA? I do have the custom_components\sia, but how to use your version of the pysiaalarm? Is that done via the manifest.json?

I can also test the functionality if i get it running...

ThaSteef commented 7 months ago

Yes, some tips for HA are welcome.

voskuh commented 6 months ago

Based on the work of @wichers I adapted pysiaalarm to enable communication with my ATS1000A. See https://github.com/voskuh/pysiaalarm

To test the changes I cloned the home assistant SIA integration to a new repo and custom component. The custom SIA component uses the adapted pysialarm repo and adds an option to select OH protocol in the config flow. Furthermore there are some minor tweaks in code consequences in the alarm panel. It's necessary to use a 6 digit account id or add preceding 0's if you have a shorter account id in the settings of your alarm system. It's still work in progress. https://github.com/voskuh/custom-sia

bjornmorsman commented 6 months ago

Hi voskuh,

thanx for the great work! Can you tell us how we can install and use your custom component?

voskuh commented 6 months ago

Hi Bjorn,

You need to copy the custom-sia repository to your home assistant config folder (the same folder where the configuration.yaml file is located). Then, when you install the SIA integration in the integration section (Settings > Devices & Services) this custom component will override the build in integration.

bjornmorsman commented 6 months ago

Hi Voskuh,

i am testing right now, when i install the custom sia as you said i get the following error. do you know what the problem is?

Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/config_entries.py", line 444, in async_setup result = await component.async_setup_entry(hass, self) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/custom_components/sia/init.py", line 14, in async_setup_entry hub.async_setup_hub() File "/config/custom_components/sia/hub.py", line 54, in async_setup_hub self.update_accounts() File "/config/custom_components/sia/hub.py", line 117, in update_accounts protocol=CommunicationsProtocol(self._protocol), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/enum.py", line 744, in call return cls.new(cls, value) ^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/enum.py", line 1158, in new raise ve_exc ValueError: 'OH' is not a valid CommunicationsProtocol

ThaSteef commented 6 months ago

Nice work Voskuh,

I also tried to install, but with no luck. Same sort of errors occur i believe.

Running HA on a VM on my NAS. I did use the HACS way om importing a custom repository, not a manual copy of the files.

voskuh commented 6 months ago

There is a failure to load the adapted version of pysiaalarm. I made some changes in the manifest.json file. So I hope that it will install correctly. Please make sure to first remove the SIA integration in the integrations section in HA. Then update in HACS or re-install the custom component (remove files and copy the new files). Restart HA and try to set up the integration again. Hope that will fix the issue.

bjornmorsman commented 6 months ago

Hi Voskuh,

Thnx for fixing the error, how did you program you pac in the ats8500 software? if i program it the way i am used to i get all sorts of errors. FTC, connection to pac failed. i think 1 at 10 messages gets to the custom component, al the others will fail. also a manual test call to the component will fail.

is that correct?

Thanx in advance

voskuh commented 6 months ago

I don't have the ats8500 software. So can't give you a fancy screenshot of my settings. I hope to get the software in the future because I want to control the alarm system with HA as well, but it needs reverse engineering. Ip address of home assistant port: an unused port (same port in PAC and integration settings), client number: random 6 digit number (must be same in PAC and integration settings). Protocol: oh-xsia mode: Primary PAC I don't have any errors on my GI and the connection to the custom component is stable since this morning (after some changes I made to the pysiaalarm repo). Before I had connection issues as well. Would you mind enable debug logging of the integration in home assistant and share the log.

ThaSteef commented 6 months ago

I can set you up with the latest software version, and firmware versions. Technical documents, some knowhow and 18 years of experience with this brand.

On topic, I think i got the HA part working, but its not receiving information at the moment. Could be on the ATS side of programming or something else, but i havent had time to check.

I use the ATS1500A-IP series (there is also a totally new model the ATS1700 on the market but i havent seen that yet.

Op wo 13 mrt 2024 19:06 schreef voskuh @.***>:

I don't have the ats8500 software. So can't give you a fancy screenshot of my settings. I hope to get the software in the future because I want to control the alarm system with HA as well, but it needs reverse engineering. Ip address of home assistant port: an unused port (same port in PAC and integration settings), client number: random 6 digit number (must be same in PAC and integration settings). Protocol: oh-xsia mode: Primary PAC I don't have any errors on my GI and the connection to the custom component is stable since this morning (after some changes I made to the pysiaalarm repo). Before I had connection issues as well. Would you mind enable debug logging of the integration in home assistant and share the log.

— Reply to this email directly, view it on GitHub https://github.com/eavanvalkenburg/pysiaalarm/issues/49#issuecomment-1995218656, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVNVUNZIRAPV36AIFJARL6LYYCIR3AVCNFSM6AAAAAAX4ZF63KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJVGIYTQNRVGY . You are receiving this because you commented.Message ID: @.***>

sanderpleijers commented 6 months ago

@voskuh ; First of all thank you so much for your effort and time! Im waiting for this for so long now! :-D @ThaSteef ; I am interested in the latest software, mine is very old unfortunately. Can you share?

I use an ATS1000AIP. I have the custom_component setup like (screenshot has a 0 to much on the port btw) 2024-03-13 20_10_20-Window

And in ATS8500 downloader: 2024-03-13 20_11_40-Window

But nothing valid seems to come trough. Did i select the correct values in ATS8500? This is the home assistant log;

024-03-13 20:04:04.360 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'\n01010052"SIA-DCS"0002R0001L0001[#696900|NRP000*\'Paneel\'NM]EC0974F06D2C60A6|#696900\r\x00\x00\x00\x00'
2024-03-13 20:04:04.360 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 01010052"SIA-DCS"0002R0001L0001[#696900|NRP000*'Paneel'NM]EC0974F06D2C60A6|#696900
2024-03-13 20:04:04.361 WARNING (MainThread) [pysiaalarm.base_server] Last line could not be parsed succesfully. Error message: Parse content: no matches found in #696900|NRP000*'Paneel'NM]EC0974F06D2C60A6|#696900, using matcher: re.compile('\n[#]?(?P<account>[A-Fa-f0-9]{3,16})?\n[|]?\n[N]?\n(?:ti)?(?:(?<=ti)(?P<ti>\\d{2}:\\d{2}))?\\/?\n(?:id)?(?:(?<=id)(?P<id>\\d*))?\\/?\n(?:ri)?(?:(?<=ri)(?P<ri>\\d*))?\\/?\n(?P<code>[a-zA-Z]{2})?\n(?P<, re.VERBOSE). Line: 01010052"SIA-DCS"0002R0001L0001[#696900|NRP000*'Paneel'NM]EC0974F06D2C60A6|#696900
2024-03-13 20:04:04.362 DEBUG (MainThread) [pysiaalarm.aio.server] Response send to alarm system: b'\n4A080025"NAK"0000L0R0A0[]_19:04:04,03-13-2024\r'
voskuh commented 6 months ago

Great to see that at least some messages came through. Although the custom component can't read them properly. Seeing the incoming lines is very helpful. There are two types of incoming lines. A heartbeat (frequency based on heartbeat time) and other states. Incoming lines for my system: Heartbeat: SR0001L0001 072538XX Other state: 01010039"SIA-DCS"0002R0001L0001[#072538|Nri01/CL003*''NM]

So if your system is sending messages in an other format, it's likely that they will not be recognized and it will fail. So we will need to add new Regex patterns for these line formats to fix it.

@ThaSteef If it's possible to get the software I would be delighted. Can you provide me some HA debug logs as well? @sanderpleijers When I compare your settings with mine, the only difference is Protocol OH version mine is OH V 1.9.3. Maybe that explains the difference in incoming line format?

wichers commented 6 months ago

Nice to see someone picking this up. It could be helpful to have a look at OH Network Receiver ver. 3.2.4.4 User Manual, there are some SIA specific details about SIA message formatting. I think it would be even more helpful to get that software, so you don't need to do the reverse engineering of the messages from scratch.

wichers commented 6 months ago

btw. It doesn't take much to get most of the software, I registered myself at https://secure.carriercms.com/ a long time ago. There you can find the ATS8500 software and firmware for your ATS. The OH Net Rec - Software page is restricted though. There should be a 4 user (limited) demo version of the OH NetRec software, somewhere..

eavanvalkenburg commented 6 months ago

hi all, love the interaction here, unfortunately I have sold the house with my alarm system, so no longer have a SIA enabled device to test against, if someone wants to be co-owner of this repo so that you can get these developments tested, integrated and release let me know!

sanderpleijers commented 6 months ago

@sanderpleijers When I compare your settings with mine, the only difference is Protocol OH version mine is OH V 1.9.3. Maybe that explains the difference in incoming line format?

I tried setting it to OH V 1.9.3 but no change. Messages are coming in so it seems there is data only why is it different? Maybe different in room/panel setup? @voskuh can you check if every setting is exactly the same?

The data is looking good but sensors are not updated:

2024-03-14 11:37:06.588 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 01010040"SIA-DCS"0045R0001L0001[#696900|NUA010*'HA Woonkamer'NM]
2024-03-14 11:37:06.588 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '696900', 'ti': None, 'id': None, 'ri': None, 'code': 'UA', 'message': "010*'HA Woonkamer'NM", 'xdata': None, 'timestamp': ''}
2024-03-14 11:37:06.594 DEBUG (MainThread) [pysiaalarm.aio.server] Response send to alarm system: b'\n29C5001C"ACK"0045R0001L0001#696900[]\r'
2024-03-14 11:37:06.595 DEBUG (MainThread) [custom_components.sia.hub] Adding event to dispatch and bus for code UA for port 12300 and account 696900
2024-03-14 11:37:06.595 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #696900|NUA010*'HA Woonkamer'NM], Zone (ri): None, Code: UA, Message: 010*'HA Woonkamer'NM, Account: 696900, Receiver: R0001, Line: L0001, Timestamp: None, Length: 0040, Sequence: 0045, CRC: 0101, Calc CRC: 00DA, Encrypted Content: None, Full Message: "SIA-DCS"0045R0001L0001[#696900|NUA010*'HA Woonkamer'NM].
2024-03-14 11:37:06.596 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #696900|NUA010*'HA Woonkamer'NM], Zone (ri): None, Code: UA, Message: 010*'HA Woonkamer'NM, Account: 696900, Receiver: R0001, Line: L0001, Timestamp: None, Length: 0040, Sequence: 0045, CRC: 0101, Calc CRC: 00DA, Encrypted Content: None, Full Message: "SIA-DCS"0045R0001L0001[#696900|NUA010*'HA Woonkamer'NM].
2024-03-14 11:37:06.596 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #696900|NUA010*'HA Woonkamer'NM], Zone (ri): None, Code: UA, Message: 010*'HA Woonkamer'NM, Account: 696900, Receiver: R0001, Line: L0001, Timestamp: None, Length: 0040, Sequence: 0045, CRC: 0101, Calc CRC: 00DA, Encrypted Content: None, Full Message: "SIA-DCS"0045R0001L0001[#696900|NUA010*'HA Woonkamer'NM].
2024-03-14 11:37:31.296 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'SR0001L0001 696900XX \x00\x00\x00\x00\x00'
wichers commented 6 months ago

@voskuh, Here is a simplified server implementation that is working well for me: https://gist.github.com/wichers/31a7e2ff1e9a1bb36b8412642766cd69

I still need to have a look at the types of response messages though.

ThaSteef commented 6 months ago

ATS8500 software and the update for the latest version are here: (for a few days) https://wetransfer.com/downloads/2e00226452853fc69cc95346aeb3d75420240314192732/07a8baa1aa807bc41ea75fe0f23cc3a520240314192752/7e4a24?trk=TRN_TDL_01&utm_campaign=TRN_TDL_01&utm_medium=email&utm_source=sendgrid

There is also the latest version for a ATSx500A-ip alarm panel. DONT USE IT ON A ATSx000a-IP PANEL!! IF YOU HAVE A OLD FIRMWARE VERSION, PERHAPSE YOU MUST UPDATE THE BOOTLOADER FIRST. if that is the case, let me know.

ThaSteef commented 6 months ago

@sanderpleijers When I compare your settings with mine, the only difference is Protocol OH version mine is OH V 1.9.3. Maybe that explains the difference in incoming line format?

I tried setting it to OH V 1.9.3 but no change. Messages are coming in so it seems there is data only why is it different? Maybe different in room/panel setup? @voskuh can you check if every setting is exactly the same?

The data is looking good but sensors are not updated:

2024-03-14 11:37:06.588 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 01010040"SIA-DCS"0045R0001L0001[#696900|NUA010*'HA Woonkamer'NM]
2024-03-14 11:37:06.588 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '696900', 'ti': None, 'id': None, 'ri': None, 'code': 'UA', 'message': "010*'HA Woonkamer'NM", 'xdata': None, 'timestamp': ''}
2024-03-14 11:37:06.594 DEBUG (MainThread) [pysiaalarm.aio.server] Response send to alarm system: b'\n29C5001C"ACK"0045R0001L0001#696900[]\r'
2024-03-14 11:37:06.595 DEBUG (MainThread) [custom_components.sia.hub] Adding event to dispatch and bus for code UA for port 12300 and account 696900
2024-03-14 11:37:06.595 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #696900|NUA010*'HA Woonkamer'NM], Zone (ri): None, Code: UA, Message: 010*'HA Woonkamer'NM, Account: 696900, Receiver: R0001, Line: L0001, Timestamp: None, Length: 0040, Sequence: 0045, CRC: 0101, Calc CRC: 00DA, Encrypted Content: None, Full Message: "SIA-DCS"0045R0001L0001[#696900|NUA010*'HA Woonkamer'NM].
2024-03-14 11:37:06.596 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #696900|NUA010*'HA Woonkamer'NM], Zone (ri): None, Code: UA, Message: 010*'HA Woonkamer'NM, Account: 696900, Receiver: R0001, Line: L0001, Timestamp: None, Length: 0040, Sequence: 0045, CRC: 0101, Calc CRC: 00DA, Encrypted Content: None, Full Message: "SIA-DCS"0045R0001L0001[#696900|NUA010*'HA Woonkamer'NM].
2024-03-14 11:37:06.596 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #696900|NUA010*'HA Woonkamer'NM], Zone (ri): None, Code: UA, Message: 010*'HA Woonkamer'NM, Account: 696900, Receiver: R0001, Line: L0001, Timestamp: None, Length: 0040, Sequence: 0045, CRC: 0101, Calc CRC: 00DA, Encrypted Content: None, Full Message: "SIA-DCS"0045R0001L0001[#696900|NUA010*'HA Woonkamer'NM].
2024-03-14 11:37:31.296 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'SR0001L0001 696900XX \x00\x00\x00\x00\x00'

The new versions of OH should bring extra features or new sensors. But the basics stay the same. If extra functionalities or new type of sensors come along they are added to the protocol. Current version is V4.0

voskuh commented 6 months ago

Thanks for all the helpful comments and the download link. Will try to install and connect to my alarm system asap.

@sanderpleijers When I compare your settings with mine, the only difference is Protocol OH version mine is OH V 1.9.3. Maybe that explains the difference in incoming line format?

I tried setting it to OH V 1.9.3 but no change. Messages are coming in so it seems there is data only why is it different? Maybe different in room/panel setup? @voskuh can you check if every setting is exactly the same?

The data is looking good but sensors are not updated:

2024-03-14 11:37:06.588 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 01010040"SIA-DCS"0045R0001L0001[#696900|NUA010*'HA Woonkamer'NM]
2024-03-14 11:37:06.588 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '696900', 'ti': None, 'id': None, 'ri': None, 'code': 'UA', 'message': "010*'HA Woonkamer'NM", 'xdata': None, 'timestamp': ''}
2024-03-14 11:37:06.594 DEBUG (MainThread) [pysiaalarm.aio.server] Response send to alarm system: b'\n29C5001C"ACK"0045R0001L0001#696900[]\r'
2024-03-14 11:37:06.595 DEBUG (MainThread) [custom_components.sia.hub] Adding event to dispatch and bus for code UA for port 12300 and account 696900
2024-03-14 11:37:06.595 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #696900|NUA010*'HA Woonkamer'NM], Zone (ri): None, Code: UA, Message: 010*'HA Woonkamer'NM, Account: 696900, Receiver: R0001, Line: L0001, Timestamp: None, Length: 0040, Sequence: 0045, CRC: 0101, Calc CRC: 00DA, Encrypted Content: None, Full Message: "SIA-DCS"0045R0001L0001[#696900|NUA010*'HA Woonkamer'NM].
2024-03-14 11:37:06.596 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #696900|NUA010*'HA Woonkamer'NM], Zone (ri): None, Code: UA, Message: 010*'HA Woonkamer'NM, Account: 696900, Receiver: R0001, Line: L0001, Timestamp: None, Length: 0040, Sequence: 0045, CRC: 0101, Calc CRC: 00DA, Encrypted Content: None, Full Message: "SIA-DCS"0045R0001L0001[#696900|NUA010*'HA Woonkamer'NM].
2024-03-14 11:37:06.596 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #696900|NUA010*'HA Woonkamer'NM], Zone (ri): None, Code: UA, Message: 010*'HA Woonkamer'NM, Account: 696900, Receiver: R0001, Line: L0001, Timestamp: None, Length: 0040, Sequence: 0045, CRC: 0101, Calc CRC: 00DA, Encrypted Content: None, Full Message: "SIA-DCS"0045R0001L0001[#696900|NUA010*'HA Woonkamer'NM].
2024-03-14 11:37:31.296 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'SR0001L0001 696900XX \x00\x00\x00\x00\x00'

I can see in your logs that it's working correctly and the event is send to home assistant. But not all SIA codes will change the status of the alarm in HA. See https://github.com/voskuh/custom-sia/blob/master/custom_components/sia/alarm_control_panel.py (line 41 and further) for all SIA codes that lead to a change. It's possible to use other codes in automations. For example (in event_type 12300 is my port number and 072538 client ID):

id: '1710365833280'
alias: Alarm events
description: ''
trigger:
  - platform: event
    event_type: sia_event_12300_072538
condition:
  - condition: not
    conditions:
      - condition: template
        value_template: '{{trigger.event.data.code == "RP"}}'
action:
  - service: notify.signal_messages
    metadata: {}
    data:
      message: 'Alarm event ontvangen: {{trigger.event.data}}'
mode: single

So I assume the V1.9.3. format is parsed correctly, but there can be some issues with receiving all events. I hope to update the repo tomorrow to support protocol OH v3 and fix an issue where not all messages come through.

bjornmorsman commented 6 months ago

@sanderpleijers when i connect my system (ats3500) to the integration i get heartbeat errors and in the end an FTC. Do you see this behavior to?

2024-03-15 04:34:23.987 DEBUG (MainThread) [pysiaalarm.aio.client] Starting OH-SIA.
2024-03-15 04:34:38.350 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'\n0101003B"SIA-DCS"0003R0001L0001[#001991|NRS000*\'Morsman\'NM]\r\x00\x00\x00'
2024-03-15 04:34:38.350 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 0101003B"SIA-DCS"0003R0001L0001[#001991|NRS000*'Morsman'NM]
2024-03-15 04:34:38.350 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '001991', 'ti': None, 'id': None, 'ri': None, 'code': 'RS', 'message': "000*'Morsman'NM", 'xdata': None, 'timestamp': ''}
2024-03-15 04:34:38.355 DEBUG (MainThread) [custom_components.sia.hub] Adding event to dispatch and bus for code RS for port 12400 and account 001991
2024-03-15 04:34:38.355 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #001991|NRS000*'Morsman'NM], Zone (ri): None, Code: RS, Message: 000*'Morsman'NM, Account: 001991, Receiver: R0001, Line: L0001, Timestamp: None, Length: 003B, Sequence: 0003, CRC: 0101, Calc CRC: BEEB, Encrypted Content: None, Full Message: "SIA-DCS"0003R0001L0001[#001991|NRS000*'Morsman'NM].
2024-03-15 04:34:38.355 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #001991|NRS000*'Morsman'NM], Zone (ri): None, Code: RS, Message: 000*'Morsman'NM, Account: 001991, Receiver: R0001, Line: L0001, Timestamp: None, Length: 003B, Sequence: 0003, CRC: 0101, Calc CRC: BEEB, Encrypted Content: None, Full Message: "SIA-DCS"0003R0001L0001[#001991|NRS000*'Morsman'NM].
2024-03-15 04:34:38.355 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #001991|NRS000*'Morsman'NM], Zone (ri): None, Code: RS, Message: 000*'Morsman'NM, Account: 001991, Receiver: R0001, Line: L0001, Timestamp: None, Length: 003B, Sequence: 0003, CRC: 0101, Calc CRC: BEEB, Encrypted Content: None, Full Message: "SIA-DCS"0003R0001L0001[#001991|NRS000*'Morsman'NM].
2024-03-15 04:34:44.098 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'SR0001L0001 001991XX \x00\x00\x00\x00\x00'
2024-03-15 04:34:44.098 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: SR0001L0001 001991XX 
2024-03-15 04:34:44.101 DEBUG (MainThread) [custom_components.sia.hub] Adding event to dispatch and bus for code RP for port 12400 and account 001991
2024-03-15 04:34:44.101 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: None, Zone (ri): None, Code: RP, Message: , Account: 001991, Receiver: 0001, Line: 0001, Timestamp: None, Length: 32, Sequence: None, CRC: , Calc CRC: None, Encrypted Content: None, Full Message: SR0001L0001 001991XX .
2024-03-15 04:34:44.102 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: None, Zone (ri): None, Code: RP, Message: , Account: 001991, Receiver: 0001, Line: 0001, Timestamp: None, Length: 32, Sequence: None, CRC: , Calc CRC: None, Encrypted Content: None, Full Message: SR0001L0001 001991XX .
2024-03-15 04:34:44.102 DEBUG (MainThread) [custom_components.sia.binary_sensor] New state will be True
2024-03-15 04:34:44.102 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: None, Zone (ri): None, Code: RP, Message: , Account: 001991, Receiver: 0001, Line: 0001, Timestamp: None, Length: 32, Sequence: None, CRC: , Calc CRC: None, Encrypted Content: None, Full Message: SR0001L0001 001991XX .
2024-03-15 04:35:15.606 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'\n0101003B"SIA-DCS"0004R0001L0001[#001991|NRB000*\'Morsman\'NM]\r\x00\x00\x00'
2024-03-15 04:35:15.606 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 0101003B"SIA-DCS"0004R0001L0001[#001991|NRB000*'Morsman'NM]
2024-03-15 04:35:15.607 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '001991', 'ti': None, 'id': None, 'ri': None, 'code': 'RB', 'message': "000*'Morsman'NM", 'xdata': None, 'timestamp': ''}
2024-03-15 04:35:15.611 DEBUG (MainThread) [custom_components.sia.hub] Adding event to dispatch and bus for code RB for port 12400 and account 001991
2024-03-15 04:35:15.612 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #001991|NRB000*'Morsman'NM], Zone (ri): None, Code: RB, Message: 000*'Morsman'NM, Account: 001991, Receiver: R0001, Line: L0001, Timestamp: None, Length: 003B, Sequence: 0004, CRC: 0101, Calc CRC: 6F8A, Encrypted Content: None, Full Message: "SIA-DCS"0004R0001L0001[#001991|NRB000*'Morsman'NM].
2024-03-15 04:35:15.612 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #001991|NRB000*'Morsman'NM], Zone (ri): None, Code: RB, Message: 000*'Morsman'NM, Account: 001991, Receiver: R0001, Line: L0001, Timestamp: None, Length: 003B, Sequence: 0004, CRC: 0101, Calc CRC: 6F8A, Encrypted Content: None, Full Message: "SIA-DCS"0004R0001L0001[#001991|NRB000*'Morsman'NM].
2024-03-15 04:35:15.612 DEBUG (MainThread) [custom_components.sia.sia_entity_base] Received event: Content: #001991|NRB000*'Morsman'NM], Zone (ri): None, Code: RB, Message: 000*'Morsman'NM, Account: 001991, Receiver: R0001, Line: L0001, Timestamp: None, Length: 003B, Sequence: 0004, CRC: 0101, Calc CRC: 6F8A, Encrypted Content: None, Full Message: "SIA-DCS"0004R0001L0001[#001991|NRB000*'Morsman'NM].
2024-03-15 04:35:28.010 DEBUG (MainThread) [pysiaalarm.aio.client] Stopping OH-SIA.
2024-03-15 04:35:28.011 DEBUG (MainThread) [pysiaalarm.aio.client] Starting OH-SIA.
2024-03-15 04:36:37.294 DEBUG (MainThread) [pysiaalarm.aio.client] Stopping OH-SIA.
2024-03-15 04:36:37.294 DEBUG (MainThread) [pysiaalarm.aio.client] Starting OH-SIA.
2024-03-15 04:37:39.136 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'\n01010053"SIA-DCS"0001R0001L0001[#001991|NRS000*\'Morsman\'NM]F18CF5754F6B9D9E|#001991\r\x00\x00\x00'
2024-03-15 04:37:39.136 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 01010053"SIA-DCS"0001R0001L0001[#001991|NRS000*'Morsman'NM]F18CF5754F6B9D9E|#001991
2024-03-15 04:37:39.136 WARNING (MainThread) [pysiaalarm.base_server] Last line could not be parsed succesfully. Error message: Parse content: no matches found in #001991|NRS000*'Morsman'NM]F18CF5754F6B9D9E|#001991, using matcher: re.compile('\n[#]?(?P<account>[A-Fa-f0-9]{3,16})?\n[|]?\n[N]?\n(?:ti)?(?:(?<=ti)(?P<ti>\\d{2}:\\d{2}))?\\/?\n(?:id)?(?:(?<=id)(?P<id>\\d*))?\\/?\n(?:ri)?(?:(?<=ri)(?P<ri>\\d*))?\\/?\n(?P<code>[a-zA-Z]{2})?\n(?P<, re.VERBOSE). Line: 01010053"SIA-DCS"0001R0001L0001[#001991|NRS000*'Morsman'NM]F18CF5754F6B9D9E|#001991
2024-03-15 04:37:39.148 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'\n01010053"SIA-DCS"0002R0001L0001[#001991|NRB000*\'Morsman\'NM]F18CF5754F6B9D9E|#001991\r\x00\x00\x00'
2024-03-15 04:37:39.148 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 01010053"SIA-DCS"0002R0001L0001[#001991|NRB000*'Morsman'NM]F18CF5754F6B9D9E|#001991
2024-03-15 04:37:39.149 WARNING (MainThread) [pysiaalarm.base_server] Last line could not be parsed succesfully. Error message: Parse content: no matches found in #001991|NRB000*'Morsman'NM]F18CF5754F6B9D9E|#001991, using matcher: re.compile('\n[#]?(?P<account>[A-Fa-f0-9]{3,16})?\n[|]?\n[N]?\n(?:ti)?(?:(?<=ti)(?P<ti>\\d{2}:\\d{2}))?\\/?\n(?:id)?(?:(?<=id)(?P<id>\\d*))?\\/?\n(?:ri)?(?:(?<=ri)(?P<ri>\\d*))?\\/?\n(?P<code>[a-zA-Z]{2})?\n(?P<, re.VERBOSE). Line: 01010053"SIA-DCS"0002R0001L0001[#001991|NRB000*'Morsman'NM]F18CF5754F6B9D9E|#001991
voskuh commented 6 months ago

Did an update on the custom component and pysiaalarm. Changes are:

Please update or re-install. Make sure to reboot. I hope it will fix most of the errors. Let me know and provide the output of the debug log if you experience issues.

wichers commented 6 months ago

fyi updated my POC. I got my hands on both the V3 and V4 of OH-Netrec. My gist implementation https://gist.github.com/wichers/31a7e2ff1e9a1bb36b8412642766cd69 (mostly regexes and a little logic) is based on the V3 version and seems to be working with SIA/XSIA and CID.

wichers commented 6 months ago

Please note that in order to make it work your decryption should only contain return self._cipher.decrypt(data) the padding and the return characters are necessary to make the regex/logic work.

sanderpleijers commented 6 months ago

@voskuh; Wow! events are comming in like they should on the newest version. There also is no 'orange led' error anymore on the key-panel, so it seems to work better!

I made some yaml template sensors to get the motion sensor data. This works fine;

template:
  - trigger:
      - id: 'on'
        platform: event
        event_type: sia_event_12300_696900
        event_data:
            code: 'UA'
            message: "010*'HA Woonkamer'NM"
      - id: 'off'
        platform: event
        event_type: sia_event_12300_696900
        event_data:
            code: 'UR'
            message: "010*'HA Woonkamer'NM"
    binary_sensor:
      - name: "Alarm Woonkamer Beweging"
        device_class: motion
        state: "{{ trigger.id == 'on' }}"
        auto_off: 5 #off after 5s when triggered
bjornmorsman commented 6 months ago

Hi Voskuh,

Thnx for your work and the update, the messages are comming through this time. someting is stil wrong with the heartbeat is think

@sanderpleijers, what are you pac settings? is still get heartbeat errors and after some time an FTC.


2024-03-15 16:26:06.808 DEBUG (MainThread) [pysiaalarm.aio.server] Receive data...
2024-03-15 16:26:06.814 DEBUG (MainThread) [pysiaalarm.aio.server] Data received: b'\x02k9\xe2@\xcd\x8b\xd4\xfe\x07\x93\x88(AWd\x1d\x13I\xed\x86\xe5\xe8|V\xa5\x15\xbf\xca\x95B5\xb0\x97\xaa\xe4Xm\xa0`2\x9a<\n\x8d\xf3\xd4\xe3'
2024-03-15 16:26:06.814 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'SR0001L0001 001991XX \x00[ID00000000]\x00\x00\x00\x00\x00\x00\x00\x00'
2024-03-15 16:26:06.814 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: SR0001L0001 001991XX [ID00000000]
2024-03-15 16:26:06.814 WARNING (MainThread) [pysiaalarm.base_server] Last line could not be parsed succesfully. Error message: No matches found, event was not a SIA or ADM Spec event, line was: SR0001L0001 001991XX [ID00000000]. Line: SR0001L0001 001991XX [ID00000000]
2024-03-15 16:26:06.814 DEBUG (MainThread) [pysiaalarm.aio.server] Response send to alarm system: b'\nD8310025"NAK"0000L0R0A0[]_15:26:06,03-15-2024\r'
voskuh commented 6 months ago

Hi Voskuh,

Thnx for your work and the update, the messages are comming through this time. someting is stil wrong with the heartbeat is think

@sanderpleijers, what are you pac settings? is still get heartbeat errors and after some time an FTC.

2024-03-15 16:26:06.808 DEBUG (MainThread) [pysiaalarm.aio.server] Receive data...
2024-03-15 16:26:06.814 DEBUG (MainThread) [pysiaalarm.aio.server] Data received: b'\x02k9\xe2@\xcd\x8b\xd4\xfe\x07\x93\x88(AWd\x1d\x13I\xed\x86\xe5\xe8|V\xa5\x15\xbf\xca\x95B5\xb0\x97\xaa\xe4Xm\xa0`2\x9a<\n\x8d\xf3\xd4\xe3'
2024-03-15 16:26:06.814 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'SR0001L0001 001991XX \x00[ID00000000]\x00\x00\x00\x00\x00\x00\x00\x00'
2024-03-15 16:26:06.814 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: SR0001L0001 001991XX [ID00000000]
2024-03-15 16:26:06.814 WARNING (MainThread) [pysiaalarm.base_server] Last line could not be parsed succesfully. Error message: No matches found, event was not a SIA or ADM Spec event, line was: SR0001L0001 001991XX [ID00000000]. Line: SR0001L0001 001991XX [ID00000000]
2024-03-15 16:26:06.814 DEBUG (MainThread) [pysiaalarm.aio.server] Response send to alarm system: b'\nD8310025"NAK"0000L0R0A0[]_15:26:06,03-15-2024\r'

I made some more changes to the heartbeat parser. So please reinstall and try it!

bjornmorsman commented 6 months ago

Hi Voskuh,

and again thanx for the good work! Everything seems to work now. I get no heartbeat errors anymore an the sensors are updated properly.

i had to turn on Area Modifier to show te arm and disarm status in homeassistant, after that also the heartbeat errors are gone. After i changed oh version to 3.1 everything stil works.

When i thought everything is working properly ik got an FTC again. When i reprogram te ats the FTC goes back to normal but after some time it is comming back. The strange thing is, al the sensors keep working. No errors in the log, not in home assistant or in the ats8500 software.

the only error i see in home assistant is this one. so when the timestamp is ' ' everything is ok and when the timestamp is populated with number i get an error


ERROR
2024-03-16 05:34:38.402 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '001991', 'ti': None, 'id': None, 'ri': '04', 'code': 'UA', 'message': "059*'HA Woonkamer'NM", 'xdata': None, 'timestamp': '7713'}
2024-03-16 05:34:38.402 WARNING (MainThread) [pysiaalarm.event] Timestamp could not be parsed as a timestamp: 7713

NO ERROR
2024-03-16 06:15:39.314 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '001991', 'ti': None, 'id': None, 'ri': '02', 'code': 'CL', 'message': "001*'Installateur'NM", 'xdata': None, 'timestamp': ''}
2024-03-16 06:15:39.318 DEBUG (MainThread) [pysiaalarm.aio.server] Response send to alarm system: b'\n70E7001C"ACK"0008R0001L0001#001991[]\r'
ThaSteef commented 6 months ago

I will test my systems today, and let you guys know.

If you want to disable the heartbeat in your alarm panel, set the time to 23:59:59. Then the alarm will not check the heartbeat, not sure what that means to HA ..

Op za 16 mrt 2024 om 05:47 schreef bjornmorsman @.***>:

Hi Voskuh,

and again thanx for the good work! Everything seems to work now. I get no heartbeat errors anymore an the sensors are updated properly.

i had to turn on Area Modifier to show te arm and disarm status in homeassistant, after that also the heartbeat errors are gone. After i changed oh version to 3.1 everything stil works.

When i thought everything is working properly ik got an FTC again. When i reprogram te ats the FTC goes back to normal but after some time it is comming back. The strange thing is, al the sensors keep working. No errors in the log, not in home assistant or in the ats8500 software.

the only error i see in home assistant is this one.

2024-03-16 05:34:38.402 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '001991', 'ti': None, 'id': None, 'ri': '04', 'code': 'UA', 'message': "059*'HA Woonkamer'NM", 'xdata': None, 'timestamp': '7713'} 2024-03-16 05:34:38.402 WARNING (MainThread) [pysiaalarm.event] Timestamp could not be parsed as a timestamp: 7713

— Reply to this email directly, view it on GitHub https://github.com/eavanvalkenburg/pysiaalarm/issues/49#issuecomment-2001639998, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVNVUN2DRBDKP3COZDDBDYTYYPFGLAVCNFSM6AAAAAAX4ZF63KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBRGYZTSOJZHA . You are receiving this because you were mentioned.Message ID: @.***>

-- Met vriendelijke groeten,

Stefan Dekkers

ThaSteef commented 6 months ago

Working nice over here! I can see the zones stats, and connectivity.

Power status seems to be not working.

Can i somehow filter out the OP (disarming) en CL (arming) codes to know if the system is enabled or disabled

bjornmorsman commented 5 months ago

Did some testing last night but disabeling the heartbeat gives me still an FTC and the orange led on the panel. i still think it has something to do with the timestamp error below, when the timestamp get parsed correctly everything works fine, when i get an timestamp parsed error the ats log gives me "send to pac failed"

so when timestamp is ' ' everything is fine, when timestamp is populated as an number i get the parsed error.

@voskuh could you maybe check your code if you see some strange behaviour, its a bit unclear for me why the timestamp get populated with a number but not at every message send from the alarm panel.

i activated the "Ignore the timestamp check of the SIA events" option in the sia integration but that doesnt help.


2024-03-20 17:31:28.853 DEBUG (MainThread) [pysiaalarm.aio.server] Data received: b'l\xc6aa\xe6\xd0\x8d\x93\\}\xfa\x1e\x9e\x96\x7f-x\xe4\xd5\xd9\x9a\x17\x16S\x1fb@\x95\x8e$\x83\x93\x04h\xa1\x81\xee\xd8?\x9b\xb5\x01\xcf]\xd9\xeaF\x14\x07i\x15\xa0\xad\x964\xee\xd2\xef\xfa9\xcf>\x98\x17Q5_|\xf8*bW.\xc4\xde\x96\xf0\x12\xf0\xfa\x13<\x82\x91\xe1\x12\xd2\xe5\xac8\xabh\xde=\xb0tG\xc1!\xcb\xc0\xa1\xfd$'
2024-03-20 17:31:28.853 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'\n01010065"SIA-DCS"0148R0002L0001[#001991|Nri04/UR069*\'HA Overloop\'NM]2A52238E74F405CA|#001991T65FB0F5F\r\x00'
2024-03-20 17:31:28.853 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 01010065"SIA-DCS"0148R0002L0001[#001991|Nri04/UR069*'HA Overloop'NM]2A52238E74F405CA|#001991T65FB0F5F
2024-03-20 17:31:28.853 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '001991', 'ti': None, 'id': None, 'ri': '04', 'code': 'UR', 'message': "069*'HA Overloop'NM", 'xdata': None, 'timestamp': '2'}
2024-03-20 17:31:28.854 WARNING (MainThread) [pysiaalarm.event] Timestamp could not be parsed as a timestamp: 2
voskuh commented 5 months ago

Working nice over here! I can see the zones stats, and connectivity.

Power status seems to be not working.

Can i somehow filter out the OP (disarming) en CL (arming) codes to know if the system is enabled or disabled

Great it works out for you. When arming/disarming your alarm the alarm_control_panel entity will get the state armed_home, armed_away, disarmed. So you can use them in your automations. An other option is to listen to events. https://github.com/eavanvalkenburg/pysiaalarm/issues/49#issuecomment-1998481831 In the example I get a notification of all received messages of the alarm except the heartbeat (SIA code RP). Third option: you can make template sensors just like the way @sanderpleijers did. https://github.com/eavanvalkenburg/pysiaalarm/issues/49#issuecomment-1999799851

The power status will react on SIA codes AT and AR. So I assume it will change when you disconnect and reconnect AC power of your alarm system. But I didn't test it.

Did some testing last night but disabeling the heartbeat gives me still an FTC and the orange led on the panel. i still think it has something to do with the timestamp error below, when the timestamp get parsed correctly everything works fine, when i get an timestamp parsed error the ats log gives me "send to pac failed"

so when timestamp is ' ' everything is fine, when timestamp is populated as an number i get the parsed error.

@voskuh could you maybe check your code if you see some strange behaviour, its a bit unclear for me why the timestamp get populated with a number but not at every message send from the alarm panel.

i activated the "Ignore the timestamp check of the SIA events" option in the sia integration but that doesnt help.

2024-03-20 17:31:28.853 DEBUG (MainThread) [pysiaalarm.aio.server] Data received: b'l\xc6aa\xe6\xd0\x8d\x93\\}\xfa\x1e\x9e\x96\x7f-x\xe4\xd5\xd9\x9a\x17\x16S\x1fb@\x95\x8e$\x83\x93\x04h\xa1\x81\xee\xd8?\x9b\xb5\x01\xcf]\xd9\xeaF\x14\x07i\x15\xa0\xad\x964\xee\xd2\xef\xfa9\xcf>\x98\x17Q5_|\xf8*bW.\xc4\xde\x96\xf0\x12\xf0\xfa\x13<\x82\x91\xe1\x12\xd2\xe5\xac8\xabh\xde=\xb0tG\xc1!\xcb\xc0\xa1\xfd$'
2024-03-20 17:31:28.853 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'\n01010065"SIA-DCS"0148R0002L0001[#001991|Nri04/UR069*\'HA Overloop\'NM]2A52238E74F405CA|#001991T65FB0F5F\r\x00'
2024-03-20 17:31:28.853 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 01010065"SIA-DCS"0148R0002L0001[#001991|Nri04/UR069*'HA Overloop'NM]2A52238E74F405CA|#001991T65FB0F5F
2024-03-20 17:31:28.853 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '001991', 'ti': None, 'id': None, 'ri': '04', 'code': 'UR', 'message': "069*'HA Overloop'NM", 'xdata': None, 'timestamp': '2'}
2024-03-20 17:31:28.854 WARNING (MainThread) [pysiaalarm.event] Timestamp could not be parsed as a timestamp: 2

It's strange that only sometimes you get that error. I think it's not necessary to disable the heartbeat. I made some changes to the repo again for better timestamp handling, so please update/reinstall and test it. Hopefully all your messages are parsed well now.

bjornmorsman commented 5 months ago

Hi Voskuh,

Thanx for the update, the timestamp errors are as good as gone. got only 1 in 30 minutes! but i still have the FTC no errors are logged in home assisant, the only thing i can see is thee connectivity sensor goes online offline very +- 2 minutes.

i have no clue where the FTC comes from, maybe there is something wrong with the ACK message back to the panel?


2024-03-22 11:49:43.644 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'\n01010065"SIA-DCS"0015R0001L0001[#001991|Nri04/UR058*\'HA PIR Gang\'NM]4394661896EF362E|#001991T65FD6245\r\x00'
2024-03-22 11:49:43.645 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 01010065"SIA-DCS"0015R0001L0001[#001991|Nri04/UR058*'HA PIR Gang'NM]4394661896EF362E|#001991T65FD6245
2024-03-22 11:49:43.645 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '001991', 'ti': None, 'id': None, 'ri': '04', 'code': 'UR', 'message': "058*'HA PIR Gang'NM", 'xdata': None, 'timestamp': '4394661896'}
2024-03-22 11:49:43.646 WARNING (MainThread) [pysiaalarm.event] Timestamp could not be parsed as a timestamp: 4394661896
wichers commented 5 months ago

I've given it some thought and more reverse-engineering of OH-NetRec, and I now believe that in it's current state, pyssiaalarm is the wrong location to add OH support. In case of merging OH/DC-09, I think pyssialarm needs complete refactoring so a clean separation between DC-09 and OH can exist. Right now the risk of breaking DC-09 is too high. As an OH event has SIA codes in them, there are of course similarities between OH/DC-09 where the event is enriched with information from the SIA tables, but that's it. Looking at OH protocol, the event structures are completely different, it's TCP only; it's basically a different protocol. Considering the addition of future OH V4 support, and the things mentioned above I've made a separate Osborne Hoffman project.

The HA SIA integration has of course more similarities with OH, as the events are already parsed and ready to forward into HA.

@voskuh, what's your thoughts on this?

voskuh commented 5 months ago

Hi Voskuh,

Thanx for the update, the timestamp errors are as good as gone. got only 1 in 30 minutes! but i still have the FTC no errors are logged in home assisant, the only thing i can see is thee connectivity sensor goes online offline very +- 2 minutes.

i have no clue where the FTC comes from, maybe there is something wrong with the ACK message back to the panel?

2024-03-22 11:49:43.644 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'\n01010065"SIA-DCS"0015R0001L0001[#001991|Nri04/UR058*\'HA PIR Gang\'NM]4394661896EF362E|#001991T65FD6245\r\x00'
2024-03-22 11:49:43.645 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 01010065"SIA-DCS"0015R0001L0001[#001991|Nri04/UR058*'HA PIR Gang'NM]4394661896EF362E|#001991T65FD6245
2024-03-22 11:49:43.645 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '001991', 'ti': None, 'id': None, 'ri': '04', 'code': 'UR', 'message': "058*'HA PIR Gang'NM", 'xdata': None, 'timestamp': '4394661896'}
2024-03-22 11:49:43.646 WARNING (MainThread) [pysiaalarm.event] Timestamp could not be parsed as a timestamp: 4394661896

Hi Bjorn, Good to hear that's is better now. It will be possible to fix the timestamp error completely in the future. If I understand it correctly you have FTC error in your alarm system and connectivity issues in HA. Do you also see SIA codes NC, NR, YK, YR in your logs? These are related to communication errors. The connectivity state in HA is updated after every heartbeat. In the integration settings you can set a ping interval. After 30 seconds after the ping interval without a heartbeat the state in HA will be disconnected. When a new heartbeat is received the state will be connected again. So make sure the ping interval in the integration and heartbeat interval in your alarm system are the same.

I've given it some thought and more reverse-engineering of OH-NetRec, and I now believe that in it's current state, pyssiaalarm is the wrong location to add OH support. In case of merging OH/DC-09, I think pyssialarm needs complete refactoring so a clean separation between DC-09 and OH can exist. Right now the risk of breaking DC-09 is too high. As an OH event has SIA codes in them, there are of course similarities between OH/DC-09 where the event is enriched with information from the SIA tables, but that's it. Looking at OH protocol, the event structures are completely different, it's TCP only; it's basically a different protocol. Considering the addition of future OH V4 support, and the things mentioned above I've made a separate Osborne Hoffman project.

The HA SIA integration has of course more similarities with OH, as the events are already parsed and ready to forward into HA.

@voskuh, what's your thoughts on this?

I agree that it is complex to integrate OH in pyssialarm. The changes of breaking something in the current implementation is quite high and maintaining will be hard. A separate project will be easier to maintain and will be more robust. But then a separate HA integration for our alarm systems seems more logical to me as well.

ROUGHSOUL commented 5 months ago

J'y ai réfléchi et effectué davantage de rétro-ingénierie d'OH-NetRec, et je crois maintenant que dans son état actuel, pyssiaalarm n'est pas le bon endroit pour ajouter le support OH. En cas de fusion de OH/DC-09, je pense que pyssialarm a besoin d'une refactorisation complète afin qu'une séparation nette entre DC-09 et OH puisse exister. À l’heure actuelle, le risque de briser le DC-09 est trop élevé. Comme un événement OH contient des codes SIA, il y a bien sûr des similitudes entre OH/DC-09 où l'événement est enrichi avec les informations des tables SIA, mais c'est tout. En regardant le protocole OH, les structures d'événements sont complètement différentes, il s'agit uniquement de TCP ; c'est fondamentalement un protocole différent. Compte tenu de l'ajout du futur support OH V4 et des éléments mentionnés ci-dessus, j'ai réalisé un projet Osborne Hoffman distinct .

L'intégration HA SIA présente bien sûr plus de similitudes avec OH, car les événements sont déjà analysés et prêts à être transmis dans HA.

@voskuh, qu'en pensez-vous ?

Hello, I am an alarm system installer, I would be very happy to be able to discuss the subject with you. I am very curious about the ways you used to decrypted the 3des protocol and how to use your latest project? Another subject, the control unit is able of communicating along the water with the ATS8600 or 8500 software (through port 32000) to have instantaneous status feedback from all the points. It would be interesting to have this option for integration into a floor plan. Do you think this is possible?

jnathalia commented 2 months ago

I have an Aritech ATS3500 and this integration seems to be working according to the thread... I'm delighted...

I have installed via HACS the repository https://github.com/voskuh/custom-sia. I rebooted HA and the integration seems to be fine via HACS and I can see the integration "SIA Alarm Systems" from @voskuh (although no comments or further instructions).

Via HA Settings, Devices & Services I'm trying to add the integration but the only I can find is "SIA Alarm Systems". The option "OH" has been added next to "TCP" and "UDP". Am I still on the right track?

I have tried to add the repository via HACS https://github.com/voskuh/pysiaalarm but this cannot be added.

What should be the next step?

I configured my alarm system already and via the old utcar container I am receiving XSIA messages... so, I should be ready for receiving...

Please assist me a little bit further. Thx

PS I suppose I have to program my Central Station (PAC) to the internal IP address of my HA instance? My HA is installed at 192.168.1.140 and listening to port 12300. Any issue if it's using https instead of http?

jnathalia commented 2 months ago

I have the integration of @voskuh up and running. I'm very happy, because this is the first time I have connected my ATSx500 Advanced alarm panel connected to HA and I can create all kinds of automation scenes. Thanks @voskuh!

However, I have a request. Currently, the "additional account" at the integration doesn't work:

Screenshot 2024-07-02 at 10 08 16

It says: "Device is already configured". It's a bit weird as I have never done that... I think the message means that the same port has been used already. However, if you look at the HA log you can see the SIA messages with other account codes are coming through. It fails when it comes to parsing/interpretation and therefore it's not reflected to sensors in HA.

The integration should follow the configuration of the alarm panel. When more than 1 area is being used and also more than 1 account code, currently the alarm panel reports multiple account code with SIA codes. So, when you consider the Central Station (PAC), all kinds of information is being reported depending on the settings of the panel.

@voskuh, would it be possible to make a small extension? So, anything that has been reported by the Central Station (PAC) and posted to the specific port, could this be parsed by your integration? Currently, if you look at Developer Tools, Events in HA we get only one Event (for instance sia_event_12300_200000), but this should be multiple events (for instance in addition sia_event_12300_100000) if you have added account codes according to the picture above.

This would prevent many users to create all kind of by-passes in our alarm systems by duplicating original zones into filters, outputs and back to (virtual) zones. As well as the state of the panel it's much more easier to read out. 🙏🙏🙏

bjornmorsman commented 2 months ago

Hi Voskuh, Thanx for the update, the timestamp errors are as good as gone. got only 1 in 30 minutes! but i still have the FTC no errors are logged in home assisant, the only thing i can see is thee connectivity sensor goes online offline very +- 2 minutes. i have no clue where the FTC comes from, maybe there is something wrong with the ACK message back to the panel?

2024-03-22 11:49:43.644 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'\n01010065"SIA-DCS"0015R0001L0001[#001991|Nri04/UR058*\'HA PIR Gang\'NM]4394661896EF362E|#001991T65FD6245\r\x00'
2024-03-22 11:49:43.645 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 01010065"SIA-DCS"0015R0001L0001[#001991|Nri04/UR058*'HA PIR Gang'NM]4394661896EF362E|#001991T65FD6245
2024-03-22 11:49:43.645 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '001991', 'ti': None, 'id': None, 'ri': '04', 'code': 'UR', 'message': "058*'HA PIR Gang'NM", 'xdata': None, 'timestamp': '4394661896'}
2024-03-22 11:49:43.646 WARNING (MainThread) [pysiaalarm.event] Timestamp could not be parsed as a timestamp: 4394661896

Hi Bjorn, Good to hear that's is better now. It will be possible to fix the timestamp error completely in the future. If I understand it correctly you have FTC error in your alarm system and connectivity issues in HA. Do you also see SIA codes NC, NR, YK, YR in your logs? These are related to communication errors. The connectivity state in HA is updated after every heartbeat. In the integration settings you can set a ping interval. After 30 seconds after the ping interval without a heartbeat the state in HA will be disconnected. When a new heartbeat is received the state will be connected again. So make sure the ping interval in the integration and heartbeat interval in your alarm system are the same.

I've given it some thought and more reverse-engineering of OH-NetRec, and I now believe that in it's current state, pyssiaalarm is the wrong location to add OH support. In case of merging OH/DC-09, I think pyssialarm needs complete refactoring so a clean separation between DC-09 and OH can exist. Right now the risk of breaking DC-09 is too high. As an OH event has SIA codes in them, there are of course similarities between OH/DC-09 where the event is enriched with information from the SIA tables, but that's it. Looking at OH protocol, the event structures are completely different, it's TCP only; it's basically a different protocol. Considering the addition of future OH V4 support, and the things mentioned above I've made a separate Osborne Hoffman project. The HA SIA integration has of course more similarities with OH, as the events are already parsed and ready to forward into HA. @voskuh, what's your thoughts on this?

I agree that it is complex to integrate OH in pyssialarm. The changes of breaking something in the current implementation is quite high and maintaining will be hard. A separate project will be easier to maintain and will be more robust. But then a separate HA integration for our alarm systems seems more logical to me as well.

Hi @voskuh,

i did some test to fix the FTC and Polling errors i get when i connect my ats to home assistant, i think it has to do something with this error in my home assistant log. is this something you can fix or is it a problem with pysiaalarm? Thanx in advance


2024-07-03 09:31:22.074 DEBUG (MainThread) [pysiaalarm.aio.server] Receive data...
2024-07-03 09:31:22.082 DEBUG (MainThread) [pysiaalarm.aio.server] Handle line finished
2024-07-03 09:31:25.310 DEBUG (MainThread) [pysiaalarm.aio.server] Handle line started
2024-07-03 09:31:25.310 DEBUG (MainThread) [pysiaalarm.aio.server] Handle line finished
2024-07-03 09:31:29.061 DEBUG (MainThread) [pysiaalarm.aio.server] Handle line started
2024-07-03 09:31:29.061 DEBUG (MainThread) [pysiaalarm.aio.server] Send scrambled key
2024-07-03 09:31:29.061 DEBUG (MainThread) [pysiaalarm.aio.server] Receive data...
2024-07-03 09:31:29.067 DEBUG (MainThread) [pysiaalarm.aio.server] Data received: b'6H\xa8\xeeW\x11\xbfq{\xa2W\xa1\x9a\xde\x01\x87W1\x9d\xf1\x16S\xed@\xc2\x90\xed\x94\x02\xbc\xeb9\xf1\nkB\xd5\xfcB"]\x02;]M~\x88d'
2024-07-03 09:31:29.067 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'SR0000L0000 123451XX \x00[ID00000000]\x00\x00\x00\x00\x00\x00\x00\x00'
2024-07-03 09:31:29.067 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: SR0000L0000 123451XX [ID00000000]
2024-07-03 09:31:29.068 WARNING (MainThread) [homeassistant.util.loop] Detected blocking call to open with args ('/usr/local/lib/python3.12/site-packages/pysiaalarm/data/sia_codes.json', 'rb') in /usr/local/lib/python3.12/site-packages/pkg_resources/__init__.py, line 1693: return open(self._fn(self.module_path, resource_name), 'rb') inside the event loop
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "/usr/src/homeassistant/homeassistant/__main__.py", line 223, in <module>
sys.exit(main())
File "/usr/src/homeassistant/homeassistant/__main__.py", line 209, in main
exit_code = runner.run(runtime_conf)
File "/usr/src/homeassistant/homeassistant/runner.py", line 190, in run
return loop.run_until_complete(setup_and_run_hass(runtime_config))
File "/usr/local/lib/python3.12/asyncio/base_events.py", line 672, in run_until_complete
self.run_forever()
File "/usr/local/lib/python3.12/asyncio/base_events.py", line 639, in run_forever
self._run_once()
File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1988, in _run_once
handle._run()
File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/aio/server.py", line 112, in handle_line
event = self.parse_and_check_event(data)
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/base_server.py", line 64, in parse_and_check_event
event = SIAEvent.from_line(line, self.accounts)
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/event.py", line 139, in from_line
return OHEvent(
File "<string>", line 28, in __init__
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/event.py", line 501, in __post_init__
self.set_sia_code()
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/event.py", line 106, in set_sia_code
self.sia_code = _load_sia_codes().get(self.code) # pylint: disable=E1101
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/data/data.py", line 44, in _load_sia_codes
data = _load_data(FILE_SIA_CODES)
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/data/data.py", line 38, in _load_data
stream = pkg_resources.resource_stream(__name__, file)
File "/usr/local/lib/python3.12/site-packages/pkg_resources/__init__.py", line 1187, in resource_stream
return get_provider(package_or_requirement).get_resource_stream(
File "/usr/local/lib/python3.12/site-packages/pkg_resources/__init__.py", line 1693, in get_resource_stream
return open(self._fn(self.module_path, resource_name), 'rb')````
jnathalia commented 2 months ago

I have the integration of @voskuh up and running. I'm very happy, because this is the first time I have connected my ATSx500 Advanced alarm panel connected to HA and I can create all kinds of automation scenes. Thanks @voskuh!

However, I have a request. Currently, the "additional account" at the integration doesn't work:

Screenshot 2024-07-02 at 10 08 16

It says: "Device is already configured". It's a bit weird as I have never done that... I think the message means that the same port has been used already. However, if you look at the HA log you can see the SIA messages with other account codes are coming through. It fails when it comes to parsing/interpretation and therefore it's not reflected to sensors in HA.

The integration should follow the configuration of the alarm panel. When more than 1 area is being used and also more than 1 account code, currently the alarm panel reports multiple account code with SIA codes. So, when you consider the Central Station (PAC), all kinds of information is being reported depending on the settings of the panel.

@voskuh, would it be possible to make a small extension? So, anything that has been reported by the Central Station (PAC) and posted to the specific port, could this be parsed by your integration? Currently, if you look at Developer Tools, Events in HA we get only one Event (for instance sia_event_12300_200000), but this should be multiple events (for instance in addition sia_event_12300_100000) if you have added account codes according to the picture above.

This would prevent many users to create all kind of by-passes in our alarm systems by duplicating original zones into filters, outputs and back to (virtual) zones. As well as the state of the panel it's much more easier to read out. 🙏🙏🙏

After re-adding the integration, I succeeded in adding additional accounts and now I can read the additional account codes (messages from other areas). The integration UI is a bit buggy I believe as the next steps to add additional accounts, the form fields I had to guess, there was no description anymore (first screen ok, the following are empty fields only).

voskuh commented 2 months ago

Hi Voskuh, Thanx for the update, the timestamp errors are as good as gone. got only 1 in 30 minutes! but i still have the FTC no errors are logged in home assisant, the only thing i can see is thee connectivity sensor goes online offline very +- 2 minutes. i have no clue where the FTC comes from, maybe there is something wrong with the ACK message back to the panel?

2024-03-22 11:49:43.644 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'\n01010065"SIA-DCS"0015R0001L0001[#001991|Nri04/UR058*\'HA PIR Gang\'NM]4394661896EF362E|#001991T65FD6245\r\x00'
2024-03-22 11:49:43.645 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 01010065"SIA-DCS"0015R0001L0001[#001991|Nri04/UR058*'HA PIR Gang'NM]4394661896EF362E|#001991T65FD6245
2024-03-22 11:49:43.645 DEBUG (MainThread) [pysiaalarm.event] Content matches: {'account': '001991', 'ti': None, 'id': None, 'ri': '04', 'code': 'UR', 'message': "058*'HA PIR Gang'NM", 'xdata': None, 'timestamp': '4394661896'}
2024-03-22 11:49:43.646 WARNING (MainThread) [pysiaalarm.event] Timestamp could not be parsed as a timestamp: 4394661896

Hi Bjorn, Good to hear that's is better now. It will be possible to fix the timestamp error completely in the future. If I understand it correctly you have FTC error in your alarm system and connectivity issues in HA. Do you also see SIA codes NC, NR, YK, YR in your logs? These are related to communication errors. The connectivity state in HA is updated after every heartbeat. In the integration settings you can set a ping interval. After 30 seconds after the ping interval without a heartbeat the state in HA will be disconnected. When a new heartbeat is received the state will be connected again. So make sure the ping interval in the integration and heartbeat interval in your alarm system are the same.

I've given it some thought and more reverse-engineering of OH-NetRec, and I now believe that in it's current state, pyssiaalarm is the wrong location to add OH support. In case of merging OH/DC-09, I think pyssialarm needs complete refactoring so a clean separation between DC-09 and OH can exist. Right now the risk of breaking DC-09 is too high. As an OH event has SIA codes in them, there are of course similarities between OH/DC-09 where the event is enriched with information from the SIA tables, but that's it. Looking at OH protocol, the event structures are completely different, it's TCP only; it's basically a different protocol. Considering the addition of future OH V4 support, and the things mentioned above I've made a separate Osborne Hoffman project. The HA SIA integration has of course more similarities with OH, as the events are already parsed and ready to forward into HA. @voskuh, what's your thoughts on this?

I agree that it is complex to integrate OH in pyssialarm. The changes of breaking something in the current implementation is quite high and maintaining will be hard. A separate project will be easier to maintain and will be more robust. But then a separate HA integration for our alarm systems seems more logical to me as well.

Hi @voskuh,

i did some test to fix the FTC and Polling errors i get when i connect my ats to home assistant, i think it has to do something with this error in my home assistant log. is this something you can fix or is it a problem with pysiaalarm? Thanx in advance

2024-07-03 09:31:22.074 DEBUG (MainThread) [pysiaalarm.aio.server] Receive data...
2024-07-03 09:31:22.082 DEBUG (MainThread) [pysiaalarm.aio.server] Handle line finished
2024-07-03 09:31:25.310 DEBUG (MainThread) [pysiaalarm.aio.server] Handle line started
2024-07-03 09:31:25.310 DEBUG (MainThread) [pysiaalarm.aio.server] Handle line finished
2024-07-03 09:31:29.061 DEBUG (MainThread) [pysiaalarm.aio.server] Handle line started
2024-07-03 09:31:29.061 DEBUG (MainThread) [pysiaalarm.aio.server] Send scrambled key
2024-07-03 09:31:29.061 DEBUG (MainThread) [pysiaalarm.aio.server] Receive data...
2024-07-03 09:31:29.067 DEBUG (MainThread) [pysiaalarm.aio.server] Data received: b'6H\xa8\xeeW\x11\xbfq{\xa2W\xa1\x9a\xde\x01\x87W1\x9d\xf1\x16S\xed@\xc2\x90\xed\x94\x02\xbc\xeb9\xf1\nkB\xd5\xfcB"]\x02;]M~\x88d'
2024-07-03 09:31:29.067 DEBUG (MainThread) [pysiaalarm.utils.osborne_hoffman] OH-XSIA OH data b'SR0000L0000 123451XX \x00[ID00000000]\x00\x00\x00\x00\x00\x00\x00\x00'
2024-07-03 09:31:29.067 DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: SR0000L0000 123451XX [ID00000000]
2024-07-03 09:31:29.068 WARNING (MainThread) [homeassistant.util.loop] Detected blocking call to open with args ('/usr/local/lib/python3.12/site-packages/pysiaalarm/data/sia_codes.json', 'rb') in /usr/local/lib/python3.12/site-packages/pkg_resources/__init__.py, line 1693: return open(self._fn(self.module_path, resource_name), 'rb') inside the event loop
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "/usr/src/homeassistant/homeassistant/__main__.py", line 223, in <module>
sys.exit(main())
File "/usr/src/homeassistant/homeassistant/__main__.py", line 209, in main
exit_code = runner.run(runtime_conf)
File "/usr/src/homeassistant/homeassistant/runner.py", line 190, in run
return loop.run_until_complete(setup_and_run_hass(runtime_config))
File "/usr/local/lib/python3.12/asyncio/base_events.py", line 672, in run_until_complete
self.run_forever()
File "/usr/local/lib/python3.12/asyncio/base_events.py", line 639, in run_forever
self._run_once()
File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1988, in _run_once
handle._run()
File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/aio/server.py", line 112, in handle_line
event = self.parse_and_check_event(data)
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/base_server.py", line 64, in parse_and_check_event
event = SIAEvent.from_line(line, self.accounts)
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/event.py", line 139, in from_line
return OHEvent(
File "<string>", line 28, in __init__
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/event.py", line 501, in __post_init__
self.set_sia_code()
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/event.py", line 106, in set_sia_code
self.sia_code = _load_sia_codes().get(self.code) # pylint: disable=E1101
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/data/data.py", line 44, in _load_sia_codes
data = _load_data(FILE_SIA_CODES)
File "/usr/local/lib/python3.12/site-packages/pysiaalarm/data/data.py", line 38, in _load_data
stream = pkg_resources.resource_stream(__name__, file)
File "/usr/local/lib/python3.12/site-packages/pkg_resources/__init__.py", line 1187, in resource_stream
return get_provider(package_or_requirement).get_resource_stream(
File "/usr/local/lib/python3.12/site-packages/pkg_resources/__init__.py", line 1693, in get_resource_stream
return open(self._fn(self.module_path, resource_name), 'rb')````

Hi Bjorn,

The warning in the logs is new, introduced in version 2024.7.0 of home assistant 119058. I'm testing a fix, so hopefully in the upcoming days I will push an update to the repo.
I don't think this warning is causing communication errors with your alarm system. Do you see SIA codes NC, NR, YK, YR in your logs, when you experience FTC and polling errors? Or timestamp errors regularly?

Unfortunately I didn't had time the last month to look into a seperate component for our alarm systems.

aperezva commented 1 month ago

Hi , any feedback regarding this issue?

Thanks