What other baggage?
It looks like it was the other guys baggage, you just chimed in. Iâm on the same page. Either way, I could see blueprints and automations creating helpers at some point and it would work exactly like you described: created at automation load, stored in the entity registry. I know itâs been mentioned before. The only issue I see is that if you created it from the automation, youâd only be able to edit from the automation. I.e. if you created it and gave it a range, you could only edit the range from where it was created.
1 Like
Then something is broken. Climate integrations show the current_temperature and temperature (ie the set temperature as attributes. Why do you need to keep them in a variable?
Good, I already have enough baggage to worry about.
A reasonable restriction. I would probably make the âautomation helpersâ visible in the main helper UI, but not directly editable. Maybe have them filtered out by default, with an option to show. Elsewhere, I would have the âautomation helpersâ visible for selection in most of the UI (dashboards, other automations, etc).
I can also agree with the sentiment helpers can be cumbersome to work with when using a âvariable.â A shorthand syntax to set the values would be nice, but would open a can of worms on how to handle consistently across all helper options and types. A line has to be drawn somewhere.
Have you looked at âpackagesâ?
This whole conversation started by @salsaman asking a question, and the example he gave was to give mirror an existing atttribute to a global variable, for which there is no earthly need. The conversation should die.
1 Like
So use Packages. Simple. Thatâs how my entire HA config is written.
EDIT: I just saw that I was beaten to the mark with this suggestion. Leaving it here for the link.
Unfortunately no. I set up a transparent proxy to get better network connection and it reaches the ghcr.io domain, but still get the same error.
Missed that. Thatâs about 80% there. UI support would be nice, but blueprint support even better, but this at least gets a lot of functionality into one sed script.
The UI wonât support packages. I recommend creating a #feature-requests for dynamically creating helpers via blueprints.
I am finding it very confusing to find the check config / restart etc. options. Itâs not obvious that they would be under developer tools / YAML. IMO a more logical place would be under settings / system / supervisor or somewhere similar.
1 Like
It is:
And when you click that - the system automatically checks config.
surely it could. If you examine the trace of an automation it shows you the âchanged variablesâ. IT ought to be simple matter to search animtaion traces to find instances of the variable in question being updated. If that doesnt work, presumably at some level HA would call a service to set the variable value (the HACS integration has var.set for example). So just search the database for instances of that service with the corresponding entity_id, and then from there figure out what animation or script called the service.
aha, yes, I hadnât noticed that. It is less prominent with the theme I am using, than in the image.
I donât find it very good UI design to have a scrolling frame with categories and then a single button in the margin to perform a specific task. Also, there is no indication that it will check the config. I wouldnât dare to press it unless I was aware of that fact. There should at least be a âCheck Configâ button alongside it, even if it is redundant, users will learn after clicking that and then Restart that it is not necessary.
Thatâs why it is on the YAML dev page. You only need to check config when you change YAML code. Seriously, itâs not an issue. Iâm getting sick of people complaining about change. The new UI is much better than the previous one.
3 Likes
In the âMarginâ ? ⊠I would call it âThe Headerâ in this case The Header of Systems-Settings
If your Theme confuses you or make things âDiffuseâ i suggest another Theme/Style/Color
Well I have a fine example which I am trying to resolve this very minute. I have an AC unit which due to the way it is integrated has only toggle state, there is no specific on or off. There is also no feedback from the unit, so I need to keep track of the assumed state, to avoid turning it on or off multiple times due to various triggers firing,
The best way I have found to do this is using an input boolean, however this is not very user friendly for novice users. You have to first set up a helper toggle, which new users might assume to be purely an interface element. Then to use it in a condition you have to check the state of input boolean (not a toggle, note), which is weird at first, because it is not an input to anything. Then to set the value you need to call service input_boolean.on or off. Sure, I figured it out, but only after months of playing around with HA.
IMO - a much better solution would be to provide an easier way to create variables (they can be input_booleans.etc with a different class perhaps), make the type (int, float, boolean, etc) a readonly attribute, separate variables from helpers in the menu, In automations, instead of call_service input_boolean.xxx on, have a more user-friendly actions: set_state, / set_numeric_sate, with entity_id: var. xxx, value: on, likewise in triggers and conditions, you would choose - state or numerical state of var.xxx.
Change variable/State : Notify, or what ever fits you, change color on âToggleâ, or change color on entity/entities, add entity to auto/conditional list etc ( What ever the âTriggersâ are ). ⊠and for your last usecase, use a âmetered Plugâ ( if W above +0.x = on , else Off ) (PS: you get power-consumption and ability to turn it off completely, just in case, 3 in 1) , in any case for some reason your AC donât provide you with any info, so take/use what you have
I think to clarify this for everyone reading you might want to refer to what youâre proposing as âautomation statesâ, âmemoryâ or âtemporary storageâ instead of variables. Since we already have âvariablesâ but you are specifically after some sort of state/memory based variables (persistent)
I had assumed until now that you had a climate entity for your AC. It seems you donât.
I think you should try setting up a Generic Thermostat, then your system will work as intended without all these workarounds or added âfeaturesâ you think you need. Generic Thermostat - Home Assistant
2 Likes