feat: enrich Zigbee sensors with room data from RoomControl by lackas · Pull Request #743 · openviess/PyViCare

lackas · 2026-04-16T12:58:35Z

Background

Viessmann has removed device.sensors.temperature and device.sensors.humidity from physical Zigbee room sensors (E3_RoomSensor). Comparing current API responses (Apr 2026) with #557 test data (May 2025), the sensors went from 12 features down to 6 — only battery, zigbee signal, and identification remain.

The temperature and humidity data still exists, but only on the RoomControl virtual device under rooms.N.sensors.*. This means RoomSensor.getTemperature() and getHumidity() silently stopped working for affected installations.

Design

Rather than mapping Viessmann's room abstraction into a new device hierarchy (as #557 proposed), this PR enriches the existing physical Zigbee devices with data from RoomControl — following @CFenner's preferred approach (#557 (comment)).

The cross-referencing works because RoomControl lists "actors" per room — these are the Zigbee device IDs of the physical sensors and floor heating channels in that room. We reverse this mapping: given a Zigbee sensor's device ID, find which room it belongs to, then read that room's sensor data.

How it works

roomControl added to device type filter — PyViCare now discovers RoomControl devices
After device discovery, __enrichZigbeeDevices() builds an actor→room mapping from each RoomControl
For each Zigbee device whose ID appears as an actor, the RoomControl reference and room ID are stored on the PyViCareDeviceConfig
When asRoomSensor() creates a RoomSensor, the enrichment is applied
RoomSensor.getTemperature() transparently reads from RoomControl when enriched, falls back to device-level data for installations without RoomControl (older API or different device models)

What's exposed

Sensors: temperature, humidity, CO2, condensation risk
Operating state: level, demand, reason
Heating programs: normal/reduced/comfort target temperatures with setTemperature commands
Quick mode: manual till next schedule (activate/deactivate/set temperature)
Schedule: read (per room)
Room metadata: name, type

What's NOT in this PR

No new HA integration entities — that's a separate HA Core PR once this lands
No changes to FloorHeatingChannel enrichment — floor heating channels also appear as actors but don't need sensor data. Could be added later for operating state.
Deprecated features (window.openState, operating.programs.active) are excluded

Test data

Depends on #742 for the E3_RoomControl_One_525 test data (contributed by blob810, sanitized).

Breaking changes

None. Existing behavior is preserved — enrichment only activates when a RoomControl device exists. Installations without RoomControl are unaffected.

lackas · 2026-04-17T06:21:41Z

HA integration steps

Once this lands and is released, the HA vicare integration needs:

Bump PyViCare version
Filter out roomControl devices from entity creation — RoomControl is an implementation detail for enrichment, users shouldn't see it as an HA device. One-line check: skip device_config.getDeviceType() == "roomControl".

That's enough to restore room_temperature and room_humidity sensors — the existing GLOBAL_SENSORS descriptions already call getTemperature() / getHumidity(), which now work again via enrichment.

For the new features (heating targets, condensation risk, schedules, quick modes), we'd add entity descriptions in a follow-up HA PR.

Impact and risk

For installations with RoomControl + Zigbee sensors (blob810's case): Temperature and humidity are restored on the physical sensor devices. Heating targets, condensation risk, and schedules become available. Confirmed working on a 10-room installation.

For installations without RoomControl (our test case): The enrichment finds RoomControl devices with 0 rooms, builds an empty actor map, and does nothing. No extra API calls, no side effects. Verified on a CU401B_G + VitoCharge setup with two RoomControl devices present but no Zigbee sensors.

For installations without RoomControl at all: The enrichment loop simply finds no roomControl devices and skips entirely. Zero impact.

`isSupported` handling

Features that only work with enrichment (CO2, room name, heating targets, etc.) now properly integrate with PyViCare's @handleNotSupported decorator. Without enrichment, _getRoomControl() raises KeyError, which the decorator converts to PyViCareNotSupportedFeatureError. This means HA's is_supported() check correctly reports these features as unsupported — no entity is created, no silent None values. Tested with isSupported() assertions and exception checks.

CFenner · 2026-04-16T13:28:43Z

+        self._room_control = None
+        self._room_id = None


This can move to class level, no?

CFenner · 2026-04-28T06:57:12Z

            (self.asRadiatorActuator, r"E3_RadiatorActuator", ["type:radiator"]),
            (self.asFloorHeating, r"Smart_zigbee_fht_main|E3_FloorHeatingCircuitDistributorBox", ["type:fhtMain"]),
            (self.asFloorHeatingChannel, r"Smart_zigbee_fht_channel", ["type:fhtChannel"]),
+            (self.asRoomControl, r"E3_RoomControl|Smart_RoomControl", ["type:virtual;smartRoomControl"]),


Will this class only represent the virtual device that handles the room thermostat mapping or also in-room control real devices?

Only the virtual device (role type:virtual;smartRoomControl). Physical in-room controllers like Vitotrol 300E are separate zigbee devices with their own device type and class.

lackas · 2026-04-28T07:15:22Z

Addressed review comments:

Moved _room_control and _room_id to class-level defaults (no more __init__)
Added type hints to all RoomSensor methods
Fixed pylint too-many-instance-attributes on PyViCareDeviceConfig
Rebased on updated chore(testdata): add E3_RoomControl_One_525 test data #742

Re: RoomControl scope question - it only represents the virtual device (role type:virtual;smartRoomControl). It holds the room-to-sensor mapping and room-level data (temperature, humidity, CO2, schedules). The physical in-room controllers (Vitotrol 300E etc.) are separate zigbee devices with their own device type.

CFenner · 2026-04-28T08:08:52Z


+            # RoomControl - room sensor data, used by enrichment (#743)
+            'rooms',
+            'rooms.0',


Is this limited to 10 rooms?

No, it's not limited to 10 rooms. I just realized these ignore entries are actually unnecessary -- find_feature_in_code already replaces single digits with {.*?}, so rooms.5.sensors.temperature in test data matches f"rooms.{room_id}.sensors.temperature" in code. The test passes without them. I'll remove the entire block.

Adds sanitized RoomControl device data with 10 rooms including temperature, humidity, and actor mappings to Zigbee room sensors and floor heating channels. Data contributed by blob810 from a Vitocal 222-SI installation with E3_RoomControl_One_525 (RoomControl-1).

Viessmann removed temperature and humidity data from physical Zigbee room sensors and moved it to the RoomControl virtual device. This restores the data on the physical sensors by cross-referencing RoomControl actor mappings with Zigbee device IDs. Enriched data includes: - Temperature, humidity, CO2 sensors - Condensation risk - Operating state (level, demand, reason) - Heating programs (normal/reduced/comfort) with set commands - Quick mode (manual till next schedule) with activate/deactivate - Schedule (read) - Room name and type Changes: - Add RoomControl device class with full room API - Add roomControl to device type filter - Enrich RoomSensor after device discovery via actor cross-reference - RoomSensor transparently reads from RoomControl when enriched, falls back to device-level data for older API versions - Add auto-detect entries for E3_RoomControl and Smart_RoomControl

…typed)

RoomControl: concrete return types with float/int/str/bool coercion at the Any boundary (matching existing PyViCare style). RoomSensor: _getRoomContext() returns (RoomControl, str) tuple, eliminating str|None arg-type errors cleanly.

find_feature_in_code already replaces digits with wildcards, so rooms.N features match rooms.{room_id} in code automatically.

CFenner · 2026-04-28T08:24:19Z

The room thermostat can be enhanced the same way no?

Yes, any device that shows up as an actor in a RoomControl room could be enriched the same way. Right now we only do it for RoomSensor, but extending to RadiatorActuator or FloorHeating would be straightforward -- same setRoomControlEnrichment pattern. Happy to add that in a follow-up if there's demand.

Ok, then let's go with this first.

The RoomControl-driven Zigbee enrichment introduced in #743 does not work in practice: the rooms.{id}.actors mapping that drives buildActorRoomMap() is not returned by the API for end users, so the enrichment is silently no-op and the lib has no reliable path to associate physical Zigbee devices with rooms. Removes the enrichment plumbing and reverts RoomSensor to direct sensor reads (device.sensors.temperature, device.sensors.humidity). RoomControl itself stays for direct per-room access. BREAKING CHANGE: RoomSensor no longer exposes hybrid getters that required RoomControl context (getRoomName, getRoomType, getCondensationRisk, getOperatingState*, getNormal/Reduced/Comfort HeatingTemperature, getManualTillNextSchedule*, getSchedule). Use the corresponding RoomControl methods with a room_id directly. Co-authored-by: Christopher Fenner <9592452+CFenner@users.noreply.github.com>

CFenner reviewed Apr 28, 2026

View reviewed changes

lackas mentioned this pull request Apr 28, 2026

chore(testdata): add E3_RoomControl_One_525 test data #742

Merged

lackas force-pushed the feature/room-sensor-enrichment branch from 1f03875 to 416ef89 Compare April 28, 2026 07:14

lackas requested a review from CFenner April 28, 2026 07:15

CFenner reviewed Apr 28, 2026

View reviewed changes

lackas force-pushed the feature/room-sensor-enrichment branch from c17da01 to 0d6735d Compare April 28, 2026 09:50

lackas and others added 9 commits April 28, 2026 13:11

Update RoomControl.json

403f72f

fix: sort test data and update deprecation database

5efde83

Refine RoomControl enrichment handling

7fe9234

Address review: add type hints, class-level attrs, fix pylint

0554fde

fix: use Any return types to satisfy mypy (RoomControl methods are un…

48a37ad

…typed)

remove unnecessary rooms ignore list entries

5ccddfd

find_feature_in_code already replaces digits with wildcards, so rooms.N features match rooms.{room_id} in code automatically.

lackas force-pushed the feature/room-sensor-enrichment branch from 0d6735d to 5ccddfd Compare April 28, 2026 11:14

CFenner reviewed Apr 28, 2026

View reviewed changes

CFenner approved these changes Apr 28, 2026

View reviewed changes

CFenner merged commit 953ba71 into openviess:master Apr 28, 2026
9 of 10 checks passed

CFenner added the new-feature label Apr 28, 2026

This was referenced Apr 28, 2026

fix: catch all exceptions during Zigbee device enrichment #751

Merged

Bump PyViCare to 2.60.1 home-assistant/core#169401

Merged

lackas mentioned this pull request May 7, 2026

feat!: remove non-functional Zigbee room enrichment #757

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: enrich Zigbee sensors with room data from RoomControl#743

feat: enrich Zigbee sensors with room data from RoomControl#743
CFenner merged 9 commits intoopenviess:masterfrom
lackas:feature/room-sensor-enrichment

lackas commented Apr 16, 2026

Uh oh!

lackas commented Apr 17, 2026

Uh oh!

CFenner Apr 16, 2026

Uh oh!

Uh oh!

CFenner Apr 28, 2026

Uh oh!

lackas Apr 28, 2026

Uh oh!

lackas commented Apr 28, 2026

Uh oh!

CFenner Apr 28, 2026

Uh oh!

lackas Apr 28, 2026

Uh oh!

CFenner Apr 28, 2026

Uh oh!

lackas Apr 28, 2026

Uh oh!

CFenner Apr 28, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

lackas commented Apr 16, 2026

Background

Design

How it works

What's exposed

What's NOT in this PR

Test data

Breaking changes

Uh oh!

lackas commented Apr 17, 2026

HA integration steps

Impact and risk

isSupported handling

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lackas commented Apr 28, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

`isSupported` handling