I was talking from the perspective of an integrationsmaintainer
In that case I’d prefer if it was a central implementation than per integration
That’s a good solution. It is harder to implement centrally as the translations may not map 1:1; but if they do, then it’s definitely doable and one of the solutions. Doing it per solution can bring a bit more of nuances into it, but both are possible.
Has any of this been considered during ADR-0010? Can it be considered and discussed?
You could do a custom component that can host integration specific configurations that can do this translation. Maybe start there to try it out
Something like
Configuration:
domain name:
parameters
Could work with both generic configs as well as specific support per domain
For those who are interested, the posts that have been moved under YAML - cost of maintenance in custom components are not really related to Custom Components.
They actually are a response to the original post (on ADR-0010) and arguing against the deprecation of YAML configuration for Integrations.
Some examples of the posts are collected here:
-
Arguments against ADR-0010 rationale on this original blog post.
-
List of user flows broken with the deprecation on YAML on integrations, fully compiled from the 600 posts on these message
-
Proofs of concept supporting the original counter argumentation:
- Experiment to showcase actual cost of adding YAML support
- Experiment to showcase how to leverage the UI flow to generate YAML configuration, also lowering development cost. And also follow ups on the implications for changes in schema.
I am happy to continue the discussions in another post, if we are not allowed to discuss ADR-0010 on the community/blog post about it. However, I wanted to make clear that these were not unrelated to the main thread or related to custom components; but actual arguments to the main discussion here.
9 Likes
For those interested in officially addressing ADR, I’ve submitted an architecture issue to allow YAML configuration optionally. Comments can be done there instead of here as that’s the official channel for these conversations.
I have also submitted another one with a potential solution which advocates for reusing the same schema, set up and partially rely on UI to solve most or all of the problems with the “cost of maintenance”.
There are also alternative proposals. If you have your ideas, you should also feel encouraged to bring them.
5 Likes
One interesting finding:
Harmony (example) still supports YAML as per documentation and code. I have not seen any notifications on my system that this is deprecated or the entity has been migrated.
However, YAML changes will no longer reflect on the system. I’ve done the following test:
- Initial set up
- platform: harmony
name: HarmonyHub
host: !secret harmony_hub_ip
- UI, shows delay 0.4 which is the default value (as per documentation)
- Changed YAML to add
delay_secs:
- platform: harmony
name: HarmonyHub
host: !secret harmony_hub_ip
delay_secs: 1
-
Restarted system, for YAML configuration to update.
-
UI still shows 0.4.
As per my discussions with OnFreund, this seems to mean that my entities have been ported from YAML to UI. However, I do not think I have received any notification on my system about it; and, as stated, this component still supports YAML.
If I was a user who do not check Blog or Community, how was I supposed to pick this up?
This feels broken and not working as intended. Can someone else replicate this?
3 Likes
You understand that the UI and Yaml are separate configurations correct? I.E. UI does not impact yaml and yaml does not impact UI. You as a user choose one or the other, not both.
Hi @petro, I understand that.
Now, I have never configured Harmony on the UI, or clicked any migrations. My configuration is solely YAML.
Additionally, Harmony still has configuration available for YAML, as you have happily copied from the documentation.
As such, why do I have the UI if “yaml does not impact UI”? The entity was migrated from YAML to UI without my changes. At the moment, I have my configuration.yaml where I still have my configuration, but this configuration is useless. I do not have any messages telling me or confirming that my entities have been migrated.
From a technical perspective, OnFreund provided a confirmation and answer here. You may want to have a look.
Hence, yes, YAML has actually affected the UI; but only for a one time configuration and not for further changes.
1 Like
That’s not entirely true.
There are many integrations that due to the deprecation of yaml are having their yaml configuration automatically imported into the UI. Then after that their yaml config is completely ignored.
The most recent one I remember that affected me was the ZHA integration. In my system it is displayed as a UI configuration but I never migrated anything to the UI and my configuration.yaml still contains my zha: config. And as a test I just removed the zha: section from my manual config and the UI config is still there and my devices still work.
Of course it doesn’t go the other way tho.
1 Like
Yes, that was the point I was trying to make. Once it has been imported (without confirmation or, apparently, notification), your YAML is redeemed useless. It’s still there, you may think it works, but it doesn’t. And this is not just when YAML has been deprecated. Harmony still supports YAML, but my entities have been migrated; so the changes are not being reflected.
I’ve known about this. Thanks though.
I thought the point I was making was clear. When you have both configured they don’t impact each other. Perhaps I could have been more clear.
With pleasure. Given the fact that I was talking about that migration and you didn’t point out to the fact that we are doing forced migrations without notifications to users (on their system, since not everyone may read the Blog/Community), I thought that it was still worth bringing to everyone’s attention.
They do, though. YAML will create UI entities if the import method is present. Also, apparently, some changes (e.g. host field) may trigger a new UI configuration (I have not verified, but it was stated on the GitHub entry as well).
This is confusing for users for two reasons:
-
Users may not have received a message about this. I know some components log about the migration/deprecation, but that does not seem the case with Harmony; so probably also not others. And not every user may check the Blog.
-
Some components still support YAML. As such, a user may change the YAML configuration of one component (e.g Harmony) and it would not work; but changing others may. Without additional context (e.g. checking Integrations, and understanding those are now migrated) or notifications, there’s no way for the user to understand what is happening.
1 Like
I guess this is the part that threw me:
Because the user never made a choice in those circumstances. It was done for them, fairly quietly unless they read the release notes or happen to look in their logs at the right time and see it - if the integration even mentions it in the log in the first place. I don’t know if any or all do.
3 Likes
Looks like we cross posted…good points tho… 
1 Like
@nitobuendia, @finity Honestly, I don’t care. If you have problems with it, make a PR against the docs to make it more clear. I’m not going to debate either of you on this issue.
1 Like
Apparently you did until you got a bit of pushback. Or at least you did care enough to post about it in the first place.
There’s no debate about it at all. It’s simply a clarification and statement of fact.
Sorry to have ruffled your feathers.
3 Likes
Hi @petro
No need to debate if you don’t want. Do note that you entered in the debate yourself, though. I personally do not find it very friendly to enter a debate, then say you don’t care or want to debate No issues, in any case. Don’t worry.
As for the PR, yes, if you read the GitHub, we are talking about that. Thanks for the suggestion.
1 Like