Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
p.kaczmarek2 wrote:I haven't heard about this problem yet. Does it happen from the start or did it begin to act that way recently?
@DeDaMrAz, have you seen that?
DCG wrote:sorry I didnt get what u are telling ? so this is a known issue ?
DeDaMrAz wrote:DCG wrote:sorry I didn't get what you are telling? So this is a known issue?
More of an acknowledgement of what you are saying, but I also noticed it is changing the toggle on the HA restart and I thought it was the issue on HA's side and haven't looked into it beyond that. It will change back if you toggle it in HA probably, and that is why I was disregarding that before.
But we will look into it more carefully now as nobody mentioned it before.
DeDaMrAz wrote:
@DCG and @mnm11
Just trying to figure out what may be the problem, do you have any (and if so, which) flags active on affected devices?
p.kaczmarek2 wrote:What yaml config did you use? Can you post code here?
mqtt:
light:
- unique_id: "Wall_Smart_Light_light"
name: 0
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: "wall_bulb/led_basecolor_rgb/get"
rgb_command_topic: "cmnd/wall_bulb/led_basecolor_rgb"
command_topic: "cmnd/wall_bulb/led_enableAll"
state_topic: "wall_bulb/led_enableAll/get"
availability_topic: "wall_bulb/connected"
payload_on: 1
payload_off: 0
brightness_command_topic: "cmnd/wall_bulb/led_dimmer"
brightness_state_topic: "wall_bulb/led_dimmer/get"
brightness_scale: 100
color_temp_command_topic: "cmnd/wall_bulb/led_temperature"
color_temp_state_topic: "wall_bulb/led_temperature/get"
p.kaczmarek2 wrote:This is correct. So, the next question is - how should we modify this YAML to fix the issue you mentioned...
Zain00 wrote:I noticed this issue too, enabling Flag 2 helped solve it for now
But with Tasmota, devices state are shown within seconds after homeassistant boot
p.kaczmarek2 wrote:if flag 2 helps, then maybe "broadcast self state on connect" can also help?
// wait for mqtt to connect
waitFor MQTTState 1
// wait more
delay_s 1
// publish data
publishChannels
alias: bekens PublishAll
sequence:
- service: mqtt.publish
data:
topic: cmnd/bekens/publishAll
payload: ""
mode: single
alias: Bekens_publishAll
description: ""
trigger:
- platform: homeassistant
event: start
condition: []
action:
- service: script.bekens_publishAll
data: {}
mode: single
TL;DR: If Home Assistant restart makes OpenBeken show 2 toggle icons or an unknown state, this FAQ is for you. One user saw it from day 1 after moving to OpenBeken, and another confirmed: "enabling Flag 2 helped." The most reliable Home Assistant-side fix in the thread is sending
publishAllon HA start so devices republish their MQTT state automatically. [#20762085]
Why it matters: This issue does not usually break switching, but it makes Home Assistant show the wrong control state until a manual toggle or forced republish corrects it.
| Approach | Reported result | Speed after HA reboot | Notes |
|---|---|---|---|
| Enable Flag 2 | Helped | Slower than Tasmota | Confirmed workaround by multiple users |
publishAll on HA start |
Worked perfectly | Better than polling every 60 s | Best HA-side workaround reported |
| Flag 10 only | Did not fix it for one user | N/A | Default on affected devices |
| Flag 7 | Solved a similar unknown-state issue | N/A | Reported as an alternative for dimmers |
Key insight: The thread points to a state-republish timing problem after Home Assistant boots, not a broken relay. For most users here, forcing OpenBeken devices to republish MQTT state on startup fixed the duplicate-toggle symptom.
autoexec.bat sequence that waits for MQTT connection, adds a 1 s delay, then runs publishChannels. [#20743863]publishAll on HA startup over periodic MQTT traffic, saying it worked better than sending messages every 60 s. [#20761607]unknown because Home Assistant starts before the affected OpenBeken devices republish a clean MQTT state. In the thread, the issue appeared only after HA reboot and cleared as soon as the user toggled the entity once. Another user rechecked and found the behavior on OBK power switches, not on Zigbee devices or OBK lights, which points to state recovery timing rather than relay failure. [#20734615]publishAll to all OpenBeken devices when HA starts. One user said this script-and-automation method “worked perfectly.” Enabling Flag 2 also helped as a workaround, but the response after reboot stayed slower than with Tasmota. [#20762085]cmnd/bekens/publishAll once Home Assistant boots. A user tested that approach on October 7, 2023 and reported that it restored states correctly without needing manual toggles. It also avoided sending MQTT refresh messages every 60 s. [#20761607]cmnd/bekens/publishAll with an empty payload. 2. Set all OpenBeken devices to the same Group Topic, such as bekens. 3. Trigger that script on the Home Assistant start event. The same idea can also use publishChannels instead of publishAll. [#20761607]unknown. Use it right after HA start or MQTT reconnect. [#20761607]publishAll was good, but still not as fast as Tasmota integration. [#20761607]command_topic, state_topic, availability_topic, and matching RGB, brightness, and color temperature topics. The posted example used wall_bulb/connected for availability and wall_bulb/led_enableAll/get for state. The maintainer reviewed that YAML and said, “This is correct,” so the config structure itself was not the root cause. [#20736712]publishAll is a forced broker command that tells devices to republish everything. In the thread, Flag 10 matched the first approach, but it did not solve the issue for one user. [#20743855]autoexec.bat startup sequence that waits for MQTT, pauses briefly, then republishes channels. 1. Add waitFor MQTTState 1. 2. Add delay_s 1. 3. Add publishChannels. The maintainer proposed this exact 3-line sequence as an alternative to using Flag 2, so it is a device-side startup fix rather than an HA automation. [#20743863]publishAll still leaves entities as unknown. [#20815209]