Possible migration from custom integration to core integration

[derjoerg]

As - at least from my perspective - the integration is "feature complete" 🥳 (only tests are missing) I wanted to start a discussion how a possible migration from a custom integration to a core integration might work.

I have to admit that I don't know very well the internals of HA so please forgive me, if I ask/write something obvious.

As pointed out by frenck the custom integration should have a different domain as the integration, which should be promoted for core integration.

So are the following high-level steps correct?

1. Fork the HA core repository and copy everything from abbfreeathome_ci into a folder under components called abbfreeathome and also change the domain from abbfreeathome_ci to abbfreeathome. Create a PR for that (also including a new brands-PR and a documentation-PR)
2. In the custom integration (not linked to the core integration) write "somehow" a detection method, which recognizes that the core integration abbfreeathome is available and create a repair issue
3. The repair issue now is responsible for:
   3.1. Load ALL data from the custom integration abbfreeathome_ci (basic config like host, username and password, but also all modifications like changed entity-names and -ids, icons, ...)
   3.2. Delete all data of the custom integration
   3.3. Save the loaded data to the new core integration abbfreeathome
   3.4. Inform the user that all data have been converted and the custom integration can be deleted

Is this correct so far and - much more important - doable?

The reason I'm asking this is that I'm really convinced from this integration and I - till now - don't see any problems in my test environment. So I plan to move this to my prod environment and replace the famous integration from jheling. But

• I have 82 devices with 260 entities
• I've done a lot of modifications in my prod environment regarding naming and so on
• I have a lot of switch-as-x entities
• I have a high number of automations referencing entity-ids
• I have a high number of dashboards referencing entity-ids

I need to modify everything by hand when moving from jheling to this integration and I'm fine with that, even that it will take me several hours.
What I don't want is to make now all these modifications when moving from freeathome to abbfreeathome_ci and than, once again, when moving from abbfreeathome_ci to abbfreeathome.

I have no glue for now how a possible detection method would look like and how a possible repair can be programmed, but I'm happy to help and test.

If this is - for whatever reason - not easily possible (what I can fully understand) but as I still want to use this integration in my prod environment, I will do the "dirty" way:

1. Download the custom integration abbfreeathome_ci
2. Save it in a folder called abbfreeathome within custom_components
3. Change the domain in const.py and manifest.json to abbfreeathome
4. Track any changes to the custom integration manually
5. Wait for the time the integration becomes a core integration 😃
6. Delete the custom component

This should not be offensive. The question was raised and my standpoint was overruled. That's how democracy and especially open-source should work.

[kingsleyadam]

I just wanted to bring this up as well. I'm curious if there's any other devices that need to be implemented (that we know of). If not then I'd like to create a 1.0.0 release and provide some cool-down time. Maybe 1-2 weeks to gather any feedback and make any changes for issues that might come-up.

I wanted to implement scenes, specifically the FID_SPECIAL_SCENE_PANIC and FID_SPECIAL_SCENE_ALL_OFF so I can run automations when those scenes are triggered. But unfortunately those scenes don't seem to come through on the websocket.

To attempt to answer some questions.

Fork the HA core repository and copy everything from abbfreeathome_ci into a folder under components called abbfreeathome and also change the domain from abbfreeathome_ci to abbfreeathome. Create a PR for that (also including a new brands-PR and a documentation-PR)

I wish it were that easy :). If we attempt to submit this entire integration in a single PR, it'll most certainly be rejected. It's way too much code for a single review. I'm sure there will be feedback. We need to break this down into smaller PR's, starting with the very basics required for the integration and a single platform.

On the initial PR we'll also need to submit documentation and logos.

I do already have the HA core repo forked. That's actually what I've been working in on all of these changes. After the cool-down period I can try to put together a first PR. Once that's merged in then we move onto the next PR, probably a PR per platform.

In the custom integration (not linked to the core integration) write "somehow" a detection method, which recognizes that the core integration abbfreeathome is available and create a repair issue

I don't think we'll have that ability to check if abbfreeathome is available in the core. I think both HACS and the core integration should exist and operate independently until all functionality is added to the core integration. My guess is we're not going to get everything added to core in a single release of HA. Once everything is added to the core we can mark this repo as archived and advise those to migrate to the core integration.

The repair issue now is responsible for:

Have you found any examples of thing being done? This sounds great but I have a feeling it's just goin to be up to the user to delete the custom integration, add the core, and make adjustments as needed. The entity id's should remain the same, any customizations made to the entities would need to be re-done.

If this is - for whatever reason - not easily possible (what I can fully understand) but as I still want to use this integration in my prod environment, I will do the "dirty" way:

Yep, that's totally doable, especially if we don't actually need many changes in the custom integration going forward (famous last words). Only issue you'll have is the logo won't appear which is purely cosmetic.

[kingsleyadam]

As an advanced topic - not so useful, but perhaps for fun - we can implement the virtualdevice API-call in the library and provide to HA a service to create specific virtual devices, e.g.

I was thinking the same. Maybe for a rainy day. :)

[derjoerg]

I also looked at the notification endpoint and I got it working through swagger. But the documentation is so ... non-existent and some of the options are totally unclear that I stopped for now.

[derjoerg]

And I agree with them. A large PR like this makes it impossible to fully review in a reasonable time. I don't want to make it more difficult for them. And I do want to make sure our code meets their standards.

As soon as you want to start, don't hesitate to come back to me. I will try to help as much as possible.

[derjoerg]

btw: I would go with the switch as first entity. It implements both directions (setting and getting) and is just one device.

[kingsleyadam]

As soon as you want to start, don't hesitate to come back to me. I will try to help as much as possible.

I've already got the basic integration stripped down and ready for a PR, but I wanted to write unit tests which are proving to be a bit more difficult than I thought.