Skip to content

fix: complete VRF device_info fix started in #338 — sub-units still share one HA device - #454

Merged
RobHofmann merged 1 commit into
RobHofmann:masterfrom
ItayGo:fix/vrf-device-info
Sep 23, 2026
Merged

RobHofmann merged 1 commit into
RobHofmann:masterfrom
ItayGo:fix/vrf-device-info

Conversation

@ItayGo

@ItayGo ItayGo commented May 22, 2026 •

Copy link
Copy Markdown

Problem

For Gree multi-split VRF gateways (one WiFi module controlling multiple indoor units, e.g. GR-Gcloud), all indoor units were grouped under a single shared HA device. This made it impossible to assign individual units to different rooms/areas.

Root cause: device_info used _mac_addr (the gateway MAC, shared by all sub-units) instead of _sub_mac_addr (the unique per-unit sub-MAC).

This is a continuation of #338, which fixed unique_id in climate.py to use _sub_mac_addr but left device_info in climate.py and both unique_id + device_info in entity.py still using the gateway MAC.

Changes

  • climate.py: device_info identifiers now use self._sub_mac_addr instead of self._mac_addr
  • entity.py: both _attr_unique_id and device_info identifiers now use self._device._sub_mac_addr

Result

Each VRF indoor unit appears as its own separate HA device and can be assigned to its own room/area independently.

Migration note for existing users

If you already have a multi-split VRF setup configured, after updating you will see a lingering ghost shared device (the old combined device with the gateway MAC). HA will keep it around because it was previously in your device registry.

To clean it up: go to Settings → Devices & Services → Devices, find the old shared Gree device (it will have no active entities), and delete it. The 5 individual devices will remain unaffected.

Tested on

  • Gree VRF gateway (GR-Gcloud type) with 5 indoor units, sub-MACs in subMAC@gatewayMAC format
  • Home Assistant OS 17.3 / HA Core 2026.5.3

In a multi-split setup (subMAC@gatewayMAC), all indoor units share
the same device_info identifier (the gateway MAC). HA treats them
as entities of one single device, so assigning the device to an
area moves all units together — it is impossible to put each unit
in its own room.

The same bug affects unique_id in GreeEntity, which also used the
gateway MAC, causing entity conflicts across units.

Fix: use _sub_mac_addr (the indoor unit MAC) as the device
identifier and unique_id base in both climate.py and entity.py.
Each indoor unit now registers as its own independent HA device
and can be assigned to a different area individually.

Note: after deploying this fix, delete the old shared ghost device
that HA will leave behind in Settings > Devices.
@RobHofmann

Copy link
Copy Markdown
Owner

Looking for people who can test this one (I don't have this feature)

@meirlo

meirlo commented Sep 18, 2026

Copy link
Copy Markdown
Contributor

@RobHofmann I can confirm this one works. Tested on a Gree GR-Gcloud VRF gateway fronting 4 indoor units (v1/ECB, current HA stable): after applying it, each indoor unit shows up as its own HA device and can be assigned to a separate area independently. No issues found — good to merge from my side.

@ItayGo thanks for this fix! I've built two related VRF PRs on top of the same setup — #507 (reliable discovery of all sub-units) and #508 (stops commands bouncing back on stale gateway reads + hides switches the units don't implement). If you have a moment, would you be willing to test them on your VRF gateway too? Extra confirmation on real hardware would help them land.

@meirlo

meirlo commented Sep 23, 2026

Copy link
Copy Markdown
Contributor

@RobHofmann summary across the VRF series — all three PRs are now validated on real hardware by VRF owners:

The three are independent and additive, but together they make VRF/multi-split work end-to-end. Testing surfaced real module variance that #507 now handles (different sub-enumeration commands — subList vs subDev — and gateways returning a partial list per form, so results are unioned by MAC).

Given the confirmations from multiple VRF owners, would you be open to reviewing/merging the set? Happy to rebase, split, or adjust anything you'd like. Thanks!

@RobHofmann
RobHofmann merged commit 9ffa6a8 into RobHofmann:master Sep 23, 2026
@RobHofmann

Copy link
Copy Markdown
Owner

https://github.com/RobHofmann/HomeAssistant-GreeClimateComponent/releases/tag/4.0.7

Thanks for contributing guys! amazing work!

I will do another PR towards the 5.0-dev branch for the future version with the same knowledge! Will ask you guys to help me test that one too later.

RobHofmann added a commit that referenced this pull request Sep 24, 2026
…until confirmed (#522)

* VRF gateways: ask all sub-device list forms, hold sent values until confirmed

Port of the VRF fixes that landed on master in #507 and #508. #454 needs no
port: 5.0 already gives each indoor unit its own device.

Sub-device list: a gateway answers one or more of three request forms,
depending on its WiFi module firmware (device key, generic key, subDev).
The old single hybrid form was never confirmed on hardware. V1 gateways
now get all three forms and the lists are joined by MAC; V2 gets the
device key form. The generic key form is encrypted with the device key
but answered with the generic key, so request_json() takes an optional
response_cipher. Gateways from a scan are handled side by side. On the
GR-Gcloud V3.2.M gateway from #507 the forms gave 4, 3 and 4 units,
joined 4.

Stale state: a gateway answers from a cache for a few seconds after a
command, so the read right after it showed the old value again. The
device state now holds sent values until the device reports them, for at
most 8 s. The coordinator polls again every 2 s while values are held. A
standalone unit confirms on the first read and gets no extra poll.

Suite: 247 passed (227 before).

* Only hold sent values for VRF sub-units

The stale cache was only seen on VRF gateways. For a standalone unit a hold
has a cost: when the unit corrects a value it cannot take, for example an
unsupported swing mode, it reports its own value, and the hold kept the
refused value on screen for up to 8 s. Standalone units now behave as they
did before the hold.

To find out whether a standalone unit or the MQTT transport caches too,
every device now logs at debug level when the read right after a command
does not report the sent value, with the transport and whether it is a
sub-unit.

Suite: 249 passed.

* Send the generic-key sub-device list request with the generic key

The generic-key form is answered with the generic key, but its request used
the bound device key, so transport.request_json() needed a separate
response_cipher for this one case. A probe on a GR-Gcloud V3.2.M gateway
(PR 507) showed the gateway ignores the request pack of this form: device,
generic and random keys all got the same answer, 3 units, readable with the
generic key. The request now uses the generic key too, and response_cipher
is removed again. The form stays in the union, because it adds units on some
gateways.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

help wanted Extra attention is needed to test This issue needs testing

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants