2022.5.3 worked here.
But are you running HA Container (Core) ?
Iām running HAOS 7.6 with VMware on Win10. The following error occurs when I try to upgrade the core to 2022.5.4. During the attampt of dowloading, I do see network traffice rising on my host Win10. And the previous upgrade of HAOS seems fine. What else shall I check for this failure? Thanks.
22-05-15 21:22:18 INFO (SyncWorker_1) [supervisor.docker.interface] Downloading docker image Package qemux86-64-homeassistant Ā· GitHub with tag 2022.5.4.
22-05-15 21:26:46 ERROR (SyncWorker_1) [supervisor.docker.interface] Canāt install ghcr.io/home-assistant/qemux86-64-homeassistant:2022.5.4: 404 Client Error for http+docker://localhost/v1.41/images/ghcr.io/home-assistant/qemux86-64-homeassistant:2022.5.4/json: Not Found (āno such image: ghcr.io/home-assistant/qemux86-64-homeassistant:2022.5.4: No such image: ghcr.io/home-assistant/qemux86-64-homeassistant:2022.5.4ā)
22-05-15 21:26:46 WARNING (MainThread) [supervisor.homeassistant.core] Updating Home Assistant image failed
Are you short on virtual disk space?
Well I run supervised, so it runs the same core container.
Iād like to request a new action type: SET VARIABLE
e.g. on trigger and condition, SET VARIABLE (name) = value (float or string)
then add this to triggers and conditions, trigger - variable value, condition - variable value
I know you can do something like this with helpers / templates and so on, but it is not very user friendly like that.
An easy example - I can set the temperature of my AC unit, but it doesnt have any feedback. So I can set a variable āAC tempā to keep track of what I set to, then use the numerical value of AC temp as a condition in another automation.
Variables exist already, and you can achieve this with an automation + 1 helper entity to store info as āmemoryā. Iāve actually done this myself to add a fan entity to HASS for a dumb IR pedestal fan which doesnāt give any feedback or even discrete on/off commands, I just track the commands which are sent and update the āmemoryā helper with last on/command times etc
You can use this as well
Yes, I know it is possible, but what I am suggesting is a more user friendly way, for example it could create a helper variable automatically, and then perhaps it could become an attribute of āvariableā, like variable.AC_temp. Then you could just trigger on numerical state of variable.xyz
Just eliminating the step of adding a helper would be nice though, not everybody will be aware of that.
Yes, this is what I was thinking of. I hope it can be included as a core component some time, but Iāll try it, thanks !
The problem with globals is theyāre easier until you have an issue. When you have an issue because the value of your global variable is in some unexpected state then suddenly everyone remembers why they hate global variables. Tracking down how that global variable got into that unexpected state is a difficult and time-consuming task since you have to follow its path through all the things that couldāve modified its value.
So while HA could make this easier Iām not really sure it should. Itās a really tough tradeoff. If you make it easier to set globals in automations people will absolutely use it and it probably will help them initially. But global variables scale very poorly so its setting users up to get very stuck as they continue to add automations.
1 Like
It ought to be possible to trace the variable and discover what changed the value and for what reason, so I dont see that as such a big issue.
No one does until they have a mess of global variables
Not sure how youāre imagining HA could do this but thereās no way HA could tell you why. It could show you what automation triggered the state change like it does with anything else. And hopefully the trace(s) are still around for you to look at. Beyond that you would be on your own.
1 Like
Anybody that has done even only a few years of proper programming will know that global state (a concept; global variables is one implementation) is the root of all evil. There are of course cases where it is useful, but more often not.
2 Likes
Hi, did you find a fix? Getting the same error and not able to updateā¦
Folks are getting too hung up on his use of the word āvariableā and thinking of it from a coding perspective.
It would be nice to have a way to define a helper that is only intended to be used within an automation inside that automationās yaml/ui vs having to go into a different yaml file/ui screen.
All the logic could be the same as existing helpers. Use the existing service calls. Tracking would be no different than if it was defined as a regular helper. Basically just need a standard naming convention and some standards on how to display āautomation helpersā in the UI.
The plumbing under the covers to create a helper from the automation config might be a nightmare and undoable, but it could really clean up my config. I doubt I would have any āregularā helpers if something like this were implemented.
It would be great for blueprints.
Something like:
automation room_lights:
helpers:
input_boolean:
sense_motion
timer:
my_timer
trigger:
- platform: event
event_type: timer.finished
id: timeout
event_data:
entity_id: timer.automation_room_lights_my_timer
- platform: state
entity_id: input_boolean:automation_room_lights_sense_motion
id: motion_enabled
to: 'on'
How would that work?
To trigger the timer has to be defined but the timer is only defined once the automation is triggered.
I would argue the timer should be defined/created when the automation loads, not upon first execution of the automation. The ātimeoutā trigger couldnāt fire until the timer is started.
Most of my motion/light type automations rely one on or more timers. The automation starts the timer(s) on certain triggers, and cancels/finish/pauses the timer on other triggers.
Helpers created that way would still show up in the state machine, so it kind of defeats the purpose. If you just want them hidden from the UI, hide them.
EDIT: Iām not arguing against being able to set them up directly in automations. That would be a nice feature, however all the other baggage you added would not fly with the current paradigm.
I donāt really want them hidden from the UI.
I want to define everything I need for the automation IN the automation. One single block of yaml or on a single UI visual editor page, instead of being split between the automation and helper ui/yaml.