Light service called twice to apply light profile

Configuration
1

I’m having an issue where I need to call light.turn_on with a colour profile twice for the correct profile to be applied. This is using a TP-Link LB130 bulb. I can’t figure out whether I’m missing something in the docs, whether it’s an issue with the integration or the hardware.

My light_profiles.csv looks like this:

id,x,y,brightness
normal,0.323,0.329,153
night,0.701,0.299,5
security,0.323,0.329,255

Say for example the last used profile was security and the light is now off. If I turn it on passing (only) the night profile as a parameter, I need to call the service twice for the light profile to be applied.

My use case is to have this light turn on as a night light after bedtime when motion is detected. The problem is that if it is turned on otherwise, the normal profile gets used. Thus, when the night time automation is triggered the light turns on with the last profile used.

I can generally find little information on light profiles and would like to ask: Are light profiles my best option here?

I know I can use scenes (and have) but I have the same issue.

Here are my scenes:

scene:
  - name: Normal Foyer Light
    entities:
      light.foyer_light:
        state: on
        xy_color: [0.323, 0.329]
        brightness: 153
  - name: Night Foyer Light
    entities:
      light.foyer_light:
        state: on
        xy_color: [0.701, 0.299]
        brightness: 5
  - name: Security Foyer Light
    entities:
      light.foyer_light:
        state: on
        xy_color: [0.323, 0.329]
        brightness: 255

I’ve come across David’s post that says one can only use the attributes seen on the state object.

Here is my light’s state when on:

min_mireds: 111
max_mireds: 400
supported_color_modes:
  - color_temp
  - hs
color_mode: hs
brightness: 255
hs_color:
  - 0
  - 0
rgb_color:
  - 255
  - 255
  - 255
xy_color:
  - 0.323
  - 0.329
current_power_w: '1.0'
daily_energy_kwh: '0.000'
monthly_energy_kwh: '0.018'
friendly_name: Foyer Light
supported_features: 19
icon: 'mdi:dome-light'

So then I try to use only what’s stated under supported_color_modes. I tried using light.turn_on specifying only hue-saturation but still the same issue: I need to call the service twice.

I’ve called light.turn_on and scene.turn_on directly from the dev tools UI, scripts and automations. None of this seems to matter.

2

I’ve now taken some time to experiment with the pyHS100/Kasa lib/utility directly, read through the code, checked the reverse engineered protocol and tried a few things by hand (in case I find something undocumented).

I have established one needs to turn on the light first before changing the colour profile and that it’s a limitation of either the firmware and/or the hardware. It seems like one can send only one command at a time and that it’s not possible to send other commands with an “on” command.

Pity. This is profoundly annoying for such an expensive device and it seems like such a basic use case.

My workaround for now will be to create a wrapper script to toggle a device and accepting a colour profile. The script will turn it off when on, and when turning it on, only turn it on and then apply the colour profile (by turning it “on” a second time since there’s no service call to set a state).

This also means that it’s futile to set up default colour profiles – the bulb will simply apply it’s last state as the default.

3

can you change the color, and then turn it on?

what if you create a scene, does it work?

4

Unfortunately not. You can send the command and the device responds by saying it’s going to use the default values (which is the last on state). I did this directly via pyHS100.

Same issue: You need to first have the light on and then the scene will be applied when scene.turn_on is called or you need to call the latter twice.

5

So I was playing with the app for the Kasa bulbs and it seems that with the app you can turn on and color a bulb at the same time. So I’m thinking this issue is something regarding the implementation of the Kasa integration rather than a firmware/hardware issue.

To test this set a bulb to an easily recognized color, I chose red, and then turn it off. In Home Assistant because of the implementation you would have to turn on the bulb and then set the scene, which causes you to see the last on state.

But on the Kasa app you can go into the bulb settings where you can set the color you can then select any color on the color wheel and the bulb turns on as that color.

This suggests that there is some way to turn on a bulb and color it at the same time.

Edit: It appears the way Kasa accomplishes this is by setting the default state to the color you want to turn on and then turning on the bulb. Meaning the default state can be changed while the bulb is off.

6

Thank you for testing this. When I have time I’ll go dig in the code again to see what I can find. It could be a limitation of the library: I couldn’t get it to send multiple commands in one go (looks like it’s architected to send only one command so it will ignore the other). But, you have given me an idea: Can’t one then set the default before turning on from HA too and then turn it on?

7

If this is what is actually happening like I suspect then it should be possible to do in HA it is just a matter of sending everything in the right order. I haven’t had a chance to fully test this yet though since I don’t have a system with all the right tools setup will do more testing later once that is setup.

I’m unsure if HA is even aware of or able to change Kasa’s default parameters

Edit: Using GitHub - python-kasa/python-kasa: 🏠🤖 Python API for TP-Link Kasa Smarthome products I am able to send just a color command and the bulb turns on to the appropriate color.
Using HSV I can set the color and brightness of the bulb from the start.

Another Edit: It looks like there’s an option to specifically ignore turning on to the default state.

    async def set_light_state(self, state: Dict, *, transition: int = None) -> Dict:
        """Set the light state."""
        if transition is not None:
            state["transition_period"] = transition

        # if no on/off is defined, turn on the light
        if "on_off" not in state:
            state["on_off"] = 1

        # This is necessary to allow turning on into a specific state
        state["ignore_default"] = 1

        light_state = await self._query_helper(
            self.LIGHT_SERVICE, self.SET_LIGHT_METHOD, state
        )
        return

This bit of code is from how python-kasa handles turning on the light.

1 Like
8

This had an issue on github: TPLink Kasa Light Automations - Brightness setting doesn't work from light off state. · Issue #50115 · home-assistant/core · GitHub
Tested and fixed it here: Add tplink light setting ignore default by gabrialdestruir · Pull Request #50334 · home-assistant/core · GitHub

Just waiting for someone to approve it.

2 Likes
9

Excellent, thanks for all your work and findings on this. I see the issue was reported very recently on Github. I hope it will make it into a release very soon.

10

The fix has been approved so it should be soon.

2 Likes
11

I’ve been keeping a keen eye on the latest beta releases and haven’t spotted this yet. I really hope it goes in soon!

12

It seems like this issue is now resolved on 2021.7.4 (I upgraded from 2021.5.5). I can’t quite make out from the statuses of the Github issues mentioned which fixed it.