Drayton Wiser Home Assistant Integration

I found it has some issues (submitted to github), but yes indeed I found it about 90% there :smiley:.

Andy, replying to your issue here for the benefit of others. The integration does not control whether the valve is open or closed or (technically) whether the boiler is firing or not. The hub controls this and the integration just sends commands to the hub to set the target temperatures (which i think from your graph look correct).

It maybe that the increments on passive mode need to be larger (there is an open issue that the integration is not using the increment value set in config which needs fixing), to reduce over shooting by the hub but as you say in your issue, it does not close the valve if you turn the room off in the Wiser app, ie not using integration.

Maybe others can chime in as to what they see in relation to this.

Link to issue detail

1 Like

See documentation on serivces. This is for experimenting. As others have said opentherm control on the wiser hub is somewhat basic and apparently they are working to improve. This service will send a command to the hub to try and change parameters but as yet it is unclear what can be changed and what effect, if any, it has.

EDIT: Should add (as i seem to have missed from the docs!) download your diagnostics file to see available parameters to use with this service and the parameters described by the service doc.

Also, excellent explanaition just posted by @ikoz as to how to use this.

Has anyone managed to change/set the schedule based on calendar events?

My missus is a nurse and works odd shifts, ideally I’d like to only heat certain rooms at certain times depending on what shift she’s on that day.

Ideally I’d like to create an automation which looks at the calendar for the day, depicts what shift she’s on (if any) and then set the appropriate schedule.

Thanks in advance!

Have a look at the Wiser services (e.g. wiser.assign_schedule and wiser.set_schedule). They can be used in automations, so you should be able to write one that changes the schedule based on any trigger.

Hi. I’m trying to understand if I could use the wiser hub directly with home assistant using this integration and the existing temperature sensors I already have for home assistant (non wiser). In other words can home assistant control the channels on the hub as though they were individual switches. I don’t really care for any other scheduling features. Just straight up switch on and off.

Thanks.

When you say channels do you mean “HotWater”, “Channel-1” and “Channel-3” or rooms?

Independent of any automation the Wiser could be managed manually. You would set a nominal dummy schedule with a very low temp and then increase/decrease the room setpoint. That would then cause the WiserHub to activate the appropriate channel. HA would just need to make the calls based on input from your sensors. If it was a limited period call for heat that could be a boost.

It’s not quite an on/off switch as once the room setpoint is achieved the hub would deactivate the channel. Of course your dumnmy schedule setpoint could be set so low that it never triggers for on, ditto for your “manual” increase setpoint is so high that it never causes off to occur within the Wiser system.

I noticed something with the integration yesterday that I haven’t seen before, and wondered if someone could explain why it was like this, or if it is a bug?

When checking my heating view on my dashboard, I noticed that 3 of my rooms were showing an incorrect setpoint of 13 degrees, when they should have been 16 degrees - as per the schedule for each room. I thought my other half could accidentally have hit advance on one room, but not 3 separate rooms, each with its own schedule. Advancing the schedule would change the setpoint to 13 degrees, as that is the overnight temp in my schedules for those rooms.

I checked the Wiser app, but all 3 rooms were showing the correct setpoint of 16 degrees, as per the schedules, so it definitely wasn’t a case of those 3 rooms being advanced to the overnight schedule temp.

I downloaded the diagnostics from the HA integration, and interestingly, the 3 rooms affected all showed that they were using “SetpointOrigin”: “FromEcoIQ”. The 3 rooms in the Wiser app did show the Eco mode icon, but still showed the scheduled correct setpoint of 16 degrees. Why would the integration be showing 13 degrees? I imagine if I had hit ‘cancel overrides’ on the 3 rooms, it would have cancelled the Eco mode override, and probably displayed the intended 16 degrees setpoint.

I’ve seen Eco mode in the Wiser app being ‘active’ on rooms before, but never seen a non-scheduled setpoint temperature display in HA when Eco mode is active.

Diagnostics from one affected room (iTRV)

{
          "id": 2,
          "OverrideType": "EcoIQ",
          "OverrideSetpoint": 130,
          "ScheduleId": 3,
          "HeatingRate": 1200,
          "SmartValveIds": [
            5
          ],
          "Name": "Office",
          "Mode": "Auto",
          "DemandType": "Modulating",
          "WindowDetectionActive": true,
          "CalculatedTemperature": 160,
          "CurrentSetPoint": 130,
          "PercentageDemand": 0,
          "ControlOutputState": "Off",
          "SetpointOrigin": "FromEcoIQ",
          "DisplayedSetPoint": 160,
          "ScheduledSetPoint": 160,
          "AwayModeSuppressed": false,
          "RoundedAlexaTemperature": 160,
          "EffectiveMode": "Auto",
          "PercentageDemandForItrv": 0,
          "ControlDirection": "Heat",
          "HeatingType": "HydronicRadiator"
        }

I don’t think this is an integration problem as such. As you can see there are 3 setpoint values

“CurrentSetPoint”: 130
“DisplayedSetPoint”: 160
“ScheduledSetPoint”: 160

The true room setpoint is 13.0 C as the Hub has enabled Eco mode which picks up the next scheduled setpoint, in your case the overnight value. However the Wiser app continues to show 16.0 as that’s the active value (or what you set via a manual adjustment) for the time. And lastly 16.0 is what the schedule indicates.

I believe eco cuts in when the hub believes the currently active setpoint will be maintained until the next scheduled change.

My guess integration is just saying the “CurrentSetPoint” is xxx (as changed by ecomode). There is no override to cancel, if there was an active boost/manual change the “SetPointOrigin” would say “FromBoost” or “FromManualOverride”. Generally the setpointorigin would be “FromSchedule”

I guess to add to Ians’ point, the integration uses current setpoint and the app uses displayed setpoint. I guess its a question of which is right. The room setpoint in this instance is 13C caused by ecoIQ. I think on the standard HA thermostat is would show from ecoIQ which would explain it better.

It’s difficult to know which is correct. My reading is, the Wiser App is showing 16.0C as that’s what you asked for. The Hub is making a calculated guess that there is no need for the heating to come on until the end of scheduled window and hence can “behind the covers” drop the setpoint to the lower value that is scheduled for the next window but if it told you that would be confusing. We only know the current setpoint as the integration exposes the value, without that you would be none the wiser!

You won’t see eco being enabled when the next scheduled setpoint is higher.

Thanks @ian1182 and @msp1974 - appreciate the explanation, and I understand what’s going on behind the scenes now. I’ll see if there is any way to display either the OverrideType or the SetpointOrigin value in my simple thermostat cards nicely. It looks like the integration’s diagnostics refer to ‘SetpointOrigin’ whereas the integration’s climate entity attribute is ‘target_temperature_origin’.

If not I might reconsider the standard HA thermostat card instead.

I suppose the question is which setpoint do you wish to see.

For example, if your schedule was
18:00-22:00 20c
22:00-06:00 15c

At 20:30 you manually reduce the setpoint to 18c and at 21:00 the Wiser Hub invokes Eco mode

You now have a “current setpoint” of 15c, “displayed setpoint” of 18c and “scheduled setpoint” of 20c. They are all true in context. IMHO, the best one to show is the “displayed setpoint” as that corresponds to what you see in the Wiser App. It’s also the most “correct” in the sense that’s what the room temperature should be. In the example above, the Wiser Hub is determing that even without the boiler firing the room temp will still be at least 18c at 22:00.

I agree - I think it’s more user-friendly to show the “displayed setpoint” on the dashboard, in the same way as the app does. I’ll have a play around with the simple-thermostat card as I know using v3 you can render climate entity attributes in addition to the 2 defaults, but I’m not sure if I can achieve the desired result. Displaying the Eco icon within the card when in this mode would be good and would help explain the setpoint temp being displayed - should this scenario happen in future.

A little more testing with the Eco Mode side of things. I noticed 3 rooms were again showing the setpoint of the next schedule (overnight lower temp), due to Eco mode kicking in. I created a native HA thermostat card and as Mark rightly pointed out, it does indicate that Eco Mode is applying - under the setpoint temperature, instead of ‘Idle’ it shows ‘Idle - EcoIQ’.

Out of curiosity I pressed the ‘Cancel overrides’ button on my custom simple thermostat card, and this seemed to cancel Eco mode for that room, as the setpoint went back to the current schedule setpoint, and upon checking the Wiser app, the Eco mode icon next to that room had disappeared.

I then opened a different room in the Wiser app, which showed the Eco mode as being active, and in the Boost menu, selected the ‘off’ button, and again, this canceled Eco mode for that room and the icon disappeared.

So, the Eco mode, when being applied, seems to be treated as an override that can be cancelled on a per room basis.

I have also reviewed how Eco is working in practice. I have a room schedule of 08:00 21C and then 09:30 20C. Yesterday I noticed EcoIQ activating at 09:05, switched off at 09:15 prior to the scheduled drop at 09:30. In my case the room temp had dropped a fraction and the heating came back on for a few minutes to maintain the temperature at the scheduled value.

I see the “CurrentSetPoint” value when in eco mode as a bit artificial, it’s not the real value the hub is checking against. The “displayedsetpoint” is a more accurate view of what the Hub is using to determine when the boiler should come on.

I was not aware that Eco was a cancellable override but even so the Hub will self cancel if required.

@LGO44 @IanQ I thought this might be of interest to at least a few people on here, as we had discussions about making immersion heaters smart further up the thread last September.

Short of waiting on the Wiser relay that is supposed to be coming this year, I’ve recently stumbled on the ClickSmart+ Smart Fused Connection Unit (a Zigbee fused switched spur) that I’m considering purchasing from here (seems to be a well rated online store and close to the lowest price I could find when the postage is added on) to swap out the dumb fused switched spur that currently controls my immersion heater.

Wondering if anyone has any experience with these, before I press the purchase button? :slight_smile:

Hmm, I’ve just noticed these are single, rather than double-pole. Tech specs here. Now wondering whether these are suitable for an immersion heater.

It’s not ideal for the application…

That unit is ‘only’ rated at 13A. While most Immersion Heaters probably don’t exceed that, they do operate for hours on end.

I don’t think it’s normal for Immersion Heater switches to have fuses in them either (because the fuse tends to get very hot when subjected to such conditions) - they are normally on a dedicated circuit, so protection is at the consumer unit end.

1 Like

It’s a 13A double-pole fused switched spur my immersion heater is connected to currently. It was the same at our old house (we only moved in here last year). It is on it’s own circuit (16A MCB) in the consumer unit, which has an RCD protecting the circuit.

The house is only 5 years old, so the wiring is pretty current, assuming the sparks did their job correctly. :laughing: I had an EICR carried out after we moved in and nothing was picked up as being awry.

The only thing making me think twice is that it’s single-pole, rather than double. Other than that, it’s a like-for-like swap-out. I guess it might be a question I need to put to my electrician.