Per-thermostat telemetry from /devices: battery state, RF signal, valve details

[CaseyRo]

Follow-up to #11 (multi-zone discovery, shipping as 1.2.0) — split out so the bug can close when stable lands.

What

Expose per-device (ETRV / room-thermostat) telemetry from the /devices PointT API resource:

• Battery state — requested by @LukyHurdy1 in #11; the Bosch app shows battery warnings, so the API most likely exposes it
• RF signal strength per device
• Any further per-device details worth surfacing (device type, firmware, zone linkage)

Status

• Groundwork already merged: the coordinator polls /programs + /devices since POINTTAPI: improve sensor UX, dynamic discovery and translations #15
• @jfhautenauven is actively building on this (his devices dump on Room zones / radiator thermostats (ETRVs) not discovered as climate entities #11 documents the payload shapes; his Jeedom plugin covered the same data on the XMPP path: valve %, signal strength, zone linkage)
• Per-zone valve position already shipped in v1.2.0-beta.5 via Add PointTAPI select translations and robustness updates #14

Notes for implementation

• Entities should attach to their zone device (or their own child device with via_device) and follow the reference-driven discovery pattern from Add PointTAPI select translations and robustness updates #14/POINTTAPI: improve sensor UX, dynamic discovery and translations #15 — only create what the appliance advertises
• Constructors must pass data= to _resolve_device_info (the beta.6 regression test enforces name agreement)
• When this lands, revisit API load: the refresh already walks ~370 paths on a 10-zone install — the bulk endpoint (as used by serbanb11/homecom_alt) is the right long-term fix

[jfhautenauven]

Coming here -->

#17

[CaseyRo]

Shipped in v1.2.0-beta.8: https://github.com/CaseyRo/ha_bosch/releases/tag/v1.2.0-beta.8 🔋📶

@LukyHurdy1 — your battery request is in. @jfhautenauven built it on top of the /devices polling from #15, so each of your radiator thermostats now shows up as its own device named after its room, with:

• 🔋 Battery state
• 📶 Signal strength
• 🏠 Assigned zone and 📡 radio protocol
• ⚠️ a problem sensor that trips when the valve reports a warning code

Update via HACS, pick the beta, then reload the integration once so the new devices register. Let me know what your valves report — one thing I'd like to confirm is whether battery comes through as a readable state on your setup (mine reads ok / unknown).

This issue closes when stable 1.2.0 ships.

[CaseyRo]

Correction to my comment above: this shipped as v1.3.0-beta.1, not 1.2.0-beta.8 — same code, renumbered onto its own release line. Please install that one; beta.8 is marked superseded.

@LukyHurdy1 — your battery request is in it. Update via HACS with beta versions enabled, then reload the integration once, and each radiator thermostat should appear as its own device with battery, signal strength, assigned zone and protocol.

It's staying in beta rather than going into today's stable 1.2.0 because nobody has confirmed it on real multi-zone hardware yet — @jfhautenauven built it and is away until the end of August. So your report genuinely decides when this ships. What I'd most like to know: does battery come through as something readable on your valves, or as unknown?

Keeping this issue open until it lands in stable.

[LukyHurdy1]

Hello, the integration looks really nice and I would like to thank you.

I would also like to ask if it would be possible to show the temperature indicator of individual devices as a temperature sensor as well? If that's not possible, no worries at all 😊

Currently, I see the temperature as:
Entity ID: climate.XXXXXX

And it would be great to also see it as:
Entity ID: sensor.XXXXX

[CaseyRo]

@LukyHurdy1 — thanks! And good news: this one is cheap. The room temperature is already polled for every zone — it's what each climate. entity shows as its current temperature — so exposing it as a sensor. is just reading data we already hold. No extra requests to Bosch, no extra load on your gateway.

Worth saying why it's worth doing rather than dismissing as a duplicate: a climate entity's temperature is an attribute, and Home Assistant doesn't keep long-term statistics for attributes — they're purged along with your recorder history (10 days by default). A real sensor with a measurement state class is the only way to keep months of room-temperature history, or to use it in a statistics card. So this is a genuine gap, not just a second copy of the same number.

One thing I want to pin down before building it, because it changes what we make. You wrote "individual devices" — do you mean:

1. One sensor per room/zone, mirroring each climate. entity you already have → sensor.living_room_temperature, etc.
2. One sensor per radiator valve — the temperature each individual ETRV measures itself.

I ask because those aren't equally possible. Zone temperature is definitely there. But the per-device data Bosch gives us (/devices/list) carries signal strength, battery, assigned zone and protocol — no temperature field. So if you mean 2, I'd first have to go find out whether the API exposes it at all, and it may simply not.

Your climate.XXXXXX → sensor.XXXXX example reads like option 1 to me, but I'd rather ask than build the wrong thing. 😄

Two smaller ones while I'm in there:

• How many rooms/zones do you have? It decides whether these are on by default or opt-in — I don't want to hand someone with 12 rooms 12 entities they never asked for.
• Want the target temperature (setpoint) as a sensor too, or just the measured one?

And if you want it working today rather than waiting for me: Settings → Devices & services → Helpers → Create helper → Template → Template a sensor, with the state template {{ state_attr('climate.XXXXXX', 'current_temperature') }}. That gives you exactly this, per room, right now. What we'd build just saves you doing it by hand for every room — and makes it work for everyone else too.

[LukyHurdy1]

Thanks for the quick reply! I'll keep monitoring it, but looks great so far—nice work. Don't worry about changing any entities, I can always set up a helper if needed. Just a random thought/idea anyway.

[CaseyRo]

Fair enough — the helper covers it, so I'll leave the entity list alone. Noted for if it comes up again. 👍

But since you're clearly running it and paying attention: there's one 30-second thing you could do that would genuinely unblock a release. 😄

The battery state you asked for on Monday is built — it's in v1.3.0-beta.1. What it isn't is confirmed. @jfhautenauven wrote it and left on holiday until the end of August, and my own CT200 is single-zone with no radiator valves, so I cannot see a single one of these entities from here. Right now nobody has laid eyes on it against real hardware.

If you're up for it: in HACS enable beta versions, update to 1.3.0-beta.1, reload the integration once, and then open any one of your radiator valve devices. You should see it as its own device named after its room, with battery, signal strength, zone and protocol.

The one answer I'm after: does battery show something meaningful, or does it just say unknown? A screenshot of one valve device is plenty — no diagnostics dump needed.

If it reads properly, that's the confirmation 1.3.0 ships on, and the feature you asked for reaches everyone rather than sitting in beta for three weeks waiting for its author to come back from the beach. 🏖️

And if it's broken, that's just as useful — better now than in a stable release.

[LukyHurdy1]

I think that working correctly .

[jfhautenauven]

@CaseyRo : issue can be closed with latest code changed IMHO

[CaseyRo]

Stable v1.3.0 is out — and @LukyHurdy1, it shipped on your screenshot. 🎉

That one image settled everything I couldn't check from here: battery ok, signal 69%, protocol homematicip, warning sensor reading OK, valve appearing as its own device named after the room. My CT200 is single-zone with no radiator valves, so I genuinely could not see a single one of those entities. @jfhautenauven built the feature and left for the beach before anyone could run it. You closed that gap in about thirty seconds.

So: requested by you on Monday, built by @jfhautenauven, confirmed by you this morning, stable by Tuesday evening. That's the whole loop working properly. 🙏

Update via HACS — you can turn off beta versions now, 1.3.0 is the stable channel.

Two things your screenshot also showed me, which are already fixed and heading for the next beta:

• Your valve reports zone 2 where it should say the room name (you'd see Obývací pokoj instead).
• Battery reads ok in lowercase while the warning sensor next to it reads OK — inconsistent, now normalised.

@jfhautenauven had spotted both and fixed them in #18 before either of us reported them, which is slightly annoying of him. 😄

Closing this — it's in stable. If your other valves show anything odd (a battery going unknown, a warning code you can't explain), open a fresh issue and I'll dig in.