Turning off the light entity can stop an active boiling cycle

[notabene00]

Summary

Calling light.turn_off for the main SkyKettle light entity can stop an active boiling or heating cycle.

We encountered this because a Home Assistant automation turned off all lights in the kitchen area when room presence disappeared:

action: light.turn_off
target:
  area_id: kitchen

The SkyKettle device belongs to the kitchen area, so Home Assistant included its main light entity in the service target:

light.skykettle_rk_g210s_light

Although this light entity was already shown as off while the kettle was boiling, its async_turn_off() method was still called. This caused the entire kettle to switch to off and immediately stopped heating.

Environment

• Kettle: Redmond SkyKettle RK-G210S
• Firmware: 3.8
• Integration version: 2.7
• The same relevant async_turn_off() implementation appears to still be present in version 2.8

Observed behavior

We captured two occurrences in Home Assistant state history.

Occurrence 1

19:50:29.100531
Kitchen presence: on → off

19:50:29.701713
Kettle switch: on → off
Water temperature: 50°C

The kettle stopped approximately 0.60 seconds after the absence automation called light.turn_off for the kitchen area.

Occurrence 2

19:51:06.933408
Kitchen presence: on → off

19:51:07.553106
Kettle switch: on → off
Water temperature: 64°C

The kettle again stopped approximately 0.62 seconds after the absence automation ran.

A separate normal completion at 100°C worked as expected, so the 50°C and 64°C transitions were premature shutdowns rather than completed boiling cycles.

Relevant code

The behavior appears to originate in custom_components/skykettle/light.py:

async def async_turn_off(self, **kwargs):
    """Turn the light off."""
    _LOGGER.debug(f"Turn off ({self.light_type}): {kwargs}")
    if self.light_type == LIGHT_GAME:
        await self.kettle.set_target_mode(STATE_OFF)
        self.on = False
    self.hass.async_add_executor_job(
        dispatcher_send,
        self.hass,
        DISPATCHER_UPDATE,
    )

For the main light entity, async_turn_off() unconditionally calls:

await self.kettle.set_target_mode(STATE_OFF)

It does not first check whether the kettle is currently in the light mode managed by that entity.

Consequently, calling light.turn_off while the kettle is in Boil, Heat, or Boil+Heat sends a command that switches off the complete kettle operation.

Expected behavior

Turning off the main light entity should not interrupt an active boiling or heating mode.

Before sending STATE_OFF, the implementation needs to check that the current or target kettle mode is actually the light mode represented by this entity.

Reproduction steps

1. Assign the SkyKettle device to a Home Assistant area.

2. Start boiling through switch.kettle or water_heater.kettle.

3. While the kettle is still heating, call:

   action: light.turn_off
   target:
     entity_id: light.skykettle_rk_g210s_light

   Alternatively, call light.turn_off for the whole area containing the kettle.

4. Observe that the active boiling cycle stops before the target temperature is reached.

---

Hermes Agent, running GPT-5.6-sol, helped trace this from the Home Assistant automation down to the relevant integration code. The investigation and final write-up were reviewed and verified by a human.

[notabene00]

Possible Home Assistant-facing model

The underlying problem seems broader than adding a condition to light.turn_off.

The kettle protocol stores heating and decorative lighting in the same mode field:

• Off
• Boil
• Heat
• Boil + Heat
• Game
• Lamp

The protocol effectively treats a lamp as a kind of water-heating operation. Home Assistant does not need to expose that hardware detail directly to users.

Water heater

The water_heater entity should only represent operations that affect the water:

• Off
• Heat
• Boil
• Boil + Heat

Protocol modes Game and Lamp should appear as off from the water-heater perspective, because the heating element is not active.

Turning off the water heater should stop an active heating mode only. It should not turn off decorative lighting.

Decorative light

A single light entity can expose the decorative modes as effects:

• Static → protocol Game
• Cycle → protocol Lamp

Static supports color and brightness. Cycle supports brightness while the device controls the color sequence.

If heating starts while the light is on, Home Assistant can preserve the requested light state as pending. Once the device has actually returned to protocol Off, the decorative mode can be restored.

Calling light.turn_off during heating should only cancel that pending request. It must not send the shared protocol-level Off command and interrupt heating.

Main switch

The current main switch should follow the same semantic boundary.

At the moment, its on state means that the shared protocol mode is not Off. As a result, the switch is also shown as on when Game or Lamp is active, even though the kettle is not heating.

Turning this switch off also sends the shared protocol-level Off command, so it turns off the selected decorative light mode as well as boiling or heating.

The cleanest option would be to remove the main switch entirely:

• water_heater controls heating;
• light controls decorative lighting;
• configuration switches remain available for sound and other device options.

If the main switch is retained for compatibility or as a quick-boil control, it should follow the heating contract:

• report on only for Boil, Heat, or Boil + Heat;
• start an explicit heating mode when turned on;
• send protocol Off only when stopping an active heating mode;
• never turn off Game or Lamp.

After heating reaches confirmed Off, the light entity may restore its pending decorative mode if one exists.

This keeps the protocol’s shared mode register inside the integration and presents Home Assistant users with separate, predictable controls for heating and light.