Hi, I am considering using HA and the Drayton Wiser integration. Is there support for a feature that allows the minimum and maximum temperature to be specified for a schedule or boosted period. Eg, I have a use case where people want the heating on between 11am and 9pm say and we want the temperature to max at 19 degrees C then shut off until it hits 18 degrees then comes back on until 19 degrees has been hit again. The minimum and maximum would be configurable. Second question, is there a flat override which can be set to ensure all heating for a zone is off after a certain time, eg 9pm. This is to prevent people accidently leaving heating on overnight. Many thanks
Unless I misunderstand your requirement, HA & Wiser integration might be overkill.
You could do this āout of the boxā with the Wiser App.
Set a schedule for the zone for 19 degrees from 11am until 9pm and the rest of the time say 5 degrees. So 19 degrees from 11am and then off after 9pm.
Then use the App to lock all devices (Thermostats and/or TRVās) within that zone so they cannot be manually overridden.
Of course you can do this with the integration in HA as well but why complicate it?
Hi, thanks for the reply. What you have suggested is not what I want. That locks the temperature at 19 degrees and constantly maintains 19 degrees. I want the temperature to hit 19 degrees then drop to a configured point (in my example 18 degrees but could be say 17 degrees) before switching back on and rising back up to 19 degrees. So the temperature will cycle from 19 down to 18 or say 17 then back to 19. The reason for this is to minimise the heating being on whilst still maintaining a level of comfort. Regarding switching off at 9pm your suggestion only works based on a fixed schedule. I want to be able to put in a hard stop of 9pm regardless of the fixed schedule. Sometimes people manually turn the heating on if its extra cold, but in this instance if they forget to turn it off, I want the override to kick in which switches it of at 9pm regardless. Thanks
Unless you want to fluctuate the heat in between two very different temperatures then setting it to 18 or 19Ā° is likely to achieve what you want, or pretty close - in my experience the temperature fluctuates Ā±1Ā° anyway with any thermostat system. You could probably achieve exactly what you describe using HA automations and this integration, but if itās just a small difference in temp it may not be worth the effort.
To stop people from adjusting the temp settings you can disable the controls on iTRVs and Roomstats using the device lock setting. If you wanted people to be able to adjust temperature according to a schedule (e.g. turn up the temp between 5-9pm only) you could create an automation using this integration that turned the device lock on and cancelled any boosts outside these times. Note that the boost buttons on the hub canāt be disabled, so if people have access to the hub they would still be able to override, but automations in HA will reduce the impact of this.
One thing to note is that the iTRVs tend to read a couple of degrees warmer due to proximity to the radiator. For rooms where these are the only thermostats, you may want to set the temperature a couple of degrees higher to achieve comfort levels for the occupants that canāt make the change themselves. Hopefully a future update from Schneider will improve this.
1 Like
Taking each of your requirements.
1. Temperature range
No Wiser and this integration cannot do this. You set a temp either manually or via a schedule and it heats the room to that temp. I agree with @dunxd that in reality it will drop to 18.5 before firing the boiler again but if you want a wider range then (as standard), no this cannot be done.
However, we have various functions that would allow you to build automations to achieve something close to this. There are events that can trigger automations when heating starts/stops/is boosted etc that you could use to detect when room set temp is reached, turn set temp down x degress and when starts heating again, turn it back up x degress etc.
We also have (currently in beta) a new function for making a room passive. Ie it will only heat if other rooms are calling for heat. This has a range of min/max so it will also call for heat itself if it gets too cold.
Maybe one of these methods will get you to what you are looking for.
2. Switching heating off at 9pm.
If you are running on schedules, then Wiser sees any manual change to this as an override. As @dunxd said, you can have an automation run at 9pm to cancel all overrides and have schedules that set the target temp to 10C after 9pm.
Using the same events as above, you can then also detect if someone boosts the heating after 9pm and cancel this with an automation.
We are always happy to have new suggestions for functionality and this community is great at helping with specific use cases of how to achieve it. We are obviously limited, in the main, by the core Wiser functionality but the events and HA automations combined can often have a solution to such a problem.
3 Likes
For my own understanding but taking your points in reverse order:
Switching off at 9pm
My experience is that SCHEDULE is King, it trumps overrides.
But I did misunderstand the brief: I thought manual overrides were forbidden. In the response to my post, that is now clear they are to be allowed.
Am I mistaken but If an override has been set above the setpoint then the next scheduled setpoint overrides this. Are Boosts not handled the same?
So a schedule that sets a setpoint at 10 degrees at 9pm and then at 9:30 and then at 10:00 etc.etcā¦ would reset any manual override.
Temperature range.
In my experience modulating the temperature of a zone by 1 or 2 degrees uses more energy than maintaining a fixed setpoint. Especially since I configured my Boiler to be Opentherm with Wiser. (My temperature flatlines (usually within 0.2 degrees C of the setpoint after external heat sources are nullified, i.e after sunset. And that 0.2 degrees is always on the plus side)).
So I donāt understand why modulating the temperature by 2 degrees would save more energy than allowing the Wiser Hub with itās inbuilt intelligent algorithms, to control that ?
See example graph below.
This is the stock history graph from HA, the vertical orange lines are the wiser system calling for heat. You can see raising the temperature by 0.5 degrees around 3:30pm calls for more heat than maintaining the setpoint after it is reached.
A boost takes precedent over the schedule. I did a trial of scheduling a temperature change at 10:10, then did a 30 minute boost via the app at 10:02. Only when the boost expired at 10:32 did the scheduled setpoint come in effect. The opposite is true for a manual temperature change, in this case the next scheduled event wins.
Another consideration is you can only have a maximum of 6 setpoint changes per day per room. Hence to meet the requirement needs automation to trap the modification and enforce the limit
What is the rational behind wanting the heating to follow an army approach (left, right, left, right) rather than maintaining a steady temperature. Older mechanical thermostats had a largish variance due to their hysteresis but thatās not true today with electronic stats. As others have indicated there is some variance in temp anyway with the Wiser system, my system fluctuates up to 0.4c either side of the setpoint. Going forward heating systems are moving to running cooler but for a much longer time as heat pumps come into play rather than an occasional blast of heat.
Thanks for the clarification with regard to manual overrides and boosts.
I hadnāt considered the max schedule setpoint changes either- doh!
I note a boost has a max of 3hrs so eventually the schedule wins 
With regard to your direct question to @AN2099, I can concur that my Opentherm boiler runs a lot cooler for longer. Once the setpoint is reached, the outflow temperature is around 45C and modulates constantly, with the boiler only using gas to boost the flow temperature occasionally to maintain the setpoint. The pump is using more energy!
Therefore, in my experience, it would use more energy to boost the temperature from 18 to 19C as in the brief, than to maintain the 19C setpoint once it is reached.
Of course there are all the external factors to consider, like thermal insulation and solar heating etc.
For example there is no need to heat my conservatory if the sun is out even in the winter.
BTW Just to clarify, I think the Wiser integration is great, I use it constantly and it was the main reason for me to adopt HA in the first place. My first post is #20 in this blog so to my surprise thatās over 3 years ago.
Wiser Home app v6.1.6 has been released. It says its for bug fixes but the bug I am aware of with the heat type setting is still there.
The subtle difference is that a boost runs until completion whilst a manual override is immediately cancelled by a schedule event. In either case to achive the requestors objective automation is required to see the modification and either cancel the boost and/or adjust the desired temperature as appropriate. It can also trap the override button on the hub being pressed Thatās not something that can be achived by the native Wiser system.
That said, itās impossible to prevent entirely, if you have physical access to the hub pressing the setup button takes it off the wifi network and automation cannot intervene.
since a few days I have two hubs at home the first one is a first generation and the second is a second generation.
first generation:
product_type: Controller
model_identifier: WT704R1A30S4
firmware: 3.10.8
second generation:
product_type: Controller
model_identifier: WT704R1B30S4
firmware: 4.12.23
I look at both wiser status, I have some wifi issue on the first one and nothing on the second one.
I am discovering the features proposed by the second generation: more devices, automationsā¦
@msp1974 Iām not sure if this has been asked before, but does the Wiser API expose the outside temperature (Weather Forecast from the Wiser App) and is there any way to modify/write to it e.g. with the data from a temperature sensor thatās located outside.
1 Like
immediately cancelled by a scheduled event, if the setpoint is for a different temperature to the previous event in the schedule.
According to support this is working as designed but i found it surprising and confusing behaviour.
Thatās a bit of a surprise but having just tested it that is indeed true. The new scheduled setpoint needs to differ from its predecessor for the manual override to be cancelled.
And my use of immediately was perhaps poor, what I really meant was the next scheduled event which with this clarification means setpoint change.
Question on the home assistant graph for a wiser climate device: If the temperature is under the setpoint, the graph shows the heating periods in orange. If the demand is under 100% then these heating periods are not continious, they have intervals and a variable width each (e.g. 6 periods per hour - which is the cycle-per-hour rate).
If I switch the boiler type to "oilā instead of gas, then the relay is going to operate on the bases of CPH_3 (3 cycles per hour of 20 minutes each). Indeed, the graph for the relay on/off status shows 3 periods of various durations according to demand.
However even when the boiler is setup as at 3 CPH, the devices themselves (TRVs and Thermostats) continue to show 6 periods per hour with their orange bars.
Are the orange bars created by the integration or are they read from the hub?
Not AFAIK. I cannot see this temp in the hub data and think the hub must get by querying the cloud. Therefore, no i dont think possible to change the source or set it via integration.
The graph produces the orange bars from whether the climate entity is in a state of heating or not. This is derived from the hub for both the hub overall heat demand and the individual room heat demand parameters.
Hm itās really strange though. The hub when set up at 3 cycles per hour (oil boiler) is going to start and stop heating at most 3 times per hour and this is reflected in the relay sensor graph (and by actually listening to when the boiler gets powered on or off).
Not quite sure how to interpret the intermittent orange shading bars on a thermostat.
The thermostat will call for heat whenever the current temp is lower than setpoint, for the whole duration of time that happens (albeit with a varying demand percentage).
What does āis in a state of heatingā mean exactly ? The relay/boiler heating state is different to those intervals presented by the thermostat or a TRV. Say I know the boiler is fired from 19.00 to 19.14 continuously. However the orange bar for a thermostat in a room without wiser TRVs shows 19.00 to 19.05 and then 19.10-19.15. What does this mean? Heating didnāt stop 19.05-19.10.
Similarly if this was a wiser TRV, the TRV valve didnāt close 19.05-19.15.
Iām not sure mapping the percentage to intervals makes sense for accessories - especially to intervals that donāt correspond to the actual relay intervals.
The same applies to TRVs - the TRVs dont close and open in accordance to the orange bars - the valves stay open for the whole time the temperature is under the setpoint and demand is higher than 0%, but close progressively as demand for the room gets lower. The orange bars appear to have no significance in reality other than to try to represent the demand percentage in the UI.
I am working on a custom component that would like to advance the schedule on a Wiser-controlled room. I can make this happen either by calling room.async_set_preset_mode or using the climate set_preset_mode service from Jupyter, but these seem to have no effect when called from the _handle_coordinator_update method for the corresponding entity in my integration. (It is being called because my entity is updated as expected.) Iām guessing that there is something I donāt understand about callbacks and the event loop. Can anyone advise on how I should be doing this?