Skip to content

fix: clear value-list state when fan-level has value-range#1729

Open
Simonvoss97 wants to merge 1 commit into
XiaoMi:mainfrom
Simonvoss97:fix/fan-dual-fan-level-keyerror
Open

fix: clear value-list state when fan-level has value-range#1729
Simonvoss97 wants to merge 1 commit into
XiaoMi:mainfrom
Simonvoss97:fix/fan-dual-fan-level-keyerror

Conversation

@Simonvoss97

Copy link
Copy Markdown

Fixes #1728.

Problem

When a fan device exposes two fan-level properties on the same MiOT service - one with value-list (gear) and one with value-range (stepless) - the Fan entity ends up with mixed internal state:

  • _prop_fan_level correctly points to the stepless prop (per the existing precedence rule),
  • but _speed_names / _speed_name_map still hold the gear value-list from the earlier iteration.

The percentage property guards on if self._speed_names and self._speed_name_map, which stays truthy, so it goes down the value-list branch and calls self._speed_name_map[fan_level]. When the device reports a stepless level (e.g. 25 on xiaomi.fan.p76, 35 on xiaomi.fan.p70) the key isn't in the gear map and a KeyError is raised during async_write_ha_state -> state_attributes. The entity is stuck reporting unknown and can't be controlled.

Fix

Clear _speed_names / _speed_name_map in the value-range branch of Fan.__init__, so the percentage property falls back to ranged_value_to_percentage - which is what the in-code comment already promises ("Fan level with value-range is prior to fan level with value-list").

Reproduction

Devices affected (both verified locally):

  • xiaomi.fan.p76 - urn:miot-spec-v2:device:fan:0000A005:xiaomi-p76:1:0000D062
  • xiaomi.fan.p70 - urn:miot-spec-v2:device:fan:0000A005:xiaomi-p70:1:0000D062

Both expose fan-level at piid=4 (value-list [0..3]) and piid=5 (value-range [1,100,1]).

Verification

  • Before fix: fan.xiaomi_de_..._p76_s_2_fan was stuck in unknown; logs showed KeyError: 25 (or 35 for p70) in fan.py:314 whenever the device pushed a state update.
  • After fix + HA restart: state=on, percentage=10, preset_mode=Straight Wind, control works from HA.

Diff

                 if prop.value_range:
                     # Fan level with value-range
                     ...
                     self._attr_supported_features |= FanEntityFeature.SET_SPEED
                     self._prop_fan_level = prop
+                    # Clear any value-list state set by a previously processed
+                    # value-list fan-level prop, so that the percentage property
+                    # does not pick the value-list branch with a stale map.
+                    self._speed_names = []
+                    self._speed_name_map = {}
                 elif (
                     self._prop_fan_level is None
                     and prop.value_list
                 ):

When a fan device exposes two `fan-level` properties on the same
service - one with `value-list` and one with `value-range` - the
`Fan.__init__` would set `_speed_name_map`/`_speed_names` from the
value-list prop, then later let the value-range prop override only
`_prop_fan_level` (per the existing precedence rule). The stale
value-list state would still satisfy the value-list branch in the
`percentage` property, causing `KeyError` for any stepless level that
is not a key in the gear map. The exception propagates out of
`state_attributes`, so the entity is stuck reporting `unknown` and the
device cannot be controlled from HA.

Clear `_speed_names` and `_speed_name_map` in the value-range branch so
the percentage property falls back to `ranged_value_to_percentage`,
which is what the in-code precedence comment already promises.

Reproduces on xiaomi.fan.p76 and xiaomi.fan.p70 (both ship gear
fan-level at piid=4 and stepless fan-level at piid=5).
@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

3 participants