Hold VRF sub-unit UI state until gateway catches up; hide unsupported switches - #508
Conversation
|
I need some testers with VRF devices for this one! |
RobHofmann
added
help wanted
|
Hi @vellad1, @Ilya-Draigor and @ItayGo — you all run VRF setups. @RobHofmann needs a VRF owner to validate this PR. Could any of you give it a quick test and report back? Thanks! |
|
Hi @meirlo, 1. my VRF have 6 units but addon discovering only 5:"subCnt":6 is number of indoor units. 2. can't assign each unit to his own Area, when changing one of them, all units assigning to that area.Thanks, |
|
I upgraded to 4.0.6. Are the fixes in it? I'm not sure what exactly I need to test; happy to do so if you give me some directions. I have 2 VRF units. Both have 3 indoor units each. The Outdoor units are different models. |
|
i'm thinking i should remove all my gree and re-add them from scratch and automations etc. however i forgot the encryption key that i was using, where can i find it in the conf please? |
|
@vellad1 it should be auto discovered |
|
i went ahead and deleted one of the VRFs. yes enc key was discovered. but somehow and vrf added but no sub units added, trying to see what is happening. |
|
some more info, i did not put in an encryption key: Logger: custom_components.gree.gree_protocol Error fetching sub-device list for 502cc6bb65b6: -- Logger: custom_components.gree.gree_protocol All 8 attempts failed for 10.XXXXX:7000, but the device DID answer a plain discovery probe. The port is open and the device is speaking, so this is not a network problem -- the encrypted exchange is failing. Check the device key and the encryption version. WiFi module: hid=362001067012+U-W06AV30.bin, ver=V1.1.0.0. Original error: TimeoutError |
…rted switches Two VRF (multi-split) usability issues, both caused by the gateway caching each indoor unit's state and answering with a stale snapshot for a few seconds after a command. 1. Commands appeared to "bounce back". After setting e.g. a new target temperature, the next poll (up to 60s away) could read the gateway's old cached value and revert the UI. climate.py now remembers the options it just commanded and re-asserts them over the read-back until the device's own reported value confirms the change or an 8s TTL expires. Confirmation is checked against the value the device actually reported this cycle, not the optimistic overlay, so a genuinely-rejected command is not forced forever. A one-shot delayed refresh (~2s) also lets the UI confirm the change quickly instead of waiting for the next scan interval. The pending refresh handle is cancelled on entity removal. 2. Non-functional switches were shown. Many VRF indoor units return an empty string for properties they do not implement (Lig, Health, StHt, ...). A real, supported property comes back as an integer. switch.py adds a _prop_supported() check so xfan/lights/health/powersave/eightdegheat/ sleep/air are hidden when the unit reports the property as empty after a successful sync. State is left untouched until the first sync so nothing flickers on startup. Standalone (non-VRF) units are unaffected: they report real integers, so the switches stay available and the pending overlay simply confirms on the next read.
7b808b0 to
db53f5f
Compare
|
Thanks so much for chiming in and taking the time to test @Ilya-Draigor — really appreciate it! 🙏 Quick heads-up: the two issues you hit aren't actually covered by 4.0.6, which is why you still see them:
To test everything together, I've put all three fixes on one branch. Could you try this build? |
|
Thanks a lot for jumping in and helping test @vellad1 — much appreciated! 🙏 One important thing: 4.0.6 doesn't include these PRs yet. The error you saw — Could you try this combined build (4.0.6 + all VRF fixes)? If sub-units still don't show up, a debug log would pinpoint it — add to logger:
logs:
custom_components.gree.gree_protocol: debugand share the |
|
@meirlo Installed it. The A/Cs were not detected on a discover VLAN/subnet section. I tried both network CIDR and I also wrote the IPs directly in the VLAN/subnet section. I then tried to adding one of the VRFs manually. I entered IP and MAC (the real mac without the @) - it added the device but couldn't turn on the climate entity - stuck to zero. Logs for subnet discovery:
Below logs when i added VRF1 (4.103) manually. I entered name, ip, mac (real - no @). Left else empty and enc was 1.
|
|
@vellad1 great news — I found the root cause from your logs. Your GR-Gcloud (V3.2.M / W06) only answers a I've updated #507 to send subList in that encrypted form. I confirmed it on my own module too — it returns all sub-units the same way — so this should fix your "gateway added but no sub-units". Could you re-pull the combined build and try again? (Same link — just re-download, it's been updated.) After restart, re-run discovery. Your gateways should now expand into their 3 indoor units each. If you enable One heads-up: don't add the gateway MAC manually — that creates a dummy climate entity that stays at zero (the gateway itself isn't an indoor unit). Let discovery add the sub-units for you. Thanks a lot for the detailed logs — they made this easy to pin down! 🙏 |
|
@meirlo thank you for you contribution! from log: Discovered gateway 9424b8fd5ba3 (subCnt=6) |
|
Hi @meirlo I updated but I am having the same issue; could it be that in the latest zip you included the wrong files? |
|
@vellad1 update on your W06 module — I figured out what was going on. The gateway encrypts the
Earlier builds only handled the first case, so even when a module answered the second form the reply came back as garbage (the Could you re-pull the same combined build and try discovery once more? (Same link — it's been updated.) With If neither appears, please paste the |
|
@Ilya-Draigor thanks again — your logs helped me understand the protocol much better. Quick recap: your gateway answered on the device-key form and returned Could you re-pull the same build and run discovery once more? (Same link — it's been updated.) With If |
|
still fails; i am really sorry - i hope i'm not doing something wrong myself |
|
@vellad1 no need to apologise at all — your logs are exactly what we needed, and they've answered the question. The new build now tries both request forms, and your gateways answered neither — every attempt timed out, on both the device-key and the generic-key form: Binding and status/command requests work fine on your gateways, but the Two questions/suggestions:
Thanks again for the thorough testing — it's genuinely helpful for making this robust across modules. 🙏 |
I don't believe it ever did.
Yes, I can add them manually as subMAC@gatewayMAC. That's how i was working before. I tried it again now and I can add them individually. Before all this I had 'reverse-engineered' it manually using the UDP Sender but it has been quite some time. However I just found some random notes that I am pasting below in case it gives you some indication on how I was getting the sub-units. |
|
@meirlo Thanks !!! |
|
some more notes i found; with remarks: |
|
@vellad1 those notes are the missing piece — thank you, this is exactly what I needed! 🎯 Your W06 module doesn't use the We'd only ever been sending Could you re-pull the same build and run discovery once more? With I'm expecting your two gateways to finally list their 3 units each via the |
|
Great news; they are now being shown :) Well done and Thank you!! 
|
|
@Ilya-Draigor 🎉 excellent — 6 of 6! And it confirms exactly why the union matters: Each form returned a different set of 5, so neither alone was complete — merging them by MAC recovered the full 6. Really glad it's all showing now, and thanks a lot for the patient back-and-forth and logs. 🙏 @vellad1 fantastic — and this one's down to your reverse-engineering notes. Your W06 needed the |
|
@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. |
Since #508, the xfan, lights, health, powersave, 8 degC heat, sleep and air switches took their availability from `_device_online`. With "Disable Available Check" on, the climate entity never sets that field, so it stays None and the seven switches were unavailable for good. The climate entity itself stayed available, because its `available` checks the option first. `_prop_supported()` now uses the climate entity's `available`, so the switches follow the same rule as the climate entity.
#508 re-applies the commanded values over the read-back for up to 8 s, so a VRF gateway's stale cache does not revert the UI. It did that for every unit. A standalone unit is read directly, and when it corrects a value it cannot take (for example an unsupported swing mode), it reports its own value. The hold then kept the refused value on screen for up to 8 s, where before the UI showed the corrected value at once. The hold and the 2 s follow-up read now only apply when the device is a sub-unit (sub MAC differs from the gateway MAC). Standalone units behave as before #508. The same change went into the 5.0 port (#522).
…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.
4 participants
Problem
On multi-split (VRF) setups the gateway caches each indoor unit's state and answers with a stale snapshot for a few seconds after a command. That surfaces as two annoyances:
Lig,Health,StHt, …), yet the switches are still exposed and do nothing.Changes
climate.py— hold commanded state until the device confirms~2 sdelayed refresh lets the UI confirm quickly instead of waiting for the next scan interval. The handle is cancelled on entity removal.switch.py— hide unsupported switches_prop_supported(): a supported property comes back as an integer; empty string /None/ missing after a successful sync means the unit doesn't implement it.xfan/lights/health/powersave/eightdegheat/sleep/airare hidden accordingly. State is left untouched until the first sync so nothing flickers on startup.Scope / safety
Standalone (non-VRF) units are unaffected: they report real integers, so switches stay available and the pending overlay just confirms on the next read.
Related
Part of a small VRF series (see #507 for reliable VRF discovery, and #454 for per-unit
device_info). Independent of both — can merge in any order.Testing
Tested on my own setup:
subMAC@gatewayMACform).Verified on the 4 indoor units: changing target temperature / mode no longer bounces back to the gateway's stale cached value on the next poll, and the change is confirmed in the UI within a couple of seconds. Switches the units don't implement (e.g. lights/health) are correctly hidden after the first sync, while the switches they do support remain available and functional.