Yes as far as I’m aware
Another area - the utility is working normally
I just can say that you scheduler is at this point not active. The code behind is very simple it just checks if a scheduler is defined and if its on.
So at this time you’ve triggered the automation in order to download the trace log your scheduler is definitely off.
1 Like
Thanks, it appears to be running at the moment. There definitely appeared to be an issue with the sensor as I got a controller unable to transmit message. After several attempts it appears to be working (though had to calibrate the temp sensor with -6*C) to be accurate.
Other than waiting for the appropriate time how are you supposed to tell whether or not a scheduler is active? I can’t see any specific way to turn it on.
Looking at the log it did turn on at the appropriate time this am - see image.
However when I checked it at just after 6:30 it was idle despite not having run. I wonder if it wasn’t receiving appropriate information from the sensor.
I’ll see what happens tomorrow.
Regarding the winter mode I created a toggle helper. If I want to disable a particular zone would I just add that toggle to the winter mode section and that provides overall control beyond the scheduler?
Hi there!
I currently move my stuff from ioBroker to HomeAssistant and i’m searching therefor for a Heating Control. This Blueprint looks like a perfect solution 
My Question:
Is there any known issue in the Version “4.0_beta6” about the “Comfort Heating Plan (optional)” ?
Because it doesn´t set the value to the TVR (Homematic HM-CC-RT-DN) BUT to the helper (input_number).
Maybe i’m doing something or misunderstood that feature ? 
As far as i read here, there is an improvement for this feature on the way.
What have i done ?
I created an input_number helper and set this one as “Comfort temperature (optional)”. Then i defined the heating times in “Comfort Heating Plan (optional)”
Here i can see the correct values that i set in the Comfort Heating Plan - but as i said - the TVR is not updated.
I can change the TVR temperature manually inside HA without any problem.
The minimal temp is set fine to the TVR, but not the Comfort Heating Plan.
Here is a trace → https://controlc.com/30113b04
Thanks for any help!
Hey, thanks for your feedback.
Comfort Heating Plan is not an optimal solution atm. It’s my next goal to make it more robust and feature rich.
Atm you just can manipulate the comfort temperature entity with it but only if the automation runs and the time changes. But I need to refactor some things first.
I would suggest to go with an additional automation which changes minimum and comfort entities.
1 Like
Thanks for all teh work on this Panhans. Trying to figure out if I can make it work for me. I have a pretty old house which doesn’t keep heat well. I do have reliable mmwave presence sensors in each room though to detect presence.
What I’d like to do is have the heating set to say 18 degrees when I’m reliably in the room according to the presence sensor. Set it to 15 degrees when I might be in the room soon, set it to 10 degrees when I’m out or in bed or it’s the middle of the night or out etc.
Any ideas on how to do that? I guess I basically the comfort temp triggered by the presence sensor and want a scheduler for the minimum temperature?
Hey Alex, you could do this with help of the custom action.
1: Setup you automation with your climates, scheduler, persons and presence sensor.
2. Select the same scheduler for the presence sensor as for heating.
3. Setup a custom action like this:
- condition: template
value_template: "{{ set_comfort == true }}"
- variables:
new_comfort_temp: "{{ iif(is_presence_on,18,15) }}"
- condition: template
value_template: "{{ states(input_temperature_comfort) | float != new_comfort_temp | float }}"
- service: input_number.set_value
data:
value: "{{ new_comfort_temp | float }}"
target:
entity_id: input_temperature_comfort
2 Likes
Just a huge thanks for the blueprint! I’m still on V3.7.3 but I’ll be changing over to the V4 beta for one of my rooms today to see how it goes.
Here’s a little tile that I made using a mushroom template tile. It aims to communicate the current status of the radiator in a room.
Something to note for Octopus customers. If you have the Octopus integration up and running, you can use the saving session boolean sensor as a window sensor to automatically turn off the heating during a saving session. I managed to get £40 off my last bill doing this (my house is all electric so £££).
Here are a few images of the card in action - these are all for the same room.
Here is the Github Gist. Feel free to scrutinise my template logic - I think I’ve done alright to keep it relatively small and not so repetitive.
3 Likes
as far as I understood … for testing purposes you can set states in developer tools. Meaning you can overwrite the state of an entitiy / scheduler to see what happens / if your automations work right. So you don´t have to wait for the scheduler to start … just change its state manually
- go to developer tools
- choose States
- search for your entity
- put in wanted state
- set state
Also you can check here for the actual state an entity is at the moment.
Yes - when winter mode ist OFF then heating is disabled - but you would need winter mode toggles for each zone if you want them to be seperated (i believe the frost protection is also disabled then)
2 Likes
Amazing, thanks!
1 Like
They looks great - thank you for sharing!
You can also create an input_boolean helper and toggle this using the custom action. Then you can use this helper entity as reference for your card.
Example for custom action:
- condition: template
value_template: "{{ states('input_boolean.is_heating_enabled') =! iif(is_heating,'on','off') }}"
- service: "input_boolean.turn_{{ iif(is_heating,'on','off') }}"
target:
entity_id: input_boolean.is_heating_enabled
Thanks for that, appreciate the input.
I do want to control each zone individually as we often don’t need to heat a number of rooms in the house - our kids aren’t always with us so their rooms may not get used for a week or more so pointless heating them. Same with our spare room - only used for guests.
Never been cold enough to worry about frost - lowest I’ve ever seen is 10*C in one of the rooms.
I will try adding the toggle to a couple of zones and see how I get on with it.
Still not really understanding the concept of the comfort heating though. Is it aimed at more of an override or something else? If you have a room that you want to heat to 20*C based on a schedule what is the additional benefit of the comfort heating?
Thanks
Hi Panhans,
Just to let you know everything has been heating appropriately for the last 24hrs. I didn’t change anything so no idea what was happening other than issues with the z-wave itself. Appreciate your help.
1 Like
as far as I understood … and how I am using it:
Comfort heating is for when you want to have it cozy, comfortable and warm.
It is activated by schedulers (presence sensors, party mode, etc. ).
If comfort heating is not active then static minimum temperature is set / but heating is still active.
The Comfort Heating Plan allows different Comfort Temps through the day … for example i like to have it a little cooler through the day and warmer late nights. (though i set this manually through an input_number)
[V4 beta]
Starting just now… Thinking about it, I am not sure it will fit my need. Would it make sense to use the proximity sensor to exit the frost protection mode? Another possible way would be to use the distance as a gradient between frost protection and either minimum or comfort. Personally, I disagree with using “on way home” as equivalent to being home.
Comfort Heating is the temperature you want to heat your room too (sometimes called the set temperature), in your case 20*C
[V4 beta]
I also see that the frost protection has precedence over the proximity. In my case, I would potentially (might need more reflection) like to see it as follows:
- home: comfort,
- away for short period or close by: minimum,
- away for long and not close by: frost protection.
There might be an option of introducing a temperature gradient in function of the distance, but I am not sure on how to do it.
@panhans i don´t know if you also want to support other options. For example the Bosch Thermostat II (BTH-RA)? Because this has the ability to set a remote temperature. So there is no need to use the calibration. Bosch BTH-RA control via MQTT | Zigbee2MQTT
So it is similar to the Aqara request some post up
Just a note for Popp/Hive/Danfoss users: if you are on ZHA, it takes some tweaking to enable external temperature support. There is a set of PRs in ZHA and HA core that is being worked on to fix that, but right now you need to use ZHA toolkit (or Z2M of course). See here.
Since the PR’s seem to be in an advanced state and will likely mess up any ZHA toolkit hacked config, I’m currently holding out for them to be merged before I start implementing this blueprint.