The Great Migration


#21

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


#22

The last part is optional and not altogether effective. You could try burnt offerings … but they make a mess of the keyboard.
:wink:

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.


#23

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…


#24

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

custom_components-my_mqtt

There must be a reason for having one … maybe my use-case is an exception (or it defaults to … something).


#26

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.


#27

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’


#28

Seemed to work for this user… Logitech Harmony removes local API


#29

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.