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.
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’).
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).
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 :
the device_tracker for Fortigate firewall is ok, though I don’t know why ! It looks like it doesn’t work in 0.92 but as it started to work with no reason in 0.91, it might work then… (I have other problems preventing upgrading to 0.92 now). For this one, I juste moved it from"device_tracker/fortios.py" to “fortios/device_tracker.py” and created an empty init.py
the climate “beok” component works, looks the same, didn’t make it in 0.92, works in 0.91 ? As I have lots of Broadlink devices, I created a new “beok” folder (instead of “broadlink”) in which I’ve put the files from github. I works, but I’m not sure why neither !
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.
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:
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:
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?
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
because it doesn’t work anymore from 0.87 on
I did all the things that I read but I think that some piece need to be rewritten perhaps.
What do you think? Is there someone that could help me?
Thank you so much
Igor
