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-
template sensors
-
mqtt sensors
-
modbus sensors
- and of course -
sql sensors
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”.
)