No, he needs individual room control and his emergency condition requires that the valves be opened in spite of what the thermostat wants
I misread.
Possibly but that only helps with 3 rooms
I was going to say “use an older image” but that wouldn’t help as it will try to update to the latest, hmmmm I think you are buggered!
Please could anyone give me advise? Wandering if I should use hass.io or hassbian/raspbian installation. Is there something what hass.io could give me regarding to my heating project? I used hassbian before but have problem with Python update to latest.
Is latest Python in latest Hassbian or is there some problem in both hassbian or raspbian regarding Python?
Thanks.
All rooms would open the valves when heating is required but the heat would only be supplied if the group is on.
Some have problems with generic thermostat but I have had no issues.
Getting the switch to do what the thermostat doesn’t want can be tricky. I need to do this to open/close valves in summer so they don’t stick. I am pretty certain when I tried the thermostat kept turning the valve off. I will probably need a routine that disabled the automation to turn on the heater and temporarily sets the target temp for all the thermostats very high for enough time for them to open, then puts everything back how it was. Unless there’s a better way.
Yeah, already got that covered
Will write to a virtual switch.
The emergency will write to a binary sensor
And if either are on the valve is on
You want USB boot right? Read this thread.
Thanks @jazzyisj but this is about Resin version.
I wrote before:
I must use old ResinOS version. But this is the dead way. Great - after few years I decide to left Hassbian because is dead and move to Hass.io and it is halfdead - LUCKY ME 
btw. someone talked about nuclear powerplant in my case. HASS.IO is a nuclear power plant. Russian. Maybe called Tschernobyl or so something. Can´t believe there are so many problems with using stupid USB. Thousands of posts about this stupidity around single bunch of scripts 
So please please PLEASE. If anyone could give me helping hand and tell me if there is ANY big advantage using hass.io over standard raspbian or hassbian hass instalation regarding to heating etc.?
If not I will not loose time tomorrow and will install it from a scratch on raspbian.
THANK YOU.
https://github.com/home-assistant/hassos/releases/download/2.12/hassos_rpi3-2.12.img.gz
Write it to an SD card
Put the sd into the pi 3b
Boot it, wait 90 mins
Worry about moving it to another system once your heating is running
That’s what snapshots are for
Sorry @Mutt but i really don´t want to run it from SD card. It is only about time when SD will die in raspbery. Since Raspbery 1 I always used USB (in 1 and 2 with SD for boot record), but always prefered this method as it is just more stable, faster, without risc of file corruption.
Jiran is your situation right now urgent? Do you have heat in your home right now?
@Mutt is trying to get you up and running ASAP so you have a heating system. Today. What he is suggesting is that you install hass.io on an SD card. Today. Then you can get your heating automation system all straightened out and tested so you have heat. You can then make a backup of your configuration and reinstall whatever operating system and flavour of Home Assistant you want at your leisure but certainly before your SD card dies. Once you’ve done that you can instantly copy your backed up configuration files including your spiffy new heating system over to your new installation.
If this is not an emergency, then get your OS straightened out at hopefully @Mutt will have time to help you out then.
Thanks @jazzyisj. It is not urgent. It works - manually.
I really prefer to decide OS first and after make everything solid.
Now I want to decide if Iĺl use hassbian or raspbian with manual or AIO.
Hass.io seems to be problem more than helper…
I´ve been using Hass.io in the same SD card for over TWO years now, running flawlessly. I think it’s a matter of card quality, but migrating to a virtual machine running some flavor of Linux is in the works (since I have a Win10 PC running 24/7 anyway).
Cheers
1 Like
Yeah, what he said 
I agree, 2 years running hassio with same EVO SD card, now on ssd but for performance not because I had issues with the SD.
Thanks for posting this. The zwave thermostat in my garage pooped out and I was thinking of dipping my big toe in the world of Tasmota or ESPHome to come up with a more homebrew (and much cheaper!) solution. You’ve posted a great starting point if I decide to go the MQTT route.
{%- set multiplier = 1 -%}
{%- if is_state('input_select.' + area + '_heatpump_mode', 'cool' ) -%}
{%- set multiplier = -1 -%}
{%- elif is_state('input_select.' + area + '_heatpump_mode', 'off') -%}
{%- set multiplier = 0 -%}
{%- endif -%}
{{ (diff * multiplier) | round(1) }}
This was a clever. I wouldn’t have thought to do it this way. I’d have probably just done something with an absolute value filter but 6 & 1/2 dozen. It’s interesting to see how different people skin their cats. I am going to take note of this technique it could be useful one day.
{%- set diff = -1.234 -%}
{% set state = 'cool'%}
{%- set multiplier = 1 -%}
{%- if state == 'cool' -%}
{%- set multiplier = -1 -%}
{%- elif state == 'off' -%}
{%- set multiplier = 0 -%}
{%- endif -%}
{{ (diff * multiplier) | round(1) }}
{%- set diff = -1.234 -%}
{% set state = 'cool'%}
{%- if state == 'off' -%}
{%- set diff = 0 -%}
{%- else -%}
{%- set diff = diff | abs | round(1) -%}
{%- endif %}
{{ diff }}
I also really like your timer solution. I’ve always just tried to use a delay or wait_template in situations like this but if the script gets called more than twice it starts to fall apart because of the underlying issues with automation/script behaviour when called again while still running. I have at least one place in my configuration (ironically my climate control) where something like this will be a better solution even if it means a couple second delay every time it runs.
- wait_template: "{{ is_state('script.livingroom_climate_stat', 'off') }}"
timeout: '00:00:15'
continue_on_timeout: false
- service: script.livingroom_climate_stat
I do have one question though. I don’t understand why you’re checking the from_state of input_text.livingroom_heatpump_command for invalid values in the livingroom_heatpump_status_changed automation. Why does it matter what the from_state was? Should’t you check the to_state for invalid values since that is the next command that will be sent to the heat pump? What did I miss here?
The reason for this would be easy to miss. When you initially start HA, before the input fields get re-populated with their previous values, their states are undefined. Without a condition for the from state, my heat pumps got a command sent to them every time I restarted HA.
1 Like
Ah ha. I see the light! I have some automations I have to delay turning on at reboot until the sensors involved get their states sorted out or weird things happen. Thanks again - I’m sure that all took a while to get that all figured out and put together.
If, for example, a State Trigger is used without a to: or from: then it will trigger for any change in the entity’s state or its attributes. A state-change can include changing from undefined to a “valid” state (like on or off) or vice-versa. You can also have the situation where to_state is identical to from_state. This can indicate there was no change to the entity’s state but there was a change in one of its attributes.
Knowing that the State Trigger can be triggered for a whole lot more reasons that just the entity’s state flipping from on to off, it may be necessary to filter out all these possibilities, using a condition, to prevent running an action when it shouldn’t.
I learned all this from pnbruckner after challenging him for using, what I called, ‘belt and suspenders’ conditions (they appeared to be overkill). Then he explained why and it all made sense.