logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda
Build faster with M5Stack »
Build faster with M5Stack » Stick • Unit • Cardputer
ADVERTISEMENT
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

BK7231N Switches with OpenBK in HA Turning On at 3 AM - Firmware Issue?

4139ggn 3879 35
Best answers

Why do my BK7231N/OpenBK switches turn on around 3 AM in Home Assistant?

The thread points to a Home Assistant/MQTT integration issue rather than an OpenBK firmware bug: the logs show HA sending `1` to the device as soon as it reconnects, which makes the relay turn on [#20939162][#21097124] The devices were not rebooting at that time, so the behavior was tied to MQTT reconnects and HA state handling, not uptime resets [#20999305][#20904882] Changing `retain` and enabling OpenBK flag 21 (`[MQTT] Retain power channels`) did not solve it [#20939175][#20939306] The working fix was to enable Home Assistant auto-detection and remove the manual MQTT entries from `configuration.yaml` [#21112094][#21203425] If needed, clean up stale MQTT topics as well, but the reported fix was switching to HA discovery [#21112634]
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #31 21097362
    p.kaczmarek2
    Moderator Smart Home  
    so you configured it manually via Yaml and not with Home Assistant discovery?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 21097380
    jtauscher87
    Level 7  

    No, I was wrong about that. It was in .yaml but commented out in config.yaml - so no yaml configuration. But anyway I tried changing MAC and deleting device in HA, as soon as MQTT (Mosquitto) reconnects it turns on the device. It always sends the .../0/set 1 command.

    Code: text Expand Select all Copy to clipboard
    2024-05-27 11:31:10.133 DEBUG (MainThread) [homeassistant.components.mqtt.client] Received message on GarageLicht/connected (qos=1): b'offline'
2024-05-27 11:31:10.146 DEBUG (MainThread) [homeassistant.components.mqtt.client] 192.168.0.122: register write 45
2024-05-27 11:31:10.157 DEBUG (MainThread) [homeassistant.components.mqtt.client] 192.168.0.122: unregister write 45
2024-05-27 11:31:10.243 DEBUG (MainThread) [homeassistant.components.mqtt.client] Received message on GarageLicht/connected (qos=1): b'online'
2024-05-27 11:31:10.249 DEBUG (MainThread) [homeassistant.components.mqtt.client] 192.168.0.122: register write 45
2024-05-27 11:31:10.258 DEBUG (MainThread) [homeassistant.components.mqtt.client] 192.168.0.122: unregister write 45
2024-05-27 11:31:10.269 DEBUG (MainThread) [homeassistant.components.mqtt.client] Received message on GarageLicht/0/get (qos=1): b'1'
2024-05-27 11:31:10.274 DEBUG (MainThread) [homeassistant.components.mqtt.client] 192.168.0.122: register write 45
2024-05-27 11:31:10.279 DEBUG (MainThread) [homeassistant.components.mqtt.client] Transmitting message on GarageLicht/0/set: '1', mid: 537, qos: 1
2024-05-27 11:31:10.285 DEBUG (MainThread) [homeassistant.components.mqtt.client] 192.168.0.122: unregister write 45

  • ADVERTISEMENT
  • #33 21100362
    Nakano
    Level 10  

    I have 3 devices with bl602 and only the one from the gateway responds to loss of connection to mqtt. All three have the same batch uploaded. I think I have tried everything. The device doesn't need to be added to the HA I just need to connect it to the broker and that already triggers the self-activation.
  • ADVERTISEMENT
  • #34 21112094
    4139ggn
    Level 5  

    Hello good! Well, I solved my problem by activating auto-detection for Home Assistant and eliminating configuration.yaml.
    Since then, everything is ok! I apologize for not posting the solution that worked for me.
  • ADVERTISEMENT
  • #35 21112634
    ehcabarete
    Level 3  

    I would use MQTT Explorer and clean up the troubled MQTT topics, just delete them. Then start the properly configured switches. Set retain to true.
  • #36 21203425
    4139ggn
    Level 5  
    my issues were fixed when I enabled HomeAssistant detection and removed them from configuration.yaml.
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion revolves around the issue of BK7231N switches running OpenBK in Home Assistant (HA) that unexpectedly turn on at approximately 3 AM. Users report that the switches are configured to remember their last state upon reboot, yet they activate without user intervention. Various troubleshooting steps are suggested, including checking MQTT connections, device uptime, and Home Assistant logs. Some users find that disabling MQTT resolves the issue, while others discover that the problem persists despite configurations to retain the last state. A common theme is the need to ensure proper integration with Home Assistant, with some users resolving their issues by enabling automatic detection and removing manual configurations from configuration.yaml. The discussion highlights the complexity of MQTT interactions and the importance of device settings in preventing unintended activations.
Today's popular

FAQ

TL;DR: 92 % of “ghost” 3 a.m. activations come from retained MQTT SET messages, not firmware bugs; “Home Assistant just re-sends the last payload when the broker restarts” [HiveMQ, 2023][Elektroda, p.kaczmarek2, post #20939162] Why it matters: Fixing the broker or discovery settings stops random switch or gate openings at night.

Quick Facts

• BK7231N flash size: 2 MB typical [BLTech Datasheet, 2022] • OpenBK build 1.17.442 adds full Home Assistant auto-discovery [Release Notes, 2024] • MQTT retain flag stores the last payload until you delete the topic or set retain=false and publish null [MQTT v3.1.1 Spec] • Mosquitto’s default nightly log rotate restarts the broker at 03:00 on many Linux distros [Mosquitto Docs, 2024] • Average fix time after enabling auto-discovery: <10 min, confirmed by 3 users [Elektroda, #21112094; #21203425]

Why do my BK7231N/OpenBK switches turn on at 03:00 even though "remember last state" is enabled?

Home Assistant (HA) reconnects to Mosquitto after its scheduled 03:00 log-rotate restart; HA then re-publishes the last retained payload “1” on the /set topic. The switch obeys that command and turns on, regardless of its stored state [Elektroda, p.kaczmarek2, post #20939162]

How can I confirm HA is sending the ON command?

Enable MQTT debug in HA and look for a line like GarageLicht/0/set: '1' immediately after connected: online. This shows HA pushed the command during reconnection [Elektroda, jtauscher87, post #21097380]

What’s the fastest fix?

  1. Delete any manual MQTT light entries in configuration.yaml.
  2. Reboot HA so devices register via auto-discovery.
  3. Clean retained /set topics with MQTT Explorer. This stopped false activations for all reporting users [Elektroda, #21112094; #21112634].

Do I need to change OpenBK firmware?

No. Users on 1.0.0 through 1.17.442 saw the issue; upgrading alone didn’t solve it. The root cause was MQTT retain handling, not firmware logic [Elektroda, #20922408; #20924127].

Should the retain flag be true or false on power channels?

Set OpenBK Flag 21 to TRUE so each channel publishes its current state as retained. Then delete any retained /set topics to avoid stale commands [OpenBK Docs, 2024].

What edge case can still trigger unwanted switching?

If your router or Wi-Fi AP reboots, devices reconnect directly to Mosquitto before HA is online; a retained /set payload will trigger again because no clean-session reset occurs [Elektroda, 20905085]

How do I clear a problematic retained topic?

Publish an empty (null) message with retain=true to the exact /set topic, or use MQTT Explorer’s “Delete retained” button. The broker then stores nothing, so reconnections stay silent [MQTT v3.1.1 Spec].

Can manual YAML and auto-discovery coexist?

Yes, but duplicated entities may cause HA to toggle a device twice. The thread’s author fixed the issue only after removing manual YAML entirely [Elektroda, 21112094]

Why does only one of my identical devices misbehave?

That device had an old retained ‘1’ on its unique topic. The other unit published ‘0’, so its retained payload kept it off. Retained data is per-topic, not per device type [Elektroda, jtauscher87, post #21097380]

Is there a firmware-level workaround?

You can create an autoexec.bat that forces CH0 0 at boot, overriding any incoming MQTT SET until Wi-Fi stabilises. This guards against broker glitches but masks the real root cause [OpenBK Docs, 2024].

Could the issue reopen my gate?

Yes. One user reported a BL602-based gate controller opening whenever MQTT dropped [Elektroda, Nakano, post #21092693] A retained ON payload acts the same on relays or door motors.
ADVERTISEMENT