Six valves move house — and the radio network improved

On the radiators of the Merano flat sit six thermostat heads. They spoke Bluetooth, through two small gateways that translate that radio into the network.

Each of those gateways occupies a power socket. That was the whole occasion: the sockets were needed for something else.

In the end the gateways were gone, the valves kept working — and the weakest radio link in the house was better than before.

What such a valve can and cannot do is in the general piece on radiator thermostats. This one is only about the radio path.

The starting point had a quirk

Every valve appeared in Home Assistant twice: once through its gateway, once directly over Bluetooth from the Raspberry Pi. The direct copy carries “BLE direct” in its name.

They look the same and are not: the direct copy only delivers readings. Only the gateway variant can switch.

Two entities for the same device are not a convenience. They are an invitation to pick the wrong one in an automation and then wonder why nothing happens.

The finding that made it all simple

The heads can do Zigbee. Not through extra hardware, but through the same radio component: Bluetooth LE and Zigbee sit in one chip.

Zigbee from firmware	1.3.2
Activation	five clicks on the device
Separate firmware image	not needed

All six heads already met the condition. So the move cost no device and no money — only an evening.

What was checked first, in this order

What hangs off the gateways besides the valves? Almost nothing: two active entities each, a restart button and a firmware version. Plus one outdoor sensor that one gateway carried redundantly — it arrives directly at the Pi’s Bluetooth anyway and keeps running without a gateway.

Is any logic attached to the valve entities? The relationship query returned, for all six: no automation, no script, no scene. Their identifiers change in the move — nothing was hanging off them.

Before a migration the important question is not “can this be done?” but “who depends on it?”

And one justification that fell apart under testing. Keeping one gateway “for firmware updates” sounded sensible. Measured on the living-room head: both update calls through the gateway answer with HTTP 500, and the device stayed unchanged. Firmware reaches these heads only through the Shelly app over Bluetooth.

Keeping a gateway “for updates” is therefore pointless — the reasoning had simply never been tested.

The channel: measured, not taken from a recommendation

The handover document recommended Zigbee channel 15, 20 or 25. That recommendation only holds when the Wi-Fi sits on 1, 6 or 11. Here it sits elsewhere:

own Wi-Fi          channel 11
neighbours         channels 9 and 13
occupied           2441–2483 MHz
free               2401–2441 MHz
Zigbee channel 11  2405 MHz   -> in the free range

Zigbee 20 and 25 would have been exactly wrong here — right in the occupied range. Channel 11 stayed.

A channel recommendation is a statement about somebody else’s house. In Kapfenberg, for the same reason, channel 20 was the right choice — there the Wi-Fi sits on 1.

A footnote that saves confusion: Wi-Fi channel 11 and Zigbee channel 11 denote different frequencies — 2462 against 2405 MHz. The shared number is coincidence.

Setting it up, with every stumbling block

Four things cost time, and none of them was in a guide.

The add-on’s options have to be set completely. Sending only the interface path aborts with a complaint about a different missing option. The correct way is: read the existing options, add to them, write them back.

The newer version starts into an onboarding mode and waits for its web interface. The way past it is a switch in the configuration file plus a restart.

The add-on writes the broker credentials itself — a separate user is not needed. That is the point where such migrations usually get stuck.

The pairing window is open for 254 seconds. My first attempt missed it because it had expired; the head’s display then simply says no. And an abort on first contact with an immediate second attempt is normal, not a fault.

What arrived

Per head: setpoint, measured temperature, valve position readable and writable, battery level, a calibration button and a manual-mode switch. Functionally that fully covers what the gateways provided.

The write test is the one I like best:

setpoint set to 20 °C   -> accepted and reported back
valve position          -> stayed at 0 %
room temperature        -> 27.1 °C

The valve correctly stayed shut because the room was warmer than the setpoint. A test that proves something works by nothing happening.

The network test before removal

Twenty minutes, all six heads directly on the coordinator, with no router in between. What was measured is link quality:

Valve	Messages	worst	mean
bedroom wall	15	87	101
bathroom	19	39	70
kitchen	18	27	60
living-room radiator	20	42	58
child’s room	22	45	57
bedroom window	20	18	46

Result: no repeater is needed. The low outliers are single moments, not a persistently poor link.

The removal — and the surprise

Here lies the trap you need to know about: the valves belong to the same configuration entry as their gateway. Delete the entry and you take both with it.

That is exactly how it was done, and before the plugs were pulled:

Entry	removed
gateway 1	gateway plus 2 valves — 3 devices, 21 entities
gateway 2	gateway plus 4 valves — 5 devices, 35 entities

No restart was needed. The side effect was intended: afterwards nobody can confuse the old entities with the new ones, because the old ones no longer exist.

And then the number I had not expected:

The worst link in the network rose from 18 to 48.

The two gateways stood close to the valves and transmitted in the same band. Once they were gone, the weakest link became more than twice as good. The planned extra repeater was settled before it was bought.

A warning that cost me a set of batteries

After pairing I sent the calibration command to all six heads — it seemed tidy.

The living-room head had been running faultlessly and afterwards reported “not calibrated”. A second run did not help. What brought it back was fresh batteries; its cells were the oldest in the house.

Plus a detail that explains older measurement series: the step counter starts again at zero after a battery change. What looks like a reset in old logs was a battery change.

Recalibrating a working head without cause is not diligence. It is an unnecessary risk on a device that is currently doing its job.

What I’d suggest

1. Check whether your hardware already does the second radio. In these heads Zigbee sat in the same chip — five clicks, done.
2. Ask who depends on the old entities before you move. Here it was nothing, and that is why one evening sufficed.
3. Test the reason you want to keep something. “For updates” sounded good and was wrong.
4. Measure the channel instead of adopting a recommendation. It applies to a Wi-Fi on channels other than yours.
5. Delete the configuration entry before you unplug hardware. Otherwise your system keeps looking for a device that is gone.
6. Calibrate only what needs calibrating.

So what?

The occasion was two power sockets — the most prosaic reason for a rebuild you can imagine.

What came out of it is more: two fewer devices in the house, no duplicate entry per valve, one transport path instead of two, and a radio network whose weakest point more than doubled.

The remarkable part is that the gateways themselves were the problem they appeared to solve. They stood close to the valves because that was supposed to secure the range — and so they stood exactly where they interfered.

I only noticed because before and after were measured with the same tool. Without that measurement the explanation would have been “Zigbee is simply better”, and that would have been wrong.