logo elektroda
logo elektroda
X
logo elektroda

OpenBeken on WiFi Smoke Detectors (Tuya CBU Chip) - ESP8266 Alternative, MQTT & Setup

toboxx 26151 162
ADVERTISEMENT
  • #61 20588792
    p.kaczmarek2
    Moderator Smart Home
    Update will be required, but testing is not finished. We are still working on that sensor with @DeDaMrAz

    Channels are used to link together behaviours. For example, if you have a smart plug with two relays and two buttons, you can set first relay and button to channel 1, and second relay and second button to channel 2.

    In case of Smoke sensor, you can for example set digital input/"door sensor" input pin to the same channel as you set LED, so LED state will follow state of the input pin.
    You can also use LED_n role, then LED state will follow state of input as well, but it will be invested (LED_n means LED_negated).

    More info soon.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #62 20591611
    array81
    Level 6  
    Therefore the value of the channels is relative, that is, it only serves to connect the various behaviors. As I imagined.
    I look forward to hearing when you finish testing the battery evaluation code. Keep us updated. Thanks for now.
  • #64 20594623
    p.kaczmarek2
    Moderator Smart Home
    Very good job on schematic! I will also most likely have to draw one, as the door sensor I received about a month ago or so (thanks to one user's donation) is a TuyaMCU version, so I can't help much with testing here. I will most likely open a separate topic for that one:
    OpenBeken on WiFi Smoke Detectors (Tuya CBU Chip) - ESP8266 Alternative, MQTT & Setup OpenBeken on WiFi Smoke Detectors (Tuya CBU Chip) - ESP8266 Alternative, MQTT & Setup OpenBeken on WiFi Smoke Detectors (Tuya CBU Chip) - ESP8266 Alternative, MQTT & Setup OpenBeken on WiFi Smoke Detectors (Tuya CBU Chip) - ESP8266 Alternative, MQTT & Setup
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #65 20605760
    DeDaMrAz
    Level 20  
    Sorry for the delay regarding this device, here is the setup that is working for me:

    autoexec.bat

    Battery_Setup 2000 3000 2 2400 4096
    //measure batt every 2s
    Battery_cycle 2
    mqtt_broadcastInterval 1
    mqtt_broadcastItemsPerSec 5
    addEventHandler OnHold 10 SafeMode 5
    
    setChannelLabel 1 Smoke
    setChannelLabel 2 Tamper
    
    again1:
    delay_s 1
    if $CH2!=1 then goto again1
    delay_s 10
    goto again
    
    again:
    delay_s 1
    if $CH1!=1 then goto again
    delay_s 10
    PinDeepSleep


    and pin setup:

      ],
      "pins": {
        "9": "dInput_n;2",
        "15": "dInput_n;1",
        "17": "WifiLED_n;0",
        "23": "BAT_ADC;0",
        "26": "BAT_Relay_n;0",
        "28": "Btn;0"
      },


    OpenBeken on WiFi Smoke Detectors (Tuya CBU Chip) - ESP8266 Alternative, MQTT & Setup

    One small HW modification that I did for tamper switch to raise the alarm if activated upon installation is that I connected a tamper switch floating pin to reset switch like this:

    OpenBeken on WiFi Smoke Detectors (Tuya CBU Chip) - ESP8266 Alternative, MQTT & Setup
    -not perfectly drawn but there is a yellow trace on the top :)

    Please feel free to share your opinions upon testing this setup or if you came across anything better.

    Thanks.
  • #66 20606093
    array81
    Level 6  
    Hi @DeDaMrAz, I'm testing your setup.
    I'd like to understand two things.
    1. on mqtt I received voltage->get and battery-> get. "voltage" gets my battery voltage but what is the "battery" value? It looks like a hole that drops with voltage. I need to figure out how to integrate it with Home Assistant to report low battery.
    2. what is the logic of your code. Doesn't seem to send the device to deep sleep, how often does wifi establish and send data via mqtt?

    Thanks for your job.
  • ADVERTISEMENT
  • #67 20606132
    DeDaMrAz
    Level 20  
    array81 wrote:
    Hi @DeDaMrAz, I'm testing your setup.
    I'd like understand two things.
    1. on mqtt I received voltage->get and battery-> get. "voltage" get my battery voltage but what is the "battery" value? It looks like a whole that drops with voltage. I need to figure out how to integrate it with Home Assistant to report low battery.
    2. what is the logic of your code. Doesn't seem to send the device to deepsleep, how often does wifi establish and send data via mqtt?

    Thanks for your job.


    1. are you using auto discovery?

    2. logic is closely mimicking the original FW that came with the device. If you don't put the back lid on ( close the tamper switch ) it will stay in the loop to check that state. Once you close the lid/back plate (close tamper switch) it will then check if smoke is present and if not device will go to deep sleep. Device can be awaken on smoke sensor (smoke present), test button on the device, if you remove the back lid or press reset switch.

    You can also change WiFiled_n to WiFiled to see when the device is awake/sleeping.
  • #68 20606241
    array81
    Level 6  
    If I understand:
    1. the device disconnects from the network if there are no alarms (smoke or tamper), therefore battery consumption is minimal;
    2. as long as an alarm is active (smoke or tamper) it will remain connected to the wifi and will send the mqtt signal every 2 seconds;

    Questions:
    1. does the device connect to the device and send an update when it detects low battery? I guess yes, so which mqtt message should I consider to monitor battery on Home Assistant? ("battery" or "voltage").
    2. what is "auto discovery"? I use MQTT Explorer to check mqtt message.
  • #69 20606577
    DeDaMrAz
    Level 20  
    array81 wrote:
    If I understand:
    1. the device disconnects from the network if there are no alarms (smoke or tamper), therefore battery consumption is minimal;
    2. as long as an alarm is active (smoke or tamper) it will remain connected to the wifi and will send the mqtt signal every 2 seconds;

    Questions:
    1. does the device connect to the device and send an update when it detects low battery? I guess yes, so which mqtt message should I consider to monitor battery on Home Assiatant? ("battery" or "voltage").
    2. what is "auto discovery"? I use MQTT Explorer to check mqtt message.


    You understood correctly.

    Answers:

    1 - there is no provision atm for reporting battery without an event if device is in deep sleep, to get battery info you will have to wake up the device. And it is voltage that is being reported right now.
    2 - under config on your device you have Home Assistant Configuration

    OpenBeken on WiFi Smoke Detectors (Tuya CBU Chip) - ESP8266 Alternative, MQTT & Setup

    You can start auto discovery form there.
  • #70 20606625
    array81
    Level 6  
    I don't need of "auto discovery" I just have edit my YAML file and I just have 2 entities for alarm and tamper. Besides I think the code on Home Assistant section is wrong, payload_on and payload_off are inverted.
    So there is no way to monitor the battery without turning the device back on. However I noticed that when the battery is low the device turns on and goes into alarm so in fact the message is sent via mqtt. However, I would like to understand what to monitor to manage the low battery level. I want to understand if when the alarm goes off it goes off because the battery is low or because there is a fire. Do I need to check the voltage? If yes, at what level can it be considered low? 2000mV? Or should I monitor the value of "battery"? I understand that below 5 the battery is almost empty. Thank you.
  • #71 20664299
    danielzippert
    Level 2  
    Thanks for this guide!

    Got my smoke sensor working, Flag 37 - [WiFi] Quick connect does also work and improve connection time against my Unifi wifi system.
    And there is no 24h wakeup check if I understand it right?

    For other users, the webapp page only accessable after wifi configuration so it have internet connection. Then you can create autoexec.bat file and add the pin configuration.

    The tamper switch does not wake up my device, if I fire the test button the state changes when the device wakes up and it goes to deep sleep when the tamper goes to off again.
  • #72 20664305
    DeDaMrAz
    Level 20  

    danielzippert wrote:

    That the tamper switch does not wake up my device, if I fire the test button the state changes when the device wakes up and it goes to deep sleep when the tamper goes off again.


    Take a look at that bad picture of mine to add a jumper to the NO side of your tamper switch. It will wake the device from sleep state.
  • #73 20664329
    danielzippert
    Level 2  

    Thanks, it's quite easy soldering, I'll try that!

    I also tried to change the tamper pin config to DoorSnsrWSleep. It wakes up the sensor, but the state is inverted and it seems to put the sensor into deep sleep in weird ways =)
  • #74 20711652
    powerbox822
    Level 1  

    Hello, I also have this device but I can't figure out where to insert the autoexec.bat file. Can you help me?
  • #75 20711677
    p.kaczmarek2
    Moderator Smart Home
    Autexec.bat can be created in LittleFS. Open Web App, and go to FileSystem/LittleFS tab. Use "Create" button to create new file.

    Let me know if you have any further questions.
    Helpful post? Buy me a coffee.
  • #76 20735204
    marnypopis1
    Level 10  

    Hi,

    I bought two YG400A - converted according to the recipe from this topic and from DeDaMrAz's advice - thank you. Autoexec works and such entities appear in Home Assistant.
    Screenshot of a sensor panel in Home Assistant, all marked as unavailable.

    But the sensor has not shown any signs of life on its own for 16 hours - it should wake up every few hours to provide information about its status and then go back to sleep, but this is not the case.

    The problem will be the battery running out - no one will know about it.
    When I press the test button or open it - it wakes up and gives information, but it doesn't do it on its own.

    What did I do wrong?
  • #77 20735416
    p.kaczmarek2
    Moderator Smart Home
    I'm afraid everything is fine for now.

    The current firmware version does not support simultaneous wake-up from GPIO and timer. Either GPIO or timer. We are currently working on supporting both of these methods at the same time.

    You have to wait a bit, unless you know C, then let me know and I will show you more or less what to do. The problem comes down to the fact that the SDK used has no documentation, Beken does not provide anything and you have to guess.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #78 20784352
    xglooom
    Level 8  

    p.kaczmarek2 wrote:
    unless you know C

    I do :)
    Can you suggest how to achieve simultaneous timer and GPIO wake-up?
  • #79 20784511
    p.kaczmarek2
    Moderator Smart Home
    @xglooom actually we got that now, at least on SDK level. A contributor has introduced a patch that allows that. We just need to link it to OBK system.
    You can see more here:
    https://github.com/openshwprojects/OpenBK7231N/pull/18
    I didn't have time yet to integrate it with OBK itself, but maybe you can? Let me know and I will merge this PR into the N SDK for you.

    NOTE: This is only for N SDK right now.
    Helpful post? Buy me a coffee.
  • #80 20799432
    marnypopis1
    Level 10  
    Let me ask you boldly - can you tell me how it will be implemented in the firmware? - which firmware and how to set the wake-up time after the timer
  • #81 20824777
    seemebreakthis
    Level 2  

    New user here. Bought this smoke detector on a whim and then realized tasmota is a no-go. Luckily I stumbled upon OpenBeken, so just wanted to share what I did (as a total newbie) to get things going:

    - When I flashed, I used the side 'connector holes' on the PCB and used the breadboard clamps to connect. To my surprise I only had to connect GND, TX, and RX. When the +3.3V is connected also to my UART, it doesn't work. When disconnected, I then used BK7231flasher.exe and successfully flashed OpenBK7231N_QIO_1.17.308.bin

    - https://github.com/openshwprojects/OpenBK7231T_App/tree/main/docs contains docs to help with initial setup, configuring Wifi etc. In the "Configure Wifi" screen, you can actually assign a static IP address instead of using DHCP (as of firmware 1.17.308). I don't think this is documented.

    - Once Wifi is configured and you can connect through the device's new IP, then it is a matter of setting up MQTT, and then follow @DeDaMrAz's guide to set up the device. Both the autoexec.bat file and the PIN settings are configured within the "Launch Web Application" function.

    - My goal is to integrate the detector into my home assistant, so I went to Config -> Home Assistant Configuration, and copied the lines into configuration.yaml of my home assistant. I noticed the yaml content has a 'retain: true' line which my home assistant didn't like so I had to delete that. And there is an inverted "payload_on" "payload_off" that I had to manually reverse the inversion for the smoke alarm to show 'ON' when triggered (instead of the other way around)

    Outstanding questions I have:

    1. I cannot 'retain' the MQTT messages. As a result after a few minutes, all four 'sensors' (i.e. RSSI, Voltage, Smoke Alarm, Smoke Detector Armed) will have 'unavailable' as the status in home assistant. I mean I can work my way around this and still have a usable smoke detector, but it would be nice for my HA to just continue to show the last known status. How can this be done?

    2. I noticed @array81 in this post said the smoke detector will wake itself up and send alarm when battery is low. Can anyone else confirm? And what voltage should I be expecting when battery is low (so I can write my automation accordingly)?

    3. The most recent comments are hinting on GPIO & timer together can be programmed to wake up the device, so maybe it can be modified in the future to quickly wake up and update the status once everyday or so, on top of the features that are already available. Curious to know that latest progress on this!

    Thank you !! And I hope my notes about will help other newbies on setting up OpenBeken on this particular device in the future.

    Added after 7 [minutes]:

    danielzippert wrote:
    Got my smoke sensor working, Flag 37 - [WiFi] Quick connect does also work and improve connection time against my Unifi wifi system.
    And there is no 24h wakeup check if I understand it right?


    Hi - I am a OpenBeken noob and after searching through the wikis / docs I still have no clue what Flag 37 is and where to set it. Could you guide me through the config so the device can connect to my Wifi quicker? Thanks so much !
  • #82 20824808
    DeDaMrAz
    Level 20  
    @seemebreakthis

    go to your device IP address in your browser of choice, once there you will see 4 button on the bottom of the screen (config, restart, launch web application and about) - click config on the page that opens go to second from the top button that says - Config Genera/Flags and explore there for a bit. I suggest you look into Flag 7 and go from there.

    Timer and GPIO wake up is in the works/planed so hold on tight for that feature.
  • #83 20825323
    p.kaczmarek2
    Moderator Smart Home
    seemebreakthis wrote:

    - When I flashed, I used the side 'connector holes' on the PCB and used the breadboard clamps to connect. To my surprise I only had to connect GND, TX, and RX. When the +3.3V is connected also to my UART, it doesn't work. When disconnected, I then used BK7231flasher.exe and successfully flashed OpenBK7231N_QIO_1.17.308.bin

    I've spoke about it here, it's not yet translated: https://www.elektroda.pl/rtvforum/topic3140885.html but long story short, it's thanks to the clamping input protection diodes and the capacitors on the board

    seemebreakthis wrote:

    - https://github.com/openshwprojects/OpenBK7231T_App/tree/main/docs contains docs to help with initial setup, configuring Wifi etc. In the "Configure Wifi" screen, you can actually assign a static IP address instead of using DHCP (as of firmware 1.17.308). I don't think this is documented.

    Ok I added a mention about that, we really need to reorganize this readme:
    https://github.com/openshwprojects/OpenBK7231...mmit/d539d2c91842ac1197c86aa13717c0e4aab668ba


    seemebreakthis wrote:

    - My goal is to integrate the detector into my home assistant, so I went to Config -> Home Assistant Configuration, and copied the lines into configuration.yaml of my home assistant. I noticed the yaml content has a 'retain: true' line which my home assistant didn't like so I had to delete that. And there is an inverted "payload_on" "payload_off" that I had to manually reverse the inversion for the smoke alarm to show 'ON' when triggered (instead of the other way around)

    I think there are channel types for both kinds.... but I am not sure, what is your config?


    seemebreakthis wrote:

    1. I cannot 'retain' the MQTT messages. As a result after a few minutes, all four 'sensors' (i.e. RSSI, Voltage, Smoke Alarm, Smoke Detector Armed) will have 'unavailable' as the status in home assistant. I mean I can work my way around this and still have a usable smoke detector, but it would be nice for my HA to just continue to show the last known status. How can this be done?

    Have you tried to set a flag for that? For retaining data?

    seemebreakthis wrote:

    3. The most recent comments are hinting on GPIO & timer together can be programmed to wake up the device, so maybe it can be modified in the future to quickly wake up and update the status once everyday or so, on top of the features that are already available. Curious to know that latest progress on this !

    This is ready on SDK level, but not yet integrated, we can try to look into it earlier for you

    seemebreakthis wrote:

    Hi - I am a OpenBeken noob and after searching through the wikis / docs I still have no clue what Flag 37 is and where to set it. Could you guide me through the config so the device can connect to my Wifi quicker? Thanks so much !

    Config -> Flags on OBK web panel
    Helpful post? Buy me a coffee.
  • #84 20825573
    seemebreakthis
    Level 2  

    Thanks to @DeDaMrAz and @p.kaczmarek2's responses. I have managed to accomplish everything I wanted to do. Smoke detector is now permanently installed in my kitchen. 😊 Here are more tips:

    1. I have enabled flag 7 and flag 37. And yes the MQTT topics are now maintained, as can be checked easily with this command:

    mosquitto_sub -t "#" -v


    i.e. basically I just did the most direct test by simply probing directly into my MQTT broker, and have it spit out all the messages. This way I can know for sure that the MQTT messages for my smoke detector are now retained.

    2. But that did not change the behavior in my home assistant. After a few minutes of testing the alarm by pressing on the device's button, every parameter (including the alarm) still became 'unavailable'. The MQTT probing with the 'mosquitto_sub' command revealed what was happening - a topic was actively getting posted by the smoke detector just before it disconnects, with this message:
    <topic>/connected offline
    . So an 'offline' message gets interpreted by home assistant and makes everything related to the smoke detector become 'unavailable'. I changed this behavior at the end by modifying the configuration.yaml in the HA environment to remove the 'availability' section of the setup for my smoke detector (the yaml configuration was generated by OpenBeken that I copied and pasted to configuration.yaml in the first place). Now the alarm status is retained, but the 'RSSI' and 'Voltage' parameters would still get updated to 'unavailable' when the device goes offline for some reason (which doesn't really matter to me).

    ... up and running (and dirt cheap)! And very soon I will be utilizing the PayPal link to donate to OpenBeken. Thank you.

    Smoke detector installed on a kitchen ceiling with a fluorescent light.
  • #85 20825725
    sithyoda
    Level 7  

    p.kaczmarek2 wrote:
    seemebreakthis wrote:
    3. The most recent comments are hinting on GPIO & timer together can be programmed to wake up the device, so maybe it can be modified in the future to quickly wake up and update the status once everyday or so, on top of the features that are already available. Curious to know the latest progress on this!

    This is ready on SDK level, but not yet integrated, we can try to look into it earlier for you


    Would appreciate that too!
  • #86 20919702
    sithyoda
    Level 7  

    I did some tests with my adjustable PSU. The device running OBK v1.17.419 powers on with a voltage of at least 2.12V. Reported percentage is 11% with 2.12V.
    I lowered voltage to 2006mV where 0% were reported.
    Then I continued lowering the voltage down to 827mV until the device went offline.

    Closing the tamper switch and doing the same tests didn't let the device wake up at any voltage - so I'd say, there is currently no reporting of low battery at all.
  • #87 20941214
    rubenlogon
    Level 4  

    Hi all. It seems I got a new board rev. of this sensor. I flashed yesterday openbeken and I configured it as is written here. I noticed that when the battery was going to drain, the smoke sensor started to buzz until the battery finally ran out. Is this behavior only happening in this board revision? For the moment, I keep an eye on the dev repo to see when the gpio+timer sleep function is ready. Thanks for the hard work!
    Purple circular circuit board with mounted electronic components.
  • #88 21038933
    marnypopis1
    Level 10  

    Hello

    In the new OpenBK7231N_1.17.539 software, waking up the smoke sensor via GPIO and Timer - command - DeepSleep xxxx - where these xxxx are seconds.

    I ran the command every 36000 seconds on my 2 sensors and since yesterday it shows me the battery status in my HomeAssistant every 10 hours.
    Here are the details.

    Graph showing battery level of sensor obkB994316A.

    https://www.elektroda.pl/rtvforum/topic4041971.html

    Now I`m completely happy and I know when the battery needs to be replaced
  • #89 21038952
    marnypopis1
    Level 10  

    Hello

    In the new OpenBK7231N_1.17.539 software, works waking up the smoke sensor via GPIO and Timer - command - DeepSleep xxxx - where these xxxx are seconds.

    I ran the command every 36000 seconds on my 2 sensors and since yesterday it shows me the battery status in my HomeAssistant every 10 hours.
    Here are the details.

    Graph showing battery level of smoke detector obkB994316A over time.

    Tuya WiFi smoke detector (CBU chip)

    https://www.elektroda.pl/rtvforum/topic4041971.html

    Now I'm completely happy and I know when the battery needs to be replaced
  • #90 21038998
    p.kaczmarek2
    Moderator Smart Home
    Thank you for testing. I am happy to hear it's working.

    Added after 46 [seconds]:

    PS: If your final configuration is posted as a separate topic, please consider posting it with some description, so people don't have to dig through 3 pages of posts to find a latest autoexec.bat version for deep sleep.
    Helpful post? Buy me a coffee.

Topic summary

The discussion centers on integrating OpenBeken firmware with WiFi smoke detectors using the Tuya CBU chip (BK7231N), as an alternative to ESP8266-based devices. Users successfully flashed OpenBeken (e.g., OpenBK7231N_QIO_1.15.182.bin and later versions) via UART without a separate TuyaMCU chip, indicating a direct BK7231N MCU control. Key challenges include configuring the smoke detection input, tamper switch, LEDs, and battery monitoring, as well as implementing effective deep sleep modes to extend battery life. The smoke sensor output is connected to GPIO pins (notably pin 15), with tamper and reset switches on other pins (e.g., pin 9 and 28). DeepSleep functionality was developed to allow the device to sleep and wake on GPIO events or timers, significantly improving battery autonomy from a few hours to days. Battery voltage measurement is done via ADC on specific pins (e.g., pin 23 and 26), with scripts to monitor and report battery status over MQTT. Users configure pins with roles such as dInput_n, DoorSnsrWSleep, Btn, and WifiLED_n, and use autoexec.bat scripts to manage device behavior, MQTT publishing, and sleep cycles. The device supports MQTT integration with Home Assistant, though full auto-discovery and YAML configuration require manual setup. Some limitations remain, such as the inability to wake the device simultaneously by timer and GPIO in earlier firmware versions, and inconsistent tamper switch wake-up behavior without hardware modification. The community continues to refine firmware, share pin mappings, schematics, and configuration examples to achieve reliable smoke detection reporting, battery status alerts, and power saving. The device is identified as a Tuya WiFi smoke detector with a Holtek BA45F5220 MCU (marked BA50F1V) on the CBU module. The discussion also covers flashing procedures, hardware connections, and troubleshooting for these detectors.
Summary generated by the language model.
ADVERTISEMENT