Gree versati 3 integration

Hi everyone​:waving_hand:

I created a custom Gree Versati 3 Local integration for Home Assistant.

It connects directly over Wi-Fi using the device UDP JSON protocol, so:

  • No RS485
  • No Modbus adapters
  • No cloud dependency
  • Fully local LAN control

You can install it via HACS (Custom Repository).

GitHub:


Current features

  • Local UDP communication
  • Auto-detects ECB / GCM encryption
  • Config Flow (UI setup)
  • Polling via DataUpdateCoordinator (default 30s, configurable)

Entities:

  • Number: HeWatOutTemSet (20–60°C)
  • Sensors:
    • HeWatOutTemSet
    • WatBoxTemSet
    • TemUn
    • AllErr
    • Mod
    • Pow

Services:

  • gree_versati.set_param
  • gree_versati.get_params

It does not expose everything yet, but it already allows basic control and monitoring.

1 Like

Hi, thank you for your work. Yesterday, I tried to get a 16-byte AES key string from Versati 3, but unfortunately without success. I tried many methods, even with the help of AI, where we listened in on traffic using Python. Still no success. Do you know of any guaranteed method that works?

Hi @MarekBrz108
Did you try this command? What result did you get?

...gree-remote$ python3 PythonCLI/gree.py search -b <gree versati ip>
Searching for devices using broadcast address: <gree versati ip>
Search finished, found 1 device(s)
Binding device: <gree versati ip> (, ID: yyyyyyy)
Bind to yyyyyyy succeeded, key = xxxxxxx

Hi, yes, I tried countless times. I also tried to unpair from the GREE+ application and log in to the local wifi Versati 3, I also tried during the process of new pairing in the application, whether the path to the key is erased. And many other attempts with the help of AI. Still unsuccessfully searching for the key. The IP address of the communicator, finds the ID, but not the key. I keep reading the message:

Search finished, found 1 device(s)
Binding device: XXX.XXX.XXX.XXX (, ID: xxxxxx, encryption: GCM)
Device XXX.XXX.XXX.XXX is not responding on bind request

I even managed to add a device via the GREE A/C integration, where this device was found under the name GREE XXXX, of course the entities are not correct, but I thought that this integration got the required key. But when I looked in .storage and core.config_entries, the field under this device was empty, or rather there was literally this:

encrypted key: “:”"

Actually, I also didn’t get this result on the first try. You can also try:
python3 PythonCLI/gree.py search -b <subnet broadcast address>
or
python3 PythonCLI/gree.py search -b <gree ip> -i <id>

You may also want to search through the issues in this repository:

I didn’t reset my Gree Versati Wi-Fi module. It is still connected to the Gree+ app.

there are two versions of gree versati heat pumps: cloud-only and udp-available. I have four heat pumps and 3 of them are udp-available and for some reason fourth is cloud-only. I spent hours to find out why one of 4 HP isn’t being discovered by your integration, before I found this fork:

where owner explains this phenomenon. I vibe coded integration on top of this fork (this guy also provides one in neighbour repo, but for some reason it didn’t work for me) and now I have three pumps working from [sarunasr] integration and one based on my vibe-coded cloud-only integration. There’re pecularities and imperfections though:

  1. [sarunasr]'s integration doesn’t let me see temperatures and current state of heat pump - only control power and set temperature for heat and hot water (that’s enough for my goals but there’s a room for make it better
  2. My vibe-coded integration publishes tons of info on heat pump (I didn’t find out everything yert) but it works only for aforementioned one cloud-only device, doesn’t get MQTT update from devices which are available via UDP. I was unable to find out why and how Gree+ app get all four pumps in one place

However mixing these two approaches gives a result.

Hope this will help a little bit and save time for others

1 Like

@mphzack Thanks for the detailed explanation and for sharing your findings. This is very useful information for us and for others who might face the same issue.

Hi, first of all thank you for this integration — I installed it on my Versati III 10kW and local communication works perfectly, great work!

Currently the integration exposes the heating water setpoint (HeWatOutTemSet) as a Number entity, but not its cooling counterpart. Would it be possible to also expose CoWatOutTemSet as a Number entity, the same way as the heating one?

My use case: I have underfloor cooling, and during hot weather I need to dynamically adjust the cooling water setpoint based on the dew point calculated in Home Assistant (from temperature/humidity sensors in each room). The goal is an automation that keeps the leaving water temperature at dew point + 2 °C, which maximizes cooling without any condensation on the floor. This is a fairly common need for anyone running a Versati with radiant floor cooling in summer.

If other cooling-related keys are easy to add at the same time (e.g. cooling mode status), that would be a nice bonus, but CoWatOutTemSet alone would already unlock the automation.

I’m happy to test a beta version on my unit and report back. Thanks a lot!

Hey, I just added it. Could you please try again now?

Hi, thanks for your answer !
There is a problem, this is not an integration bug. Reads work perfectly end-to-end (values changed on the panel propagate to HA and CLI). But writes never reach the mainboard: both the integration and the gree-remote CLI get their value cached by the WiFi module (readable back for ~1 min), then it resyncs to the unit’s real value. Nothing ever changes on the panel. Weather-dependent mode is off. Next I’ll test whether the official Gree+ app can change the water setpoint — if it can, I’ll capture its packets to compare the write format.

Final update — confirmed hardware/firmware limitation, not an integration bug: the official Gree+ app has the exact same behavior: it can read water temperatures and setpoints, turn the unit on/off and change mode, but it cannot modify the water setpoints either. So the Versati WiFi module simply doesn’t support writing water setpoints to the mainboard. Nothing to fix in the integration — maybe worth documenting the setpoint entities as read-only for Versati units. Setpoint control appears to only be possible via the Modbus RTU interface.

On my own Versati the heating water setpoint writes work fine from Home Assistant, so the WiFi module does support setpoint writes — the limitation you hit is specific to your unit’s configuration, not the integration. The most likely cause: the leaving-water setpoint is only writable when the unit controls by leaving water temperature . If it’s set to room-temperature control or has the weather-compensation/climate curve active, the mainboard computes the setpoint and ignores manual writes — which matches exactly what you saw (value cached ~1 min, then resyncs). Can you check your control-type setting on the panel? For your underfloor-cooling dew-point automation you’ll want fixed leaving-water-temperature control. The CoWatOutTemSet entity is in place, so once the unit is in the right mode it should work the same as heating does for me.

Hi, actually, I had to change the control mode from ‘room temperature’ to ‘water temperature’ and disable the ‘water rule’.

So I can confirm that everything is OK – using Home Assistant’s automation, I’m controlling the water temperature based on the house’s dew point, so I shouldn’t have any more condensation on the tiles with these high.
Thank you very much for your work :wink:

1 Like