Ok. I did it. Thanks for your help.
Is it my config or is it intended by the blueprint that all my thermostats turn to off
when I restart home assistant? I need to manually turn them to heat
again, every time I restarted homeassistant. Any ideas @panhans where to start debugging this? I’ve the latest stable release of the blueprint installed.
Did you set up the uptime integration?
Hello,
Wondering if there is a way to add multiple thermostats for heating/cooling such as i have gas heat and i have mini splits and may add other ways to heat or others and the automation can cipher with one to use based on temperature for efficiency and or emergency heat etc.
Yes, up and running. Is it used automatically or do I need to do anything with it?
I think this is a very special use case. Adding multiple climates in a single automation is no problem as long as they’re supporting the same hvac modes.
Emergency / redundant backup logic I would handle in two separate automations and one for toggling between them.
@DenisLanz
Did you set an on/off entity for your automation? Did you check if it’s enabled at startup?
Further more a trace log after a reboot would be helpful. (Described in the initial post of this thread)
You’re right, setup the input boolean from the UI but there I can’t set the initial
state. Nevertheless, in summer this would be counter productive. Do I need to setup an automation to set it to the state it was before the restart, I don’t really understand the documentation for the input boolean on this point.
That’s weird, the documentation clearly states:
" Otherwise, it will restore the state it had prior to Home Assistant stopping."
I’ll test it later today, removing the initial
value from my helper again and provide you with a trace log as the blueprint is the only action interacting with the thermostats.
Usually the state will be restored. You could have a look into your logbook, filter for your input boolean and figure out what turns it off.
The scheduler card seems more user friendly than the schedule helper. I already use that to set my heating setpoint. Is there anyway to use that to set my schedule for comfort instead?
I assume use it to set a helper entity, do it just need to be a boolean?
So, it’s definitely the blueprint that is shutting of the valves on restart:
it changed from
heat
to off
within two seconds on start.
To test it I even disabled the original and set it up from scratch to test if it’s caused by an update of the blueprint, same result.
Traces:
https://controlc.com/1072c5ec
https://controlc.com/a8e1b61b
I also did the same test with the development version of your blueprint - no issue then. I just don’t want to set up all automations again with a development version.
It seems the automation is loaded before your outside temperature sensor is ready.
Maybe I have to add a variable delay so you can delay the actions when home assistant was just started.
//I have another idea. Will provide a new version soon. But could you tell me the state of your sensor after a restart? (You can see this in the history)
Hm, that might be the issue, the sensor plots first unknown
and then unavailable
before returning a temperature again. It’s an Aqara WSDCGQ12LM connected through Zigbee2Mqtt.
Btw. that might also be the issue with the Aqara E1 thermostats error with the exclamation mark on the display: the external thermometer are unavailable when calibrating them, leaving them in some sort of limbo, leading them to throw a valve alarm:
Valve alarm
Notifies of a temperature control abnormality if valve detection is enabled (e.g., thermostat not installed correctly, valve failure or incorrect calibration, incorrect link to external temperature sensor)"
Thanks for the hint. I just updated the blueprint (dev). Calibration and any changes will be blocked if there is a temperature sensor defined but has an invalid state. Feel free to update, test and give feedback.
//EDIT: ah don’t update. found a litte issue fixed
Yes, you’re right. But I want to be this blueprint designed for native home assistant entities without any 3rd party dependency. I wish there is a good schedule card and at least UI support for the new custom attributes for schedules.
You can always go with a binary template sensor that checks the state of your custom schedule and set it as guest mode / presence sensor.
Isn’t there a also small typo in line 2469 which reads _senso instead of _sensor?
{% set temp_diff = state_attr(valve,'temperature') | float(temperature) - value_temperature_senso | float %}
Thanks for your review. It’s also fixed now.
Sorry, that was my mistake. This is the config, wich works for me now.
The behaviour only takes place when i have two schedulers inside. Only the first is working.
input_schedulers:
- schedule.buro_heizplan_werktags
- schedule.buro_heizplan_wochenende
You didn’t define a selector that handles the switch between the two schedules.
Just because I’m curious: Why do you have an extra schedule for the weekend? A schedule covers all 7 days and so each day can be specified individually. Or do you also have the weekdays assigned differently in the weekend schedule, e.g. if you are on vacation? That would then make sense.
I have a question: what are the differences between the Calibration Temperature Sensor and the Room Temperature Sensor in matter of operation/functionality? In theory they can be the same and in an essence they are both controlling the “desired” temperature.