Add new tomorrow.io integration to replace Climacell - Part 3/3

[raman325]

Proposed change

I will be merging this in pieces and then we will do one big merge once all parts are done.

This is part 3 of 3: Auto-migrate climacell config entries that are using the v4 API and semi-auto migrate ones that use the v3 API

ClimaCell as a company rebranded to Tomorrow.io right around when we introduced the climacell integration 🙃 After consulting some other members, I decided to build a new integration which is more or less a stripped down version of climacell (climacell supported two different APIs, this one only supports the one that's currently supported by the company). This overall effort is split into three separate parts to make it easier to review per Martin's suggestion:

• Part 1: Create new tomorrowio integration. This uses a new library but the underlying code in the library is the exact same as the v4 API logic in pyclimacell. Similarly the integration logic is a simplified version of the climacell integration since v3 is deprecated: Add new tomorrow.io integration to replace Climacell - Part 1/3 #57121
• Part 2: Remove config flow from climacell: Add new tomorrow.io integration to replace Climacell - Part 2/3 #57124
• Part 3: Auto-migrate climacell config entries that are using the v4 API and semi-auto migrate ones that use the v3 API: Add new tomorrow.io integration to replace Climacell - Part 3/3 #59698
• Final Step: Merge all three parts together into dev (this will include the documentation updates)

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

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

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:

• Documentation added/updated for www.home-assistant.io

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.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• 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:

• I have reviewed two other open pull requests in this repository.

[bdraco]

@raman325 Since we have a few of these that could use similar treatment, are you intrested in working on a more generalized approach to build helpers to migrate a domain?

We have at least the following that could use domain name changes.
august -> yalexs
hunterdouglas_powerview -> powerview
flux_led -> magichome
luftdaten -> sensor.community?
unifiprotect -> unifi_protect?
hassio -> supervisor

I'm thinking about some type of mapping file that gets auto generated maybe homeassistant.generated.renames that is used to map the old name to the new one.

If the integration is listed there the tooling would take care of migrating

• config entry
• device registry entries
• entity registry entities
• renaming the service calls with a warning thrown
• ????

-- Something to think about after beta wraps up

[raman325]

@bdraco I spoke about this with Frenck when I first went down this path. I agree that a more generalized solution would be great, but there were two things that held me back:

1. Deciding on a design for this feature. If it's purely a name change we can probably shortcut a lot of things. But in my case...
2. The logic has changed from the old integration to the new one. I suppose I didn't have to do it this way, but it felt like the cleaner approach for my use case because the new one has a lot less code.

I'd definitely be open to discussing this in more detail and brainstorming together if you are interested. send me a DM on discord and we can go from there (warning - I am on vacation and so may not be able to properly respond until next week

[bdraco]

send me a DM on discord and we can go from there (warning - I am on vacation and so may not be able to properly respond until next week

I'm happy to wait until you get back and beta is wrapped up so no rush!

[raman325]

Is there an implicit assumption here that we won't merge this and will instead target a more general approach? In the convo about cleaning up branches this came to mind 🙂

CC @bdraco @MartinHjelmare

[MartinHjelmare]

I think we can merge this.

[MartinHjelmare]

Is there a docs page already for tomorrow.io?

[raman325]

yes, this was originally all in one PR and here is the related docs PR: home-assistant/home-assistant.io#18916

Once we merge this, i will create a new master PR to merge climacell_to_tomorrowio into dev and will link the docs PR to that