Corrupt response from panel: Unexpected start, expected 't', got 0x9 #77
Comments
|
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: 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) 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. |
|
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 Ideally the code would be less sensitive to packet timing/splits, but at least we have a workaround |
|
@leocrawford do you still have this error using esphome? |
|
No. I haven't experienced that on ESPLink (or at least not that I have noticed). |
|
Can you help debug with me? (Not sure who else to ask) |
|
sure. What is the serial config on your esphome? |
|
I didn’t have any joy with ESPHome, I used ESPlink instead.
|
|
given that EspLink doesn't seem to have the equivalent of chardelay, I think the easiest thing would be to try lowering the baud rate to something very slow. You'll have to change both ends; the alarm one via wintex and this end via esplink. |
|
I have totally lost the plot with this now. Board remains the same as above (as in using pin 0 and 1) esphome:
name: texecom-link
friendly_name: texecom-link
esp8266:
board: d1
external_components:
- source: github://oxan/esphome-stream-server
stream_server:
uart_id: uart_bus
port: 23
binary_sensor:
- platform: stream_server
connected:
name: texecom-link
uart:
id: uart_bus
tx_pin: GPIO1
rx_pin: GPIO3
baud_rate: 19200
data_bits: 8
stop_bits: 2
web_server:
port: 80
# Enable logging
logger:
level: DEBUG
# Enable Home Assistant API
api:
ota:
platform: esphome
wifi:
ssid: "XXX"
password: "XXX"
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Texecom-Link Fallback Hotspot"
password: "123456789"
captive_portal:I can see from the debug terminal on ESPHome that it tries to connect to the Texecom but it never actually gets through. |
|
Questions/thoughts:
1. Do those TX/RX pins work? Can you connect a UART connector to these and
check they actually work? then just use nc to see if you can shift bytes
between them.
2.It might be helpful to use socat server-side so you can create another
local port (e.g. 1234) that you connect to from texecom, but also
logs/dumps all the bytes going in either direction. Alternatively use
tcpdump/wireshark to look at what is happening on wire.
3. What protocol and speed is the com port you're using set to? Assume if
you attach a normal UART cable to that COM port (on the alarm board) it
actually works?
Leo
…On Thu, 26 Sept 2024 at 13:33, metaljay ***@***.***> wrote:
I have totally lost the plot with this now. Board remains the same as
above (as in using pin 0 and 1)
I refreshed with ESP home like you did, my config looks good
esphome:
name: texecom-link
friendly_name: texecom-link
esp8266:
board: d1
external_components:
- source: github:https://oxan/esphome-stream-server
stream_server:
uart_id: uart_bus
port: 23
binary_sensor:
- platform: stream_server
connected:
name: texecom-link
uart:
id: uart_bus
tx_pin: GPIO1
rx_pin: GPIO0
baud_rate: 19200
data_bits: 8
stop_bits: 2
web_server:
port: 80
# Enable logging
logger:
level: DEBUG
# Enable Home Assistant API
api:
ota:
platform: esphome
wifi:
ssid: "XXX"
password: "XXX"
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Texecom-Link Fallback Hotspot"
password: "123456789"
captive_portal:
I can see from the debug terminal on ESPHome that it tries to connect to
the Texecom but it never actually gets through.
So frustrating
—
Reply to this email directly, view it on GitHub
<#77 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAG7MSAW64P3HMFPIYEAA7DZYP5I3AVCNFSM6AAAAABOTT5FWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZWHAZDMNBQGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
According to the D1 pinout (same board you have) the bottom two pins (TX and RX) are labelled as GPIO1 and GPIO3 im not smart enough to understand what you mean on points 2 and 3 (ill ask chatGPT to help dumb it down for me haha). I can't adjust the baud rate on comport 3 so I imagine it's 19200 on the Texecom side too? My esphome log looks like this, when 192.168.2.254 connects that's my texecom2MQTT add-on trying to connect but it errors out (so .254 is the add-on, .182 is the ESP8266): 
If I try 'sudo tcpdump -i en0 tcp and host 192.168.2.182 (the ESP) and host 192.168.2.254 (home assistant)' it doesn't look like any data is being sent - which doesn't make sense as I can see in ESPhome log that it tries to connect.. HA has it connecting and disconnecting all the time too |
|
Ok, working backwards... The Logbook entries show a successful connection between your serial client (the texecom mqtt plugin) and the server, so if it is failing to connect then it is no surprise that it disconnects/reconnects again and again. If you drop to the command line and try On that note:
Other thoughts:
Instead of trying to connect from texecom2mqtt (actually disable it) try connecting from wintex instead, as you know that works. Once you have that working, graduate to texecom2mqtt. Finally you said you got nothing from tcpdump. Which device were you running it on? It should work if you're on the esphome host. Anything else requires thought about whether the packets will pass through it. Generally they would with a router (actually acting as a switch), but if they were both wireless then you wouldn't see them as you're listening on ethernet.. and you might not see them anyway if the wireless switches directly without dropping down to the CPU. |
|
My wintex config, so actually listed as "nothing fitted"
and the config to then reach said device over wintex
|
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 a2alarm:
0b 5a 05 01 00 00 01 05alarm:
09 00 85If 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
The text was updated successfully, but these errors were encountered: