You can adjust the minimum temperature directly in the blueprint options or by an additional input number helper. At night the valve only set to off if you enable the option off instead of minimum temperature otherwise the target temperature will set to minimum temperature.
I will think about your idea of lower the temp when airing. Thank you for your suggestions.
Yes, here was someone who requested the off instead minimum option.
This blueprint is very generic and works with climate entities. This is just an abstraction layer of home assistant. The technology behind this layer is totally independent of this blueprint.
V4 blueprint user here. Question (and apologies if it sounds noob ). My setup is a bit “Frankenstein’ish” and it’d take a while to explain, but in short: My battery powered z-wave thermostats communicate with the z-wave recievers that in turn control the zone heating valves. So, it is only the thermostat setpoint that turns them (valves) on or off. I integrate both, thermostat and reciever into HA via MQTT and modes are “off” and “heat”, following the state of the valve, current temperature/temperature setpoint are following the battery operated thermostat. With the V4 blueprint, my experience is the following: if Presence Detection kicks in and comfort setpoint is set to 18 degrees, but the actual room temp is 21, the plugin would still send “heat” command and trigger the valve. It will heat the room indefinitely - will stop only if I’ll physically adjust the termostat dial (setpoint) above the room temp (causing it to send “on” command to reciever) and then change it back to lower temp, causing it to send an “off command”. Is that the intended behaviour, that the blueprint always commands “heat”, ignoring the comfort setpoint?
OK, I switched to the latest V3 and I guess there must be something wrong with my setup. The temperature in my office, reported by the thermostat is 22.2 degrees.
1 out of 2 person specified in “Persons (optional)” is home
Scheduler (optional) is set and currently “off”
Static Comfort Temperature is set to 20
Minimal Temperature is set to 18
Comfort temperature (optional) is set to 18
If I change the “Comfort temperature (optional)” to any value even still below the actual room temperature (like 20) - it still turns on the heating, ignoring the fact that Comfort temp (20) is way lower than actual (22.2).
Below is the link to trace. Any help appreciated, but I guess my MQTT setup is probably causing it…
Mode heat means your thermostat will hold the target temperature.
If your room temperature is above your confort temperature your thermostat will close the valve also if mode is set to heat.
Mode heat doesn’t mean it that the valve is open. It does not represent the position of your valve.
If you will set the mode to off when target temperature is reached your batteries will drain in a short time.
Thanks - my issue is, that my “real” thermostat does not have ANY modes. You send it a setpoint value and it will decide how to control the reciever that controls the valve. It wakes up every 4-5 minutes to recieve such setpoint command. I “mis-used” the state from the reciever to represent the current status of the system (heat or off) on homeassistant, but I guess this is not compatible with this concept that you describe - as I’m essentially combining 2 standolone devices into one and it confuses HA.
And this is how it’s integrated into HA. Those two colors represent two separate devices. When “heat” command (value 255) is issued, it essentially gets sent to the Reciever (mains powered) that is just an on/off switch, if you like and operates a hydraulic zone valve (a mains powerred valve, not the TRV). And the thermostat itself (battery powered) is unaware about it.
Could you create a template switch with help of your commands in home assistant.
On → 255
Off → 0
With help of an external temperature sensor you can create a generic thermostat.
It aims on target temperature und toggles off the switch if target temperature is reached. And this climate aka generic thermostat can be set in this blueprint.
I don’t know if your integration operates like this. But this should work if I understand your case correctly.
I’m using “mqtt: climate” integration, but you’re right, perhaps I need to break it down and use the generic thermostat - was just starting looking at it and now your message gives me some hope that I’m looking into right direction :).
Thanks for that - this won’t work, again because the “mode” in this case is still present and controlling the valve directly. I looked at the generic thermostat and created standalone MQTT entities to plug into the configuration, but discoverred that I’ll need now some script/automation to link the setpoint from the climate entity and the physical thermostat, otherwise I’ll loose the ability to reflect the setpoint change on the thermostat dial and HA dashboard…What I ended up doing for now, is setting “mode_command_topic” to something that my valve controller is NOT subscribed. For now it looks like it’s working with your blueprint and the Thermostat card changes color when heating is actually on. I know I’m confusing the hell out of you, appologies! Thank you for trying to help!
- name: Office
modes:
- "off"
- "heat"
min_temp: 15
max_temp: 25
mode_command_topic: "homeassistant/set/office/actuator/modeX" # this topic is NOT valid on purpose
mode_command_template: >
{% if value == "heat" %}
255
{% else %}
0
{% endif %}
mode_state_topic: "homeassistant/status/office/actuator/mode"
mode_state_template: >
{% if value == "255" %}
heat
{% else %}
off
{% endif %}
temperature_command_topic: "homeassistant/set/office/therm/setpoint"
temperature_state_topic: "homeassistant/status/office/therm/setpoint"
current_temperature_topic: "homeassistant/status/office/therm/temperature"
precision: 0.1
Hey & thank you very much for this powerful blueprint which gets me a huge benefit. But i have a little “problem” in several rooms. I use Aqara E1 Thermostats via ZHA and an external Sensor. The calibration delta in the blueprint is set to 0,2 and calibration timeout is set to 1 min by a target temperature of 19 °C. Does anyone may have an idea to get the temperature in the room a bit more stable? The stable graph on 19,2 °C was before installing the smart trv. best regards, Ziegelsandundspucke
Looks to me like the reaction temperatures of your thermostat. What I’ve read the aqara e1 reacts if there is a temperature difference of around 1°C between target and actual temperature.
The aggressive mode could solve this but I have to add some selectors for adjusting the difference and target temps first.
Oh wow, thanks for your quick answer! But i do not think that aqara just react by a difference of 1°C because i hear that it reacts very often around the target temperature. Btw, i use v3, is aggressive mode only available in new beta? best regards
One more thing what i have seen, may it helps to investigate further in. The highs and the downs are about 0,5 °C and always in a time distance about 1 hour. Also in another room with the same configuration.
hey, sorry but i am at the beginning with home-assistant. Could you explain what you mean with generic calibration? I use an external sensor for target temperature. So i am not sure if its related to the blueprint but i was thinking about that i can make some adjustments with some settings in the blueprint to get a better result.
OK, I think if figured it out - added a helper timer and specified it under “party” entity in the blueprint. But it still does nothing - not kicking in when changing the setpoint on the thermostat:
if static comfort is set to 20 and minimum at 18,
schedule set to “off”
I’ll adjust the thermostat physically to 21 with conditions as per above, the automation reverts it back to 18 instantly and timer is still idle.
One of my climate entities is acting up on my a bit. I’ve seen this pattern a couple of times recently. For some reason, one of the zones (a. H. Suite) of my heating system seems to live a life of its own, despite the fact that I only have one single automation which has all the different climate thermostats in scope (so, all climate entities should react the same way):
Is there anyway I can extend the traces buffer? I’ve seen I can always download the last 5 runs, but I would need to find the 4:30:03/4:30:07pm mark trace along with the 7:01 pm trace in order to investigate what happened.
My gut feeling tells me that maybe the Airzone central system API may struggle to process all the individual commands that the automation may trigger. Could you kindly implement a way to add some spacing between the climate entities so that not all of them are invoked simultaneously, if this is now the case?
). My setup is a bit “Frankenstein’ish” and it’d take a while to explain, but in short: My battery powered z-wave thermostats communicate with the z-wave recievers that in turn control the zone heating valves. So, it is only the thermostat setpoint that turns them (valves) on or off. I integrate both, thermostat and reciever into HA via MQTT and modes are “off” and “heat”, following the state of the valve, current temperature/temperature setpoint are following the battery operated thermostat. With the V4 blueprint, my experience is the following: if Presence Detection kicks in and comfort setpoint is set to 18 degrees, but the 
