Adaptive lighting turns LED strip on intermittently

[bakadave]

I have an LED stript that keeps receiving MQTT messages with payload {"color_temp":xxx} even in the OFF state which results in the stript turning on "by itself" every few minutes. This only happens if adaptive lighting is selected. The messages are published by homebridge so I believe the problem lies in this plugin.

What strange is that this is the only light which does this even though I have multiple bulbs with adaptive lighting enabled.

There is also a "secondary" problem with _colortemp values being sent after {"state":"OFF"} payload which prevents light from turning off completely.

[akno2205]

I have the same problem. But when I restart Homebridge and the led strip is off, it switches on immediately (with adaptive light on or off). When I set the StartPub to message:0 and restart the Homebridge, the led strip went off for 1 sec. and turn on again, because the brightness is set to 100 and the colors 177. I have also other light bulbs, but only the led strips (I have two) are doing this. Everything started with version 1.1.27. When I go back to version 1.1.26 everything is fine.

This is my configuration for the led strip. With version 1.1.26 is it working fine. { "accessory": "mqttthing", "type": "lightbulb", "name": "LED Tisch Büro", "url": "http://192.168.178.148:1883", "topics": { "getOn": "stat/LEDTischBuero/POWER", "setOn": "cmnd/LEDTischBuero/power", "getHSV": "stat/LEDTischBuero/RESULT", "setHSV": "cmnd/LEDTischBuero/HSBColor" }, "integerValue": "false", "onValue": "ON", "offValue": "OFF", "hex": "false" },

[arachnetech]

Interesting: does indeed sound like mqttthing is publishing colour temperature updates for adaptive lighting that's turned off and some devices interpret this as an instruction to turn the bulb back on again. I'll see what I can do to stop this.

[bakadave]

wow fast support, let me know if you need more data

[akno2205]

Hy, thank you for your effort. I hope we can fix it.

[nickbalch]

Just wanted to bump this - I see this same issue ... using mqttthing 1.1.30 with homebridge v1.3.4. As above, installing a version prior to 1.2.7 does not show this behaviour. In case its relevant, I'm running an LEDEnet esp8266 device flashed with Tasmota

[nickbalch]

After watching the mqtt commands and the Tasmota responses, I could see that the Tasmota powers on in response to HSBcolor commands - regardless of power state (but potentially only if dimmer is >0) I found that there is an option in Tasmota to change this behaviour: https://tasmota.github.io/docs/Lights/#disable-auto-power-on "When enabling SetOption20 1 any change to webUI sliders or using commands CT, Dimmer, HSBColor3, Color or Channel will not automatically power on the light if it is off." Will run with this and report back.

[caffeineflo]

When enabling SetOption20 1 any change to webUI sliders or using commands CT, Dimmer, HSBColor3, Color or Channel will not automatically power on the light if it is off

Thanks for mentioning that, fixed my Tasmota strip!

[nickbalch]

After watching the mqtt commands and the Tasmota responses, I could see that the Tasmota powers on in response to HSBcolor commands - regardless of power state (but potentially only if dimmer is >0) I found that there is an option in Tasmota to change this behaviour: https://tasmota.github.io/docs/Lights/#disable-auto-power-on "When enabling SetOption20 1 any change to webUI sliders or using commands CT, Dimmer, HSBColor3, Color or Channel will not automatically power on the light if it is off." Will run with this and report back.

Just to update - this addressed my problem with unexpected on/off behaviour on a Tasmota device. I can imagine other lighting devices may also respond to color change commands by powering on, even without an explicit power on command. Apologies to @bakadave @akno2205 if you are encountering a different issue.

[nixmeer]

Well, I did request the feature a while back and I am glad @arachnetech did implement it! However, my own esp8266 firmware only uses the RGB color code since that is always updated with the brightness or power commands.

So I got two thoughts/questions: 1st) is the adaptive color only published, if adaptive lighting is selected in HomeKit? It does not look to me like it is. My esp8266 firmware only used the RGB color code till now since all brightness and power commands are also update the RGB code. Is it possible to keep it like that and have the RGB code updated with brightness and power state in mind? 2nd) not all lamps I run do have great color accuracy. Would it be possible to configure a range of RGB or temperature (depending on the lamps capabilities/topics)?

[ceraz68]

I found that there is an option in Tasmota to change this behaviour: https://tasmota.github.io/docs/Lights/#disable-auto-power-on "When enabling SetOption20 1 any change to webUI sliders or using commands CT, Dimmer, HSBColor3, Color or Channel will not automatically power on the light if it is off."

Thanks a lot for pointing to the setoption20. In my case when no payload is added to the 'color' command, Tasmota does not power on the module.

In my setup, everytime homebridge rebooted, my LED would turn on. I was going crazy thinking that some Mqtt message was retained somewhere. Then I noticed that when homebridge reboots, the Mqttthing plugin issues an MQTT command with a specific colour code as payload. I assume this relates to the mqttthing plugin "setRGB" topic.

[Elliot LED] Publishing MQTT: cmnd/elliotled/COLOR = 240,240,255

As a payload is appended, Tasmota powered on the LED. IMHO the plugin should not append any payload on the initial plugin start but can't find where this is done in the code. Fortunately, the Tasmota setoption20 is a good workaround.

I don't know if this is related to Adaptive Lighting. Below is my corresponding homebridge config, nothing is forcing the plugin to issue a payload command on startup and I am not using the Mqttthing "startPub" feature.

{ "type": "lightbulb", "name": "Elliot LED", "url": "mqtt://192.168.0.2", "username": "user", "password": "password", "logMqtt": true, "topics": { "getRGB": "stat/elliotled/COLOR", "setRGB": "cmnd/elliotled/COLOR", "getOn": "stat/elliotled/POWER", "setOn": "cmnd/elliotled/POWER" }, "onValue": "ON", "offValue": "OFF", "accessory": "mqttthing" },

[eriksmets]

I have the same issue, however, not using Tasmota but zigbee2mqtt. Is there any way to disable sending adaptive lightning updates while state = OFF ? Do you think you could create an option for this ?

[noelhibbard]

I just ran into the same issue with an IKEA color changing bulb connected via Zigbee2MQTT. If you send an HSV packet to the light without also including "state": "OFF", the bulb will turn on. My fix (needs testing but should be the fix) was to write a codec for mqttthing which keeps track of the state of the bulb at all times. In Zigbee2MQTT I also set this device to retain the MQTT topic so that when homebridge restarts it will receive the last known state right away. After some testing I will share my codec for anyone else running into this issue. Even if you don't have an IKEA bulb, my codec would at least give someone a starting point for a solution to other bulbs.

[makleso6]

i have same issue

[makleso6]

@noelhibbard any updates with your codec?

[noelhibbard]

This is what I am using currently and it's working well: https://gist.github.com/noelhibbard/0241c82b9dd2749edc553e49b661fa9e

[noelhibbard]

@makleso6 , I did a little code cleanup before creating that gist and inadvertently injected a bug which I didn't discover until I got home from the office and noticed my bulbs weren't working anymore. Be sure use the 3rd revision of this gist and make sure your bulbs are setup in zigbee2MQTT to retain.

[makleso6]

I made for myself to turn off the adaptive lighting when the light bulb turns off https://github.com/arachnetech/homebridge-mqttthing/commit/3d88a4c8e40a6445518c506b88ed0aaa1bb7dc8a it may be worth adding this option to a specific lamp and not for everyone