I suppose that’s possible. But you’re asking to implement workarounds to compensate for incorrectly working light platforms. If it were me, I’d be logging an issue on the offending light platform.
@pnbruckner you did understand correctly 
I know I cannot send those to the light from that page, but I tought the same payload would be accepted from the “turn_on” function, my bad
Regarding logging an issue, that’s where I am confused, who’s fault would this be?
I would say HA itself, not really the light, the light is a simple MQTT Light, so the light itself is not sending (as far as I am aware) that piece of information.
Well, I’m assuming you’re using an MQTT Light. I don’t use these, but browsing the docs, it seems you can control whether or not color_temp and/or rgb_color/hs_color/xy_color are used, and whether or not for each if HA updates the corresponding HA entity attribute based on incoming messages or via an optimistic mode. So, depending on how you have your MQTT light configured, and how the MQTT Light Platform code works, it seems it’s possible for the HA light entity’s attributes to possibly be set incorrectly (i.e., both color_temp and rgb_color/hs_color/xy_color, and for them not to agree.) I haven’t read the code, so I don’t know if the fault is the code, or your configuration.
Well the configuration is fairly “simple”
---
platform: mqtt
name: "Alarm Light"
command_topic: "cmnd/Alarm_Light/POWER"
state_topic: "stat/Alarm_Light/POWER"
payload_on: "ON"
payload_off: "OFF"
brightness_command_topic: "cmnd/Alarm_Light/DIMMER"
brightness_scale: 100
brightness_state_topic: "stat/Alarm_Light/RESULT"
brightness_value_template: "{% if value_json.Dimmer is defined %}{{ value_json.Dimmer }}{% endif %}"
rgb_command_topic: "cmnd/Alarm_Light/COLOR"
rgb_command_template: "{{ '%02X%02X%02X0000' | format(red, green, blue) }}"
rgb_state_topic: "stat/Alarm_Light/RESULT"
rgb_value_template: "{% if value_json.Color is defined %}{{ value_json.Color[0:2]|int(base=16) }},{{ value_json.Color[2:4]|int(base=16) }},{{ value_json.Color[4:6]|int(base=16) }}{% endif %}"
color_temp_command_topic: "cmnd/Alarm_Light/CT"
color_temp_state_topic: "stat/Alarm_Light/RESULT"
color_temp_value_template: "{% if value_json.CT is defined %}{{ value_json.CT }}{% endif %}"
effect_command_topic: "cmnd/Alarm_Light/SCHEME"
effect_state_topic: "stat/Alarm_Light/RESULT"
effect_value_template: "{% if value_json.Scheme is defined %}{{ value_json.Scheme }}{% endif %}"
effect_list:
- 0
- 1
- 2
- 3
- 4
availability_topic: "tele/Alarm_Light/LWT"
payload_available: "Online"
payload_not_available: "Offline"
qos: 1
retain: false
My idea that is sort of HA fault is because if I restart HA and turn on the light, HA doesn’t know the state of the lamp and it guess a simple “on” state, but with all those informations:
min_mireds: 153
max_mireds: 500
effect_list: 0,1,2,3,4
brightness: 255
color_temp: 150
hs_color: 0,0
rgb_color: 255,255,255
xy_color: 0.323,0.329
effect: none
friendly_name: Andrea Bedside Lamp
supported_features: 23
The light turn on Blue color, as per last color used but it doesn’t send to MQTT the current state informations regarding colors and such.
Another piece of information is that as soon as I use the color picker to select the color, the data changes to be:
min_mireds: 153
max_mireds: 500
effect_list: 0,1,2,3,4
brightness: 255
color_temp: 499
hs_color: 240,100
rgb_color: 0,0,255
xy_color: 0.136,0.04
effect: none
friendly_name: Andrea Bedside Lamp
supported_features: 23```
So this in my opinion exclude the lamp, because those information looks like are driven by the color picker rather then the lamp itself (or the MQTT Light configuration).
I might be wrong of course If you see something I missed in my config that’s wrong please do let me know
For now I can only say thanks for your time and effort on helping me
Andrea
Well, again, I don’t use MQTT at all, so I can’t really say. But if you don’t use color_temp when turning on the light, and you don’t care about color_temp, then I would suggest taking the corresponding three lines out of your mqtt light configuration.
Disabled those color_temp option
Turned on (after HA restart)
effect_list: 0,1,2,3,4
brightness: 255
hs_color: 0,0
rgb_color: 255,255,255
xy_color: 0.323,0.329
effect: none
friendly_name: Andrea Bedside Lamp
supported_features: 21
Changed color to blue:
effect_list: 0,1,2,3,4
brightness: 255
hs_color: 240,100
rgb_color: 0,0,255
xy_color: 0.136,0.04
effect: none
friendly_name: Andrea Bedside Lamp
supported_features: 21
So yes, those options there cause the issue, I will notify HA Devs about this, it looks like something or in the MQTT Light or in the color picker which are sending color_temp (or the wrong one) when an RGB color is selected.
Thanks for your time
Andrea
Hi,
I don’t use the same settings for MQTT light like you have (mine is MiLight emulator with MQTT JSON schema) but sending rgb_color: 255,255,255 turns the bulbs into white mode even if no color_temp command was used. On the other hand, sending rgb_color and color_temp packages would result into an error thrown by HA.
In order to use color_temp I’m sending white_mode effect and then can further select brightness and color_temp.
I use input_number for keeping the track of individual light components (r,g,b, color_temp and brightness) and these are restored after reboot. Due to MiLight specific, saturation is sent as a separate packet and causes the light to flicker.
- service: light.turn_on
data_template:
effect: "white_mode"
entity_id: light.light_x
brightness: '{{ states.input_number.dimmer.state | int }}'
color_temp: '{{ states.input_number.color.state | int }}'Hi @Petrica,
thanks for your feedback!
But without having the cold_temp configuration are you till able to have the “temperature bar” on the light card?
If not, how do you manage that? (Well, if you actually use it)
Thanks
Perhaps I don’t fully understand the problem but I think this is being taken care by HA when moving the Color temperature slider or selecting the middle (white) portion of the color wheel. There shouldn’t be any issue with setting the light in white_mode from the frontend as HA will use the proper JSON format.
The problem is when trying to set color_temp from automation or scripts as HA won’t send both rgb_color and color_temp in the same command (see my previous action part of the automation).
This is an example command sent by HA to MQTT broker when using the color wheel to move on the color_temp slider:
Client mosqsub|30005-hass received PUBLISH (d0, q0, r0, m0, 'milight_gw/0x14AA/rgb_cct/3', ... (34 bytes))
{"state": "ON", "color_temp": 307}
It can be seen that HA includes only color_temp in the command (no rgb_color).
The reply from the MiLight gateway includes the entire payload as the messages can also be used by other smart home software (like OpenHAB) and needs to have a wider applicability.
Client mosqsub|30005-hass received PUBLISH (d0, q0, r0, m0, 'milight_gw/state/0x14AA/rgb_cct/3', ... (123 bytes))
{"state":"ON","brightness":31,"color_temp":307,"bulb_mode":"white","color":{"r":255,"g":255,"b":255},"effect":"white_mode"}
The settings for the above controlled lights (4 E27 bulbs) is as following.
Saturation can be controlled individually with a slider by using an workaround (setting light with white_value in HA which includes a new slider in frontend and then forwarding that value to gateway as saturation). Otherwise, if not looking for a separate slider, saturation is controlled in frontend by going on the color wheel from inside to outside on the same line.
- platform: mqtt
schema: json
name: "Bedroom"
state_topic: 'milight_gw/state/0x14AA/rgb_cct/3'
command_topic: 'milight_gw/0x14AA/rgb_cct/3'
brightness: true
rgb: true
color_temp: true
effect: true
effect_list:
- 0
- 1
- 2
- #etc
optimistic: true
qos: 0
Isn’t this an issue, though? A color temperature of 307K is not equivalent to an RGB value of 255,255,255. So it’s basically lying by saying that the RGB value is 255,255,255. If the light’s color was just changed to a color temperature of 307K, then it should be reporting the RGB value as 255,67.9,0 which is equivalent to a color temperature of 307K.
But of course it is 
Though having dual whites or RGB+CCT light bulbs won’t matter that much as no RGB translation is needed.
The problem is to do white light with RGB only bulbs (and to consider the fact that any RGB color combination isn’t even close to regular web design color palette). Also, the efficiency of the bulb will be affected so the full advertised lm level won’t be achieved.
Not to speak about the fact that the different bulb manufacturers use non-consistent parts and calibrations, so good luck porting settings… I’ve set MiLight bulbs by comparison (side to side) with a Philips Hue and, to reach a similar color, the settings in HA for MiLight are completely different than for Hue.
I am so confused 
I can see in your config that you have things I didn’t even know were possible!
schema: json
brightness: true
rgb: true
color_temp: true
I will definetely try this,Tasmota (Sonoff B1 Light) it using json aswell so I am not 100% sure why that huge mapping was required on my config (to be fair, I simply copy/paste from @DrZzs video so presumably things have been improved since he did it )
But if you have color_temp aswell and your light is responding with that in the state too… wouldn’t you have the same problem I do have with this python_script where the color_temp and the rgb_color neds to be inverted in order for the script to use the right one?
Or for you it is simply working as it is?
The color_temp and rgb_color are both present in the state, not the command topic. If sending both in the same payload, HA will throw an error (also, for this reason, it is not possible to simply forward state from one MQTT light to command topic of another light).
What I’ve found with HA is that, for some areas, my logic is different than the one used by the developers so workarounds need to be found
That’s all probably true, but I’m not sure how relevant it is to this discussion.
The crux of the matter is what the HA light entity has for attributes, and what it accepts when the light.turn_on service is called. If it has both color_temp and rgb_color/hs_color/xy_color attributes, then they should be correct. (Note that internally the light component translates color_name, rgb_color or xy_color, when used to turn the light on, to hs_color, and when updating the entity’s attributes reports hs_color, and also reports the equivalent values for rgb_color & xy_color.)
Maybe the issue is that, for these types of lights, it should be deciding which attributes to report based on the bulb_mode. If it’s white, then report color_temp. If not, then report hs_color (& rgb_color & xy_color.)
Ideally, I think only hs_color should be used. However, there are all sorts of lights that don’t support it.
Anyway, I’m unsure of the logic used by the developers when forbidding color_temp & rgb_color in the same command (perhaps to allow white light to be generated with RGB only bulbs?) as there are also lights that allow for both color_temp & hs_color (that is RGB+CCT bulbs with all leds turned on in the same time and for which both saturation and color_temp can be modified).
The light.turn_on service has several “color” parameters – profile, color_name, rgb_color, xy_color, hs_color, color_temp & kelvin – that can be used, but it requires that only one be used in a given call. It is enforced by the light.turn_on “schema”.
There is also an attribute – supported_features – that is supposed to indicate which “features” are supported by a particular light entity. The individual bits of this value each correspond to a different feature, and should be 1 if the feature is supported, and 0 if not. Here are the bit definitions. You can see there is a bit for “color” (which corresponds to hs_color, rgb_color & xy_color), and a bit for “color temp” (which corresponds to color_temp & kelvin.)
Yes, different bulbs support different ways to control their “color” or “white temperature”, but the corresponding light platform code (in this case mqtt) is supposed to honor the requirements of the light component-level code.
It’s just not clear to me (since I don’t use MQTT, and don’t have any of these lights, so I’m not that familiar with them) whether the issue is in the MQTT light platform code, or in the user config, or both.
I also see that the “color” parameter used when turning on the light does not necessarily need to correspond to the attributes reported in the light entity. E.g., I can see turning on an “RGB light” using color_temp (since, AFAIK, all color_temp values can be converted to HS, RGB & XY), but not necessarily the reverse. And even if the light is turned on using color_temp, I don’t see it as an issue if the light entity then reports only hs_color/rgb_color/xy_color (and not color_temp.)
Anyway, again, getting back to the script to save and restore a light’s settings, if a light entity reports both color_temp and hs_color/rgb_color/xy_color, then they both should be correct and be equivalent values. If they aren’t, then at least to me, that’s a bug.
BTW, I said “307K” above, when I should have said “307 mireds.”
For MQTT, the settings for command & state are not consistent at all: although HA doesn’t allow combined color_temp and rgb_color commands, the MQTT state topic can include everything in the JSON format provided by gateway (color_temp&hs/rgb/xy_color & effects & saturation, etc). JSON state payloads are then filtered based on the light properties set in config (and yes, different, conflicting translations of light properties received from the gateway vs. the settings used by HA cause the bulbs to flicker).
I’m not sure whether HA turns on lights with any settings at all (color_temp/*_color), except if supported by platform. Most of the bulbs (Hue are an exception and last known settings has been recently added) use last known settings to turn on. Then, the settings sent in the light.turn_on package will be applied to the lights and there’s some flicker if they’re different than last known settings. In order to prevent this I send light.turn_on with brightness 1 just before light.turn_off so that turning on will be at minimal brightness (also avoids problems with power failures at night that would set the lights to maximum brightness either).
No problem
Hello,
Thanks for the great script. I was searching for this .
Edit: already solved. I had a capital letter in my store name. Changing that to a normal letter solve the issue
I just want that when I open my closet, one light is going to 100%, and when I close it, it goes to the original state. But it doesn’t work… I think I have a very stupid error at the restore, but I can’t figure it out what… Can somebody check my code?
Automation:
- id: '005'
alias: Deur kledingkast open
trigger:
- platform: state
entity_id: binary_sensor.door_window_sensor_158d000319bc2e
to: 'on'
action:
- service: script.save_lights
data:
store_name: 'Spot_3_store'
entity_ids: 'light.dimmable_light_1'
- service: light.turn_on
data_template:
entity_id: light.dimmable_light_1
brightness: 255
- alias: Deur kledingkast dicht
trigger:
platform: state
entity_id: binary_sensor.door_window_sensor_158d000319bc2e
from: 'on'
to: 'off'
action:
- service: script.restore_lights
data:
store_name: 'Spot_3_store'
scripts:
save_lights:
alias: Save light state
sequence:
- service: python_script.light_store
data_template:
store_name: "{{ store_name }}"
entity_id: "{{ entity_ids }}"
restore_lights:
alias: Restore light state
sequence:
- service: python_script.light_store
data_template:
store_name: "{{ store_name }}"
operation: restoreThnx fit the great script. Its a shame hassio didnt build it in the software.
I have an issue with the script. Sometimes it works and sometimes it doesn’t. Can’t get a clue why.
I have some ws2812B leds, powered by a WEMOS d1 at ESPHome. An hass automation is changing color of the leds after a binary sensor got high. After 15 secs the leds has to change back to original state.
In the automation I call the save script first and then a second script to notify the phones and a 
.
All works except for storing and restoring the leds sometimes.
Anyone experience with this bug?
Thx in advance!