Completely agree, a small lower cost temperature sensor is a gap in the offer at the moment. Be great if this could be suitable for bathrooms as well, ie appropriately designed for damp spaces. I’d be keen to have something like that. I never interact with the screen on the existing room thermostat, it’s not needed with the app and HA.
2 Likes
@Scoff @msp1974 I’ve been looking for any discrepencies and it appears that there can be a 30 second delay (due to the integrations default scan interval; it could be more or it could be less if you’ve changed that), where the sensor.wiser_hub_heating and the is_heating attribute for rooms can be ‘out of sync’. I’d say this is perfectly normal and probably to be expected due both the scan interval and latency of the Zigbee nodes updating the hub.
@Scoff is this maybe what you’re observing?
@RolandLT @johnBoy @swifty @Angelo_Santagata and for anyone else that has been looking to use the iTRVs in ‘passive mode’ i.e. not call for heat and only come on when other radiators are heating, basically behaving like a normal non-smart TRV. I have come up with an automation to emulate this behavior as closely as possible.
It’s not perfect and the ‘Passive TRVs’ do still call for heat while they’re on, but will only come on if one or more of the ‘Active TRVs’ are calling for heat. Anyway, it does what I need it to do for a few rarely used rooms and I suspect will be good enough for people looking to emulate this behaviour. It’s been asked what the benefit of having a ‘passive mode’ for an iTRV over a non-smart TRV is, as that is what it is emulating. Well, for me at least, I still have automated control over it for other things so I can make changes without needing to be physically present to adjust the TRVs manually.
To set this up you’ll need to copy (and modify to suit your use case) both the automation and the template sensors. Only binary_sensor.active_trvs_heating_demand is essential, but I do recommend you create both the binary_sensor.passive_trvs_heating_demand and the binary_sensor.wiser_hub_status as well. The ‘Passive TRVs’ is useful to pop onto a dashboard along with the ‘Active TRVs’ to keep an eye on things and that the automation is behaving itself, while the ‘Wiser Hub Status’ is being used in all my Wiser automations to make sure that requests are delivered to the hub in case it’s offline. If you don’t create the ‘Wiser Hub Status’ template entity, you’ll need to remove both conditional references to it where it is being used with wait_for_tigger from the automation (they are enclosed by if-then statements).
So, firstly the template entities:
- binary_sensor:
# Wiser Hub Status binary sensor
- name: Wiser Hub Status
device_class: problem
icon: >-
{%- if is_state('binary_sensor.wiser_hub_status', 'on') -%}
mdi:router-wireless-off
{%- else -%}
mdi:router-wireless
{%- endif -%}
state: >-
{%- if is_state_attr('sensor.wiser_hub_heating_operation_mode', 'last_update_status', 'Success') -%}
off
{%- else -%}
on
{%- endif -%}
# Active TRVs Heating Demand binary sensor
- name: Active TRVs Heating Demand
icon: >-
{%- if is_state('binary_sensor.active_trvs_heating_demand', 'on') -%}
mdi:radiator
{%- else -%}
mdi:radiator-disabled
{%- endif -%}
state: >-
{%- if is_state('sensor.hallway_climate_heating_demand', '0')
and is_state('sensor.living_room_climate_heating_demand', '0')
and is_state('sensor.kitchen_climate_heating_demand', '0')
and is_state('sensor.bedroom_climate_heating_demand', '0')
and is_state('sensor.office_climate_heating_demand', '0') -%}
off
{%- else -%}
on
{%- endif -%}
# Passive TRVs Heating Demand binary sensor
- name: Passive TRVs Heating Demand
icon: >-
{%- if is_state('binary_sensor.passive_trvs_heating_demand', 'on') -%}
mdi:radiator
{%- else -%}
mdi:radiator-disabled
{%- endif -%}
state: >-
{%- if is_state('sensor.spare_room_climate_heating_demand', '0')
and is_state('sensor.garage_climate_heating_demand', '0') -%}
off
{%- else -%}
on
{%- endif -%}
And, secondly the automation:
# Wiser passive TRV emulation 1.4
- id: C70E4094-B538-43C3-9CCD-59F908475DBE
alias: "Wiser: Passive TRV emulation"
mode: restart
trigger:
# Active TRVs Heating Demand turns On
- platform: state
entity_id: binary_sensor.active_trvs_heating_demand
from: 'off'
to: 'on'
id: active_trvs_on
# Active TRVs Heating Demand turns Off
- platform: state
entity_id: binary_sensor.active_trvs_heating_demand
from: 'on'
to: 'off'
id: active_trvs_off
action:
- choose:
- conditions:
# Active TRVs Heating Demand turns On
- condition: trigger
id: active_trvs_on
sequence:
- repeat:
while:
# Check Active TRVs Heating Demand is On
- condition: state
entity_id: binary_sensor.active_trvs_heating_demand
state: 'on'
sequence:
- if:
# Check Wiser Hub is not offline
- condition: state
entity_id: binary_sensor.wiser_hub_status
state: 'on'
then:
# Wait for Wiser Hub to come back online
- wait_for_trigger:
- platform: state
entity_id: binary_sensor.wiser_hub_status
to: 'off'
- if:
# Check Away Mode is Off
- condition: state
entity_id: switch.wiser_hub_away_mode
state: 'off'
then:
# Spare Room
# Set thermostat to Heat; easier to identify it's in passive heating mode and stops it being reset by Cancel Heating Overrides
- service: climate.set_hvac_mode
target:
entity_id: climate.spare_room_climate
data:
hvac_mode: heat
- if:
# Check Spare Room target temperature hasn't hit the limit temperature already
# AND Spare Room current temperature is at least 0.4°C below limit temperature; to prevent increase beyond limit temperature
- condition: template
value_template: >-
{{ (state_attr('climate.spare_room_climate', 'temperature') | float) < (states('input_number.passive_trv_limit_temperature') | float)
and (state_attr('climate.spare_room_climate', 'current_temperature') | float) < (states('input_number.passive_trv_limit_temperature') | float - 0.4) }}
then:
# Set Spare Room target temperature to current temperature plus 0.5°C; to prevent high demand
- service: climate.set_temperature
target:
entity_id: climate.spare_room_climate
data:
temperature: "{{ state_attr('climate.spare_room_climate', 'current_temperature') | float + 0.5 }}"
else:
# Set Spare Room target temperature to limit temperature; in case limit temperature has been lowered or current temperature is less than 0.4°C below limit temperature
- service: climate.set_temperature
target:
entity_id: climate.spare_room_climate
data:
temperature: "{{ states('input_number.passive_trv_limit_temperature') | float }}"
# Garage
# Set thermostat to Heat; easier to identify it's in passive heating mode and stops it being reset by Cancel Heating Overrides
- service: climate.set_hvac_mode
target:
entity_id: climate.garage_climate
data:
hvac_mode: heat
- if:
# Check Garage target temperature hasn't hit the limit temperature already
# AND Garage current temperature is at least 0.4°C below limit temperature; to prevent increase beyond limit temperature
- condition: template
value_template: >-
{{ (state_attr('climate.garage_climate', 'temperature') | float) < (states('input_number.passive_trv_limit_temperature_garage') | float)
and (state_attr('climate.garage_climate', 'current_temperature') | float) < (states('input_number.passive_trv_limit_temperature_garage') | float - 0.4) }}
then:
# Set Garage target temperature to current temperature plus 0.5°C; to prevent high demand
- service: climate.set_temperature
target:
entity_id: climate.garage_climate
data:
temperature: "{{ state_attr('climate.garage_climate', 'current_temperature') | float + 0.5 }}"
else:
# Set Garage target temperature to limit temperature; in case limit temperature has been lowered or current temperature is less than 0.4°C below limit temperature
- service: climate.set_temperature
target:
entity_id: climate.garage_climate
data:
temperature: "{{ states('input_number.passive_trv_limit_temperature_garage') | float }}"
# Update target temperature every 15 minutes
- delay: 00:15:00
- conditions:
# Active TRVs Heating Demand turns Off
- condition: trigger
id: active_trvs_off
sequence:
- if:
# Check Wiser Hub is not offline
- condition: state
entity_id: binary_sensor.wiser_hub_status
state: 'on'
then:
# Wait for Wiser Hub to come back online
- wait_for_trigger:
- platform: state
entity_id: binary_sensor.wiser_hub_status
to: 'off'
# Reset to thermostats to Auto
- service: climate.set_hvac_mode
target:
entity_id:
- climate.spare_room_climate
- climate.garage_climate
data:
hvac_mode: auto
Hopefully this is useful to a few people and easy to understand, especially as I’ve commented everything.
Just swap in your own sensors and limit temperature variables etc and change the delay in the while loop that sets how often it checks and updates the target temperatures while maintaining a low heating demand to something suitable for your heating system. I imagine 15 minutes is probably OK for most people, but if you’ve got a really high flow temperature set on your boiler and your rooms heat up really quickly, you may want to reduce this, or vice-versa.
Note, you can probably create the ‘Active TRVs’ and ‘Passive TRVs’ as Groups instead. I just prefer using template sensors, as you can set dynamic icons for them (which I don’t think you can do with Groups, at least not within the UI anyway).
EDIT: I’ve updated the automation to use template conditions, as I discovered that the numeric_state conditions I was using at the outset and had tested with do not work with variables, even when trying to convert to a float. I’ve also updated it to work with two input_number helpers, created as below. For the second one, use the same settings, but append Garage (or whatever you want to call it) to the name:
This means you can change either input_number as you wish, either via the dashboard, or another automation using the input_number.set_value service to set it on a schedule to suits your needs. Consquently, the variables referenced elsewhere have also been removed, as they are no longer needed and would have prevented changes to the limit temperatures while the automation is running.
EDIT: I’ve updated the automation again to include some else statements to take into account that now input_numbers are being used, there are some additional considerations like if the limit temperature is lowered while the automation is running and if it’s less than 0.4 degrees below the limit temperature when it’s triggered. All tested and seems to be working properly for me. If anyone else uses this and finds any oddities (bugs), please let me know.
EDIT: Another update to the automation to take into account whether Away Mode is on (I don’t want this bumping the unheated rooms up when Away Mode sets everything to 10 degrees) and to set the hvac_mode to heat in order to prevent it being reset if you use the Cancel All Heating Overrides button, plus make it easier to identify that it’s in ‘passive heating mode’. This is optional and can be removed if you don’t care about whether it can be reset by the Cancel All Heating Overrides button and don’t like the change of colour of the thermostat dial to orange. I’ve also added a version number to the comment at the top for easy identification of whether any further updates have been added since this update. It’s currently at version 1.4. 
5 Likes
@robertwigley That’s pretty much what has been crossing my mind since asking the question! I did have the refresh interval set at 60 seconds originally, but recently brought it down to 30 seconds in order to reduce the discrepancy. States of entities and attributes could well be out of sync due to this, along with the Roomstat latency, so I expect it is exactly as you say.
I’m not sure if reducing the 30 second interval for the integration would start to put too much load on the hub - was that ever concluded to be a contributing factor to the hub and hub wifi drop outs?
I don’t think there was ever anything conclusive about whether reducing the scan interval affected WiFi drop-outs (and the following long re-connection times) and I think most of us have probably given up any further investigation on this, pending the imminent firmware update that is supposed to help address the problem, at least by making it reconnect much faster if/when it does drop-out.
Personally, I hadn’t really noticed (I may have, but it never really consciously registered) the discrepancy until I started looking for it after you pointed this out. The default of 30 seconds is fine for my use case and, just in case there is a correlation, I’d probably avoid dropping it lower (if you feel you need to) at least until the new firmware is released (very soon hopefully).
@robertwigley On the note of iTRV accuracy - I have SNZB-02 in living room, bedroom and spare room and use automation from github recipes which tracks schedule and and boost room if temperature is bellow required. As you can see iTRV accuracy is very poor in solid wall house without insulation
Without this automation performance was abysmal - I had to keep adjusting schedule differently for each room every time weather changes.
As I’m using spare room as my home office and it is East facing I’m just using regular TRV there - after finishing work set it to 1, before going to sleep - fully open, for weekend - 2 (will need to try out your automation for this). Chart shows iTRV and SNZB-02 sitting side by side on my desk. My initial idea was to use 3 spare iTRVs as temp sensors for above automation, but it can seen from chart that there is some algorithm preventing from reading accurate temperature while it is rising quickly.
The bit I’m still not happy is how heating is behaving during night - so many short heating cycles. If anything, during the night it is not important to keep very steady room temperature.
@robertwigley I’ve read through automation and would like to confirm I’ve understood it correctly.
Passive iTRVs are set to something low like 10C in schedule. So if room does fall below 10C passive iTRV would actually demand heat.
As soon as hub demands heat it triggers 15min cycle of slowly increasing temperature, so not to trigger high demand and, I assume, preserve battery.
I’ll see if I can iterate on idea and pick var_limit_temperature from schedule as per previous post I want to have 3 different set points on different days and times for passive iTRV
What I am calling ‘Passive TRVs’ are iTRVs that do not call for heat if below the target temperature, so they mimic non-smart TRVs. They will only be on when one or more ‘Active TRVs’ are calling for heat. In my case I have some ‘unheated rooms’ that I have set to a target temperature of 12 degrees, which is as low as I want the temperature to drop in those rooms. However, if one of my ‘Active TRVs’ is calling for heat, then this automation will bring any of the ‘Passive TRVs’ on at 0.5 degrees above the current temperature in that room until they hit the limit temperature (which is as high as I want them to be) set in the automation, or until the ‘Active TRVs’ stop calling for heat. It may never reach the limit temperature and that’s the point here. It’s just to put some extra heat into those rooms if the heating is already on for the rooms that are calling for heat.
You could most definitely do something with e.g. an input_select (Dropdown) or input_number (Number) helper and set the tempertaure limit variable(s) var_limit_temperature and var_limit_temperature_garage to one of those, so that you can dynamically adjust them on a dashboard or schedule of your choosing. That would be really easy to do and is actually not a bad idea for an improvement. This really is just a 1.0 version. You can obviously also rename those variables to e.g. max_temperature if that makes more sense to you and create more if needed. I like to always proceed a variable with var_ as I find it makes the code easier to read. I do all my automations in Visual Studio code in YAML and don’t use the UI.
The 15 minute slowly increasing by 0.5 degrees loop is to keep heating demand (and thus any extra energy use) to a minimum, as I don’t want heating demand jumping to 100% and firing my boiler solidly, which it would if one of the unheated room was at 12 degees and we put it up to 16 or 14 degrees straight away. That would completely defeat the purpose of this, which is to syphon some of the excess heat energy that is already in the system for the rooms that are actively calling for heat, just like a normal non-smart TRV would do.
I hope that makes sense. I’ll probably update this to include target temperature input_number (Number) helpers shortly.
2 Likes
@RolandLT I’ve updated the automation to work with an input_number (Number) helper and correct a problem with the conditions I had introduced since I tested it. Consequently, the variables referenced elsewhere have also been removed, as they are no longer needed and would have prevented changes to the limit temperatures while the automation is running. This will allow you to change them on a schedule via another automation using the input_number.set_value service if you want.
Ok, I’m utterly baffled. Set this up a few weeks back, included a few automations (if window open put on “low” schedule, if i’m away but he’s not put on a mid schedule), and every single automation that includes “call service” for the Wise intergration is empty, all the Wiser actions have been removed.
Any idea what would wipe all the Wiser steps? (all the other if’s and condition checks remain). Up todate on HA and all integrations.
Have you any errors in the logs that it has not loaded properly?
Does anyone know if there’s a way to put a temperature limit on a thermostat/room natively in Wiser, without resorting to an automation in Home Assistant to drop the target temperature if it exceeds a set value? I can’t see one, but thought I would ask, before I write an automation. Thanks.
Wow, the Heat Hub dropping off the wifi is really annoying - fingers crossed the magical new firmware fixes everything.
If you mean like a ‘non bill payer limit’ then no that doesn’t exist. You can use the wiser_event with type target_temperature_increased in an automation to do this though.
Looks like when the drayton integration doesn’t load, all the services already in automations magically disappear. Changed the ip address and they’re back.
Thanks. I mean as in if someone sets the target temperature to 23 degrees, then drop it to 22 degrees i.e. prevent turn up beyone 22 degrees in this case. I actually already wrote an automation, which seems to do what I want, as I just can’t see anywhere that you can do this natively in Wiser.
# Wiser thermostat temperature limiter
- id: E33DF30D-E646-4B6D-815F-3A80BBAB8B30
alias: "Wiser: Thermostat temperature limiter"
mode: parallel
trigger:
# Thermostat target temperature changes to above 22°C
- platform: numeric_state
entity_id:
- climate.hallway_climate
- climate.living_room_climate
- climate.kitchen_climate
- climate.bedroom_climate
- climate.office_climate
- climate.spare_room_climate
- climate.garage_climate
attribute: temperature
above: 22
action:
# Set target temperature to 22°C
- service: climate.set_temperature
target:
entity_id: "{{ trigger.entity_id }}"
data:
temperature: '22'
Not sure how I would use target_temperature_increased to set a limit, as listening to the event in Developer Tools only indicates that it’s increased and not to what temperature, unless I am missing something? Would there be any benefit to using this over what I have already?
It would just simplify by not having to list your entities as this is provided in the event payload. If youre on 3.2.3beta2 i think it should provide temp in data but if not just use entity id in payload to query. If you look at documentation for events shows how to do this.
1 Like
Can someone help me debug this issue, it’s 4th time Wiser integration stops working and can only be fixed by restarting HA?
Looks like this happened around 8:30 today, but I’ve only just notices. Hub had definitely had his light green for the last couple hours, but can’t tell if it gone red around 8:30.
This is especially annoying because HA carry on using last values set by Wiser integration, so statistics thinks my heating was solidly on for the last 3 hours 
I have a question that unrelated to the integration but as everyone here has Wiser TRVs it’s a good way of getting a good response.
I’ve moved house recently and I’m having problems with TRVs since. The problem that despite buying a house on the same development, this house had Danfoss controls and TRVs rather than Drayton at previous house but no worries, the other adaptor in the box is for these valves.
The issue I’m finding is the calibration. They fully open on twisting left, fit fine and appear to calibrate the closed position fine after twisting right. However, on the Drayton valves if the temp dropped below setpoint you’d hear a short buzz of the head opening then after a short delay the boiler would fire, but in the Danfoss valves the buzz appears to be much shorter and the valve doesn’t actually appear to open on some rads. You can confirm that by twisting the TRV 1/4 turn off of the adaptor and you hear the water starting to flow and rads get hot.
Out of 16 rads I’ve got 7 or 8 like this. I’ve measured the total travel on Wiser head and its about 7mm from fully open to fully closed and the valve only has approx 3mm of travel so it should be OK. Using the Danfoss standard head before fitting the Wiser head seemed to allow it to open and close fine and that had 3-4mm travel.
Is this something other using Danfoss valves have found, and can I ‘fix it’? I’m planning on changing the valves to Drayton as we redecorate each room and sort/replaced radiators but that’s going to be in the summer when we don’t need the heating.
Pete
Hmm, not getting any complaints about this happening.
2 things to look at to start:
- Are you using IP address or dns name to connect? Check in integration config. If using dns, change to IP. Could be a dns issue.
- To see if the hub is going offline, create a ping sensor like below:
binary_sensor:
- platform: ping
host: [your hub ip]
name: "WiserHub"
count: 3
scan_interval: 15
As you know, lots of us have hub drop offs but the integration recovers fine when it comes back online. This does possibly point to a networking issue affecting HA.