I think it needs a second slider for the activation time when presence is detected. Most presence sensors do not have continuous detection. So it makes sense to set the switch-off to 10 min with no detection and the switch-on when presence has been detected for 1 minute.
Thank you for the feedback. Doesn’t have that issue with my test instance and a generic thermostat. Maybe you’re right and its integration or hardware related so it only works with a small waiting time.
Even with 1 min enabled, it does not heat up, please see my last log.
Yes, thanks for the log. I think it has to do with your presence sensor. I had a look at your log:
You can see presence detected just a few seconds. The comfort temperature will be set after a minute. This is never the case with your presence sensor.
How did you setup your presence sensor? With help of a template sensor you can debounce this timings otherwise it can be fixed with my approach with a second time for activation. In your case, however, the activation must only take a few seconds and not minutes.
@panhans Nice Blueprint, but one question, why we need extra input_number helper for this? Is it not possible to integrate it directly? - sorry for thsi noob question ^^
I am using Ikea tradfri motion sensors (IKEA E1525/E1745) with zigbee2mqtt and occupancy timeout of 180 seconds. I don’t know what else I could change.
Seems the occupancy time has no impact.
The sensor is reset just after 15 seconds.
I will add a second timeout slider for activation in seconds. If the timeout doesn’t work there must be an issue related to z2m. Maybe you should open an issue at the github repo.
I want to set the temperature using the ui. Some people want to set the different comfort temperatures over the day set by another automation. Thats only possible with an separate input number entity.
It’s possible to set it in the blueprint settings if requested. Then it will be overwritten if a input number is defined.
ah okay i understand, nice feature
Is it possible to make this optional? i’m a noob and like it easy with no extra helpers and fix values (only a question, when not i make helpers ^^)
Curerntly im using this Blueprint ECO Heating Ultimate.yaml · GitHub
Ok, I think I have to refactor the code a little bit and rewrite some features with a little bit more log information. With every new feature it became a bit more messy. Give me some more time until I sort those things.
On a recent trip away from home I realised that rather than keep the house at the minimum temperature setting it made sense to let the house be able to cool down further and just prevent the system from freezing.
I don’t think I can use the Winter Mode boolean for this as it doesn’t protect the system from freezing temperatures?
So is this a use case for an additional ‘Anti freeze’ boolean added? Or alternatively, to allow the min temperature to be set by an input number so it can be easily adjusted when away from home (or changed via an automation)?
Sorry if this issue has been raised before, I’ve been happily using your excellent blueprint and haven’t kept track with the thread!
(I’m on blueprint v2.9.1)
My home builder advised to not set the thermostat above 75F (24C) in summer or below 65F (18C) in winter. In practice, when away I let the house go to 77F when cooling or 68F when heating.
As far as i know there isn’t a seperate frost protection mode. Most TRVs come with that feature build in. Even if they are off the frost protection is working. If TRVs don’t come with frost protection I would never turn them off in winter. As @odwide said, it’s recommended to stay at minimum 18°C, but it depends on the age of the building, insolation, humidity… I think it’s almost impossible today to get frost in the rooms except you leave windows open. The main reason to stay at least at 18°C is to prevent mold.
@panhans I have discovered an issue with the Tado temperature calibration. For some reason the calibration triggers an opening of the valve for 1-2 seconds. So the valve opens and closes periodically and this drains the battery. It is also quite annoying.
I am not sure what causes this. Is it possible that you are somehow telling the thermostat to also recalibrate itself for the valve?
The calibration is only called every 10 minutes and new values get only set if the new calibration value differs from the old ones.
My TRVs had that issue yesterday, too. But in my opinion it hast nothing todo with the automation. Did you updated to the new version of home assistant?
Two of my TRVs act like this yesterday but just for that time window.
Will see if this appears again.
Just see when the automation got called the last 3 times and have a look into your logbook especially your Tado. Then compare the times.
Did you integrate them using the Tado Bridge?
Alright, then it doesn’t sound like it is the root of the problem, although it did no occur anymore after I removed the recalibration from the automation.
I’ve been experiencing this issues for weeks now and not only yesterday. I already asked the support about this. No answer so far. I also have to say that I don’t like the whole closed-off cloud-based setup and am thinking of switching to Bosch or something else which uses Zigbee. I really like the compact design of the Tados, but the lack of control is frustrating. Whatever we send to the API, we never know what is actually happening under the hood.
I am using the latest HA version, yes.
Btw, I just put back the calibration and it happened again. When I look at the automations window, I can see that it has been triggered seconds ago. I think there is a link somehow. The trace also did end up at the calculated offset
Alright, when was the second last call? You can step back with the arrows next to the time stamp.
What happens if you take out the external sensor out of the automation and set the -3.5 offset manually. Also try full rounded values like -3.
ADVANCED HEATING CONTROL 3.0 BETA
logger:
default: warning
logs:
blueprints.panhans.heatingcontrol: debug
What changed?
- Guest Mode can be a timer
- multiple windows / doors possible
- calibration only triggers when external sensor gets updated - not time based anymore
- comfort temperature can be set in automation or provided by input_number
- party mode overrides all other settings
- simplified and more functional presence detection
- completely new logic for presence sensors
- presence detection only is possible now
//EDIT: Link deleted, since final version is out.
Happy testing!
I tried v3_beta2 (as a new user, just started with heating control today:)).
Getting errors in the log that brought me here: GitHub source code where is_heating_if_presence_only
is evaluated but had never been written before.