ADM-CID: Last line could not be parsed as a SIAEvent or OHEvent about pysiaalarm HOT 22 CLOSED

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.

from pysiaalarm.

Could you turn on some additional logging and post here:

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

from pysiaalarm.

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

from pysiaalarm.

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

from pysiaalarm.

Official

from pysiaalarm.

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?

from pysiaalarm.

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....

from pysiaalarm.

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

Thanks!

from pysiaalarm.

@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

from pysiaalarm.

which version did you try?

from pysiaalarm.

Latest dev:

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

pysiaalarm==3.0.2

from pysiaalarm.

@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

from pysiaalarm.

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?

from pysiaalarm.

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?

from pysiaalarm.

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

Could this not also be a solution here?

from pysiaalarm.

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!

from pysiaalarm.

ok, thanks.

from pysiaalarm.

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?

from pysiaalarm.

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

from pysiaalarm.

@eavanvalkenburg

For example: 4474415a4458714f6961674662736a36

from pysiaalarm.

@eavanvalkenburg

Any news about it?

from pysiaalarm.

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 ;)

from pysiaalarm.