I am relatively new to Home Assistant. I was forced to find an alternative to controlling all of my Radio Thermostats when the company turned off the cloud service. Home Assistant has been a good replacement for making remote access to these devices possible.
I have created an automation that sets the thermostats to a specific temperature when occupied and another when set to away. My automation works as expected but I have one thing I would like to correct.
My two scripts are below. The first automation triggered by the occupied / away toggle like I mentioned works as expected. The one problem I would like to correct is when someone manually changes the thermostat set-point. I would like to toggle the Boolean back to the occupied state. I created a second script that achieves this but after the additional script was added I now get a toggle bounce. I have tried timers, delays turning off the opposing script and nothing seems to work.
Your 2 automatons appear to be performing as the code intends.
The home/away automation seems to assume the helper is synced to some presence logic. Your second automation seems to assume the presence logic can miss someone present at the location & you thus appear to be using this automation to fix that. As a consequence turning the helper on triggers your first automation. That seems to result in your “bounce”
That is providing my understanding is accurate. (I’m still pretty green)
since i don’t have your device id’s, i can’t really test it… but do a compare with your s block by block and see how much tighter the code is. it went from 116 lines to 87
now… to actually fix your problem… i’d probably have a boolean that said “manual override mode” … because that’s what’s really happening.
but a surgical fix is this (see my ## comment below)
alias: "Automation: Manual temperature change, reset toggle to OFF"
description: Reset away toggle to off after manual temperature adjustment
trigger:
- platform: state
entity_id:
- climate.shelter_house
id: manual temperature change
attribute: temperature
condition:
- condition: state
entity_id: input_boolean.helper_shelter_house_away_toggle
state: "on"
action:
- service: automation.turn_off
data:
stop_actions: true
target:
entity_id: automation.name_of_the_Automation_set_away_Shelter_house
- service: input_boolean.turn_off
target:
entity_id: input_boolean.helper_shelter_house_away_toggle
data: {}
## i don't think this is necessary... but just in case... try testing with and without it.
- delay:
seconds: 5
- service: automation.turn_on
target:
entity_id: automation.name_of_the_Automation_set_away_Shelter_house
data: {}
mode: single
you need to replace the automation name above with the correct one for the first automation you had.
Thanks for your reply. Yes, I thought about a “manual override.” but that kind of defeats the purpose of the original Boolean. I will continue to use as it is for now. The operator will simply need to do an additional tap of the toggle to put it back in sync. Thanks for the advice on the device ID’s. I will make sure not to use them going forward.
take a look at the code i posted above. what i posted fixes your issue w/o a manual override. i was saying that i personally would do it with a manual override, but if you didn’t want that, then i’m giving you that code instead…
bummer… do you want to give up? this has to be solvable. but may need to do a little tracing… unless someone else here spots the issue. but if you don’t want to bother… your call. but if you want to figure it out, i’d update the second automation to this:
alias: "Automation: Manual temperature change, reset toggle to OFF"
description: Reset away toggle to off after manual temperature adjustment
trigger:
- platform: state
entity_id:
- climate.shelter_house
id: manual temperature change
attribute: temperature
condition:
- condition: state
entity_id: input_boolean.helper_shelter_house_away_toggle
state: "on"
action:
- service: automation.turn_off
data:
stop_actions: true
target:
entity_id: automation.name_of_the_Automation_set_away_Shelter_house
- delay:
seconds: 5
- service: input_boolean.turn_off
target:
entity_id: input_boolean.helper_shelter_house_away_toggle
data: {}
- delay:
seconds: 5
- service: automation.turn_on
target:
entity_id: automation.name_of_the_Automation_set_away_Shelter_house
data: {}
mode: single
notice i put a 5 second delay before and after the house_away_toggle boolean change. so do this, trigger the manual temperature change, then see when does the first automation bounce it back? does it do it immeidately, at 5 seconds, or at 10 seconds.
No, I’m not giving up. But I did decide to add the local calendar integration so that may change things up a little. I have a total of 13 thermostats between 5 buildings. This is a church campus with the Pastor and a handful of others that have access to this. I just want to make sure I have it working 100% before I push this new version. My current HA installation is running on my Synology NAS in a docker container. As you know that greatly limits what we could do with HA. I decided to spin up Proxmox on an old machine. Since I now have a DEV platform I can do some trial and error.
I have these thermostats grouped into 5 different areas. for each group I now have 3 automations and 2 scripts so it is getting a little complicated. Your previous suggestion about using the device ID’s is a good one, but it appears these ID numbers are generated by HA when I built my custom conditions. I do not see any way of changing these ID’s I could provide a flow chart if that would help in understanding.
After adding the calendar integration, I have it working as before. Still have the nuisance of not being able to toggle the Boolean after a manual temperature change.
i think you may have misunderstood me about the device id. we’re not saying to rename device id’s to friendly human readable names. you can’t do that. those device ids, as you said, are generated and fixed. however each device has one or more corresponding entities. those entities are the things you should be interacting with. and those entities are ones you can choose the name of.
and when you build your automations and scripts, refer to just the entity_id friendly name. do not use the device id.
not only does this make your code more readable, the system will autocomplete for you so it’s easier to program. and, if ever a device breaks and you have to replace it, you won’t need to update all of your code. you just set the entity_id to be what the old broken one was, and everything continues to work.
back to the bouncing of temperature control. if you get a moment, do the test i said above with the 2 different wait times and let’s see at what point the bounce happens…
I am doing as you suggest as far as the friendly names. The results in code I’m not sure I can do anything different… Below is a screen shot of the condition that is showing the numeric string for ID. Below that is the code generated when building the automation.
Running out of time this evening, But I will give your code another go tomorrow evening.
