Setup
- Gateway: Xcom-232i (with RCC-02, Xtender XTM 3500-24, BSP on the SCOM bus)
- Serial parameters: 38400 baud, 8E1
- Bridge: Waveshare RS232/485-ETH (B), TCP server mode (port 8899), raw/transparent
- Proxy: custom Python proxy between Home Assistant and the Waveshare bridge
- Client: pystuderxcom / hass-studer-xcom
- OS: Linux
[Xtender + BSP + RCC-02] ── SCOM bus ── [Xcom-232i] ── RS232/8E1 ── [Waveshare :8899] ── LAN ── [Proxy] ── TCP :4001 ── [pystuderxcom / HA]
Role of the proxy
The proxy bridges two TCP connections and acts as a TCP client on both sides:
- Towards the Waveshare bridge: the proxy connects as a TCP client to the Waveshare, which runs in TCP server mode (port 8899). The serial Xcom traffic (RS-232, 8E1) flows over this link.
- Towards Home Assistant/pystuderxcom: the proxy connects as a TCP client to pystuderxcom, which runs a TCP server listening on port 4001. This is exactly the role a real serial-to-Ethernet gateway (Moxa/Waveshare) would take: pystuderxcom always listens, and the gateway is the connecting party.
The proxy forwards all traffic transparently — with one exception (see below).
Observation
During discovery, pystuderxcom sends (among others) a frame with object_type = 4 (dst=501). The Xcom-232i does not answer this frame and locks up completely immediately afterwards: it stops responding to any further frames. Only a power cycle (hardware reset) of the Xcom-232i restores communication.
For this reason, the proxy intercepts this specific frame (object_type = 4, dst=501) and answers it itself with an error frame instead of passing it through to the hardware. With this in place, everything works flawlessly: discovery, cyclic reading, and writing (to RAM via property_id = 0x0D).
Key point: Frames with object_type ∈ {1 (INFO), 2 (PARAMETER), 3 (MESSAGE)} are answered correctly by the Xcom-232i (confirmed via debug logs). Only object_type = 4 causes the hardware to lock up.
Questions
- What is the purpose of the
object_type = 4 frame in the discovery flow?
- Is it strictly required, or could it be made optional/removable (e.g. via a config flag)?
- Are there setups (e.g. Xcom-CAN, Xcom-LAN/Moxa) where the gateway responds to it in a meaningful way — or is the lock-up a general Xcom-232i behaviour?
I'm happy to provide full debug logs (OUT/IN frames) as well as the proxy source code.
Setup
Role of the proxy
The proxy bridges two TCP connections and acts as a TCP client on both sides:
The proxy forwards all traffic transparently — with one exception (see below).
Observation
During discovery, pystuderxcom sends (among others) a frame with
object_type = 4(dst=501). The Xcom-232i does not answer this frame and locks up completely immediately afterwards: it stops responding to any further frames. Only a power cycle (hardware reset) of the Xcom-232i restores communication.For this reason, the proxy intercepts this specific frame (
object_type = 4, dst=501) and answers it itself with an error frame instead of passing it through to the hardware. With this in place, everything works flawlessly: discovery, cyclic reading, and writing (to RAM viaproperty_id = 0x0D).Key point: Frames with
object_type∈ {1 (INFO), 2 (PARAMETER), 3 (MESSAGE)} are answered correctly by the Xcom-232i (confirmed via debug logs). Onlyobject_type = 4causes the hardware to lock up.Questions
object_type = 4frame in the discovery flow?I'm happy to provide full debug logs (OUT/IN frames) as well as the proxy source code.