GeezerVison

Summary

• Conditionally include device_on: True in the set_device_info payload from set_brightness(), set_color_temp(), and set_hsv() — only when self._device.is_on is already true.
• Fixes silent command failure on devices that treat power state and brightness/color as independent parameters (confirmed on Tapo L900-5 LED strip), without regressing Regression? Latest kasa cli turns light on when setting brightness. #1532 (changing brightness on an already-off device must not turn it on).

Problem

Some Tapo devices (confirmed on the L900-5 LED light strip) do not implicitly turn on when receiving brightness or color commands via set_device_info. The device:

1. Accepts the KLAP command and returns success (error_code: 0)
2. Updates its internal state (reports device_on: true, brightness: 100 when queried)
3. But does not physically turn on the LEDs

This creates a "zombie state" where the device reports it's on but the LEDs are off. The state persists until the device is power-cycled. Since every protocol response indicates success, python-kasa (and Home Assistant) have no way to detect the failure.

Root cause

• Brightness.set_brightness() sent {"brightness": N} — no device_on
• ColorTemperature.set_color_temp() sent {"color_temp": N} — no device_on
• Color.set_hsv() sent {"hue": N, "saturation": N} — no device_on

Meanwhile, Light.set_state() always includes device_on in the payload, and works correctly.

Fix

Include "device_on": True in all three methods' set_device_info payloads, only when the device is currently on. This re-asserts the power state for the zombie-state case (the device thinks it's on, so the flag is still sent and the LEDs physically come up) while leaving a deliberately-off device alone.

This matches the spirit of set_state() (which sends device_on explicitly) without contradicting the "set brightness without turning on" use case from #1532 / #1066.

Testing

Tested on a Tapo L900-5 (firmware current, KLAP v2 transport) controlled via Home Assistant's tplink integration:

• Before fix: light.turn_on with brightness_pct=100 → device reports on, LEDs stay off
• After fix: light.turn_on with brightness_pct=100 → device reports on, LEDs turn on
• Stress test: 28 rapid-fire on/off commands (delays from 10s down to 0.1s) — all 28 physically executed correctly with the fix

Unit tests

New tests/smart/modules/test_light_device_on_payload.py parametrizes set_brightness, set_color_temp, and set_hsv over is_on=[True, False] and locks in:

• is_on=True → payload includes device_on: True
• is_on=False → payload omits device_on (no regression for Regression? Latest kasa cli turns light on when setting brightness. #1532)

Updated existing test_light_effect_brightness cases to force dev._info["device_on"] = True so the asserted payload is deterministic across fixtures (some have device_on: false baked in).

Closes the regression risk for #1532 / #1066.

🤖 Generated with Claude Code