10-19-2026, 12:55 PM
Thank you, that makes sense: the HAv2 panels send on their own as masters, the TS only answers as a slave, and there is no arbitration, so two transmissions at the same moment are lost. We accept that, just as two panels pressed at the same instant already can't both get through.
We tested it on our bench F24 (ESPHome) with one TS at address 101 on the HAv2 bus, polled every 10 s, and 10 presses on one panel for each run:
- Stock kc868_ha v3.0.3: only 6 of 10 presses arrived. The cause was not collisions. The component reads the UART in fixed 21-byte blocks, so after a 9-byte TS reply it is out of step, the CRC check fails, and it flushes the buffer, which costs the next button press.
- With a small change to loop() that searches for the HAv2 frame header and checks the CRC before accepting a frame: 10 of 10 presses, no CRC errors, and all 40 TS replies read.
We are happy to share the change as a pull request to esphome-kc868-ha if it is useful.
For production we plan to poll each TS only every 90 minutes, only when the bus has been quiet, and never within a few seconds of a button press. That keeps the remaining collision risk very small.
Three questions:
1. If a button frame is lost in a collision, does the HAv2 send it again? Does it expect any reply from the controller?
2. Does the HAv2 check that the bus is idle before it transmits?
3. Can foreign Modbus frames on the bus (TS polls and replies, address 101+) ever disturb the HAv2, for example when it parses LED frames?
And a feature request for a future HAv2 version: either a small I2C header for a temperature/humidity sensor /IRreceive/IRSend, or a setting in HA485_Ctrl for "my TS address", so the HAv2 polls its own sensor and adds the values to the frame it already sends to the controller. Then the readings would never compete with button presses.
We tested it on our bench F24 (ESPHome) with one TS at address 101 on the HAv2 bus, polled every 10 s, and 10 presses on one panel for each run:
- Stock kc868_ha v3.0.3: only 6 of 10 presses arrived. The cause was not collisions. The component reads the UART in fixed 21-byte blocks, so after a 9-byte TS reply it is out of step, the CRC check fails, and it flushes the buffer, which costs the next button press.
- With a small change to loop() that searches for the HAv2 frame header and checks the CRC before accepting a frame: 10 of 10 presses, no CRC errors, and all 40 TS replies read.
We are happy to share the change as a pull request to esphome-kc868-ha if it is useful.
For production we plan to poll each TS only every 90 minutes, only when the bus has been quiet, and never within a few seconds of a button press. That keeps the remaining collision risk very small.
Three questions:
1. If a button frame is lost in a collision, does the HAv2 send it again? Does it expect any reply from the controller?
2. Does the HAv2 check that the bus is idle before it transmits?
3. Can foreign Modbus frames on the bus (TS polls and replies, address 101+) ever disturb the HAv2, for example when it parses LED frames?
And a feature request for a future HAv2 version: either a small I2C header for a temperature/humidity sensor /IRreceive/IRSend, or a setting in HA485_Ctrl for "my TS address", so the HAv2 polls its own sensor and adds the values to the frame it already sends to the controller. Then the readings would never compete with button presses.