[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...

[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.

[p-monteiro]

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?

While including this, I noticed that only the target host might be needed.
I have a Docker container with 2 networks (bridge and macvlan).
While only connected to the bridge, broadcasts to 255.255.255.255 obviously fail to find my devices.
However, all it takes is for me to enable the second network in HA settings, and the HA helper that I use to retrieve broadcasts gives me the generic one (255) and one for each network adapter. When performing discovery on those specific ones, it gets the proper replies with the socket bound to 0.0.0.0, so no need for a socket per interface.

@RobHofmann and anyone else, can you confirm if you can discover your devices when enabling the respective adapters in HA configuration?
your_ha_url/config/network

[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?

While including this, I noticed that only the target host might be needed. I have a Docker container with 2 networks (bridge and macvlan). While only connected to the bridge, broadcasts to 255.255.255.255 obviously fail to find my devices. However, all it takes is for me to enable the second network in HA settings, and the HA helper that I use to retrieve broadcasts gives me the generic one (255) and one for each network adapter. When performing discovery on those specific ones, it gets the proper replies with the socket bound to 0.0.0.0, so no need for a socket per interface.

@RobHofmann and anyone else, can you confirm if you can discover your devices when enabling the respective adapters in HA configuration? your_ha_url/config/network

Can you explain what your doing here? Im unsure what you are looking for here. I dont have any network configuration in my HomeAssistant at all. In the past I did use macvlan, but i switched to docker networks due to their more secure nature.

In my cross VLAN solution, its only needed to pass networks you want to scan (since scanning cross vlan is not a default option) cross VLAN. For the same subnet, it wouldn't require input.

[p-monteiro]

@RobHofmann Oh, so your HA Docker container is only connected to a single bridged Docker network? No macvlan or host networking, and you have no adapter directly connecting HA to the VLAN, right?
You should see the available networks/adapters in HA by going to Settings > System > Network and unticking Autoconfigure if required.

In your solution, does cross-VLAN broadcast work? Or is it the case that if a cross-VLAN is specified, it targets its individual hosts?