Works OK from developer tools. Never thought to check it there - to be fair didn’t know it was there, new to this HA game.
No, this is not the expected behaviour, not as I designed it anyway and I think @msp1974 pretty much followed the model I created. When it reaches the upper limit, it should stop heating, just as it would do without Passive Mode on. Personally I have not noticed this happening on my system. Maybe there’s something else causing this.
I have noticed that Wiser sometimes heats or lets heat flow in for longer than you would expect regardless of Passive Mode or not. I simply put this down to the Wiser alogrithms anticipating that it would need to fire the heating again soon if it switches off at that point and trying to prevent that by heating a bit longer. Is this maybe what you’re seeing?
1 Like
I’ve just had a very quick look at the logic I came up with for Passive Mode. Basically it was as follows:
If active TRVs have heating demand (i.e. heat in the system regardless of whether the boiler is firing at that moment), check the passive TRV hasn’t hit the upper limit already and the current temperature is at least 0.4 degrees below the limit temperature, then change the setpoint to current temperature plus 0.5 degrees. Check every 15 minutes.
For troubleshooting, or just for extra information, the displayed_setpoint attribute will reflect what the thermostat is actually set to (this is hidden from us as part of the passive mode emulation). You can template these out for each room.
# Hallway Setpoint
- name: Hallway Setpoint
device_class: temperature
state_class: measurement
unit_of_measurement: °C
icon: mdi:home-thermometer-outline
state: "{{ state_attr('climate.hallway_climate', 'displayed_setpoint') }}"
do you have any of the modes enabled (Eco / Comfort) ?, those will effect how it performs.
I’ve managed to replicate what you’re seeing and I think it’s just down to Wiser choosing to heat still, the same as it would if it were not in Passive Mode i.e. the algorithms are just deciding it shouldn’t switch off yet, probably as it’s determined it will need to switch back on too soon if it does. I can’t see anything wrong with the setpoint going above the upper limit, so I think that Passive Mode is behaving as expected. Probably still worth checking the setpoint on your system is not exceeding the upper limit though, just to be sure.
Yes, I have comfort on. I can see the effect that has on my zones that physically heat (i.e not in Passive mode) and all it appears to do is just make the heating come on early so it gets to setpoint at the scheduled time.
This does have an effect on passive as it heats up at the same time which is to be expected.
What I wasn’t expecting was it to heat above the passive target high setpoint but it looks like its expected behaviour if its within 0.5 degrees of target high.
Just checking the displayed_setpoint and percentage_demand attributes now as the system is fired back up.
It will take a bit of time to get to temperature.
I’ll get back to you later
Thanks
Edit –
So I think I’ll buy that.
My displayed_setpoint is the upper limit 18.5
My percentage_demand is now 0 my current temperature is 19.1
AND passive is not heating now even though the other zones are heating!!
So it looks like your 0.5 degree offset theory is correct.
It passively heats until it reaches above the target high setpoint plus 0.5 degrees then stops.
1 Like
@Hillman10 & @msp1974
Thanks for the advice, I will get the integration installed soon 
However it is a moot point currently, since last night my carbon monoxide detector went off and the gas man has disabled my boiler until they can return with a new part tomorrow and (hopefully) get it working again 
As a serious PSA can I remind everyone to ensure they have a working CO Detector, I’m glad I did or I may not have been here tonight to write this post.
2 Likes
I’m running version 3.3.9 of the integration on version 2023.12.3 of HA, so I need to upgrade the integration to 3.4.1 to get rid of the communiction errors.
This might be a dumb question, but how do you update the Drayton integration? I can see installation instructions but no update instructions.
Or am I missing the obvious?
Go into HACs and you will see the update available. Select update and then restart HA.
1 Like
Ah. Maybe I’ve a different problem then. Thanks for the reply, but I’m not seeing any Update shown within HACS.
I therefore tried deleting and re-installing the Drayton integration and I get the same version of the integration back - 3.3.9. I also still have the communications error too, when I (say) flip a Smart plug on or off.
Failed to call service switch/turn_on. Response error trying to communicate with Wiser Hub 192.168.xxx.yyy for url http://192.168.xxx.yyy:80/data/v2/domain/SmartPlug/40. Error is 400, message="Data after `Connection: close`:\n\n b'0'\n ^", url=URL('http://192.168.xxx.yyy:80/data/v2/domain/SmartPlug/40')
My HA runs as a Virtualbox VM on a Linux host.
From the Wiser integration diagnostic JSON file:
"home_assistant": {
"installation_type": "Home Assistant OS",
"version": "2023.12.3",
"dev": false,
"hassio": true,
"virtualenv": false,
"python_version": "3.11.6",
"docker": true,
"arch": "x86_64",
"timezone": "Europe/London",
"os_name": "Linux",
"os_version": "6.1.63-haos",
"supervisor": "2023.12.0",
"host_os": "Home Assistant OS 11.2",
"docker_version": "24.0.7",
"chassis": "vm",
"run_as_root": true
}
and
"custom_components": {
"wiser": {
"version": "3.3.9",
"requirements": [
"aioWiserHeatAPI==1.3.5"
]
}
Is your HACS version up to date? You def need version 3.4.1 if on HA2023.12.x.
If you google HACs no showing updates, some people have had to reinstall it and this fixed.
As no doubt most of us will be busy tomorrow and a bit tipsy on the Strongbow!, i thought i would just take the chance now to thank all those who have interacted and contributed this year on this thread. It so great to see a group of people who share an obsession with heating 
, interact and help each other out so well. It is very much what makes Angelo and me want to put our time in to this integration.
So, have a wonderful (and warm!) Christmas whatever you are doing and look forward to some more chat in 2024.
11 Likes
Thanks for all your efforts and help.
And in the immortal words of Noddy Holder…
Merry Christmas Everybody.
2 Likes
I just upgraded my HA docker from 2023.10 to 2023.11.3. All seems fine other than following upgrade, heating/hot water on today both jumped by ~5hrs.
AIUI, those are LTS stats, but I also send them to influx, which was similarly impacted.
I kept the Wiser integration version as previous container.
"custom_components": {
"wiser": {
"version": "3.3.9",
"requirements": [
"aioWiserHeatAPI==1.3.8"
]
}
},
What might cause this to happen and what precautions might I take to avoid it? I have upgraded my HA container several times but not seen this before.
Presume these are template sensors. What is their config?
On my dashboard I have an entity card that includes
type: entities
entities:
- entity: sensor.wiser_heating
- entity: sensor.heating_on_today
- entity: sensor.wiser_heating_operation_mode
- entity: button.wiser_boost_all_heating
- entity: button.wiser_cancel_all_heating_overrides
- entity: switch.wiser_away_mode
title: Heating
show_header_toggle: false
state_color: false
That graph above is presented when I click on that dashboard entity. I see the same if I explicitly select that entity in history.
EDIT: Sorry, they are template sensors! This is their config:
- platform: history_stats
name: Heating on Today
entity_id: sensor.wiser_heating
state: 'On'
type: time
start: "{{ now().replace(hour=0, minute=0, second=0) }}"
end: "{{ now() }}"
- platform: history_stats
name: Hot Water on Today
entity_id: sensor.wiser_hot_water
state: 'On'
type: time
start: "{{ now().replace(hour=0, minute=0, second=0) }}"
end: "{{ now() }}"
I haven’t even had a drink yet today!
Not really sure why that would happen as it is derived from an on/off sensor. Only thing is whether there is an entry in history with the wrong timezone.
I seem to remember having this issue after an upgrade (potentially the same upgrade as you). Not sure why it happened but it didn’t happen again to me with 2023.12.