Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADM-CID: Last line could not be parsed as a SIAEvent or OHEvent #22

Closed
bropat opened this issue Oct 1, 2021 · 22 comments
Closed

ADM-CID: Last line could not be parsed as a SIAEvent or OHEvent #22

bropat opened this issue Oct 1, 2021 · 22 comments
Assignees

Comments

@bropat
Copy link

bropat commented Oct 1, 2021

System informations:

System Health

version: core-2021.9.7
installation_type: Home Assistant OS
dev: false
hassio: true
docker: true
user: root
virtualenv: false
python_version: 3.9.7
os_name: Linux
os_version: 5.10.62
arch: x86_64
timezone: Europe/Rome

logged_in: false
can_reach_cert_server: ok
can_reach_cloud_auth: ok
can_reach_cloud: ok

host_os: Home Assistant OS 6.4
update_channel: stable
supervisor_version: supervisor-2021.09.6
docker_version: 20.10.7
disk_total: 30.8 GB
disk_used: 2.0 GB
healthy: true
supported: true
board: ova
supervisor_api: ok
version_api: ok
installed_addons: File editor (5.3.3)

dashboards: 1
resources: 0
views: 1
mode: storage

I get the following error message:

DEBUG (MainThread) [pysiaalarm.aio.client] Starting SIA.
DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: D0850078"*ADM-CID"6879R0L0#123F[64F7ADD9BA9377DBF2C014BC709329BEEE345B5F20C60B7EB9D2C6B8C222666B13D0B4A114B448B0AC555FCC658DB6EE
WARNING (MainThread) [pysiaalarm.base_server] Last line could not be parsed as a SIAEvent or OHEvent, line was: D0850078"*ADM-CID"6879R0L0#123F[64F7ADD9BA9377DBF2C014BC709329BEEE345B5F20C60B7EB9D2C6B8C222666B13D0B4A114B448B0AC555FCC658DB6EE

Can you maybe help me?

Thanks!

Regards
Patrick

@eavanvalkenburg
Copy link
Owner

Could you turn on some additional logging and post here:

logger:
  default: error
  logs:
    homeassistant.components.sia: debug 
    pysiaalarm: debug

@bropat
Copy link
Author

bropat commented Oct 1, 2021

This configuration is already active. No more log than above is generated.

@eavanvalkenburg
Copy link
Owner

ok and this is using the official integration or the HACS one?

@bropat
Copy link
Author

bropat commented Oct 1, 2021

Official

@eavanvalkenburg
Copy link
Owner

ok, so I added the line above to the tests and there it works so there is something else going on, you have the keys used for encrypting the same in both? and could you do a test without encryption?

@eavanvalkenburg eavanvalkenburg self-assigned this Oct 1, 2021
@bropat
Copy link
Author

bropat commented Oct 1, 2021

ok, so I added the line above to the tests and there it works so there is something else going on, you have the keys used for encrypting the same in both?

Yes i have. I already have a working integration with another home automation solution (ioBroker with ioBroker.sia).

and could you do a test without encryption?

No, I'm afraid I can't. However, I think that the cause is not the encryption, as this only comes into play afterwards ;)

When looking at the code, the cause can actually only be here, as the following log line can only be thrown by an EventFormatError exception:

WARNING (MainThread) [pysiaalarm. base_server] Last line could not be parsed as a SIAEvent or OHEvent, line was: D0850078"*ADM-CID "6879R0L0#123F[64F7ADD9BA9377DBF2C014BC709329BEEE345B5F20C60B7EB9D2C6B8C222666B13D0B4A114B448B0AC555FCC658DB6EE

The regular expression is also correct according to me....

@eavanvalkenburg
Copy link
Owner

No that is not completely the case, it can also be raised by the parse_content function later on (here). So I noticed there is a small gap when the account is not encrypted but the message is, which would result in trying to parse content in the wrong way which throws the eventformaterror as well. So I'm doing two things now that will hopefully help with this one. 1) check if both the message and the account are encrypted 2) change the logged error for the other situation.

@bropat
Copy link
Author

bropat commented Oct 1, 2021

You're right, I overlooked it :P
Sounds good.

