Protocol basics (simplified)

To communicate with each other, computers require a protocol — a "common language" that all connected devices understand and use. Well-known protocols include Modbus for communication to various devices, ot the Transmission Control Protocol / Internet Protocol (TCP/IP), which every computer relies on to communicate over the Internet.

The protocol used by Helios/Vallox ventilation systems is similar to Modbus but not identical, which is why a custom integration is necessary. Its key characteristics are:

• Each device has a fixed unique address, e.g., 11 for the mainboard of the ventilation unit, 21 for the first remote control.
  Additionally, there are broadcast addresses for groups of devices, e.g., 10 for all mainboards, 20 for all remote controls.

• Each transmission packet has a fixed length of exactly 6 bytes:
  [start(always_1)] [sender_address] [receiver_address] [data1] [data2] [checksum]

• If data1 = 00, it is a request, followed by a particular register number/ID in data2.

• If data1 ≠ 00, it is a response to a request. data1 contains a register number/ID, data2 holds its value.

Here a typical example (FB=Fernbedienung/Remote Control, MB=Mainboard):

01 21 11 00 a3 d6    FB1>MB1: remote control (21) requests (00) from mainboard (11) the power state (a3)
01 11 21 a3 01 df    MB1>FB1: mainboard (11) replies to remote control (21): power state (a3) is 'on' (01)

Special protocol features: Regular broadcasts and polls

The mainboard broadcasts the following packets to all remotes approximately every 12 seconds:

2025-01-27 17:33:28,985       01 11 20 2b 00 5d    MB1>FB*   CO2 (upper byte)
2025-01-27 17:33:29,091       01 11 20 2c 00 5e    MB1>FB*   CO2 (lower byte)
2025-01-27 17:33:29,197       01 11 20 35 9e 05    MB1>FB*   temperature_supply_air: 19°C
2025-01-27 17:33:29,303       01 11 20 34 a2 08    MB1>FB*   temperature_extract_air: 21°C
2025-01-27 17:33:29,410       01 11 20 32 86 ea    MB1>FB*   temperature_outdoor_air: 11°C
2025-01-27 17:33:29,516       01 11 20 33 91 f6    MB1>FB*   temperature_exhaust_air: 14°C
2025-01-27 17:33:29,623       01 11 20 2a 27 83    MB1>FB*   max humidity measured

Each remote control polls the mainboard approximately every 5.5 seconds to refresh the information shown on the display:

2025-01-27 17:33:30,748       01 21 11 00 a3 d6    FB1>MB1   Request LED's (Flags 1)
2025-01-27 17:33:30,749       01 11 21 a3 09 df    MB1>FB1   LED's 9 (on off off on)
2025-01-27 17:33:30,749       01 21 11 00 29 5c    FB1>MB1   Request fanspeed
2025-01-27 17:33:30,749       01 11 21 29 07 63    MB1>FB1   fanspeed: 3
2025-01-27 17:33:30,749       01 21 11 00 35 68    FB1>MB1   Request temperature_supply_air
2025-01-27 17:33:30,750       01 11 21 35 9e 06    MB1>FB1   temperature_supply_air: 19°C
2025-01-27 17:33:30,750       01 21 11 00 a3 d6    FB1>MB1   Request display icons (Flags 2)
2025-01-27 17:33:30,750       01 11 21 a3 09 df    MB1>FB1   display icons: 9 (on off of on)
2025-01-27 17:33:30,750       01 21 11 00 71 a4    FB1>MB1   Request boost_status
2025-01-27 17:33:30,751       01 11 21 71 00 a4    MB1>FB1   Boost is 0 (off)

This typically results in the RS485 bus being occupied at regular intervals. It also seems that broadcasts and frequent polls have priority in the programming of the ventilation. Therefore, the integration must delay sending packets if a poll occurs at the same time ('bus is not silent'), or re-send its request if the poll has already been sent, but no answer is received yet ('re-read').

Further details on this are also explained in this FAQ entry.