Again, that was an example.
I quite frequently add new devices or redo my setup.
And this also includes changing the unqiue id (because I use the name for the unique id. So this messes up area.
And the one pain I have is that I have to manually define the area via UI instead of having a simple oneliner in the mqtt yaml.
So, why not make this available? Obviously if you never change anything, never add anything new, never redo your setup, you will only ever have to setup everything once. But let’s be honest, we don’t enjoy that
So why not make it easy and simple and add one more option to mqtt? So simple. area:
Don’t do that. You don’t need to care about unique_id, just make it unique. You can use this website, make it like 20 characters:
It would require you to add a unique_id so integrations that don’t have unique_id’s wouldn’t get it, and a system would need to be developed to manage a yaml area that can be overridden by the UI. It’s not a simple “just do this”.
I use unique id like that because my names are also always unique and it makes it easier to specify unique id if I ever need to refer to it (like in my scripts before switching to service call).
I did not quite understand why it is a problem to define the area in mqtt climate, mqtt sensor etc. That integration is part of core and you can define everything else just not area.
I did not understand what you meant and why area defined in mqtt cannot be passed to the same destination as the area defined via UI.
Could the mqtt integration not write that information (assuming you define a unique id, which I do) to the config?
Of course you can make unique_id mandatory. No problem. As long as the option is then available. Defining another option in yaml is fast and simple and one time job.
It cannot. The only way to use an area is if you have a config entry. The only way a config entry is created is when you have a unique_id. The only way a config entry remains static is if you do not delete the integration and you keep the exact same unique_id.
But the problem with unique ids potentially being used by others already exists.
So let’s limit the discussion to adding area to mqtt. So the “only” thing needed would be for mqtt to write area to config on load (boot or manual reload). If it writes to the same file as UI, then they would simply overwrite each other. Since unique id is defined, both will write to the same entry. So if a user defines in yaml and then in UI and overwrites himself->his problem.
But on an integration basis (here mqtt), only writing to config file is needed using the unique id
P.S.: I don’t mind changing thread to MQTT atea option if a global solution is too complicated.
No, integrations append a unique integration identifier to user added unique_id’s so that it’s truely unique on the entire system.
No. Because as soon as you add a unique_id, it creates a config entry. And if you adjust the area via the UI, every restart the area would be wiped out. Anything that is added via yaml needs to have a mechanism built to over ride it via the UI. There’s no way around this.
No outcome well facing same issue. Why can we not just Add manually the area like name or any other config option for an Integration… I know Its always easier but I think due to the area option in home assistant we should be able to add no matter what entity to areas …even if only manually…but better via UI of course
My strong impression that Devs wish to move everything to UI and get rid of yaml one day. And yes, I heard promises like “yaml will be never deprecated”. So, no expectations that “area” will be available to define in yaml.
That will never happen. For random integrations that may happen. For templates, scripts, automations, scenes, helpers. That will not happen. When new helpers are added, it’s a requirement to support yaml and UI. All other integrations, the code owner have the option to support both, however most code owners don’t want to support both.
Also, for integrations of some kind there are rules like “UI only, not yaml”.
Anyway, for some stuff (incl. new like “number format”, “visible”) yaml in not supported, and this worries. This is where these doubts about a “future support of yaml” come from.
It’s been stated multiple times. It’s even in the ADR about yaml. There’s only so many times everyone can say it’s not going away.
No. The rule is you have to add UI for new integrations, you can optionally also add yaml. If the integration is internal, you can completely skip UI all together. It would be great if the people here (Not this thread specifically) would actually read the ADRs instead of passing around gossip. They haven’t changed since yaml-gate in 2020.
I don’t see the distinction between “core” and “random” in the ADR. Therefore one could assume, “core” integrations might lack YAML config as well.
Yep, that optional YAML is a problem (for ppl like me). If it was the other way around (YAML required, WebUI optional) → YAML wouldn’t be less and less supported.
Areas – as hmm… entity attributes [?]… separate concern [?]… – are obviously not on the list, so they don’t have to have YAML support, right?
well facing same issue. Why can we not just Add manually the area like name or any other config option for an Integration… I know Its always easier but I think due to the area option in home assistant we should be able to add no matter what entity to areas …even if only manually…but better via UI of course
