fix: complete VRF device_info fix started in #338 — sub-units still share one HA device - #454
Conversation
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.
|
Looking for people who can test this one (I don't have this feature) |
|
@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. |
|
@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 — 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! |
|
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. |
…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.
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_infoused_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_idinclimate.pyto use_sub_mac_addrbut leftdevice_infoinclimate.pyand bothunique_id+device_infoinentity.pystill using the gateway MAC.Changes
climate.py:device_infoidentifiers now useself._sub_mac_addrinstead ofself._mac_addrentity.py: both_attr_unique_idanddevice_infoidentifiers now useself._device._sub_mac_addrResult
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
GR-Gcloudtype) with 5 indoor units, sub-MACs insubMAC@gatewayMACformat