Hopefully a simple question :) I need to have some smart light bulbs to be always on when I press the ON button on a smart light switch. I also need the light bulb to remember its last brightness, temperature, color, etc. And the third requirement is NOT to have an ON/OFF toggle switch, but...

That's a very strange requirement. I don't think it's supported out of the box. Why do you want to hide the toggle button of the bulb? Maybe I could add a flag for this, this would not be hard, but it would require changing code in few places (on/off display, commands, etc), and I need to know first what is the use case for that, there must be some motivation for us to support it. What are the chances that someone else will need this feature? Also... This can be very easily if you use manual YAML integration instead of the Home Assistant Discovery.

For me, there is a use case for this - and maybe there will be more in the future from other people too.As you can see from my OP, I have smart lights and smart switches.The smart switches are Zigbee, so no OBK controls on these devices.While there are multiple reasons, the main reason is to keep the family happy. They are used to walking into a room and telling Alexa to turn the lights on or off.With smart switches and smart lights, one cannot toggle the smart lights off as the smart switch expects load/resistance on the electric wire (I don't have/use neutral wires).I already had some issues where I have dimmed the smart light to the lowest possible value, then the switch turned off. When I tried to turn the light on (from the switch), nothing happened. The light acts like it's dead - no Wi-Fi, no AP rescue mode (I tried many times to get it into rescue mode but no luck). I know the light is not actually dead (it has been used only for about 2 months) and I have many other lights that were bought at the same time and they work fine. Other family members managed to do the same thing by asking Alexa to turn off the light that was dimmed by about 30%. Alexa turned off the light and the switch turned off. Lights never came back to life.I managed to rescue a couple of dead lights (by turning off/on a few times all the buttons from a 4-way configuration - 3 buttons controlling one light). 2 lights eventually came back with all the settings that they had. But I still have a couple that are not coming back. Have moved the :dead: lights in the same place as the rescued lights and tried again. But nothing happened.So my request will sort out the above issue and keep my lights alive.Another issue is that the family is used to turning on the lights by saying Alexa, turn on lights when they walk into a room. As lights are assigned to rooms, Alexa knows which lights to turn on. This can't work anymore with the smart switches, if I want the smart switch to control the on/off for lights.While there is an option to add a switch to a light group in HA and have the switch turn on the light/s, it might create a similar condition like the one above when the lights are turned off. If the command issued to Alexa is to turn off the lights and the lights respond first, then it will create the exact above scenario all over again. If the switch responds first, then it should be OK. But there is no way to control which device responds first.So for me, the best option is to have the switch in control and turn off/on the lights. It will eliminate a lot of issues.Hope all this makes sense. You have mentioned that through YAML integration, I can have lights in HA without the option to turn them off. Would you have an example of such YAML that I can test with?

Ok, so we can try to start with this YAML and later I will add necessary changes, if they are required. I think the basic yaml is here: I think the basic YAML is also generated on Home Assistant page in obk. but HA will not accept it, you will have to convert it to new format:

OK - I will do this a bit later on (at work now).Thank you for working with me on this.

OK - I have added a new test downlight to HA via mqtt template as opposed to auto discovery. Please note that I have many other downlights integrated in HA via the auto discovery method. I can see it in HA - and it has the ON/OFF toggle still there (just like all the other downlights added with auto discovery). What should be the next step?

What is your current YAML? Let's try remove the state topic so it is always on. I am not sure how will HA react in this scenario.

I would suggest removing everything with led_enableAll in the MQTT topic. Then save, reboot HA and check if it's still possible to turn it off. Nothing to do on OpenBeken, well, maybe except adding something like: Code: text Expand Select all Copy to clipboard led_enableAll 1 to short startup command or autoexec.bat As I said, I didn't check it on my side, so we're experimenting together. Try what I said and we'll see how it goes.

Oh no, it looks like that the Home Assistant guys are forcing us to have command topics for every light! This is not good. Your use case is so unique that they didn't expect nobody to try that... Well, the docs confirm: Maybe we can try to do the work around. So: - keep state_topic set like it always was - set command_topic to something like this/topic/does/not/exist etc etc so it goes into the ether... so light never receives the commands for ON or OFF...

Smart Light Bulb - how to configure it to be always on, no toggle button of control from toggle

MnM1 4590 21

Best answers

How can I configure a smart light bulb so it always turns on, remembers its last brightness/color/temperature, and exposes no on/off toggle in Home Assistant?

Use a manual Home Assistant MQTT light YAML config, keep the state topic, and point the command_topic to a dummy/nonexistent topic so brightness, RGB, and temperature still work while on/off becomes effectively unusable in HA [#20706018][#20711888][#20711912] The device still needs to be connected to MQTT, and on the OpenBeken side you can put `led_enableAll 1` in autoexec.bat or the short startup command so the light comes back on after a cold boot or power cut [#20711901][#20712016] For remembering the previous light settings, enabling flags 10, 12, and 37 preserved the last RGB, temperature, and dimmer values after a power cycle in the thread test [#20711957] Removing `state_topic` was tried but caused Home Assistant configuration errors, so the working approach was not to remove the state, only to neutralize the command topic [#20711820][#20711851][#20711888] HA auto-discovery customization for this kind of hidden-toggle setup was mentioned as a planned future feature, not an available one yet [#20714646]

AI summary based on the discussion. May contain errors.

Report a violation of the law

Reply | New topic

Removing on/off control while keeping dimming and color
#1 20705860 24 Aug 2023 03:22

MnM1 MnM1

Level 10

Posts: 175

Help: 4

Rate: 13
Topic author

Removing on/off control while keeping dimming and color
Post #1 20705860 24 Aug 2023 03:22

Hopefully a simple question

I need to have some smart light bulbs to be always on when I press the ON button on a smart light switch.

I also need the light bulb to remember its last brightness, temperature, color, etc.

And the third requirement is NOT to have an ON/OFF toggle switch, but retain the LED Dimmer/Brightness, LED RGB Color, and LED Temperature Sliders.

The idea behind this is that when I press the ON button on a light switch (zigbee smart light switch), the smart light bulb will:

Code: text Expand Select all Copy to clipboard
1. always turn on 2. always remember the previous values for brightness, temperature, RGB color, etc but not the power state (see point 1 above) 3. there will be no way to switch the light off (via its web interface, Alexa, Home Assistant, or any other means) except from the smart light switch button 4. Have all these options in Home Assistant - e.g. a light bulb in Home Assistant will not have an option to turn it on or off but will have all the other usual options for brightness, RGB color, scenes, temperatures, etc. Only the light switch button will turn the bulb on and off.

My guess for points 1 and 2 is to:

Code: text Expand Select all Copy to clipboard
- in Configure Startup set correct channel (Channel 0) to 1 - Enable Flag 12

But I am not sure how to remove the toggle control (point 3 above).

For point 4 above, am I correct in assuming that if no toggle is present on the device, the MQTT will present the device to Home Assistant the same way and will not have an on/off option?
ADVERTISEMENT
Manual YAML integration can hide the on/off toggle
#2 20706018 24 Aug 2023 09:36

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14797

Help: 659

Rate: 12955
Helpful post? (0)

Manual YAML integration can hide the on/off toggle
Post #2 20706018 24 Aug 2023 09:36

That's a very strange requirement. I don't think it's supported out of the box.

Why do you want to hide the toggle button of the bulb?

Maybe I could add a flag for this, this would not be hard, but it would require changing code in few places (on/off display, commands, etc), and I need to know first what is the use case for that, there must be some motivation for us to support it. What are the chances that someone else will need this feature?

Also...

MnM1 wrote:

3. there will be no way to switch the light off (via its web interface, Alexa, Home Assistant, or any other means) except from
the smart light switch button
4. Have all these options in Home Assistant - e.g. a light bulb in Home Assistant will not have an option to turn it on or off
but will have all the other usual options for brightness, RGB color, scenes, temperatures, etc. Only the light switch button
will turn the bulb on and off.

This can be very easily if you use manual YAML integration instead of the Home Assistant Discovery.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Smart switches can leave dimmed bulbs unresponsive
#3 20706067 24 Aug 2023 10:18

MnM1 MnM1

Level 10

Posts: 175

Help: 4

Rate: 13
Topic author Helpful post? (0)

Smart switches can leave dimmed bulbs unresponsive
Post #3 20706067 24 Aug 2023 10:18

For me, there is a use case for this - and maybe there will be more in the future from other people too.

As you can see from my OP, I have smart lights and smart switches.
The smart switches are Zigbee, so no OBK controls on these devices.

While there are multiple reasons, the main reason is to keep the family happy. They are used to walking into a room and telling Alexa to turn the lights on or off.

With smart switches and smart lights, one cannot toggle the smart lights off as the smart switch expects load/resistance on the electric wire (I don't have/use neutral wires).

I already had some issues where I have dimmed the smart light to the lowest possible value, then the switch turned off. When I tried to turn the light on (from the switch), nothing happened. The light acts like it's dead - no Wi-Fi, no AP rescue mode (I tried many times to get it into rescue mode but no luck).
I know the light is not actually dead (it has been used only for about 2 months) and I have many other lights that were bought at the same time and they work fine. Other family members managed to do the same thing by asking Alexa to turn off the light that was dimmed by about 30%. Alexa turned off the light and the switch turned off. Lights never came back to life.

I managed to rescue a couple of dead lights (by turning off/on a few times all the buttons from a 4-way configuration - 3 buttons controlling one light). 2 lights eventually came back with all the settings that they had. But I still have a couple that are not coming back. Have moved the :dead: lights in the same place as the rescued lights and tried again. But nothing happened.

So my request will sort out the above issue and keep my lights alive.

Another issue is that the family is used to turning on the lights by saying "Alexa, turn on lights" when they walk into a room.
As lights are assigned to rooms, Alexa knows which lights to turn on. This can't work anymore with the smart switches, if I want the smart switch to control the on/off for lights.
While there is an option to add a switch to a light group in HA and have the switch turn on the light/s, it might create a similar condition like the one above when the lights are turned off. If the command issued to Alexa is to turn off the lights and the lights respond first, then it will create the exact above scenario all over again.
If the switch responds first, then it should be OK. But there is no way to control which device responds first.

So for me, the best option is to have the switch in control and turn off/on the lights. It will eliminate a lot of issues.

Hope all this makes sense.

You have mentioned that through YAML integration, I can have lights in HA without the option to turn them off. Would you have an example of such YAML that I can test with?
#4 20707234 25 Aug 2023 07:31

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14797

Help: 659

Rate: 12955
Helpful post? (0)

Post #4
20707234 25 Aug 2023 07:31

Ok, so we can try to start with this YAML and later I will add necessary changes, if they are required.

I think the basic yaml is here:
https://www.elektroda.com/rtvforum/topic3880540.html
I think the basic YAML is also generated on Home Assistant page in obk.
but HA will not accept it, you will have to convert it to new format:

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#5 20707255 25 Aug 2023 08:08

MnM1 MnM1

Level 10

Posts: 175

Help: 4

Rate: 13
Topic author Helpful post? (0)

Post #5
20707255 25 Aug 2023 08:08

OK - I will do this a bit later on (at work now).
Thank you for working with me on this.
#6 20711705 28 Aug 2023 14:46

MnM1 MnM1

Level 10

Posts: 175

Help: 4

Rate: 13
Topic author Helpful post? (0)

Post #6
20711705 28 Aug 2023 14:46

OK - I have added a new test downlight to HA via mqtt template as opposed to auto discovery. Please note that I have many other downlights integrated in HA via the auto discovery method.
I can see it in HA - and it has the ON/OFF toggle still there (just like all the other downlights added with auto discovery).

What should be the next step?
#7 20711820 28 Aug 2023 16:16

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14797

Help: 659

Rate: 12955
Helpful post? (0)

Post #7
20711820 28 Aug 2023 16:16

What is your current YAML? Let's try remove the state topic so it is always on. I am not sure how will HA react in this scenario.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
ADVERTISEMENT

Remove state_topic for always-on light

#8 20711846 28 Aug 2023 16:31

MnM1 MnM1

Level 10

Posts: 175

Help: 4

Rate: 13

Remove state_topic for always-on light

Post #8 20711846 28 Aug 2023 16:31

This the code I am using:

mqtt:
  light:
    - unique_id: "DownLight-80_light"
      name: "Downlight-80"
      rgb_command_template: "{{ '#%02x%02x%02x0000' | format(red, green, blue)}}"
      rgb_value_template: "{{ value[0:2]|int(base=16) }},{{ value[2:4]|int(base=16) }},{{ value[4:6]|int(base=16) }}"
      rgb_state_topic: "Home/DownLights/Spare/Downlight80/led_basecolor_rgb/get"
      rgb_command_topic: "cmnd/Home/DownLights/Spare/Downlight80/led_basecolor_rgb"
      command_topic: "cmnd/Home/DownLights/Spare/Downlight80/led_enableAll"
      state_topic: "Home/DownLights/Spare/Downlight80/led_enableAll/get"
      availability_topic: "Home/DownLights/Spare/Downlight80/connected"
      payload_on: "1"
      payload_off: "0"
      brightness_command_topic: "cmnd/Home/DownLights/Spare/Downlight80/led_dimmer"
      brightness_state_topic: "Home/DownLights/Spare/Downlight80/led_dimmer/get"
      brightness_scale: 100
      color_temp_command_topic: "cmnd/Home/DownLights/Spare/Downlight80/led_temperature"
      color_temp_state_topic: "Home/DownLights/Spare/Downlight80/led_temperature/get"

So this is the line you want me to remove:

state_topic: "Home/DownLights/Spare/Downlight80/led_enableAll/get"

Anything else I should remove?

How about the light config in OBK? Anything I should do there before I make changes in the YAML?

Remove led_enableAll MQTT control and set startup command
#9 20711851 28 Aug 2023 16:33

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14797

Help: 659

Rate: 12955
Helpful post? (0)

Remove led_enableAll MQTT control and set startup command
Post #9 20711851 28 Aug 2023 16:33

I would suggest removing everything with "led_enableAll" in the MQTT topic. Then save, reboot HA and check if it's still possible to turn it off.

Nothing to do on OpenBeken, well, maybe except adding something like:
Code: text Expand Select all Copy to clipboard
led_enableAll 1

to short startup command or autoexec.bat

As I said, I didn't check it on my side, so we're experimenting together. Try what I said and we'll see how it goes.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

Commenting out command_topic breaks MQTT light config

#10 20711867 28 Aug 2023 16:49

MnM1 MnM1

Level 10

Posts: 175

Help: 4

Rate: 13

Commenting out command_topic breaks MQTT light config

Post #10 20711867 28 Aug 2023 16:49

I understand

Will do the suggested steps now. Will let you know shortly

Added after 8 [minutes]:

OK so I commented out like below

mqtt:
  light:
    - unique_id: "DownLight-80_light"
      name: "Downlight-80"
      rgb_command_template: "{{ '#%02x%02x%02x0000' | format(red, green, blue)}}"
      rgb_value_template: "{{ value[0:2]|int(base=16) }},{{ value[2:4]|int(base=16) }},{{ value[4:6]|int(base=16) }}"
      rgb_state_topic: "Home/DownLights/Spare/Downlight80/led_basecolor_rgb/get"
      rgb_command_topic: "cmnd/Home/DownLights/Spare/Downlight80/led_basecolor_rgb"
      #command_topic: "cmnd/Home/DownLights/Spare/Downlight80/led_enableAll"
      #state_topic: "Home/DownLights/Spare/Downlight80/led_enableAll/get"
      availability_topic: "Home/DownLights/Spare/Downlight80/connected"
      payload_on: "1"
      payload_off: "0"
      brightness_command_topic: "cmnd/Home/DownLights/Spare/Downlight80/led_dimmer"
      brightness_state_topic: "Home/DownLights/Spare/Downlight80/led_dimmer/get"
      brightness_scale: 100
      color_temp_command_topic: "cmnd/Home/DownLights/Spare/Downlight80/led_temperature"
      color_temp_state_topic: "Home/DownLights/Spare/Downlight80/led_temperature/get"

I think that's all I need to do?

However as soon as I comment out command_topic I get an error:

And of course the configuration is invalid message in HA's Check and Restart page

Use a dummy MQTT command topic to ignore toggles
#11 20711888 28 Aug 2023 16:59

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14797

Help: 659

Rate: 12955
Helpful post? (0)

Use a dummy MQTT command topic to ignore toggles
Post #11 20711888 28 Aug 2023 16:59

Oh no, it looks like that the Home Assistant guys are forcing us to have command topics for every light! This is not good.

Your use case is so unique that they didn't expect nobody to try that...

Well, the docs confirm:
https://www.home-assistant.io/integrations/light.mqtt/

Maybe we can try to do the work around.

So:
- keep state_topic set like it always was
- set "command_topic" to something like "this/topic/does/not/exist" etc etc so it goes into the ether... so light never receives the commands for ON or OFF...

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
ADVERTISEMENT
#12 20711896 28 Aug 2023 17:06

MnM1 MnM1

Level 10

Posts: 175

Help: 4

Rate: 13
Topic author Helpful post? (0)

Post #12
20711896 28 Aug 2023 17:06

One question - should the light be configured to connect to mqtt? in the Config>>Configure MQTT page?
#13 20711901 28 Aug 2023 17:11

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14797

Help: 659

Rate: 12955
Helpful post? (0)

Post #13
20711901 28 Aug 2023 17:11

Of course, otherwise there will be no communication at all.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

HA MQTT light on/off commands not reaching OBK device

#14 20711912 28 Aug 2023 17:16

MnM1 MnM1

Level 10

Posts: 175

Help: 4

Rate: 13

HA MQTT light on/off commands not reaching OBK device

Post #14 20711912 28 Aug 2023 17:16

OK the new YAML is like this now:

mqtt:
  light:
    - unique_id: "DownLight-80_light"
      name: "Downlight-80"
      rgb_command_template: "{{ '#%02x%02x%02x0000' | format(red, green, blue)}}"
      rgb_value_template: "{{ value[0:2]|int(base=16) }},{{ value[2:4]|int(base=16) }},{{ value[4:6]|int(base=16) }}"
      rgb_state_topic: "Home/DownLights/Spare/Downlight80/led_basecolor_rgb/get"
      rgb_command_topic: "cmnd/Home/DownLights/Spare/Downlight80/led_basecolor_rgb"
      command_topic: "cmnd/Home/DownLights/Spare/Downlight80/this/command/topic/is_not_Used"
      state_topic: "Home/DownLights/Spare/Downlight80/led_enableAll/get"
      availability_topic: "Home/DownLights/Spare/Downlight80/connected"
      payload_on: "1"
      payload_off: "0"
      brightness_command_topic: "cmnd/Home/DownLights/Spare/Downlight80/led_dimmer"
      brightness_state_topic: "Home/DownLights/Spare/Downlight80/led_dimmer/get"
      brightness_scale: 100
      color_temp_command_topic: "cmnd/Home/DownLights/Spare/Downlight80/led_temperature"
      color_temp_state_topic: "Home/DownLights/Spare/Downlight80/led_temperature/get"

Rebooted HA and the light is there. Turn it on/off does nothing. I can toggle it ON or OFF from the OBK device web page.
All the other options seem to work OK in HA - brightness, rgb, temperature

ADVERTISEMENT
#15 20711951 28 Aug 2023 17:45

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14797

Help: 659

Rate: 12955
Helpful post? (0)

Post #15
20711951 28 Aug 2023 17:45

So maybe now we can script OBK page to... to automatically turn it on once it's turned off?

That could be done with change handler.

Something like:
Code: text Expand Select all Copy to clipboard
When Users Turns Light Off -> Turn It On

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Startup value 1 may force bulb on after cold boot
#16 20711957 28 Aug 2023 18:20

MnM1 MnM1

Level 10

Posts: 175

Help: 4

Rate: 13
Topic author Helpful post? (0)

Startup value 1 may force bulb on after cold boot
Post #16 20711957 28 Aug 2023 18:20

So what you mean is to allow users to turn it off and then OBK page will turn it on actually?
Will there be small delay between the off and on? Cause that will freak out the smart switches.

If there is a way to have the light on all the time in OBK that will be best. As one of the pre-rqs (as far I can tell from my use cases) is for OBK to always have the light ON - so when a switch turns it ON light will always be ON without user intervention. But is also good to remember all of the last setting (rbg, temp, dim values).

Added after 4 [minutes]:

Thinking about it now - if the toggle is on the OBK page can can only be used from there that is not a bad thing. Switches and bulb wont be able to use it via Alexa or HA so it OK.
Just need a way to figure the always on option.

Added after 2 [minutes]:

Did a quick test - changed to red in HA and then rebooted the light from OBK page.
After it started the light was back to white. So is not remembering rgb, dim, temp.[/line]

Actually disregard the above - still testing.

Added after 20 [minutes]:

I have enabled Flags 10, 12 and 37.
Last values for rgb, temp, dim are remembered after a cold start (to simulate what a smart switch will - it will just cut the power the light).
The device turns on after a cold boot but I suspect that is because flag 12 enables that.

Should I set a startup value of 1 in Start Values - I think that is what will always have the light on after a cold boot regardless of the last state?
Use led_enableAll in autoexec.bat for always-on light
#17 20712016 28 Aug 2023 18:28

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14797

Help: 659

Rate: 12955
Helpful post? (0)

Use led_enableAll in autoexec.bat for always-on light
Post #17 20712016 28 Aug 2023 18:28

I don't think start StartValue will work for the light. It's better to execute led_enableAll from autoexec.bat or short startup command:

p.kaczmarek2 wrote:

Nothing to do on OpenBeken, well, maybe except adding something like:
Code: text Expand Select all Copy to clipboard
led_enableAll 1

to short startup command or autoexec.bat

If we enable smooth transitions on light, and set change handler to the turning light off to turn it on, then the blink will not be visible.

Futhermore, as you said, in most cases it won't turn off anyway, because it's already blocked at HA level.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Questioning the rationale for toggle-to-on mode
#18 20712030 28 Aug 2023 18:39

MnM1 MnM1

Level 10

Posts: 175

Help: 4

Rate: 13
Topic author Helpful post? (0)

Questioning the rationale for toggle-to-on mode
Post #18 20712030 28 Aug 2023 18:39

OK, I already had led_enableAll 1 in the startup command - so now I know why the light comes back on after a reboot/power cut.

Still struggling to understand why you want to have "the turning light off to turn it on" - is this so one can bring the light value in HA to an off position (without the light being actually off?) Just want to understand the rationale behind that because the way the device is configured right now seems to be the correct way to work for my use case. Wondering what I am not seeing by using the turning light off to turn it on option.
#19 20712036 28 Aug 2023 18:43

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14797

Help: 659

Rate: 12955
Helpful post? (0)

Post #19
20712036 28 Aug 2023 18:43

MnM1 wrote:

Still struggling to understand why you want to have "the turning light off to turn it on" - is this so one can bring the light value in HA to an off position (without the light being actually off?)

No, it's just a precaution for a situation where user accesses OBK WWW panel directly and turns off light there. It's just to be sure.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#20 20712039 28 Aug 2023 18:49

MnM1 MnM1

Level 10

Posts: 175

Help: 4

Rate: 13
Topic author Helpful post? (0)

Post #20
20712039 28 Aug 2023 18:49

Aha, got it. Yes, it makes sense now :)

Now the next question - the changes that we worked on for the device in HA - the YAML config for it - is there an option that you can build in OBK HA Auto Discovery to set up a zombie command topic? Will be much better that way so one can use HA auto discovery rather than manually add YAML config in HA. Or OBK auto discovery doesn't work that way?
Planned HA discovery customization for no-toggle setup
#21 20714646 30 Aug 2023 14:50

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14797

Help: 659

Rate: 12955
Helpful post? (0)

Planned HA discovery customization for no-toggle setup
Post #21 20714646 30 Aug 2023 14:50

The feature you are asking about is the HA Discovery customization. This is something that is planned for months already, but I haven't had time to look into it yet.

The basic idea would be to display the HA Discovery Yaml before publishing it to MQTT. This could be done most likely trough our Web App.

Usage would be the following: first, you go to the Web App, to the new HA Discovery tab, where you can press button "Generate Discovery". Then you get the Discovery yaml in the text field, where you can review it and make the changes as you wish. Finally, down below you'd have a "Send modified Discovery" button that would ultimately publish changed device description to HA.

I am hoping to add this feature in the following weeks. Currently I also have a DS18B20 request from several users, I have your Alexa request and I was also planning to test SPI individually-addressable LEDs on my side, namely the WS2812Bs which I mentioned in the SM16703 thread. We'll see how it goes.

Please stay around and check Elektroda every now and then, I'll post an update on the forum once the HA custom discovery is done.

Anyway, except that discovery thing, what else is left to do for your "no toggle" setup?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Smart switch may trigger AP rescue mode
#22 20714683 30 Aug 2023 15:23

MnM1 MnM1

Level 10

Posts: 175

Help: 4

Rate: 13
Topic author Helpful post? (0)

Smart switch may trigger AP rescue mode
Post #22 20714683 30 Aug 2023 15:23

Ok, no worries - I am here every day to check new posts and learn about devices and what people are doing, so I will also check every now and then to see when the HA Discovery Update field is ready for testing.

The other thing was your suggestion for "When Users Turn Light Off -> Turn It On."

Also, after further testing, I have noticed the following - sometimes (not always) when I turn on the smart light from the smart switch, the light does not come on at all (this happens with OBK and with the original firmware). Most of the time, the smart light does show up in AP Rescue Mode on the Wi-Fi.

I am not sure why this is happening - my guess is that the smart switch sends pulses of electricity to turn on a light. And this puts a smart light in AP Rescue Mode.

I was thinking that it would be good to have an option (if possible) in the GUI for a user to specify after how many on/off/on cycles to put a device in AP Rescue Mode. I think right now it is hard-coded at 3 or 5, and whatever the smart switch is doing is triggering that limit when a smart light is turned on. What do you think?
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

Reply | New topic

Report a violation of the law

Topic summary

The discussion revolves around configuring smart light bulbs to remain always on when activated by a Zigbee smart switch, while retaining their last brightness, color, and temperature settings. Users express the need to eliminate the ON/OFF toggle functionality, allowing only dimming and color adjustments through sliders. The conversation explores potential solutions using Home Assistant (HA) and manual YAML configurations, including the removal of command topics to prevent the bulbs from being turned off. Suggestions include using MQTT for communication and implementing a workaround to ensure the bulbs remain on despite user interactions through the OBK web interface. The need for a feature to customize HA Discovery for better integration is also highlighted.
AI summary based on the discussion. May contain errors.

FAQ

TL;DR: With 1 dummy command_topic and 3 OBK flags, “forcing us to have command topics” becomes manageable: keep brightness, RGB, and temperature in Home Assistant, but make wall-switch power the only real ON/OFF path. This setup suits OpenBeken users who want family-friendly smart lighting without accidental bulb shutdowns or low-brightness lockups. [#20711888]

Why it matters: This setup separates power control from scene control, which helps smart bulbs survive non-neutral switch behavior and keeps voice assistants from issuing destructive OFF commands.

Approach	ON/OFF in HA	Brightness/RGB/Temp	Setup effort	Best use case
HA auto discovery	Normal working toggle	Yes	Low	Standard smart-bulb use
Manual YAML + real `command_topic`	Working toggle remains	Yes	Medium	Custom MQTT entity
Manual YAML + dummy `command_topic`	Toggle shown, but ineffective	Yes	Medium	Physical switch is the only real power control
OBK startup `led_enableAll 1`	Forces bulb back on after power restore	N/A	Low	Always-on bulb after wall-switch restore

Key insight: Home Assistant still expects an MQTT light to have a command_topic, so the practical workaround is not removing ON/OFF entirely, but routing ON/OFF commands to a non-existent topic and forcing the bulb on at OpenBeken startup.

Quick Facts

The reported failure case happened after the bulb had been used for about 2 months, then was dimmed very low and later would not come back normally. [#20706067]
A family member reproduced the issue after dimming to about 30% and then asking Alexa to turn the light off before the smart switch cut power. [#20706067]
Recovery sometimes required repeated switching from a 4-way setup controlling one light, and only 2 bulbs were rescued that way in one test. [#20706067]
The manual MQTT YAML used brightness_scale: 100, plus separate RGB and color-temperature topics, so HA kept full scene controls even when ON/OFF was neutralized. [#20711846]
The proposed AP Rescue threshold appeared fixed at roughly 3 or 5 cycles, which raised concern because smart-switch power pulses may hit that trigger unintentionally. [#20714683]

How can I configure an OpenBeken smart light bulb to always power on after a wall switch or Zigbee smart switch restores power, while still remembering the last brightness, color, and temperature settings?

Use OpenBeken startup commands to force power on, and use OBK flags that preserve light parameters across cold boots. The working setup in the thread used flags 10, 12, and 37, and the bulb then remembered RGB, temperature, and dimmer values after a power cut. The maintainer recommended placing led_enableAll 1 in autoexec.bat or the short startup command so the bulb comes back on whenever power is restored. [#20712016]

What is the best way in Home Assistant to expose an MQTT light with brightness, RGB color, and color temperature controls but without a usable on/off control?

The best working method is manual MQTT YAML with a fake command_topic. Keep the normal RGB, brightness, and color-temperature command and state topics, but point command_topic to a non-existent MQTT path so HA shows a toggle that cannot actually switch the bulb off. In the thread, this kept brightness, RGB, and temperature working while ON/OFF from HA did nothing. [#20711912]

Why does a Home Assistant MQTT light still show an ON/OFF toggle even when I add the device manually through YAML instead of using MQTT auto discovery?

It still shows because Home Assistant treats an MQTT light as a light entity and expects power control to exist. Manual YAML changes how the entity is defined, but it does not change the platform model. The maintainer confirmed that HA was effectively “forcing us to have command topics” for every MQTT light, so switching from discovery to YAML alone does not remove the toggle. [#20711888]

How do I create a manual Home Assistant MQTT YAML configuration for an OpenBeken light so Alexa and HA can change brightness and color, but the physical smart switch remains the only real on/off control?

Create a manual mqtt.light entity and keep the RGB, brightness, temperature, availability, and state topics, but replace only the power command_topic with a dead topic. 1. Copy the working OBK MQTT topics for led_basecolor_rgb, led_dimmer, and led_temperature. 2. Keep state_topic for led_enableAll/get. 3. Set command_topic to an unused path, then restart HA. That leaves HA and Alexa able to change scenes while the physical switch remains the only real power path. [#20711912]

What happens in Home Assistant if I remove the MQTT state_topic or command_topic from a light entity, and why does HA require a command topic for MQTT lights?

Removing command_topic makes the light configuration invalid in Home Assistant. The user tested that change and HA immediately raised a configuration error when command_topic was commented out. The maintainer then checked the documentation and concluded HA requires a command_topic for MQTT lights, which is why the workaround uses a dummy topic instead of removing it. [#20711888]

How do I use a dummy or non-existent MQTT command_topic in Home Assistant as a workaround to block ON/OFF commands for an OpenBeken light?

Point the light entity’s command_topic to an MQTT path that no device subscribes to. The tested example used cmnd/Home/DownLights/Spare/Downlight80/this/command/topic/is_not_Used, while keeping the normal state_topic and all color-control topics intact. After rebooting HA, the light still appeared, ON/OFF did nothing, and brightness, RGB, and temperature continued to work. [#20711912]

Which OpenBeken settings or flags help a smart bulb restore its previous RGB, temperature, and dimmer values after a cold boot or power cut?

Flags 10, 12, and 37 were the successful combination in this case. After enabling those three flags, the user confirmed that RGB, temperature, and dimmer values were preserved after a cold start used to simulate a smart switch cutting power. The same test also showed the bulb powered back on after cold boot, which matched the always-on goal. [#20711957]

What does the OpenBeken command led_enableAll 1 do, and why would I put it in autoexec.bat or the short startup command for a smart bulb?

led_enableAll 1 turns the light output on, and placing it in startup makes that happen every time the bulb boots. The maintainer recommended putting it in autoexec.bat or the short startup command so a power-restored bulb does not stay off after a wall switch event. That is more reliable for lights than relying on a generic StartValue. [#20712016]

What is OBK or OpenBeken, and how does it interact with MQTT and Home Assistant for smart lighting control?

“OBK” is device firmware that exposes smart-light functions through a web interface, MQTT topics, startup commands, and Home Assistant integration. In this thread, it published topics for power, RGB color, dimming, temperature, and availability, and HA consumed those topics either through auto discovery or manual YAML. It also let the user add commands like led_enableAll 1 at boot. [#20711851]

What is AP Rescue Mode on an OpenBeken smart bulb, and why might a light enter it unexpectedly when switched from a smart wall switch?

“AP Rescue Mode” is a recovery Wi-Fi mode that lets an OpenBeken device expose its own access point after repeated power cycling, so users can reconnect and recover the device. The thread suggests a smart wall switch may send brief power pulses during switching, and those pulses can mimic the recovery trigger. That can make a bulb enter rescue mode instead of returning to normal lighting operation. [#20714683]

Manual Home Assistant MQTT YAML vs HA auto discovery for OpenBeken lights — which approach is better when I need custom behavior like disabling effective on/off control?

Manual YAML is better when you need custom behavior that HA auto discovery cannot express. Auto discovery is simpler, but it publishes the standard light definition and keeps normal ON/OFF control. The maintainer said discovery customization was only planned for a future feature, while manual YAML already worked for the no-effective-toggle workaround in August 2023. [#20714646]

Why might a non-neutral Zigbee smart switch cause a smart bulb to appear dead or fail to turn back on after the bulb was dimmed very low or turned off by Alexa?

A non-neutral Zigbee switch may need load on the wire, so a smart bulb at very low output or OFF can leave the switch in a bad state. The user reported bulbs dimmed to the lowest level, or to about 30%, then switched off by Alexa, sometimes would not return, showed no normal Wi-Fi behavior, and looked dead. In that home, the switch expected resistance on the line and controlled lights through a non-neutral setup. [#20706067]

How could an OpenBeken change handler be used so that if someone turns the bulb off from the OBK web interface, it automatically turns itself back on?

Use a change handler that watches for OFF and immediately issues ON. The maintainer proposed this only as a precaution for direct use of the OBK web panel, not for Home Assistant control, because HA ON/OFF was already blocked by the dummy command_topic. He also noted that with smooth transitions enabled, the off-on blink would not be visible. [#20712036]

What would be the best way to customize OpenBeken Home Assistant discovery so it can publish modified MQTT discovery data, such as a zombie command topic for lights?

The best design is a discovery editor in the OpenBeken web app that generates YAML, lets the user modify it, and then republishes it to MQTT. The maintainer described a planned flow with a new HA Discovery tab, a “Generate Discovery” button, an editable text field, and a “Send modified Discovery” button. That would let users inject a zombie command_topic before Home Assistant sees the entity. [#20714646]

Why would it be useful to make the AP Rescue Mode trigger count configurable in the OpenBeken GUI, and how could smart switch power pulses interfere with the current fixed threshold?

A configurable trigger count would reduce false rescue entries on power-pulsing switches. The user suspected the current threshold was hard-coded at about 3 or 5 on/off/on cycles, and a smart switch may accidentally generate enough pulses during one restore event to hit that limit. Raising the threshold in the GUI could keep a normal switch action from dropping the bulb into AP Rescue Mode. [#20714683]

AI summary based on the discussion. May contain errors.