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?
- Delete any manual MQTT light entries in configuration.yaml.
- Reboot HA so devices register via auto-discovery.
- 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.
How do I test without touching HA?
Disconnect the device’s MQTT credentials; if it never turns on by itself, your problem is in the broker or HA, not OpenBK [Elektroda, p.kaczmarek2, post #20904909]
