Corrupt response from panel: Unexpected start, expected 't', got 0x9

[leocrawford]

Describe the bug
When starting it reports Corrupt response from panel: Unexpected start, expected 't', got 0x9.

This appears to be before auth, so we have:

HA: 04 5a a2
alarm: 0b 5a 05 01 00 00 01 05
alarm: 09 00 85

If I compare this to a dump from wintex, the sequence is the same and the auth happens in the following step.

The alarm is connected via a raspberry pi zero W hanging off the on-board serial port, using ser2net. The alarm settings are.

Wintex works fine.

Application version
1.2.3

Texecom alarm type
Premier Elite 48, firmware V6.02.00LS1

Home Assistant version
2022.10.1

Debug log
2023-01-02 14:25:05 - INFO: Starting texecom2mqtt v1.2.3 (Node v16.13.0)...
2023-01-02 14:25:05 - INFO: Connected to alarm, sleeping for 2 seconds...
2023-01-02 14:25:07 - INFO: Connection ready
2023-01-02 14:25:07 - INFO: Logging in to panel
2023-01-02 14:25:07 - ERROR: Corrupt response from panel: Unexpected start, expected 't', got 0x9
2023-01-02 14:25:07 - INFO: Panel disconnected

[leocrawford]

Trying to debug further, using pialarm (https://github.com/shuckc/pialarm) as a fake texecom unit (emulating a premier elite 24)

The connect sequence starts the same, but after the alarm responds for the first time the HA starts sending:

74 43 0a 00 01 31 32 33 34 34

In total it sends it five times, before aborting. Looking at the protocol defined here (https://github.com/shuckc/pialarm/blob/master/protocol/wintex-protocol.md) This seems odd, as the first byte should be be length of the message in bytes (10 in this case). The corresponding send from wintex (which seems to meet the standard I'd expect is)

07 5a 31 32 33 34 d4

This suggests a slightly different protocol, with 64 added (the most significant bit), a different command code and then three extra bytes .

I'm happy to get the NDA signed to try and get the code and debug from there, but struggling to find anything on-line. If anyone has a link I'd appreciate it.

[leocrawford]

OK. Found a fix.

The packet captures above showed that the response from the alarm was being spit over two packets, despite being only 11 bytes long. The first byte of the second packet was 09 as reported in the error. I wondered if it was the timing and/or packet alignment causing this so I started fiddling with ser2net and find the following ser2net.yaml connection works.

    accepter: tcp,10001
    enable: on
    options:
      kickolduser: true
      chardelay: true
      max-connections: 1 
      chardelay-scale: 240
      chardelay-min: 5000
      chardelay-max: 100000
    connector: serialdev,
              /dev/ttyAMA0,
              19200n82
              local   

Ideally the code would be less sensitive to packet timing/splits, but at least we have a workaround