Skip to content

[DNM] Gree Integration rewrite#373

Draft
p-monteiro wants to merge 110 commits intoRobHofmann:masterfrom
p-monteiro:gree-rewrite
Draft

[DNM] Gree Integration rewrite#373
p-monteiro wants to merge 110 commits intoRobHofmann:masterfrom
p-monteiro:gree-rewrite

Conversation

@p-monteiro
Copy link
Copy Markdown
Contributor

@p-monteiro p-monteiro commented Sep 23, 2025

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.

- Change config flow to: be multi step and allow setting the device features; allow to reconfigure an entry
- Separate HA and Device API logic: device API is now declarative and handles device behaviour. HA entities expose the device
- Implement a coordinator
- Async device communication
- More error handling
- Move consts around
- Proper error report on config_flow
- Proper translations on config_flow
- Configuration of timeout
- Fetch device info during binding
@p-monteiro
Copy link
Copy Markdown
Contributor Author

@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
Copy link
Copy Markdown
Contributor

@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
Copy link
Copy Markdown
Contributor Author

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
Copy link
Copy Markdown
Contributor Author

@ChillingSilence, packet capture would be the best way if you actually know how to do it. I'm not good at it.

@ChillingSilence
Copy link
Copy Markdown

It looks like it's still doing stuff on UDP port 7000? All the five packets are pretty much the same
image
The actual commands afterwards from "the cloud" seem to happen on TCP port 1982.

Is this helpful as a starting point thought @p-monteiro ?
Grateful for your assistance, thanks again 🙏

@p-monteiro
Copy link
Copy Markdown
Contributor Author

@ChillingSilence It's performing the normal {"t":"scan"} broadcast. What is the device sending back after those?
src: 192.168.22.120 dst: 192.168.22.86

Also, I would prefer not to pollute this PR with this since it is unrelated to it. Open a new issue, and we can continue discussing there.

@p-monteiro
Copy link
Copy Markdown
Contributor Author

p-monteiro commented Mar 26, 2026

@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))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants