Discussion: keep midea_ac_lan or rename to midea_lan

[wuwentao]

Device type and model (or SN)

none

The description of new feature

Hi friends

@rokam @chemelli74 @Necroneco @Qianli-Ma

After some consideration, I think we should discuss with this naming issue at early.

First of all, when we started to maintain midea_ac_lan repo, we were unsure who would help us with this forked repo. We just wanted to fix some bugs and try to continue improve it. Fortunately, we have many members contributing code to this repo now, really thanks for all of us.

I know we still have a lot of mypy/pylint/unit test/code coverage issues that need to be improved,
based on our plan and future goal: to integrate with Home Assistant core and rename to midea_lan when we commit to core, so we should consider the naming issue at early.

As @rokam mentioned in the Discord group, midea_ac_lan also is no only for AC now. it should be rename to midea_lan and using new name for us in future.

There is more issue with current forked repo:

1. it can't show our contributors list
2. new PR will default goto the origin upstream repo georgezhao2010/midea_ac_lan, we need to manual select it
3. we have add more tools like pre-commit/lint rule/mypy/etc, @chemelli74 did most of the work
4. current repo Issue/PR/Star/commit history still increasing
5. the most important is : if we want to integrate with core, and rename to midea_lan, we need migrate old midea_ac_lan domain user data to midea_lan doamin, if we do it later, we may lost more repo contributors/commit history.
6. doc update/bug track/feature request in future

@rokam has finished deattach the core device lib to midea-local repo with pip package, any suggestion and comments?
I'm really sorry for these inconveniences with current forked repo, we should have a plan for it.

• Solution 1: rename to midea_lan with a new repo
  try to migrate old midea_ac_lan domain user data to new midea_lan doamin, then migrate to new midea_lan repo. we should do it at early, if we directly going to core with midea_lan, we may miss more user data and cause incompatibilities, we should finish most of the migration before we commit, using two domains in HA core may not be approve in code review.

• Solution 2: do nothing, continue using midea_ac_lan in future and always using fork repo mode, no any changes.

• Solution 3: continue using midea_ac_lan, but remove current repo and reinit it with latest codes, manual save issue/bug list for future track, PR/commit history/repo star will be miss, start a new repo without fork mode for future.

most of us did so many contributing to current midea_ac_lan repo and our future goal, so please add your comments and suggestion with this naming issue, then we can know where we will go in future.

not use Discord and just using GitHub Issue to discuss it, as most of us not in same timezone, it's a most important changes for us and future plan.

Thanks

[Necroneco]

Is it possible to migrate user data to a new domain?

[wuwentao]

Is it possible to migrate user data to a new domain?

I think it should be possible:

1. history data saved in /config/home-assistant_v2.db, it's sqlite3 db, basic docs can be found at Database
2. midea_ac_lan integration cache data, such as accout.json/device_id.json saved in /config/.storage/midea_ac_lan/ using domain name, source code can be found in config_flow.py, it's easy for us, we can directly process with both old and new domain when we doing migrate and changes.

also did some grep check:

 # cd /config
config # grep -rl "midea_ac_lan" .
./home-assistant_v2.db
./configuration.yaml
./home-assistant.log
./.storage/core.entity_registry
./.storage/core.restore_state
./.storage/core.config_entries
./.storage/core.device_registry
./.storage/hacs.repositories
./.storage/core.logger
./.storage/hacs.data
./custom_components/hacs/utils/default.repositories
./custom_components/midea_ac_lan/manifest.json
./custom_components/midea_ac_lan/const.py
./home-assistant.log.1
config #

[Necroneco]

You mean modifying these files manually?
or just create a new domain, but it can access the old domain data to rebuild the same entities?

[wuwentao]

You mean modifying these files manually? or just create a new domain, but it can access the old domain data to rebuild the same entities?

1. for json file: we can use config_flow.py to check old domain dir and rename it to new domain dir name , maybe HA web UI option can be provide to user and automatic finish it after got confirmation, no need to do any file changes, just domain dir name changes.
2. for device history data in sqlite3 db: I'm not sure, need more check if we plan to do it, if it's necessary, maybe we can provide a migrate.py script to operate sqlite3 db and finish the domain name update.
3. we only need to update domain name, no anyd device data or file content changes, like dir rename.

[Necroneco]

for 2. maybe not possible. For example, I did not use home-assistant_v2.db, I used a postgresql on the network.
for 3. What will happen to the currently configured devices and entities?

[rokam]

I think we should rename only when ready to merge core. Thats due to brand repo require of images. Othetwise the integration will miss images.

[Necroneco]

Add brand image is easy.

I think the main question is whether we should consider migrating user data and whether we can easily complete the migration.

[wuwentao]

I think we should rename only when ready to merge core. Thats due to brand repo require of images. Othetwise the integration will miss images.

directly rename and commit to core will cause all the old domain users lost the devices, configs and old history.
all the setup will be start from zero like the first time setup

[wuwentao]

for 2. maybe not possible. For example, I did not use home-assistant_v2.db, I used a postgresql on the network.

for 3. What will happen to the currently configured devices and entities?

oh, for Q2, like home assistant, it don't care about db type, we can use sqlite/postgresql, only the connection type/mode/args diff in configs, finally, it will using the same SQL syntax and same table name to store our data to different DB, sqlite3 can be the default option.

for Q3, domain name changed, there is no any impact for saved devices and device entries, this is what we should do in config_flow.py, as code controlled in our midea_ac_lan or midea_lan custom integration, we should process it with right during config steps, once config finished,old devices should works well in new format.

[Necroneco]

So, what does a typical migration process look like?
The user starts with a midea_ac_lan, then adds a midea_lan, then removes midea_ac_lan, and everything is OK?

[chemelli74]

I'm checking if there is a helper to migrate domain for an integration.

[rokam]

To spice it up a little. On core we might need to create pseudo integrations for other brands, so when the user search brand "Midea" or "Electrolux", they will receive the correct result.
I think that migrating is part of moving to core. Maybe we use midea_ac_lan to migrate the config entries to the new midea_lan from core.

[chemelli74]

BTW, we should enable discussions on the repo instead of using issues ;-)

[chemelli74]

We have a nearly ready PR , #159, that will migrate all 3 categories:

• config entry
• device entries
• entities entries

so keep all historical data.

I think we are quite ready to rename this repo and hopefully merge the PR right after ( hassfest failure was suggeste dis due to this inconsistency).

[wuwentao]

We have a nearly ready PR , #159, that will migrate all 3 categories:

• config entry
• device entries
• entities entries

so keep all historical data.

I think we are quite ready to rename this repo and hopefully merge the PR right after ( hassfest failure was suggeste dis due to this inconsistency).

Idon't test it now, but before I want to test it, seems I found there is some more issue:

1. now, we have renamed the domain name and renamed the dir name. also include migrate the entries/devices.
2. once we installed it midea_lan.zip via HACS custom repo, then we need to reboot HA.

After reboot:
issue 1: there is two integration exist, old domain should have the old configs/entries/devices, it still there, only device_id migrate pass.
issue 2: new domain start, but it can't found any available entries/device, so the migrate job will can't works.

so, we should have both domain to work at the same time to finish the migrate:

1. we need to start it from old_domain, and it should have a fixed new_domain nam, and try to confirm whether it can update the entries/device in current old_domain to a new_domain..... I'm not sure, we may need to check HA async_update_entrity source code to confirm it.
2. once we convert all the entries/devices in old domain, we may need to uninstall old midea_ac_lan, install with midea_lan, confirm whether it can found the old entries/devices/configs.
3. so current repo may used for finished the migrate jobs only.
4. then we can install new files from new repo https://github.com/wuwentao/midea_lan with new domain, and just load the old entries/devices. no any addition migrate job exist.
5. or you have any good solution?

anyway current migrate solution may not work as our expected.

in addition, for migrate configs, #86 should works well, you can check with it for reference, #86
we can defined both domain in const.py and try to use it for migrate base job for new domain.

[rokam]

I've tried to show that this approach has issues without success. With this approach, to be able to migrate the user will have many needed interventions, and those could cause system disruption.

I believe that the migration repair should be in the midea_lan integration and not on midea_ac_lan. So, when the user installs midea_lan, the user will be prompted to migrate the configs from midea_ac_lan.
Then, the repair will migrate data and erase midea_ac_lan entries.

After this, the midea_ac_lan will be useless.

That should be inside the core integration, forcing only one migration of the user configs.

[wuwentao]

thanks @rokam for your suggestion.

use new domain to check old entries/devices should ok, both solution should select one:

1. use old domain to migrate to new ,and remove old integration, reboot, work with new domain
2. use new domain to migrate from old, and remove old integration, reboot, work with new domain.

if we use solution 1: new domain will be clean and old domain will used as a bridge to finish the migrate job, it should be safe, as migrate can be finish it old domian, we can continue improve it with new domain changes, both migrate action and new action is split. but I'm not sure whether it can works, just a idea.

if we use solution 2: it should be easy and user can got prompt , to confirm migrate the configs/entries/device to current new domain, and how long we will keep this migrate jobs in new domain ? we should accept it and have a plan for it.
for example, if old user keeps in old HA version and midea_ac_lan domain, they don't upgrade, after some months, we removed it from new domain, they will missed the migrate window. but solution 1 should always available, and don't care about new domain changes.

@rokam @Necroneco any suggestion and idea ?

once we confirmed the solution, test pass with the basic process, we can add document/operation process to user in old domain repo and new domain repo.

[rokam]

For solution 1 and 2 we need to maintain the migration process. If we change something in the new domain it should be changed in the old one.
The migration should stop support in a specific momment. I dont think that solution 1 will always be supported.

[wuwentao]

For solution 1 and 2 we need to maintain the migration process. If we change something in the new domain it should be changed in the old one. The migration should stop support in a specific momment. I dont think that solution 1 will always be supported.

agree, we should stop migrate support in a specific momment.

solution 1 will keep new domain is clean and without any migrate jobs, all the migrate jobs keeps in old domain. it don't impact our future plan, for example, try to commit it to HA core.