[DNM] Gree Integration rewrite

[p-monteiro]

Caution

This PR changes the domain of the integration, so current users will lose their device configs!
The config schema also changed, so verify your YAML if you use it to configure the devices.
This no longer overwrites the official integration.

This PR introduces a rewrite of this integration. The main goal of this was to better align the integration with the Home Assistant (HA) development workflow with two main changes:

• Completely separate device API code from HA code
• Align with code style guidelines (mainly Ruff code formatting and full typing)

Breaking changes

• Major version bump
• New domain for the integration
• Configs have a different schema, devices need to be re-added
• Translations need to be redone (can use the old ones, but need to be migrated to the new template)

Features

• Device features are now user-configurable (automatic detection removed due to unreliable Gree API)
• Async device communication via DataUpdateCoordinator
• GreeDevice abstraction for device logic
• Auto Encryption support
• Expose all device sensors as entities
• Add device fault detection support
• Add diagnostics download for config entries and devices
• Add option to set device temperature units (device display)
• Add RestoreEntity support in ClimateEntity
• Auto recovery of device IP

Improvements

• Improve config flow with better validation and error handling
• Allow reconfiguration of config entries (e.g., device IP changes)
• Allow individual device removal
• Make entity restore behavior configurable
• Refactor Gree API to be fully declarative (remove string guessing)
• Improve API structure and reuse of logic
• Improve entity creation and organization

Fixes

• Improve error handling across config flow and entity setup

Known problems:

• Broken VRF Device Status (needs debugging, could be fixed later)

As you can see, there are a lot of changes, and I understand if this does not go through as is.

[p-monteiro]

@RobHofmann I was adding the temperature step back, but I'm not sure of its utility.
Is there any device that accepts non-integer ºC/ºF?

[domialex]

@p-monteiro
The temperature step should not be in the configuration entities anyways, it should be in the climate options. That was a mistake on my part.

[p-monteiro]

Hi @domialex, that's fine. I'm more interested in the real use case for it. Should it be locked to integers? I don't think any device supports half degrees or even 0.1 steps, as is the lower limit for the current slider...

[p-monteiro]

@RobHofmann I'm down to get this merged into a different branch and published as an alpha/beta version. Fixes can then be made against that. I'll let you decide whatever you deem fit for the project. Remember, this is a breaking update.
The only thing I prefer to do extra is to drop yaml config as per HA guidelines (https://github.com/home-assistant/architecture/blob/master/adr/0010-integration-configuration.md#decision), but I understand if you are against it.

Refer to the original PR message (#373 (comment))

[RobHofmann]

Hey! Im unable to discover my devices through this integration. I've created a fix for this on my own version yesterday:
0134bb7

Can you please include this in your setup too?

As for your comment on YAML: I'm not sure. I'm not using it anymore. But theres a big reason why I could see people wanting to use this: Configuration as Code --> Easier to save in a repository. Same with Infrastructure as Code. This also means you can version your configuration. Reason why i'm currently not using it anymore is because I need to test the config flow for the ingration, but for other components I use YAML as long as I can :). But tbh i'm not sure how other people look at this.

PS. I've started testing your release just now.

[p-monteiro]

@RobHofmann Hi, thanks for the notes. Keep testing and let me know whatever you need.
I'll remove my workflows for release and use yours, but I do advise keeping the validation ones.
Yes, I saw that commit. Looked good, so yes, I intend to integrate it as well. I'm gonna be busy in the next few days, but I should be able to do it next week.

As for the YAML, that's a good and valid point, though HA backups should address the issue. I'm just more comfortable following the official guidelines. But your call.

[RobHofmann]

@RobHofmann Hi, thanks for the notes. Keep testing and let me know whatever you need. I'll remove my workflows for release and use yours, but I do advise keeping the validation ones. Yes, I saw that commit. Looked good, so yes, I intend to integrate it as well. I'm gonna be busy in the next few days, but I should be able to do it next week.

You need to brief me on the validation part here. No hurry, let me know when you get it in :).

As for the YAML, that's a good and valid point, though HA backups should address the issue. I'm just more comfortable following the official guidelines. But your call.

Backups would be nice, but for a docker setup this is not a feature. I do have backups in place, but its all "self managed". I trust more in plain code "backups" to a repository where I can also use things like branching (and test on my dev machine etc). So in short: i assume powerusers have more benefit from the YAML than "regular" users. Normally i'd absolutely go "home assistant native", but so far I'm not really seeing solutions accros the board. This is why I want to keep the options open. For us it's easy to maintain YAML for now. If these challenges get solved in the future we can always drop it.
Right now, nothing is holding anyone back from not using YAML. You just have a choice now :).

[p-monteiro]

You need to brief me on the validation part here. No hurry, let me know when you get it in :).

It's just HACS and Hassfest validation to ensure integration quality.
Check the file and the related links: https://github.com/p-monteiro/HomeAssistant-GreeClimateComponent-Rewrite/blob/08402760b13fbba1f1474e79695846f00388f9e8/.github/workflows/validate.yaml

Backups would be nice, but for a docker setup this is not a feature. I do have backups in place, but its all "self managed". I trust more in plain code "backups" to a repository where I can also use things like branching (and test on my dev machine etc). So in short: i assume powerusers have more benefit from the YAML than "regular" users. Normally i'd absolutely go "home assistant native", but so far I'm not really seeing solutions accros the board. This is why I want to keep the options open. For us it's easy to maintain YAML for now. If these challenges get solved in the future we can always drop it. Right now, nothing is holding anyone back from not using YAML. You just have a choice now :).

I also have backups configured for my Docker instance, and they are automatic through the Backups page inside HA, but I do understand where you come from. That's fine, really. It requires a bit more code to do proper config validation, but that's all. It's done and working.