Skip to content

Conversation

MartinHjelmare
Copy link
Member

@MartinHjelmare MartinHjelmare commented Aug 20, 2020

Breaking change

Proposed change

  • Add ozw websocket command to do zwave to ozw migration.
  • Add zwave websocket command to start a ozw config flow at the import step with zwave config data.
  • When the migration is done:
    • Entity ids, names and icons in the entity registry should be migrated.
    • Device name_by_user and area_id in the device registry should be migrated.
    • The zwave config entry should be removed.

TODO

  • Migrate device registry data.
  • Remove zwave config entry on migration completion.
  • Warn user if zwave present in configuration.yaml.
  • Fail zwave setup if migration is done and ozw is setup.
  • Create frontend part.

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

# Example configuration.yaml

Additional information

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • The code has been formatted using Black (black --fast homeassistant tests)
  • Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

  • No score or internal
  • 🥈 Silver
  • 🥇 Gold
  • 🏆 Platinum

To help with the load of incoming pull requests:

@probot-home-assistant
Copy link

Hey there @home-assistant/z-wave, mind taking a look at this pull request as its been labeled with an integration (zwave) you are listed as a codeowner for? Thanks!
(message by CodeOwnersMention)

@probot-home-assistant
Copy link

Hey there @cgarwood, @marcelveldt, mind taking a look at this pull request as its been labeled with an integration (ozw) you are listed as a codeowner for? Thanks!
(message by CodeOwnersMention)

@cgarwood
Copy link
Member

We'll also need to check if they have a zwave: section in configuration.yaml - as it will try to re-import that as a new config entry on the next HA restart

@MartinHjelmare MartinHjelmare marked this pull request as ready for review August 31, 2020 18:22
async def async_migrate(hass, migration_map):
"""Perform zwave to ozw migration."""
dev_reg = await async_get_device_registry(hass)
for ozw_device_id, zwave_device_id in migration_map["device_entries"].items():
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we migrating info between devices instead of merging them ? A device can be linked to multiple integrations: https://developers.home-assistant.io/docs/device_registry_index

Calling dev_reg.async_get_or_create with identifiers of both devices will link them up. We find by identifier first, so you just call dev_reg.async_get_or_create with the Z-Wave device ID first, so it gets OZW one added. Then delete OZW device ID.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(this works too, so fine with it)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'd have to look up the device identifiers first to do that, right? So it looks like the current way is easier.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you will need to find both entries first anyway.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should apply this suggestion to solve the migration of device actions etc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've decided to not add more to this migration, consider the recent move with zwave_js.

@MartinHjelmare MartinHjelmare marked this pull request as draft November 11, 2020 11:32
@MartinHjelmare
Copy link
Member Author

MartinHjelmare commented Nov 11, 2020

We'll wait to merge until we have confirmation from frontend that we have all that is needed in the backend.

CC @bramkragten

@MartinHjelmare
Copy link
Member Author

I'll need to look into the meter and notification command class migration. It doesn't work consistently for all users.

@MartinHjelmare MartinHjelmare marked this pull request as ready for review January 7, 2021 16:12
@MartinHjelmare MartinHjelmare merged commit 8b72324 into dev Jan 9, 2021
@MartinHjelmare MartinHjelmare deleted the add-ozw-migration branch January 9, 2021 14:23
KJonline pushed a commit to Pyhass/core that referenced this pull request Jan 9, 2021
* 'dev' of https://github.com/home-assistant/core: (98 commits)
  Bump pymyq to 2.0.13 (home-assistant#44961)
  Add zwave to ozw migration (home-assistant#39081)
  Add pressure forecast to HA weather entity model (home-assistant#44965)
  Deduplicate MQTT entity discovery code (home-assistant#44970)
  Fix parameters when toggling light (home-assistant#44950)
  Move MQTT entity helpers to separate file (home-assistant#44838)
  Helpers type hint improvements (home-assistant#44964)
  Remove script/test (home-assistant#44967)
  Add MQTT Number (non optimistic) (home-assistant#44883)
  Fix Netatmo climate boost for valves (home-assistant#44957)
  Disambiguate Supervisor HTTPUnauthorized on user/password validation (home-assistant#44940)
  Add torrent id to Transmission events (home-assistant#44187)
  Prefix versions in system health (home-assistant#44921)
  Fix media renderers without volume control (home-assistant#44874)
  Fix wait_template incorrectly matching falsey values (home-assistant#44938)
  Upgrade youtube_dl to 2021.01.03 (home-assistant#44942)
  Upgrade discord.py to 1.6.0 (home-assistant#44941)
  Fix KNX cover state return open when unknown (home-assistant#44926)
  Use parent_id to find cause of logbook events with new contexts (home-assistant#44416)
  Implement support for additional ecobee hold modes (home-assistant#40520)
  ...
@sbruggeman
Copy link

Is it possible that this PR is causing the behavior that is being seen in this issue? #46679

If so, I think this is an edge case where this is a breaking change for the zwave component.

@frenck
Copy link
Member

frenck commented Feb 24, 2021

@sbruggeman Please do not use handled PRs for handling issues. There is an issue, that is sufficient. Thanks 👍

@home-assistant home-assistant locked and limited conversation to collaborators Feb 24, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants