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.
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.
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.
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.
Looks like we cross postedâŚgood points thoâŚ
@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.
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.
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.
Not at all, just fed up with the semantics debates. I already made it known that i could have been more clear. Yet here we are, still talking about it.
And I should have been more clear myself that I accepted your mea culpa. So mea culpa.
I was just explaining why I thought there was a misunderstanding. Itâs all good on my end.
I was not entering the debate. I was pointing out what I thought was going wrong. Word of advice: not everyone comments here to debate with you personally. Some people are just trying to help, whether that help is correct or not remains to be seen.
Hi @petro
I am also trying to help those users who may get confused by this forced YAML migration; or with some of the statements that you posted in reply, that at least me (and I think @finity) do not find fully accurate or at least clear.
Some of us do find that debate is a healthy way to contribute and clarify, as opposed to sparing smart statements and leave.
In any case, youâre not interested in debating; you made that clear. We can park it here. I can continue debating and discussing with whomever finds this conversation relevant.
Thank you!
As was I.
And thatâs what I thought I was doingâŚtrying to help clarify a point of confusion. Maybe not on your part but possibly on someone elseâs part that might come by later and misread your comments.
Wow! we really have to stop cross posting like this. Itâs getting really creepy.
Can someone expand on this statement? Or at least provide a little more clarity. is this referring to the configuration.yaml file itself, or configuration in general?
Any integration polling data from devices like a hub (Hue) or a cloud based service (SmartThings) will only be allowed to be configured via the GUI.
This is a solution (as owners said, do it yourself) for those of you who, like me, stopped updating Home Assistant due to YAML Components. I wanted to share a way to downgrade your components to the versions where YAML was being used, so you can upgrade the rest of the platform.
Introduction
Git (GitHub) keeps version control of all changes to components and you can revert to any version. On this process, we will simply download a copy of the home-assistant/core component at a certain point of history, where YAML was still supported.
As such, the key point is that YAML has to have been supported at some point for this to work.
Process
Before you start, it is advisable that you create a backup (a.k.a snapshot) and download it in case something goes wrong and you need to revert to this point in history.
Finding the right version
The first task is to find the most recent version where YAML was still supported. For this, we are going to go to home-assistant/core > homeassistant > components. Then select the platform that you want to downgrade. For this demo, we will use roomba
.
If UI is the main configuration, there will be a file called âconfig_flow.pyâ, click it and navigate to History on top right.
Scroll all the way down and check the date of the first commit. If there are many changes, you many need to click âOlderâ a few times. In this case, itâs April 11, 2020
and the commit is Add config_flow for Roomba (#33302)
. This is the commit where config_flow.py
(UI) was created. We probably want to revert to the version exactly before this one.
Within that view, click now on the name of the platform folder, to go to the History page for the whole component. Your objective now is to find the commit before where config_flow.py
was added. Again, you may need to click âOlderâ a few times. Memorizing the date before will help you in doing this faster.
In this case, we want to revert the component to âAdd prettier (in pre-commit and CI) (#33693)â. The last version before UI was added.
Downloading the component
Via Command Line
If you are familiar with git (GitHub), you can clone the repository at that version (example):
git clone https://github.com/home-assistant/core.git
cd core
git checkout 39336d3ea367e5c50e88fa09165257290a07b150
Where 39336d3ea367e5c50e88fa09165257290a07b150
is the commit id. You can get it by clicking on the commit.
Once done, copy the platform folder (eâŚg homeassistant/components/roomba
). See next section to know what to do with it. Once you have copied the folder we need, you can delete the overall folder containing the other files of the home-assistant/core
repository.
Manually
If you are not familiar with git or do not want to clone the repository, thereâs also a manual way:
Once you have identified the version you want, click the button [<>]
to revert the view to that commit/point in history.
Once you click it, you will be back to the main home-assistant/core
folder, but with a key difference. Now, you will be in the view of the repository in the point of history where you selected.
Navigate again to your component folder: home-assistant/core > homeassistant > components > (e.g. roomba)
Click the files one by one (e.g. __init__.py
, manifest.json
, vacuum.py
) and copy its contents to files with the same name within a folder named exactly like the platform. In this case: roomba/__init__.py
, roomba/manifest.json
, etc. If there is a translations
folder, you can copy only the languages that are relevant to you.
TIP: Clicking âRAWâ and then cmd+S or cntrl+S may make this process easier as you can either copy or simply download the files with the right name.
Once you have a folder with all the files in the component, see next section on what to do with it.
Uploading as a custom_components
Regardless of what method you use to download it, you should have now a folder called like your platform. In our case, roomba
.
Simply, add the platform folder to your custom_components
on your system. Your component is now downgraded to support YAML.
However, before restarting, keep reading as you may need to update the configuration.
Make Changes to the Configuration
You have just downgraded your component to an older version. It is possible that the configuration.yaml
requires to be downgraded as well. How to know this?
The documentation for the components lives within a different component called home-assistant/home-assistant.io
. Access it and navigate to source/_integrations/ and click the file with the platform name you want (e.g. roomba.md).
What you are seeing is the current configuration of the component. What we want now is to revert to the point in history where we downgraded our component. For this, we will go again to History and find the change before our config_flow.py
was added. In our case, it was April 11. Click on [<>]
button, to revert the component to that point in history.
Once again, you will be taken to the root directory. Navigate again to source/_integrations and open the platform.md file that you want.
Scroll down to the Configuration section and compare.
TIP: Click in RAW to read it clearly.
For example, in the case of roomba
, I had to change from:
# Example configuration.yaml entry
roomba:
- host: IP_ADDRESS_OR_HOSTNAME
blid: BLID
password: PASSWORD
to:
# Example configuration.yaml entry
vacuum:
- platform: roomba
host: IP_ADDRESS_OR_HOSTNAME
username: BLID
password: PASSWORD
The change from platform (e.g. roomba
) to generic device (vacuum: - platform: roomba
) may be common; but do note that there might be other changes too. For example, here blid
was the new name for the former username
and had to revert it.
Delete existing integration
Once you have downgraded the component by adding it to custom_components and updated the configuration, your YAML configuration and component are ready.
Before restarting, you should remove the existing configuration to avoid conflicts. Navigate to Configuration > Integrations. Find the integration you want click the 3 vertical dots and click Delete.
Restart core system
Once the old (new?) UI integration is deleted. You can restart your system. Your YAML configuration should be working now.
(Optional) Upgrade system
Once you have migrated all the components that you want, you can freely upgrade your home-assistant and your components should still be working as YAML. If new components were migrated to YAML, you may need to repeat this process for all your components.
(Optional) Manual maintenance
Once you do this, your components will be reverted to old version. Most of them will work as is, however, some may require or could benefit from some maintenance. This is especially true if you want to keep upgrading Home-Assistant.
The most common maintenance that I encountered is migrating from Device to Entity. For example, in the case of roomba I had to change:
from homeassistant.components.vacuum import VacuumDevice
class RoombaVacuum(VacuumDevice):
to:
from homeassistant.components.vacuum import VacuumEntity
class RoombaVacuum(VacuumEntity):
Other optional improvements could involve migrating from setup_platform
to async_setup_platform
to improve system performance.
Now, you are in control of what happens with your components
Risks
-
In general, having old and outdated components is not a recommendable thing to do. However, compared to not updating your whole system, not updating certain components is a lesser security issue and might be preferable.
-
This solution is based on the fact that (1)
custom_components
load before core components and (2) setup_platform and other YAML methods are not meant to be deprecated as per this blog post. If this changes in the future, there will be no way to have YAML components at all. -
As you are reverting to an older point of history, your components will no longer update and receive improvements or broken changes. For example, imagine that roomba changes its API endpoints. This will completely break the component. (However, this is also true if youâre not updating your system). If you want the best of YAML Configuration, while having updates, you will need to create the custom_component yourself. You can read an example on this PS4 experiment.
Thank you!
PS: Copy of this post in Github repository as an experiment, with showcase of code.