KC868-HAv2: TS sensor on HAv2 bus, temp/humidity at panel, source code

[swisstmack25]

Hello KinCony team,

We have received order #QEDPUML5Q (4x KC868-F24 DC 12 V, 27x KC868-HAv2, 6-gang and 2-gang momentary panels). Each F24 runs ESPHome with the kc868_ha component and has its own HAv2 RS485 bus (9600 baud, up to 8 panels). The panels sit in European 60 mm flush-mounted boxes.

We need temperature and humidity at each wall panel for heating control, and we cannot run new cables (the panel cable has no spare cores).

1. We already have KinCony TS sensors (SHT30, RS485 Modbus), but we were told the TS cannot share the HAv2 bus. We would like to understand why.
From your protocol document (KC868-HA protocol v1.06, tid=8624) and our own bus captures: an HAv2 button frame is a Modbus FC16 write addressed to the controller (byte 0 = controller address, default 1), and the register field carries the panel's own HAv2 address (10-99). On the TS, register 0x000A is its own RS485 address and 0x000B its baud rate, and the TS default address is 1, the same as the controller. So a TS on its default address would take every button frame as a write to itself, and the panels with HAv2 address 10 and 11 would overwrite its address and baud rate.
- Is that the reason?
- If every TS is set to its own address of 100+ (never the controller address the HAv2 modules target) and its terminating jumper is off, does the restriction still apply? If yes, what is the reason?
- Do the HAv2 modules (V2 firmware) ignore Modbus frames that are not "03 12 55 BB" frames from the controller?
- If an HAv2 button frame collides with a Modbus poll from the F24, does the HAv2 retry the button event?

2. In thread tid=6966 you mentioned an "HAv2 with SHT30 sensor" as a possible product. Is that available or planned?

3. Could you share the HAv2 V2 firmware source code (AT32F413), or at least the full specification of the V2 private protocol? We would like to add a temperature/humidity reading to the HAv2 frames ourselves. (We have the schematic R485HA_V200.pdf from tid=5840.)

4. The HAv2 has the P3 terminating resistor jumper. Does the F24 also have built-in 120 ohm termination on its RS485 port, or should we fit an external resistor there?

Thank you,
swisstmack25

[admin]

because HAv2 is "MATER", TS is "SLAVE".
The slave station operates via passive response—after all, you have a switch connected to the HV2 terminal. Since switches can be pressed in any room, it’s possible for multiple users to attempt to operate them at the same time; in such cases, simultaneous control is not supported.

[swisstmack25]

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.

[admin]

thanks share your code.

Question 1: The HAV2 does not perform "repeat asks" (re-polling); instead, it receives status reports from the F24 regarding the corresponding lights (where the panel indicator reflects the relay state, and all nodes update their status accordingly). In the event of a data collision, one must simply retry the operation to obtain the correct value.

Question 2: There is no check for bus availability (idle state). In a home automation context, the probability of switches being pressed simultaneously is extremely low.

Question 3: When sharing a bus, operations must be time-multiplexed. The HAV2 must not initiate any operations while the TS (Time-Slot/polling master) is polling the bus; however, under normal circumstances, this will not cause the HAV2 to malfunction.

[swisstmack25]

Thank you for the clear answers, that helps a lot.

So a lost press is not repeated and the HAv2 does not wait for an idle bus. Collisions can only be avoided on the
controller side, which is what we do: the F24 polls the TS only when the bus has been quiet, never within 10 s of a
button frame, and tries up to 3 times. Good to know that foreign frames do not disturb the HAv2 itself.

Update from our bench: 18 hours with the TS polled every 10 s on the HAv2 bus, using the patched kc868_ha.
6,438 polls, 6,436 replies (one retry, one poll in flight when we read), 0 failed cycles, no reboot. In production
we will poll only every 90 minutes.

The code change is here as a pull request: https://github.com/hzkincony/esphome-kc868-ha/pull/3

Thanks again.