1
2
3
I’m a bit late with this, but apart from comment 1 above which I accept is slightly subjective how can anyone not agree with comments 2 and 3? Frankly I’m amazed that such a generally ‘professionally’ run project like this has no way for the ordinary user to track what has changed (broken their system) and when.
Ok thanks… I begin to understand how to make it work. Not how it’s supposed to work (and why this changed), but never mind, I’ll see that later.
Basically, I should just change directory structure, add an empty __init__.py in each folder and pray it works !
I rely on custom component for device tracking and heating, so I’d rather have this working !
And if it doesn’t, time to restore a snapshot !!
@k8gg As far as I know Paulus will update the information on that topic, but as far as I know as a general rule of thumb, if you don’t modify a component like for example hue or mqtt which have several platforms, just create a new folder for your custom version and add an empty __init__.py. Also don’t override the built in components but rather create <config>/custom_components/<my_darksky>/sensor.py for example. I hope this helps.
@klogg If you read the changelog for each release you haver a pretty good overview of what has changed, I don’t see what that is not sufficient? Add an individual changelog
to each platform is a lot of overhead in my opinion. The docs should present the state that things are not how they once were in my opinion.
@Mister_Slowhand The reason this was changed is to not break a users modified version by changing any of his dependencies. That is why you’d have to copy tho whole directory if you want to modify something like netatmo for example. Good luck with your migration. And don’t hesitate to ask for help.
I think the reason people find this ‘insufficient’ is that it means reading through all the changelogs for all components for all upgrades since your installed version (ignoring for now the idea that not keeping up to date with latest releases might not be in some peoples opinion the best course of action).
I can’t argue with that, but from the outside, one compromise solution would be to simply keep a copy of the previous version of the docs. Again from the outside it seems that all that would require would be a simple file copy before updating? (I admit to having little experience of maintaining documentation on a project this size so I apologise if this isn’t sensible).
Again, I can’t disagree with you here but still think the docs for such a ‘fluid’ project should provide some (simple) way to see what has changed and when.
You points are all valid and I understand that it can be frustrating, I’ve had some of that issues myself. But people (not necessarily you, you probably are aware of that) need to keep in mind that this project is still pretty young, the core developers are not that many, it is not a commercial product and practically still in beta. A lot of things like better usability or user management and a more powerful permission systems have just been recently introduced and do still need work. All in all we can say HA is powerful and evolving fast, I don’t know of any home automation platform out there that has such a vast pallet of products it can work with and a generally super helpful community around it. We all want it to evolve further and improve upon what has been built but we have to accept that things will break from time to time. People (again not you) have to either deal with it or just use something else.
But back to the original topic, HA provides many ways it can be modified and extended beyond what is already built in. The changes recently made should ultimately lead to a more stable world of custom components since they can’t be easily broken by upstream changes. But it also means that the one who modifies components need to take care of things themselves and implement possible upstream changes into his own component.
Sorry if I’ve gotten a bit of track there. 
The last part is optional and not altogether effective. You could try burnt offerings … but they make a mess of the keyboard.
Probably the most succinct description of how to adapt custom components for the “Great Migration”!
The “don’t override the built in components” is the strategy I chose for my two custom components which are enhancements to MQTT climate and alarm_control_panel. I christened this approach “derivation”, meaning to derive a new platform (“my_mqtt”) based on an existing one (“mqtt”). It makes for the easiest installation but has the disadvantage of not benefiting from future improvements to the “Great Migration” (because it still functions like a ‘partial overlay’).
If you have created a custom component that overrides an existing component then you have (at least) three ways of installing it in 0.89. This post contains a summary of the three approaches.
I must admit I’m a little confused about
__init__.py
Maykar for example has not redone his custom components and also a couple of other authors and none of them are using that file at all… so As I had already moved the folder structure around and created the dummy file, I just deleted it again and it seems to work equally well with or without that file… I’d be curious to know why and under what circumstances that file makes a difference…
FWIW, there’s no empty __init__.py file in the directory (my_mqtt) containing my customized versions of MQTT climate and alarm_control_panel components. Seems to work well with 0.89.1 and I haven’t had any surprises (yet).
There must be a reason for having one … maybe my use-case is an exception (or it defaults to … something).
From my understanding that needs to be there for initialization of the python component. After it is initialized in would guess it could be removed.
I deleted the other files it then creates in a sub-directory as well so I don’t think so. Also when I first moved things around, I didn’t create one… it was only after I read you were supposed to I did that… Then the component devs didn’t use them either so I removed them. Anyway, as I said, I’m confused by this ‘requirement’
for that specific component. As I said even the devs for components I use don’t use that in their updated instructions. One of 5 does but the others happily work without it. Hence my confusion.
Ok, I’ve started the great migration… And it’s gonna be a long path I’m afraid !
My main custom components work now :
My big problem is with the custom_ui extension, thus the “customizer” component. I don’t know what to do with this ? As it’s only a customizer/__init.py__ file ? Any idea ?
Customizer works now, it was in custom_components folder, created a sub-directory with the files in it. There’s no “platform” so the content is the __init__.py file.
Dear @balloob
Could you please help me?
I have problems with my custom_components that is this one:
RelayMaster switch platform for Home Assistant. Contribute to trisk/switch.relaymaster development by creating an account on GitHub.
I’ve already asked to Alber Lee @trisk to fix his custom component to fit with the great migration and he told me he did it moving the tree in this way, from this:
custom_components/relaymaster/binary_sensor/relaymaster.py
custom_components/relaymaster/sensor/relaymaster.py
custom_components/relaymaster/switch/relaymaster.py
to this:
custom_components/relaymaster/binary_sensor.py
custom_components/relaymaster/sensor.py
custom_components/relaymaster/switch.py
or this:
custom_components/switch.relaymaster/binary_sensor.py
custom_components/switch.relaymaster/sensor.py
custom_components/switch.relaymaster/switch.py
but it doesn’t work, the system tells me:
Integration relaymaster not found when trying to verify its switch platform.
Integration relaymaster not found when trying to verify its binary_sensor platform.
Integration relaymaster not found when trying to verify its sensor platform.
I put an empty init .py in the same folder like I red here:
How to “package” custom_components Configuration
You should also be able to use something like from .spaclient import SpaClient I saw a change not too long ago where they moved all the components to use relative imports. The advantage is that if you were to submit this as a core component, you wouldn’t have to adjust the imports.
but it doesn’t work anyway.
Is someone able to help me please?
thank you
Igor
You will probably need to create a manifest.json file for it. See here for some info on how it is done. Try creating one like the ‘minimal example’.
Thank you, but I saw the link you told me and it’s clear said:"…except for custom components."
so it’s not my case
I know, but it has been the only way to fix a number of custom components so far so I wouldn’t worry about that comment. It was the only I was able to fix at least two custom components…
Give it a try and see what happens, worst case scenario, it doesn’t fix it
I try it, this is my file manifest.json:
{
“domain”: “relaymaster”,
“name”: “Scheda Relaymaster”,
“documentation”: “https://github.com/trisk/switch.relaymaster”,
“dependencies”: [],
“codeowners”: [],
“requirements”: []
}
but it doesn’t work 
@sparkydave @trisk @balloob do you think the proble could be this?: