logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda
UV printer on your desk?
UV printer on your desk? Discover eufyMake E1 »
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 4284 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  
    Posts: 14654
    Help: 655
    Rate: 12661
    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  
    Posts: 13
    Rate: 2

    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  
    Posts: 25
    Rate: 2

    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  
    Posts: 36
    Rate: 1

    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  
    Posts: 3
    Help: 1
    Rate: 1

    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  
    Posts: 36
    Rate: 1
    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: If your OpenBK switch turns on around 03:00 and logs show "HA sends value 1", the usual cause is Home Assistant MQTT behavior after reconnect, not a spontaneous OpenBK relay change. This FAQ helps Home Assistant, Mosquitto, and OpenBK users stop night-time self-activation by checking uptime, MQTT topics, and discovery settings. [#20939162]

Why it matters: A relay that flips ON at 03:00 can light rooms, trigger gates, or create unsafe automations after Wi‑Fi or broker reconnects.

Setup choice What the thread showed Result
Manual configuration.yaml MQTT setup Some devices received .../0/set 1 after reconnect Unwanted turn-ons persisted
Home Assistant auto-discovery Problem disappeared after removing manual YAML entries Stable behavior reported
MQTT reconnect without cleanup Devices went unavailable, then reconnected within seconds Some relays turned ON

Key insight: The strongest evidence in the thread is the OpenBK log line showing MQTT received data 1 on the command topic right after reconnect. That points to Home Assistant or retained MQTT state, not random firmware self-activation.

Quick Facts

  • The failure window clustered around 03:00–04:00, including 03:01:00, 04:00:00, and even 05:00 in one history screenshot, which strongly suggests a scheduled network or broker event rather than random relay noise. [#20922408]
  • One affected device reported "Online for 16 hours, 38 minutes, and 8 seconds" after the night event, so at least that case was not caused by a full device reboot. [#20899305]
  • The thread mentions multiple OpenBK builds during testing, including 1.17.405, 1.17.424, and 1.17.442; updating alone did not consistently fix the issue across devices. [#20922408]
  • In the decisive log dump, OpenBK received MQTT payload 1 on topic Interruptor barra/0/set, changed channel 0 to 1, then later published 0 again; that shows an external command path, not a local spontaneous toggle. [#20939156]
  • A later resolution reported that enabling Home Assistant auto-discovery and removing manual configuration.yaml entries fixed the unwanted activations. [#21112094]

Why do BK7231N switches running OpenBK turn on by themselves around 3 AM in Home Assistant?

They usually turn on because Home Assistant or MQTT sends an ON command when the device reconnects around 03:00, not because OpenBK randomly flips the relay. The clearest proof is the OpenBK log showing MQTT received data is 1 for ch 0, then CHANNEL_Set channel 0 has changed to 1. The thread also shows many devices going unavailable between 03:00 and 04:00, then reconnecting seconds later, which matches a broker, router, or HA event window. [#20939156]

How can I tell whether an OpenBK device is actually rebooting at night by checking its uptime?

Check whether the uptime resets near the event time. If the web interface still shows a long session, such as Online for 16 hours, 38 minutes, and 8 seconds, the device did not reboot at 03:00 that night. That distinction matters because a reconnect without reboot points to MQTT, Home Assistant, or network interruptions instead of a firmware crash or power cycle. [#20899305]

What does the OpenBK uptime value mean, and where can I find it in the web interface?

OpenBK uptime is the elapsed time since the device last booted, shown in the device web interface status area. It tells you whether the switch truly restarted or only lost MQTT or Wi‑Fi briefly. In the thread, the developer explicitly asked for the OBK uptime visible in the web UI screenshot, because that value is the quickest way to separate reboot problems from reconnect problems. [#20897704]

Why would a Home Assistant MQTT setup send a '1' to an OpenBK command topic right after the device reconnects?

Home Assistant can send 1 right after reconnect because it restores or republishes state through the MQTT command topic when the device comes back online. The OpenBK log in this case shows mqtt_incoming_publish_cb topic Interruptor barra/0/set, then data is 1 for ch 0, then channel 0 changes to 1. The thread’s expert conclusion was direct: “your HA sends value 1 to OBK just when OBK connects.” [#20939162]

How do I stop OpenBK relays from turning on after Wi‑Fi loss or MQTT reconnect in Home Assistant?

The most successful fix in the thread was to enable Home Assistant auto-discovery and remove old manual MQTT YAML entries. That user reported the issue stopped after switching to discovery and deleting configuration.yaml definitions. If the relay still activates, test with MQTT disabled for one night, then inspect whether .../0/set 1 appears after reconnect. [#21112094]

What is MQTT retain, and how does the OpenBK 'Retain power channels' flag affect switch state recovery?

"MQTT retain" is a broker message setting that stores the last published payload on a topic, so newly reconnected clients immediately receive that saved value. In the thread, the OpenBK maintainer suggested enabling Flag 21 - [MQTT] Retain power channels as a workaround, and also testing retain: true in Home Assistant. It can help state recovery, but users reported it did not fix every device. [#20939306]

Home Assistant MQTT auto-discovery vs manual configuration.yaml for OpenBK devices — which is better for avoiding unwanted turn-ons?

Home Assistant auto-discovery worked better in this thread. Manual configuration.yaml setups were repeatedly linked with reconnect events that sent .../0/set 1, while the original poster later said the problem disappeared after enabling Home Assistant detection and removing manual YAML entries. That makes discovery the safer choice here for avoiding false ON commands after MQTT reconnects. [#21203425]

How do I enable Home Assistant auto-discovery for OpenBK and safely remove the old manual MQTT YAML entries?

Use this 3-step method. 1. Enable Home Assistant detection in OpenBK. 2. Remove or comment out the old manual MQTT switch entries from configuration.yaml. 3. Restart the device and verify Home Assistant recreates it through discovery. The thread’s confirmed fix was exactly that sequence: enable auto-detection, eliminate manual YAML, and the unwanted turn-ons stopped. [#21112094]

Why does an OpenBK switch configured to 'remember last state' still power up ON after a restart?

It powers up ON because the remembered state is not the only factor; Home Assistant can still send an ON command after reconnect. In the thread, the user expected “remember last state” to restore OFF, but logs later showed MQTT pushing 1 to the command topic. So the startup setting may be correct, yet the relay still turns ON because an external MQTT command overrides it moments later. [#20939156]

What should I check in Home Assistant logs, Mosquitto, and router settings if multiple MQTT devices go unavailable between 3:00 and 4:00 AM?

Check for any scheduled restart or reconnect event between 03:00 and 04:00. The thread specifically suggests reviewing Home Assistant uptime, Home Assistant logs, Mosquitto behavior, and whether the router is scheduled to reboot at 03:00. If several devices become unavailable for a few seconds and then reconnect, that pattern fits a network or broker interruption more than a single bad relay. [#20904909]

How can MQTT Explorer help clean up stale retained topics that make OpenBK switches or gates self-activate?

MQTT Explorer can remove stale retained topics so reconnecting devices do not receive an old ON state again. One participant advised deleting the troubled MQTT topics, then starting the correctly configured switches and setting retain to true. That is especially useful when a gate or 2-channel relay self-activates immediately after broker reconnection, even before Home Assistant fully re-adds the device. [#21112634]

What's the best way to test whether Home Assistant, Mosquitto, or OpenBK firmware is causing random relay activation?

Isolate each layer one at a time. First disconnect MQTT and leave the device overnight. Next restart Mosquitto and watch whether the relay turns ON immediately. Then compare OpenBK uptime with Home Assistant logs. If the device stays online for more than 16 hours yet still switches ON after reconnect, the fault path is upstream of the relay logic. That method was repeatedly recommended in the thread. [#20905085]

How do I read OpenBK logs to see whether the relay changed state locally or because MQTT sent a command?

Look for an incoming MQTT publish before the channel change. In the decisive example, the log shows mqtt_incoming_publish_cb topic Interruptor barra/0/set, then mqtt_incoming_data_cb data is 1 for ch 0, and only after that CHANNEL_Set channel 0 has changed to 1. That sequence proves the relay changed because MQTT sent a command, not because the relay logic toggled locally. [#20939156]

Why do two OpenBK or Beken devices with the same flags and config behave differently when reconnecting to the same MQTT broker?

Because the broker or Home Assistant may hold different topic history or entity state for each device. The thread includes cases where two Bekens had identical flags and config, yet only one turned ON after reboot or Wi‑Fi loss. Another user reported three BL602 devices from the same batch, but only one self-activated after MQTT loss. Matching firmware alone did not guarantee matching reconnect behavior. [#21100362]

What is OpenBK, and how does it work with BK7231N, BL602, Mosquitto, and Home Assistant MQTT devices?

"OpenBK is open-source device firmware that runs on chips such as BK7231N and BL602, exposes relay and channel control, and integrates with Home Assistant through MQTT brokers like Mosquitto. In this thread, users ran OpenBK on switches, lamps, and even a gate controller. The practical problem was not basic compatibility, but MQTT reconnect behavior that could send 1 to a relay command topic. [#21092693]
ADVERTISEMENT