Skip to content

Briefing: Diagnose Inovelli Spotlight Switch hold-dim failure

You are an Opus 4.8 diagnostic worker. Use high / ultra reasoning. Be rigorous and adversarial about your own conclusions. This problem has resisted a full day of fixes, so do not trust surface-level "success" responses.

The problem (one line)

ONE Inovelli VZM31-SN Blue Series 2-1 dimmer will NOT drive hold-to-dim, while four identical VZM31-SN switches on the same ZHA network dim natively.

Devices

  • BAD: "Inovelli Studio Spotlight Switch", ieee f0:44:d3:ff:fe:6d:a6:9e, HA device_id ef0bf00129adf141b45610199ca29a0d, entity prefix spotlight_switch. Drives 8 Philips Hue LCG007 (Signify) spots = ZHA group 4 studio_spotlights_zigbee (members at endpoint 11), HA group entity light.krystal_s_office_sonoff_dongle_plus_mg24_studio_spotlights_zigbee.
  • GOOD reference: "Inovelli Studio Recessed Switch", ieee f0:44:d3:ff:fe:6d:e0:e7, device_id e69fff3a3030fa05e89bdc0637adcc12, prefix inovelli_studio_recessed_switch. Drives 8 cans = ZHA group 16 studio_recessed_zigbee.
  • 3 more working VZM31-SN in the kitchen (Counter, Island, Recessed).

Access

  • HA REST + WS at http://192.168.86.180:8123. Long-lived token in ~/.forge-secrets/wellness.env and in forge/memory/general/reference_ha_api.md.
  • ZHA WS commands used so far: zha/devices, zha/groups, zha/group/add, zha/group/members/add, zha/groups/bind, zha/groups/unbind, zha/devices/reconfigure, zha/devices/bindable, config/device_registry/list, config/entity_registry/list, trace/list, trace/get, blueprint/list, subscribe_events (zha_event).
  • Full prior context: forge/memory/general/home-assistant.md (sections: "Studio Inovelli switch", "Two-switch split", "FIRMWARE GOTCHA") and forge/memory/daily/2026-06-29.md (multiple checkpoints).

How the WORKING switches function (mechanism)

  • Smart Bulb Mode ON. Tap on/off is handled by an fxlt ZHA blueprint automation (fxlt/zha-inovelli-vzm31-sn-blue-series-2-1-switch.yaml) reacting to zha_event; the automation sets the bulb group to 3100K/80% on tap-up and off on tap-down.
  • Hold-to-dim is PURE Zigbee group binding, device-to-device, no HA: the switch's OnOff (cluster 6) + LevelControl (cluster 8) OUT clusters at endpoint 1 are bound to the bulb ZHA group. On hold the switch multicasts Level commands straight to the group.

What was already tried on the BAD switch (all failed to fix hold-dim)

  1. zha/groups/bind to group 4 (and re-pushed many times) — returns success:true every time.
  2. zha/devices/reconfigure.
  3. Physical air-gap (reboot).
  4. OTA firmware update 0x01020303 -> 0x01020304 (now MATCHES the working recessed switch).
  5. Full copy of all 42 config params (smart_bulb_mode on, output_mode Dimmer, local_protection off, all dimming/ramp speeds identical to recessed).
  6. FULL factory reset (up-paddle + config button ~20s to red) + re-pair: LQI improved 68->108, new nwk 55385, SAME ieee/device_id, name preserved. Hold-dim still does nothing after ALL of that.

Key evidence (do not re-derive blindly, but DO verify if cheap)

  • Bulb side is fine: HA group-cast to group 4 controls the spots (on/off + color temp work). So group membership on the Hue bulbs is correct.
  • Tap on/off works on the bad switch (because that path is the automation, not the binding). Triple-tap temp cycle works too (also automation).
  • Live zha_event capture (script was forge/.../scratchpad/zha_capture.py): on HOLD, the BAD switch emits stop on cluster 8; the GOOD recessed switch emits move_to_level_with_on_off [level, transition]. This is the crux: the bad switch sends STOP on hold instead of a move/level command.
  • Cross-test: binding the BAD switch to the proven-good group 16 ALSO failed to dim the cans. So the fault is the SWITCH, not the group/bulbs.
  • Anomaly: GOOD switch exposes number.inovelli_studio_recessed_switch_default_move_rate (=0). BAD switch's number.spotlight_switch_default_move_rate returns 404 / missing in /api/states. (Could be a disabled entity in the registry, or the LevelControl DefaultMoveRate attr 0x0014 not present/interviewed.)

Current state of the system (so you don't get confused)

  • Native binding has been REMOVED from the bad switch.
  • An HA-driven ramp-and-stop hold-dim is currently wired into the spotlight automation (id 1751240000001) via blueprint inputs button_2_hold -> script.studio_spotlight_dim_up, button_1_hold -> script.studio_spotlight_dim_down, button_X_release -> script.studio_spotlight_dim_stop. Untested. This is a fallback, not the goal.
  • Tap on/off + triple-tap Warm/Neutral/Cool work.

Your job

Find the REAL root cause and determine whether native binding can be made to work on this unit. Investigate deeply (read-only ZHA queries and attribute reads are fine; do NOT make changes that need Justin physically present without flagging them): 1. Read the actual Zigbee binding table on the bad switch (ZDO Mgmt_Bind_req via the ZHA gateway/zigpy if reachable, or HA device diagnostics). Confirm whether the group-4 bind (or ANY bind) is actually committed in the device's binding table vs. ZHA optimistically reporting success. Compare to the recessed switch's binding table. 2. Compare LevelControl (cluster 8) attributes between good and bad switch via ZHA read-attribute, especially DefaultMoveRate (0x0014), Options (0x000F), OnOffTransitionTime, OnLevel. Find any device-level attribute difference the HA entities hide. 3. Inspect endpoints / clusters / quirk_class / signature of both devices for differences. Check whether the bad switch's outgoing Level commands originate from endpoint 1 vs 2, and whether the bind endpoint must match. 4. Consider manufacturer-specific parameters (Inovelli params governing paddle/dimming behavior, Smart Bulb Mode interaction, button delay, or anything that would make it send Stop instead of Move on hold) that may differ at the raw attribute level even though HA entities look identical. 5. Conclude whether this is fixable in software or the unit is defective (RMA).

Search the Inovelli community / ZHA docs if useful (WebSearch/WebFetch). The fxlt blueprint and Inovelli VZM31-SN binding behavior are well-documented.

Deliverable

Write findings + a concrete recommended fix to forge/memory/handoffs/inovelli-spotlight-dim-diagnosis-2026-06-29.md (add the URL: header line). Notify when done. State your confidence level and what evidence would falsify your conclusion.