Is it possible to go back to the slider for on/off instead of a lightning bolt for on and off.
See:
My Yeelights are normal but the LimitlessLED ones are changed in 0.64 - Is this a customise function I can use?
You’ve always had to set assumed_state in customize to get toggles instead of lightning bolts.
I have never set assumed state anywhere (and don’t have now for Yeelights which are displayed normally). They have always shown toggles.
In that case they’re now being seen as switches instead, you could fix it like I said but there’s obviously something broken then.
Not broken, unfortunately intentional.
https://github.com/home-assistant/home-assistant/issues/12703#issuecomment-368698507
From 0.64 release notes under Breaking Changes:
LimitlessLED has been converted to assumed state. Will no longer turn the lights off when restarting Home Assistant. Will no longer revert changes made by other controllers. (@amelchio - #12475) (light.limitlessled docs) (breaking change)
The ‘assumed state’ is what has changed your sliders to lightning bolts.
You may be able to get around this by using a template_light to represent your LimitlessLED lights in the front end, and hide the Limitless in customize.
For the benefit of other readers, this is the trick to get the toggles back. If you only use HA to control your lights, this is a sensible thing to do:
homeassistant:
customize_domain:
light:
assumed_state: false
Can I customise just the Limitless LED Lights? I don’t need to screw with the Yeelights.
You need to screw them a little bit or they won’t go in the socket.
Individual entities can be customized but then you have to list each of them. However, the domain-wide change should not affect Yeelight because they are already not assumed_state.
1 Like
So… exactly what I said in the first place then 
Can you tell me why when I change the color temperature by clicking on the light under the light group (click on the lightning bolt) it just comes on in some random state and does not use the last set color temperature?
Further, if I have an automation like this:
- action:
- data:
brightness_pct: 75
effect: white
entity_id: light.lounge
service: light.turn_on
- data:
entity_id: light.lounge
kelvin: 2300
service: light.turn_on
alias: Turn Lounge Lights On
condition: []
id: '1'
trigger:
- entity_id: light.lounge
from: 'Off'
platform: state
to: 'On'
It turns the lights on in some cold white and then changes but if I include the Kelvin in the brightness command it is ignored? Actually it is probably ignoring the effect as well. My Json command originally read:
{
"brightness_pct": 75,
"effect": "white",
"entity_id": "light.lounge",
"kelvin":2300
}
But it ignores the temperature setting. A while back, if I had this JSON it actually set the lights to Blue which was the last color state I had used.
So I found it was ignoring the effect anyway.
Anyway, it would be super to find out what I am doing wrong here. In the frontend light panel I’d like to use the lightning bolt to turn the lights on white, 75% brightness and 2300 kelvin (or whatever was last set even) but it just does not seem to do that. I’d like to have the automation use just one action but it doesn’t seem to like that either.
Another side issue is that the 3100 kelvin in the Milight App seems to be the same color as the kelvin 2300 setting in Home Assistant.
Any thoughts?
A while back I had thought the issue was something I was doing was setting the bulb to a color mode and not white (and hence Kelvin was invalid) but I didn’t get any response at all when I asked about that.
Any advice welcome…
If you change to assumed_state: false will the lights go out with a reboot again? I was really happy that this finally wasn’t the case anymore.
Don’t know anything about these lights but could you just turn them on with a ‘normal’ scene in the automation rather than putting all that code in there.
My Yeelights behave themselves quite well in your scenario but that’s how I did it so they get an automatic reset if needed as well as making it easy to add to other automations etc.
Never noticed it have any effect on my setup other than getting the toggle in the front end.
The assumed_state setting only affects the UI button, it will not mess with the lights during reboot.
1 Like
Hi @DavidFW1960.
Home Assistant used to force its understanding of the state upon the light. It no longer does that.
If you set the light to green with Home Assistant and change it to blue with the MiLight app, Home Assistant will never now that the light is blue. Before, if you then turned the light off and on in HA, it would go back to green. Now, the color is not modified.
So HA now tries less to be clever and more to just do as it is told. That is a significant change and might require automation adjustments.
About your automation, you can remove the effect and the kelvin alone will turn the light away from color mode (this is also a recent change). I actually only have bulbs with a single white temperature so I cannot test what happens if you include both commands. I think it should work but maybe not.
This automation works for me (I also had to lowercase the state keys):
trigger:
- entity_id: light.test
platform: state
from: 'off'
to: 'on'
action:
- service: light.turn_on
data:
entity_id: light.test
kelvin: 2300
brightness_pct: 25
alias: Turn Lounge Lights On
condition: []
id: '1'
Yes, the Kelvin setting is not precise (this is not new). Home Assistant needs to know the actual Kelvin range of the bulb and that is not yet implemented. Do you know if different MiLight products have the same Kelvin range or will it differ between bulbs?
I’ll try your suggestion. However if I just use the lightning bolt to turn the light on and then off it comes back on with a totally different kelvin (much cooler) If I click on the bulb it seems to be right in the middle of the slider. The brightness % seems to be right and it also is not screwing with the colour anymore which is an improvement so it just seems to not be remembering the colour temperature.
It seems to me that the 2300 kelvin is 3100 in the milight app. (guessing/approximation). I have 2 RGBWW and also a bunch of RGBWW GU10 downlights and both of those seem to be around the same warmth.
EDIT: I tried it and it ignores the Kelvin. If I trigger the Kelvin again it’s changing the colour temperature.
I could but there does not seem to be any advantage in doing that to me?
I use scenes only when I want to turn multiple rooms on…
So turn_on with kelvin only works if the light is already on? That sounds like a bug :-/
It looks like the proper Kelvin range could be 2700-6500, in that case you should set kelvin: 2474 to get the 3100 from MiLight. I can change this but it will be a breaking change so I am a bit afraid that it will not be right and another breaking change will be needed.
Why do you say that? (You may well be right of course). It’s not really that important although it would be nice if the scales between milight app and HA agreed.
I have previously had trouble with the Kelvin setting - it seemed that using Kelvin triggered the light to colour mode. So every time I used it I ended up with Blue lights - removed Kelvin and they stayed white.
I’m happy to help by giving you feedback - but I’m on Hassio so it’s not easy to change stuff…