No disagreement there, automations need some organization that’s missing. It’s the top feature request.
7 Likes
Thank you for the replies. I had no idea scan intervals were controversial. It seems so simple; some things should be done every second, some things once a day, and anything in between. I assumed one simple setting in hh:mm:ss format would be plenty.
I think I had one integration which went to the UI from YAML and I lost scan interval control. That’s fine, the default was good enough for me. I can’t imagine how I’d trigger that integration to do it’s thing from an automation though. It calls a manufacturer’s API. If I needed to write an automation to do that, I don’t really see why I’d even need the integration.
I guess my point (if any) is that every situation is different. I understand there’s a compromise between simplicity and control. I hope we don’t end up making things more complex in the name of simplifying.
I assume what you mean by third party devs is folks making custom components that you downloaded from somewhere like HACS? Custom component devs don’t have to follow that adr. Or any ADR really, they can do whatever they want.
This ADR is enforced entirely by PR reviews. Generally no one from core reviews PRs for custom components and even if they did their feedback would only be suggestions, not requirements.
That would change if a dev wanted their custom component added to core, then it would be treated as a new integration. But many never seek that so they can continue to do whatever they want in their repo.
You didn’t lose it. What I described works for all integrations, YAML and UI.
I already explained it, use homeassistant.update_entity. To make it more clear…
trigger:
- platform: time_pattern
seconds: "/1"
action:
- service: homeassistant.update_entity
target:
entity_id: sensor.xyz
3 Likes
Got it, thank you!
Thanks again for the discussion.
In my mind, we’re mixing two different discussions:
- Is GUI or YAML more or less appropriate for certain integrations?
- How is the intent of ADR-0010 being carried out in practice?
They’re different things and should be discussed separately.
There is a third element in the discussion, which is:
- This decision was made two years ago. Why are you complaining now?
TL;DR: I’m specifically calling out that I think the loss of YAML config for the SQL integration is a backward step; certainly for me, and – I suspect – for most people who use it. I’m also suggesting that a subtle update to ADR-0010 is called for to provide better clarity for a small number of integrations that should maintain YAML config (even if GUI config is added as an option).
Is GUI or YAML more or less appropriate for certain integrations?
In the case of the SQL integration, there is no question in my mind that YAML is better. To be a little more precise: I’m saying the loss of YAML config is a bad thing.
The core configuration of each sensor is the SQL statement, which is code. Code should be managed as code, which means things like:
- Full integration with source control so that I can track changes
- Support for code management in a full IDE (Studio Code Server)
- Allow me to structure my code into packages (for example keep an automation, an SQL query and a template sensor in the same YAML file because they are all related)
- Enable the use of conveniences like secrets
- Avoid the code owner having to reinvent the wheel by building in some / any of the above into the GUI
It’s been pointed out that including .storage is a workaround to the source control problem. Putting aside that this doesn’t address the other issues, this isn’t an adequate solution. JSON formatting / structure changes regularly, making change tracking awkward and arbitrary. Moreover, in other contexts, it has been made clear that .storage is private to HA’s implementation, and manipulating JSON files directly is frowned upon (for good reason).
@CentralCommand makes an interesting comment about the workflow of building SQL queries. Absolutely I use a separate tool to master my SQL queries (MySQL Workbench in my case). I’m certainly not an SQL guru. But source control is still a good idea (what did I change last time?) packaging of code (how does this query relate to that automation?) and so on.
I also acknowledge that the code owner for the SQL integration may have amazing plans for an awesome GUI experience. That would be fabulous and I shouldn’t presume one way or the other. But it still feels like make-work. YAML config provides an excellent and consistent experience; it would be a huge ask of the code owner to first replicate what YAML already provides and then make it better still.
Lastly, I still cannot imagine novice users making use of the SQL integration.
Which means I am left wondering who benefits from this change? To be quite specific, while I accept that many integrations should be migrated to GUI config, the SQL integration stands out as one where loss of YAML config doesn’t make sense.
How is the intent of ADR-0010 being carried out in practice?
My understanding of ADR-0010 is that it sought to provide clarity on when GUI config is more appropriate than YAML. The original problem statement appeared to be centred around services / devices requiring complex external authentication. No question - GUI all the way.
Similarly, integrations that are discoverable and / or have trivial configuration. GUI all the way.
In my system, I have 108 integrations. 28 are configured in the GUI. 27 of those make perfect sense - they require external authentication, are discoverable and / or have trivial config. Only the SQL integration stands out as not making sense.
What I think is needed is a subtle tweak to ADR-0010 to maintain the focus on shifting integrations to the GUI where it makes sense, but provide a more explicit recognition of those integrations where YAML config is preferred. They don’t have to be mutually exclusive, so GUI + YAML config might be an option, but some guidance is provided on what types of integration should maintain YAML config.
If I look at my own system, I would be disappointed if I lost YAML config for:
automationscenescriptcommand_line-
templatesensors -
mqttsensors -
modbussensors - and of course -
sqlsensors
For these integrations, two things stand out:
- The services are (generally) local
- Config is not trivial and usually involves some kind of “code” which may change from time to time (not set and forget)
The input_xxx integrations are an interesting in-between case. They are somewhat trivial / set and forget, but I certainly appreciate being able to package them near to their corresponding automations / template sensors.
It may be that some consider these examples as no-brainers - of course YAML config will stay. But I don’t know and nothing in the ADR makes it clear one way or another. Until now, I would have considered the SQL integration a no brainer.
This decision was made two years ago. Why are you complaining now?
OK cool. I’m late to the party. My apologies. I was aware of the ADR at the time, and I thought I understood its consequences. The SQL integration is the first time I’ve felt the need to “complain”.
I don’t think it serves any of us well to use the argument that the ship has sailed, can’t be changed, don’t open an old discussion. The argument feels blinkered to me and misses the opportunity to continually review big decisions with the objective of making the project better for everyone.
I am not seeking to upend the decision or to say that GUI is always wrong. I’m arguing for a little clarification on a small number of integrations where I think our community will be best served if we can agree YAML config should not be lost.
Hopefully this can be seen as constructive discussion, not “complaining”.
8 Likes
This gets brought up a lot in these discussions. I get it, there is value in it for those that have invested the time and effort setting it up. I do have to point out though that it is not available for users OOTB. And while there is a git pull addon to make this easy to set up, its only used in 1.8% of deployments. This suggests to me that while it is clearly of high value to a number of people on this forum, its not very high value to the general userbase of HA.
I encourage you to prove me wrong if you know of alternative metrics that do so. Seriously, that’s not sarcasm, I want to know.
See to me this is where the YAML experience falls flat. When I think of an IDE experience, I expect a tool that actually helps me write my code. It should provide me with prompting, syntax validation, perhaps even code autocompletion in some cases.
Studio Code Server doesn’t provide this when it comes to HA config. It helps me with the YAML sure, but that isn’t my task. I’m trying to write SQL and I don’t get any help with that.
This also applies to templates for reference. I have tons and tons of template entities. And while I’m glad Studio Code Server helps me with the YAML, the meat of the task is the template. And for that I have to go to the HA UI (the developer tools tab) to get help writing the code.
Don’t get me wrong, its nice that it helps me with the YAML, I’m not complaining about that. It’s just that the YAML isn’t actually the code here, its the vehicle for packaging my code. I would like an IDE experience for the actual code, not just the boilerplate that surrounds the code. That I can only get currently by installing phpMyAdmin or MySQL Workbench or some other equivalent software. Perhaps someday Studio Code Server and/or HA GUI will provide that for me while I am configuring one of these code-like integrations, currently neither is in my opinion.
Can’t argue with this one, I love packages. I wish analytics had data on how often they were used though. Not really possible currently since they aren’t an integration. I would suspect the answer is a low percentage since it is definitely an advanced feature and only helps organize config not automate a house. But I have no way to confirm that suspicion.
I guess? Secrets are a sharing feature, not a security feature, since they must be stored in an unencrypted file in /config. And they aren’t usable in the actual SQL statement unless you want the entire query to be a secret.
So I guess now people just share the SQL statement instead of the entire sensor config. Is that a huge difference? Wasn’t the SQL statement generally all that was shared already?
I feel like I should point out that of the things you listed only one is actually provided by YAML (sort of). Secrets are a native feature of HA YAML so I guess you could say that is provided by YAML. All others require installing and running additional software.
Now perhaps one could argue that HA would still be reinventing if it added features like these since a user could simply install additional software. I guess that’s true? But personally i would prefer to install, manage and learn less software. I mean learning and managing a deployment of HA is quite a lot of work already.
EDIT: Ok I guess two things are provided by YAML since obviously packages are also an HA YAML thing. Although I would note that despite the existence of packages the #1 most requested feature by a good amount is grouping automations in the frontend. So I think people are looking for more options in this area anyway.
Thanks for the thoughtful response @CentralCommand. For me, context is everything. My commentary is structured around those who use the SQL integration. It’s about understanding the needs and typical set up of those users. I think HA-wide metrics are unhelpful, because only a certain type of user will be using it (current metric is 3049 users or only 2.5% of the user base).
So what can we typically say about the 2.5% of users who use the SQL integration? I don’t know because the HA analytics are not correlated. But I think we can say:
- Those users are advanced because they know how to write SQL queries and they are trying to access data that isn’t easily accessed through native entities
- Those users may have abandoned the out-of-the-box SQLlite database and replaced it with MySQL for performance reasons (I have), so they are probably not out-of-the-box users
- Those advanced users may also run a home-lab; a private gitlab / gitea deployment is not out of the question
- There may be a strong correlation between the 2.5% of SQL integration users and 1.8% of git pull add-on users
- To date, these users have been configuring their SQL sensors in YAML - do we know if any of those users were unhappy about doing it this way? Were they clamouring for a GUI config option?
I don’t know, and the HA analytics don’t really give a clear view.
I do use source control and I don’t use the git pull add-on. I found it clunky, so I don’t show up as one of the 1.8% of add-on users. Like many advanced users, I also run a (separate) home lab server, on which I have deployed a private giltab instance. For advanced users, this is trivially easy to do, as is configuring Studio Code Server to pull directly from my private gitlab instance (configure an SSH key and copy and paste an SSH link from gitlab into Studio Code Server). To your question - I have no idea whether it is possible to measure how many people use source control in the same way I do.
As I say, context is everything - for me, the decision to change the SQL integration specifically should be structured around the users who actually use it.
I acknowledge your point that it would be better if Studio Code Server also helped me write SQL code - that would be lovely. But I don’t need it to - the other reasons are enough for me.
Maybe the way to carry this discussion forward is to think about the other integrations for which we may find ourselves repeating this discussion in the future. As I said in my last post, there are a small number of integrations for which the loss of YAML config would be a clear step backwards. Is it possible to agree that this is not something we want to see happen?
5 Likes
Nice update!
Only I don’t get one thing and maybe someone can explain it to me.
What is the main difference between the “old” Choose a Group of Actions and the new If/then actions.
For example:
old
- choose:
- conditions:
- condition: state
entity_id: input_boolean.rolluik_logeerkamer_automatisch
state: 'on'
sequence:
- service: cover.close_cover
target:
entity_id: cover.rolluik_logeerkamer
new
- if:
- conditions:
- condition: state
entity_id: input_boolean.rolluik_logeerkamer_automatisch
state: 'on'
then:
- service: cover.close_cover
target:
entity_id: cover.rolluik_logeerkamer
For me the old and new look the same (except for choose and if).
So what is the main difference between the two actions?
1 Like
It would be all good if we could disable the scan interval on YAML entities 
You can, ofc, put an absurdly high number on the interval, but you cannot prevent the initial scan.
One of my PR which was denied… 
Why and because of what? Esp. If this is the current only way to disable in UI cases and then use automations if you want another frequency.
Was the reason for this error ever discovered?
Found 2 non-daemonic threads.
s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening
It is removed (Missing "Import from USB" in 2022.5b7 · Issue #12585 · home-assistant/frontend · GitHub), use the CLI (from the SSH add-on):
ha os import
Just use which ever makes more sense for you personally. You can achieve the same thing with both, except with multiple conditions you would nest if/then/else inside each other to replicate “choose”.
If/then/else just replicates traditional programming syntax.
(In my opinion having both is confusing 
)
1 Like
Configuration streamlining is good, but how do you turn off the pi? I found only restart stop server (which leaves pi on)?
Settings > System > Hardware > ⋮ (top right) > Shutdown host.
1 Like
Thanks, would be nice to have these in settings search too. Now it finds only home assistant controls I assume.
You mean the menu that comes up on screen when you hit ‘c’?
If so they were deliberately left out so people didn’t hit the wrong one.
yes, that. Ok.
Wouldn’t it be clear if the front tag was like RPi, like there is “server” tag in front of those other commands.
A lot of people don’t know the difference between reboot host and restart server.
2 Likes