Thanks!

@bropat
Copy link
Author

bropat commented Oct 19, 2021

@eavanvalkenburg I have tested the latest DEV version and I still get an error:

DEBUG (MainThread) [pysiaalarm.base_server] Incoming line: 505A0078"*ADM-CID"4342R0L0#123F[64F7ADD9BA9377DBF2C014BC709329BE3A82EACDA4510DF0F0BC292479E95411755FE284C0B72BCC45F2413EC27B91B2
WARNING (MainThread) [pysiaalarm.base_server] Last line could not be parsed succesfully. Error message: Parse content: no matches found in %s, using matcher: %s. Line: 505A0078"*ADM-CID"4342R0L0#123F[64F7ADD9BA9377DBF2C014BC709329BE3A82EACDA4510DF0F0BC292479E95411755FE284C0B72BCC45F2413EC27B91B2

@eavanvalkenburg
Copy link
Owner

which version did you try?

@bropat
Copy link
Author

bropat commented Oct 19, 2021

Latest dev:

ha supervisor options --channel dev
ha supervisor reload
ha core update

pysiaalarm==3.0.2

@bropat
Copy link
Author

bropat commented Oct 25, 2021

@eavanvalkenburg

I have found the error and now the decryption of the messages works. The error is here.

key_b should be the hex key in bytes, but you convert the string to bytes and not the hex string to bytes.

This way it works fine for me:

    self.key_b = bytes.fromhex(self.key) if self.key else None

@eavanvalkenburg
Copy link
Owner

Well, I think changing that would break other alarms. Most alarms use a key inputted as string with just hex characters, so I will have to test to see. What is the key you use?

@bropat
Copy link
Author

bropat commented Oct 25, 2021

I think a key that is given in hex format but then encoded as a string in byte is not necessarily the best solution. e.g. my alarm system only accepts a 16 byte hex key. Others only accept a string?
Furthermore, when configuring the integration, you are explicitly asked for a hex key. If you enter a string, you get the error Please enter hex key...

Do you know anyone who is actively using encryption with the current version?

@bropat
Copy link
Author

bropat commented Oct 25, 2021

With the ioBroker integration (already mentioned above) you can choose between a string and a hex key:

image

Could this not also be a solution here?

@eavanvalkenburg
Copy link
Owner

I am! In my alarm they ask you to set the key as a hex, so you type in a key with just 0-9A-F, but I'll have a look!

@bropat
Copy link
Author

bropat commented Oct 25, 2021

ok, thanks.

@bropat
Copy link
Author

bropat commented Nov 6, 2021

I am! In my alarm they ask you to set the key as a hex, so you type in a key with just 0-9A-F, but I'll have a look!

@eavanvalkenburg

Have you looked?

@eavanvalkenburg
Copy link
Owner

@bropat could you share an example of the key you use, especially the format?

@bropat
Copy link
Author

bropat commented Jan 20, 2022

@eavanvalkenburg

For example: 4474415a4458714f6961674662736a36

@bropat
Copy link
Author

bropat commented May 30, 2022

@eavanvalkenburg

Any news about it?

@bropat
Copy link
Author

bropat commented May 30, 2022

Well, I think changing that would break other alarms. Most alarms use a key inputted as string with just hex characters, so I will have to test to see. What is the key you use?

Another proposal in contrast to this is:

If you accept any string as a key and do not check whether it is a HEX "string", i.e. only check the length of the string in bytes, it also works for me.


My key is a string that has been converted to a hex key so that it can be entered into the alarm system as a numeric hex key (not as a hex string). Unfortunately, I cannot change this key without contacting the alarm company.

Example:

Original Key as string: dhF3978fbas5Naj1
Hex Key (numeric!) used in the alarm system: 6468463339373866626173354e616a31

When I enter the string in the SIA integration, I get the error that it is not a "hex string", but would be correctly translated by pysiaalarm into a byte array and it would work.
If I enter the HEX value of the string, it does not work, of course, because the corresponding byte array does not correspond to the stored keys in the alarm system (numeric hex values).

I hope I have expressed myself better ;)

@bropat bropat closed this as completed Nov 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants