Hi,
thanks for sharing your blueprint / heating management. Why are switching the system only on/off and not use incease/decrease heating demand?
I rather don’t need an on/off for start the heater but an increase of the temp. “thermostat_hc1_selected_room_temperature”.
My idea is to have an heating demand like described on page 10-11 here: https://github.com/tp1de/ioBroker.ems-esp/blob/5fade71fbb3aecc9f8d2d24c33040112aa4cfb9b/doc/ems-esp-es.pdf
The described program is running for the last 2 years quite smoothly - unfortunatelly on io-broker - and if possible shoud be moved to HA.
Turning on/off the central heating system instead of selecting a T° is a choice based on … my heating system … It only accept on or off so I don’t have (and don’t need) something else.
Feel free to adapt to your heating system, or better, propose a PR on my scripts to take into account a manageable central heating system.
You might like to compare it with Heating X2: Schedule Thermostats with Calendars, which includes the facility to turn off heating if a door or window is open, or if the room is left unoccupied for a while.
Heating X2 features:
Schedule by calendar: set the temperature of each room with a local calendar and as many heating events as you like
Multiple thermostats: One or more thermostats per room: multiple thermostats are synchronised together. Works with smart TRVs, any smart thermostat, or Generic Thermostat
Manual override: a change on the thermostat, dashboard or by voice assistant remains in effect for a defined period (default 2 hours)
Door or window open: heating turns off heating in the room if any door or window is left open for a defined period (default 3 minutes) – optional list of zero or more closure sensors.
Occupancy: heating turns off heating if a room is left unoccupied for a defined period (default 1 hour) – optional list of zero or more motion or human presence sensors.
Warmup period: occupancy is ignored for a defined period at the start of a calendar event (default 2 hours)
Away mode: set all rooms to a temperature specified per room (default 5C) when there is no one at home
Background temperature: used when there is no calendar event (default 5C but specified separately from the frost and away temperatures)
Zone control: can switch one or multiple heating zone valves, or a boiler that needs a heat demand switch, based on heat demand from a group of thermostats
Notifications: if thermostats do not respond to a new setting, go offline, or come back online
Robust: Graceful degradation when a thermostat or a sensor is offline
Battery-efficient: conserves TRV battery life by only transmitting real changes
Code generator: uses mail merge (!) to automatically generate YAML code for helpers, timers, template sensors, groups, automations, and dashboard cards from a single EXEL spreadsheet that lists zones, rooms and thermostats
Thanks for your link and for your remarks (and ads description of your bluerints ).
My blueprints already includes openings, taking care of outside vs inside openings, and shutoff one room or the entire heating system depending on the room “link”.
Occupancy is already managed, but only with a manual boolean.
Yrs, I was comparing because we had many of the same ideas.
What do you mean by ‘manual boolean’ for occupancy? If you use detectors, they are also boolean, so you should be able to connect them?
Having said that, I have found it difficult in practice to get reliable presence detection — I tried several motion and human presence devices. Has anyone else succeeded?
Yrs, I was comparing because we had many of the same ideas.
What do you mean by ‘manual boolean’ for occupancy?
I use a human actionable indicator, a HA input_boolean. Not related to any sensor. My usage is to leave a room out of management when nobody use it. Mainly for bedrooms, that are only maintained at Eco T°.
I try to set up this thing, but its not so straight forward. So i may give you an outsider point of view. Maybe you could change text / adapt naming to actual names for users to better understand what to do?
There are a lot of helpers and blueprints needed and i think more consistent naming would be helpful.
F.e.
so i need to look at github files to find out heater_switch_mode.yaml is a blueprint and its named Room heating mode switching.
Maybe remove the first quoted part if we simply can use the blueprint buttons?
I have imported all the Blueprints, but there is no “Heater system management global script” in my blueprint list. So i need to look at the git file - ok, i have to look for “Heating system should start”.
I would propose to
use always the same naming
use always the same sequence 1. 2. 3. …
maybe remove unneeded Texts in first post or link to an install text
put heating and lighting on different pages in git.
add some explanation in the blueprints for selecting entities (like in this BP i currently use: 🔥 Advanced Heating Control)
add which blueprints are needed and which ones are optional (room link?)
I think my setting is similar to yours and i hope i can optimize my heating, so i really want to try it - i am able to find out which is which:-)
Heating system should start
(switch heating on if needed)
Request heater switch - which one of the new helper should i use? A global one? all of the single rooms? - ok, i can add more then one so all “Request heater switches” from my rooms? is this correct?
Heater switch - my boiler switch
Room link status - i think same as Request heater switch
I think its not very attractive to users if they have to use a lot of helpers and blueprints and are not sure what to do.
Heater request compute
My EQ3 TRVs have an offset i can set, but no internal thermometer.
Heater setpoint compute
can i switch between several heating plans?
Heater room link management
*In-/outside aperture?? opening? Not used now, i set room link dropdown to none
Heater Winter mode management
yaml called start stop, title Heating system operationnal or not
Request evaluate automation - name it Request compute like above?
Ok, now i deactivate it to not switch of my boiler, i have to the add the other rooms first - tomorrow.
Hi @vajdum , thank you for your feedback Always interesting to have this kind of feedback
First of all, don’t hesitate to place a PR (or more) or an issue on github, for proposed changes !
I try to set up this thing, but its not so straight forward.
Agree
i think more consistent naming would be helpful.
You mean replace heater_switch_mode.yaml by Room heating mode switching for example ?
Heater system management global script is not a blueprint name, but the description of the blueprint importable by the button below this title. But you’re right, it’s not clear .
About your proposals:
use always the same naming
I agree ! Please post an issue about this point.
use always the same sequence 1. 2. 3.
I don’t get it, could you be more explicit ?
maybe remove unneeded Texts in first post or link to an install text
I will use github README.md as first post text, easier for me, so please propose PR on the README file and I will check.
put heating and lighting on different pages in git
For now, I use this repo this way because it’s automatically installed/refreshed on my HA install (using GH integration on HA) with automatic reload. But yes I can split it into multiple repo. Please could you open an issue ?
add some explanation in the blueprints for selecting entities
I don’t really understand. You mean description: entry in input: selections ?
add which blueprints are needed and which ones are optional (room link?)
For me, all are needed ! Room links are essential to shut off one valve or the entire system.
Ok, I’ll reply to other remarks/question in another post, it’s a bit late here and I’ll go to bed right now
you have a list of needed yaml in what to do + a list of Blueprint imports:
You need to instantiate heater_switch_mode.yaml, heater_setpoint_compute.yaml, heater_room_link.yaml and heater_request_compute.yaml for each
room you want to activate automation.
Blueprints:
Heater system management global script, Heater request compute, Heater setpoint compute, Heater switch mode, Heater room link management
yes, like this:
regarding optional, i have only one window sensor and no door sensors at all. So i created the helper, set it to none and i think i can go without room link blueprint.
Heater boot management - what is needed for “Switching manual/auto/setpoint automation”???
During boot process, I don’t know why, but some MQTT messages are received, as if the valve was manually updated (T°, auto mode, …), so I deactivate the “Switching” automation for some minuts, as explained in my original post:
This blueprint is in charge to lock switch automation during the HA boot process. I noticed that climate valves are sending some messages, and trigger the switch automation, resulting on a wrong setup of the room.
Yes, because this automation is in charge to take care of manual actions done on the TRV. If you change the setpoint T° on a valve, it switch to manual. If you set the TRV to automatic (mine is a TuYa TV02-Zigbee control via MQTT | Zigbee2MQTT able to send when you press the knob), then the automatic mode is selected on HA.
Process is not (yet) described in the blueprint README
Manual T° (RW) : Boolean indicating that Setpoint is manually determined. Set when climate valve is manually modified
So i change the TRV temp. to heat a room outside of the schedule?
It get not set back automatically?
What happens if temperature is reached, but TRV is still heating?
I think i created the helper for room link (explained in the link above) and set it to none (nothing opened).
I only tried it and decided to stay with the other blueprint i was using for the rooms. https://community.home-assistant.io/t/advanced-heating-control
I added an automation to switch the boiler off based on added valve openings from all TRVs and room temperatures reached in important rooms.
… It only accept on or off so I don’t have (and don’t need) something else.
).
.
