Anti Direct Blow is marked unavailable when its current value is 0

[vaL1nna]

Bug description

The integration uses the current AntiDirectBlow value to infer whether the device supports the feature. For a device that supports the feature but currently has it turned off, the local status query returns 0. The detection code treats this as false and sets _has_anti_direct_blow = False, so the switch becomes unavailable after setup/reload.

Turning the feature on in Gree+ makes the query return 1; after reloading the integration, the same switch is detected and becomes available.

Reproduction

1. Use a Gree AC that supports Anti Direct Blow and add it through the config flow.
2. Turn Anti Direct Blow off in the Gree+ app.
3. Reload the Gree integration (or restart Home Assistant).
4. Observe that the Anti Direct Blow switch is unavailable.
5. Turn the feature on in Gree+, then reload the integration.
6. The switch becomes available and the local status contains AntiDirectBlow=1.

Actual behavior

GreeGetValues(["AntiDirectBlow"]) returns the scalar 0 when the feature is supported but off. In custom_components/gree/climate.py, the current truthiness test therefore takes the else branch:

if anti_direct_blow:
    self._has_anti_direct_blow = True
else:
    self._has_anti_direct_blow = False

This conflates a supported capability with its current disabled state.

Expected behavior

The entity should remain available for a supported device regardless of whether its current value is 0 or 1. A successful reply should be distinguished from an unsupported/missing field.

A possible direction is to test for a returned value rather than truthiness, e.g. anti_direct_blow is not None (while retaining appropriate handling for a missing/unsupported field).

Environment

• Home Assistant Core: 2026.8.1
• Integration: Gree A/C 3.6.0
• Device: Gree KFR-35GW/NhHf1BAj
• Device firmware: V1.14
• Local connection: UDP/7000, direct IP configuration

Related historical report: #182

[p-monteiro]

Maybe @RobHofmann can give more input on this for the current version. I remember there was a commit that changed this to do an "auto" feature check that introduced the problem you're reporting. The issue is that the API is generic in the sense that the devices will answer with a value of 0 even if the unit does not support the feature.
For a future version (no ETA), this is already solved, since the features will be configured by the user.

[vaL1nna]

Thanks for looking into this and for the detailed explanation. I appreciate your attention and the clarification. I’ll look forward to the future version with user-configured features. Thank you!

[RobHofmann]

@p-monteiro in all honesty: I do not know. My devices don't support this feature, so someone else has developed this at some point (I assume @domialex has refactored this).

However, feel free to make a PR onto main if you want. As @p-monteiro, a future version does this a bit different and therefore would solve this.

[domialex]

I also don't have that feature so I can't test it.

[p-monteiro]

There's not much to test. The device replies with the status property, whether it supports it or not, so checking feature availability based on the property value/presence, as is done now, will not have the intended results. Honestly, just wait for vNext, or if you really need the feature from HA, maybe try another integration.