The future of YAML

And to add:


UI First
I 100% agree! Let’s make it UI first. Let’s make sure that everything works in the UI, please.

Now, let’s make it like Lovelace dashboards. Do you want to “edit manually”? At your own risk, expect the system to break, expect lesser support for you and more problems.

However, do you see benefits on it? Let me enable you to use YAML! :wink:


Cost of Maintenance

Let’s also make configuration.yaml optional to avoid burden on those who don’t want to implement it. Let’s not add burden to people.

However, a contributor wants to add a simple fix like the Adapter Pattern above? Let’s encourage it!


It’s the best of both, not either or that we are asking for.

3 Likes

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

35 posts were split to a new topic: YAML - cost of maintenance in custom components

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:

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:

  1. Initial set up
- platform: harmony
  name: HarmonyHub
  host: !secret harmony_hub_ip
  1. UI, shows delay 0.4 which is the default value (as per documentation)

  1. Changed YAML to add delay_secs:
- platform: harmony
  name: HarmonyHub
  host: !secret harmony_hub_ip
  delay_secs: 1
  1. Restarted system, for YAML configuration to update.

  2. 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.

Pulled right from the docs:

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:

  1. 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.

  2. 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… :wink:

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