I’ve taken a punt on the Eurotronic Spiritz TRV’s having read these forums regarding how to provide the development branch of open-zwave config, and because they are by far the best price for UK. £36 from reichelt.
I’m consistently seeing the TRV’s report temperature below the set-point (by as much as .4 degrees Celsius) and so my configuration will interpret that as a request for heat, yet the internal logic of the TRV seems to be to close the valve. Which isn’t a great combo for economy! as the boiler is working away, and no heat is coming through.
I’ve configured the TRV to report temperature changes at .1 degree Celsius, having already considered that this would be the issue. but the problem remains.
The way I’ve configured these units, which perhaps is relevant:
Virtual Room Thermostat
temp <- TRV current temp
switch -> input_boolean
Sensor (template) - heat
all virtual room thermostats = heat
HEAT or
IDLE
Automation - Call for heat
trigger <- heat.heat
action -> boiler switch on
Automation - heat satisfied
trigger <- heat.idle
action -> boiler switch off
Automation - forward set-point changes
trigger <- virtual thermostat set-point is changed
action -> TRV set-point is mirrored
I’m ignoring the heat_eco and boost/furnace thermostats. and i’m driving the heat/comfort thermostat in heat/comfort mode.
it’s a much more complicated setup than I had imagined before buying these. however the TRV’s do not have an IDLE state.
as i’m writing this, (always to good to talk it through) I have perhaps another idea, which would simplify the setup and might solve it to. There is an option for the TRV’s to report how open/closed the valve is, i could drive the call for heat from the valve being opened/closed.
Any other thoughts, please let me know. Anyone else using these noticed similar?
I’m also thinking of using the Spirit TVR and am trying to work out how difficult it is going to be to use with Home Assistant as I have no experience with any of the hardware or software but I do have a background in programming so should be capable of learning! Are you using https://hass-apps.readthedocs.io/en/latest/apps/schedy/index.html or are you writing your own controller? I have found a thread here about using the dev build of Open Z wave in order to support the Spirit TRV - do you have any other pointers for a UK TRV system with Z wave TRVs on every rad?
I’m still working through all this,
and note that I arrived at this solution because I wanted a thermostat interface like the Generic_thermostat that provides current temp, set-point temp, heat, idle and away mode.
The software thermostat that you get for the TRV behaves differently in that it stays in heat mode regardless of whether the valve is opened (calling for heat) or closed (satisfied). I have not manged to acquire any valve status.
Like I described above, a concern I have is that with two mechanisms for determining if there is a call for heat is for the potential for the boiler to be working against the TRV’s.
But if it helps, here is what I have so far:
# Create a input_boolean because the generic thermostat requires a device to switch.
input_boolean:
heat_lounge:
icon: mdi:fire
# Create a temperature sensor, not needed if you only plan to have one temp sensor.
sensor:
- platform: template
sensors:
avg_temp_lounge:
friendly_name: "Lounge Average Temperature"
unit_of_measurement: '°C'
value_template: "{{ ((float(states.sensor.multisensor_temperature_lounge.state) + float(states.sensor.trv_temperature_lounge.state)) / 2) | round(1) }}"
# Abstract from Generic Thermostat the temperature set-point and use it as a sensor - so that we can catch the event when this value is changed (by user).
- platform: template
sensors:
target_temp_lounge:
friendly_name: "Lounge Target Temperature"
unit_of_measurement: '°C'
value_template: "{{ states.climate.lounge.attributes.temperature }}"
device_class: temperature
# Create a overall sensor that defines 'Call for heat' or 'Satisfied', if any Thermostat is in heat mode then CH otherwise S.
- platform: template
sensors:
heat:
friendly_name: "Call for heat"
value_template: >-
{% if is_state('climate.bedroom', 'heat') or is_state('climate.guest', 'heat') or is_state('climate.lounge', 'heat') or is_state('climate.dining', 'heat') or is_state('climate.hallway', 'heat') or is_state('climate.loft', 'heat') %}
heat
{% else %}
idle
{% endif %}
# plug a generic thermostat. This is the public thermostat if you like, the one that is accessible to Google assistant, and the Home-Assistant frontend.
- platform: generic_thermostat
name: Lounge
heater: input_boolean.heat_lounge
target_sensor: sensor.avg_temp_lounge
min_temp: 10
target_temp: 19
cold_tolerance: 0.5
hot_tolerance: 0.5
away_temp: 14
initial_operation_mode: "auto"
# Rest of the logic is done in automations
# Turn away mode on
- alias: 'Heating: Away Mode On'
trigger:
- platform: state
entity_id: group.all_devices
from: 'home'
to: 'not_home'
action:
- service: climate.set_away_mode
data:
entity_id:
- climate.bedroom
- climate.guest
- climate.lounge
- climate.dining
- climate.hallway
- climate.loft
away_mode: 'on'
# Turn away mode off
- alias: 'Heating: Away Mode Off'
trigger:
- platform: state
entity_id: group.all_devices
from: 'not_home'
to: 'home'
action:
- service: climate.set_away_mode
data:
entity_id:
- climate.bedroom
- climate.guest
- climate.lounge
- climate.dining
- climate.hallway
- climate.loft
away_mode: 'off'
# Warm the house up on a work day morning
- alias: 'Heating: Workday Morning'
trigger:
platform: time
at: '05:00:00'
condition:
- condition: state
entity_id: binary_sensor.workday_sensor
state: 'on'
action:
service: climate.set_temperature
data:
entity_id:
- climate.bedroom
- climate.guest
- climate.lounge
- climate.dining
- climate.hallway
- climate.loft
temperature: 19
# Warm the house up on a home day morning
- alias: 'Heating: Homeday Morning'
trigger:
platform: time
at: '07:00:00'
condition:
- condition: state
entity_id: binary_sensor.workday_sensor
state: 'off'
action:
service: climate.set_temperature
data:
entity_id:
- climate.bedroom
- climate.guest
- climate.lounge
- climate.dining
- climate.hallway
- climate.loft
temperature: 19
# Keep the house from being too cold at night
- alias: 'Heating: Night time'
trigger:
platform: time
at: '22:00:00'
action:
service: climate.set_temperature
data:
entity_id:
- climate.bedroom
- climate.guest
- climate.lounge
- climate.dining
- climate.hallway
- climate.loft
temperature: 16
# Turn the boiler on if our sensor goes into heat mode
- alias: 'Heating: Call for Heat'
trigger:
platform: state
entity_id:
- sensor.heat
to: 'heat'
action:
- service: homeassistant.turn_on
data:
entity_id: switch.heating
# Turn the boiler off if our sensor goes into idle mode (this means all thermostats are satisfied)
- alias: 'Heating: Satisfied'
trigger:
platform: state
entity_id:
- sensor.heat
to: 'idle'
action:
service: homeassistant.turn_off
entity_id: switch.heating
# The next two automations work due to the way I name my devices. I'm extracting the room from the entity id of the device that triggered the automation, and plugging that name to complete the entity id of the device to be actioned.
# This event fires IF the generic thermostat's set point temp changes. IF this happens, I want the TRV to also receive the new temperature set point adjustment.
# it mirrors/links the two thermostats.
- alias: 'Heating: Thermostat Temp Change'
hide_entity: false
trigger:
platform: state
entity_id:
- sensor.target_temp_lounge
- sensor.target_temp_bedroom
- sensor.target_temp_guest
- sensor.target_temp_hallway
action:
- service: climate.set_temperature
data_template:
entity_id: >
{% set room = trigger.entity_id.replace('.','_').split('_')[-1] %}
climate.trv_heat_{{ room }}
temperature: '{{ trigger.to_state.state }}'
# This event mirrors the state change.
# The TRV's do not have an IDLE state, they only have heat(comfort), eco, boost, or off. The generic thermostats only have heat,idle,off. This automation transitions the TRV's from OFF and HEAT, meaning if we turn off the Generic Thermostat, then the TRV is turned off too.
- alias: 'Heating: Thermostat State Change'
hide_entity: true
trigger:
platform: state
entity_id:
- climate.lounge
- climate.bedroom
- climate.guest
- climate.hallway
action:
- service: climate.set_operation_mode
data_template:
entity_id: >
{% set room = trigger.entity_id.replace('.','_').split('_')[-1] %}
climate.trv_heat_{{ room }}
operation_mode: '{{ trigger.to_state.state }}'
Schedy - not yet, but i think this would only cover changing the temperature set-points based on a more complicated daily schedule. Say for example if you want Mondays to be warmer than Tuesdays, but only between certain hours etc and on alternating weeks. (a little exaggeration, but i’m looking into it too)
My system is simple, if anyone is home and its not night time = 19.
if anyone is home and it is night time = 16
if everyone is away = 14.
Regarding the ‘Dev’ branch of open-zwave. Yes, I read and followed the same posts. you need the latest configuration files that are only in this development branch. for Hassio, it’s as simple as putting them in /usr/share/hassio/share/open-zwave (<- git clone -b Dev …git) and
zwave:
usb_path: /dev/ttyACM0
network_key: !secret zwave_secure
config_path: /share/open-zwave/config # <- this line
No other pointers per se, but they are zwave-plus and so if you haven’t already, and if its appropriate I would follow the guides for enabling secured-nodes, and add those nodes using home-assistant webinterface via the secure node button.
Thanks for the replies. My first TRV has arrived very quickly from Reichelt so that I can check out which of my valves the Spirit head will fit on, with adaptors, I had not appreciated that I can’t install the Spirit TRV in standalone mode without having a Z Wave controller to join it to so I’m going to have to find a lot of time to get to grips with that!
if you haven’t got a z-wave controller yet, then you have a fair few decisions to make! if you have a linux system, you could simply buy a USB z-wave stick and use that to prove out your options. That will save you from buying anything else.
I use the aeotec gen5 stick, I think it’s a popular choice, though there are cheaper options.
in the mean time, I think i’ve come to the conclusion that I need to run the TRV’s in manufacturer specific mode, which gives full control over the valve opening/closing, instead of that being determined by the TRV’s internal logic. However, it would appear that there is yet more support required in open-zwave, and i’m not sure if simply updating the config’s will be enough. looks like this won’t be the fastest solution, unless using the internal trv logic works for you.
I’ve have just taken delivery of a Pi 3 B+ and a Aeotec Gen 5 - so it looks like I made a good choice! Unfortunately my software business clients are more interested in me helping them than in my home automation project so progress at home is slow. I understand your problem and can see that I will have the same issue as I want to control each room in isolation - which is the whole point of the project. We have other heat sources (solar gain on the south side, wood burners etc) which make it impossible to manage the house from a single thermostat.
I wonder if it is possible to to detect the point at which all the TRVs shut down and the bypass valve opens and use that to trigger turning off the pump as it would seem to be desirable to let the TRV’s internal controller manage the local set point. That won’t help with turning the pump back on but I suppose one could estimate the likely time before the pump is needed again and then see if the bypass opens again when the pump starts and then fire the boiler if needed. I need to look at the bypass valve and see if it can trigger an external microswitch or I may have to monitor the pressure in the bypass pipe to get an idea of how much flow is still going to the radiators - https://community.smartthings.com/t/z-wave-integrated-pressure-sensor-idea-for-swimming-pool-filter/16330
I will also have to give some thought to how all of this will fail safe.
I’ve also got the Spiritz and trying to persuade HA to drive it; HA seems quite confused about which of the values it’s worth showing by default; it also seems to show the temperature in icons next to each of the three modes (eco/normal/furnace?) that seems just the wrong way to do it. As for valve status; I’ve seen that in the OpenZWave web interface but not seen it in HA yet. From what I can tell it’s a separate ‘CommandClass’ - for a ‘Multilevel switch’.
The other problem I have is that HA seems to give everything the big long names; while I can rename the device to ‘Daves Bedroom TRV’ that doesn’t rename all of the other measurements which is a pain.