And this is what I fully agree with.
I got 99.99% of my automations in packages - i.e. in yaml files.
(my observation is - many many people use packages…)
Now I have to create an automation (also based on blueprint) on UI, check&debug it, and then move it to a yaml-file in a corresponding package. And then I am not able to use UI for this automation any more.
It is OK for me that I cannot EDIT via UI - but I cannot debug it via UI too.
Because late at night, when my wife is already asleep and I think to myself “I think the thermostat should be set to 19 °C at night instead of 20”, I do not want to get up and fetch my laptop
And movies on a mobile is a similar reason. It won’t wake the wife as quickly as a 50" bedroom TV would
Not sure where to go… Trying here… With 2021.12 installed, I now have the dialogue box popping up when pressing icon (prior to 2021.12 the dialogue box did not appear - which I like). Hitting one of the six icons in this example, all result in the action as listed in the card, but also having the dialogue box popping up unwantedly. Any thoughts how to prevent the dialogue box popping up?
Actually made them sliders.
But also created automations, scripts etc. so you can simply click a tile and call a scenario. I am not a big fan of time based changes. I prefer them via user input (one input → batch behaviour)
My guess is that UI in today’s form is not matured enough to cover all details possible to be entered into yaml. Such a situation brings the risk that using gui can break original automation. Or at least may confuse users.
While I’m guessing the morivation, I faced once or twice the situation where gui were confused about my (working) automation or it wasn’t able to save it (even with no changes made) etc
The issues are which file it (the configured automation) comes from, position in said file, inserted comments, key order, and serialization/deserialization.
That’s another strange approach. What good is a unique id? It makes absolutely no difference as long as the alias is unique. A unique ID is an unnecessarily complicated way of creating identifiers.
Especially in a system that does not show you the ids in use.
So you kind of have to guess a number and hope it is not in use.
I see no reason why a unique id is necessary. So I would add it to the change and make it obsolete and just enable editing of recognized automations, customizations etc.
This would not change with a unique id.
Plus, if the system had trouble identifying the source of the code, the code would not work. As the system understands the code, it clearly has all the components of said code and could allow editing.
P.s.: position in file is also irrelevant as the yaml syntax clearly separates code blocks. So if the code works, the respective block was recognized.
If I have read the history on this correct ShellyHass was using CoIoT and the official integration was not, this is what was causing the lag (don’t flame me if I’m incorrect there). However, both now uses CoIoT and I’m finding response time identical between the two options.
Not clear which icon do you mean - you got FOUR icons in each row.
Even before 2021.12 tapping ANY icon (main & any secondary) caused displaying more-info popup for the corresponding entity - if this entity was specified & if there was no other tap_action handler specified.
You provided 2 pics & none of them allows to see the whole code - entity_ids are clipped - are these entities are same or different? But probably this does not matter because of pt.2 (see below).