Drayton Wiser Integration for Home Assistant

Just buy Wiser. It works really, really well, it can operate without a cloud service, you can integrate it with Home Assistant to add layers on top of the base system and you have a warranty and tech support if you should need it. About the only downside is hanging a(nother) Zigbee network fighting for frequency space alongside your WiFi and any other Zigbee you might already have. Heating is important. Home brew is nice, but you can guarantee it will go wrong or need attention at the worst time - this is an area where an established ‘appliance’ makes sense.

Excerpt saved from the Arctic Shift Reddit archive on 2026-10-23.

… under Z2M). As for other options, I know a few using Tado via Homekit in hass and then block the ecobee devices from the internet. Also know some using Drayton Wiser with local control and blocked from internet.

Excerpt saved from the Arctic Shift Reddit archive on 2026-10-23.

Summary Adds Home Assistant battery support for Wiser wireless button panels, addressing the battery-reporting part of #691. The integration now: - Recognises API objects representing wireless button panels - Creates a battery sensor when the hub supplies usable battery data - Resolves battery devices by both device ID and product type, preventing collisions with combined light/button-panel devices - Handles temporarily missing devices and battery values without breaking sensor setup or coordinator refreshes - Avoids creating unsupported battery entities for button panels that do not report …

Excerpt saved from GitHub on 2026-10-23.

Added support for PowerTag C - issue #528 - BREAKING CHANGE - refactored HW climate automation - issues #481, #490. See wiki for updated instructions - Added illuminance, humidity and temp sensors to devices with threshold sensors - issue #531 - Added support for 2 gang light switch - issue #529 - Added interacts with room climate switch to supported devices - Fixed support for Binary sensors with threshold sensors - issue #530 - Fixed incompatibility with Python3.13 and HA2024.12 - issue #535 - Fixed events not correctly firing for climate changes - issue #526 - Fixed error when saving …

Excerpt saved from GitHub on 2026-10-23.

Fixed smoke alarm naming issue - issue #496 - Set humidity to Unavailable if no value - issue #503 - Add support for BoilerInterface - issue #499 - Add support for WindowDoorSensor for v2 hub - Add support for CFMT device for v2 hub - issue #507

Excerpt saved from GitHub on 2026-10-23.

Added support for heating actuators in devices * Added basic support for Shutters and Lights in devices * Bump api to 0.0.13 * Improved handling of battery data * Changed model to use product_type as model_identifier not consistantly supplied for all devices

Excerpt saved from GitHub on 2026-10-23.

Summary - Adds `WiserHotWaterSwitch`, a stateful `SwitchEntity` that reflects the real `hotwater.current_state` and calls `override_state("On"/"Off")` on turn on/off, so Hot Water can be exposed to HomeKit as a proper switch with accurate state (instead of only the stateless "Toggle Hot Water" button that requires guessing at current state). - Purely additive, the existing `WiserOverrideHotWaterButton` is left in place, so no existing entities/automations are broken. Fixed issue #626 ## Test plan - [x] `python -m unittest discover -s tests -v`, all 17 tests pass (4 new tests added covering …

Excerpt saved from GitHub on 2026-10-23.

Summary Hub V1 currently exposes the following entities even though the corresponding data is unavailable: - Summer comfort available - Summer discomfort prevention - PCM device limit reached This leaves unsupported entities showing `Unknown` or misleading default states. ## Changes - Create the three system binary sensors only when: - the hub reports generation 2; and - the API supplies summer-comfort capability data. - Remove unsupported entries previously registered on affected hubs. - Recognize both historical plain unique IDs and migrated UUID unique IDs during cleanup. - Verify that …

Excerpt saved from GitHub on 2026-10-23.

Summary Reintroduces detailed equipment data sensors for compatible smart plugs, PowerTags, and heating actuators. A new Equipment sensors entry is added to the integration options menu, the feature is disabled by default. ## Changes - Add detailed equipment sensors for compatible devices. - Add an Enable equipment data sensors option. - Show the menu only when compatible equipment data is available. - Check that PowerTag equipment data is not `None` before creating its sensor. - Preserve the existing power, energy, current, and equipment binary sensors regardless of this option. - Add …

Excerpt saved from GitHub on 2026-10-23.

Summary Fixes #641. Passive mode controls were only created for rooms containing smart radiator valves. Rooms heated exclusively through an underfloor heating controller were therefore excluded. This change creates passive mode controls when a room contains either: - One or more smart radiator valves - An underfloor heating controller Rooms without a supported heating device remain excluded. ## Testing Added regression tests covering: - Smart-valve rooms - UFH-only rooms - Rooms without heating devices No aioWiserHeatAPI changes are required.

Excerpt saved from GitHub on 2026-10-23.

… alarm naming issue - issue #496 - Set humidity to Unavailable if no value - issue #503 - Add support for BoilerInterface - issue #499 - Add support for WindowDoorSensor for v2 hub - Add support for CFMT device for v2 hub - issue #507

Excerpt saved from GitHub on 2026-10-23.

… logging this. Looking at it I think this is more a homekit issue. HASS allows 'non standard' HVAC action values (which is what we are using to display passive mode) but Homekit errors if this is the case. Can you log with them and I'll close this issue here. Thanks

Excerpt saved from GitHub on 2026-10-23.

The issues mentionned here concern the aioWiserHeatAPI not really the wiserHomeAssistantPlatform Bug 1, Connection timeout: Hub Gen2 firmware 7.x enforces HTTPS I try the fix proposed by @briceg-1337 , it works fine with a hub gen2 but when I want to add a hub gen1 it's impossible. I get the error Connection timeout trying to communicate with Wiser Hub when i want to add the hub. So I make some other test: - go back to the previous situation > _suppress the line: self._wiser_rest_controller.use_https = True # ← added_ in the aioWiserHeatAPI wiserhub.py - in the file …

Excerpt saved from GitHub on 2026-10-23.

Hi, I have a Schneider Mureva EV Link socket connected to a 2nd Gen Wiser Hub. Currently, it is not detected by the integration because it uses the `EVSE` application instance type. Here is the JSON payload for this device from the `/api/domain/` endpoint: ```json { "id": 6, "DeviceApplicationInstanceType": "EVSE", "DeviceApplicationInstanceId": 12, "UUID": "bc58b0f5-b8a9-46ce-8379-869d31b129e9", "Controllable": true, "CloudManaged": false, "NumberOfPhases": "One", "Configured": "Configured", "InstallationType": "Mono", "OverviewScheduleId": 1, "CanBeScheduled": true, …

Excerpt saved from GitHub on 2026-10-23.

No, we do not support and do not plan to support BLE devices. This integration is purely designed to talk to a Wiser hub. Is it not supported by the Bluetooth integration? I think it's not supported. Wiser's support for fully functioning Non-Hub devices is terrible. In some FAQs they say that the new Wiser app supports BLE devices, but then support says that it does not work with BLE devices. SE is so damn confusing! If anyone wants to help me check if it works with the BT integration, would appreciate it!

Excerpt saved from GitHub on 2026-10-23.