logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

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

toboxx 26148 162
ADVERTISEMENT
Reply | New topic
  • #31 20462301
    p.kaczmarek2
    Moderator Smart Home  
    @toboxx thanks! One user has already did a donation here and smoke detector is on my queue list, but if you still want to donate or just accelerate the development, here is my Paypal: https://www.paypal.com/paypalme/openshwprojects
    I have just recently finished youtube videos about donated bulb (BL602 Sonoff) and donated LED strip (Magic Home), more coming soon...
    https://www.youtube.com/watch?v=L6d42IMGhHw
    https://www.youtube.com/watch?v=bs0ylC6xRs0&ab_channel=Elektrodacom
    More coming soon! We are ultimately going to cover every device, but it's a long way, and the less popular things like smoke detectors are very hard to handle.
    But we had a progress with deep sleep power saving!
    I have managed to get it working for Door Sensor, so it might be possible to transfer the experience to Smoke sensor as well....
    Or maybe also just use the same driver directly in case of non-TuyaMCU sensors?

    Here is the topic:
    Door/window sensor without TuyaMCU - deep sleep and energy saving, OpenBeken
    I have to find time to check, but the following approach could be used for non-TuyaMCU smoke sensors, maybe even without code modifications..

    I must find some time to look into that. Days are very short when you're trying to support so many devices.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 20462331
    toboxx
    Level 3  
    I just sent 10 € (plus 0,99 € fee) - thanks already for all your great work!
  • #33 20462378
    DSF4ever
    Level 6  
    @toboxx: Excellent! Thx as well. As I am the other donator, I hope this floods the smoke detector up in the queue list ;-)

    And I am wondering that the smoke detectors should not be popular, as these guys are real lifesavers.
  • #34 20462498
    p.kaczmarek2
    Moderator Smart Home  
    Yes, I'm grateful. Thank you for the support.

    Do both of you guys have a smoke sensors without TuyaMCU? The ones requiring deep sleep on the BK7231 side so the batteries won't drain in one day?

    I am asking because there are two types of low power devices on the market. First type is using TuyaMCU, an external MCU which works all the time in low power mode and only turns on and off WiFi module power (via MOSFET) when data is needed to be reported to the server, and the MCU is using TuyaMCU protocol to communicate with WiFi module, and the second type is where smoke sensor is connected directly to WiFI module and WiFi module is always on, but it's using deep sleep to save energy.

    Here is a measurement data of BK7231T current consumption in active WiFi mode and in deep sleep mode:
    OpenBeken on WiFi Smoke Detectors (Tuya CBU Chip) - ESP8266 Alternative, MQTT & Setup
    Helpful post? Buy me a coffee.
  • #35 20462559
    DSF4ever
    Level 6  
    In my case it's without TuyaMCU, just the BK7231. As mentioned in a former statement, the DeepSleep works well on my BK7231N (OpenBK version 1.15.460). As soon as the smoke detector wakes up and I get an "online" message via MQTT, I send back via MQTT a "DeepSleep = 21600" to get the smoke detector fall asleep for another 6 hours. This runs now for around 2 weeks and I cannot measure any loss of power on the batteries. Voltage is stable.

    Beside may be other smart features, the most important missing feature is that the smoke detector does not wake up via GPIO. So, if there is smoke/fire in my house, in the worst case I need to wait 6 hours to be alarmed. But I doubt that there is anything left after 6 hours of fire :-)
  • #36 20462565
    p.kaczmarek2
    Moderator Smart Home  
    DSF4ever wrote:

    As mentioned in a former statement, the DeepSleep works well on my BK7231N (OpenBK version 1.15.460). As soon as the smoke detector wakes up and I get an "online" message via MQTT, I send back via MQTT a "DeepSleep = 21600" to get the smoke detector fall asleep for another 6 hours. This runs now for around 2 weeks and I cannot measure any loss of power on the batteries. Voltage is stable.

    The thing I mentioned for door switch is different. To be precise, it's a "deep sleep with GPIO wakeup", also called "PinDeepSleep" in the code.
    Please consult those topics:
    Door/window sensor without TuyaMCU - deep sleep and energy saving, OpenBeken
    [OpenBeken] SHT Sensor configuration, commands, and deep sleep usage with wake up on pin change
    In those two examples, the device goes into deep sleep and sleeps until the voltage on IO pin changes. The device can be both waken up by a button press (configuration button) and by door sensor value change (door opens or closes). This is not like "Sleep for 6 hours", this is like "Sleep until something happens". This is a new feature.

    It is very possible that you could just take the driver from the "Door/Window sensor without TuyaMCU" topic, run it on the smoke sensor, just configure the smoke sensor pin as "DoorSensor" pin and it may work..
    Helpful post? Buy me a coffee.
  • #37 20462576
    DSF4ever
    Level 6  
    Aaaaah, excellent!
    Unfortunately I am on a business trip and not at home until Friday evening. But on weekend I will give it a try. I will keep you informed.
    Thanks a lot !!

    Or, eventually @toboxx you might be able to enlighten us sooner. If I remember right you bought 4 of these "no TuyaMCU" smoke detectors.
  • #38 20462584
    p.kaczmarek2
    Moderator Smart Home  
    My first worry would be that the current system reports the current channel value to the server, and not the value that was present at the boot/wakeup time.

    So, if the smoke sensor gives only a spike (for example, a high value, only for 0.25s), then the device will wake up but will report "no smoke".

    But I don't think it's the case, I'd rather assume it reports, let's say, the high value as long as there is a smoke in the test chamber.
    Helpful post? Buy me a coffee.
  • #39 20463137
    danielschiltz34
    Level 2  
    Hello,

    I'm following this topic for quite a while now, and I must say that you people are doing a fantastic job chasing down the issue with deep-sleep. I have also donated in the same context as both members above.

    In this sense, I wish you all a great day
  • ADVERTISEMENT
  • #40 20464003
    p.kaczmarek2
    Moderator Smart Home  
    Thank you, it will be useful for getting new devices or dev boards from online shops. Don't forget that we're also maintaining the Youtube channel:
    https://www.youtube.com/@elektrodacom
    Yesterday I also improved the sensors code. Devices with sensors will now connect to WiFi faster, which means faster reporting and longer battery life. On non-sensor devices, the quick connect is enabled by default because it's experimental, so if you want to take the risk you can enable flag 37 after updating the software. If something goes wrong, do 5 power off/on cycles to go to safe mode and disable flag there.
    Helpful post? Buy me a coffee.
  • #41 20467903
    DSF4ever
    Level 6  
    Hello,

    I just did an upgrade to version OpenBK7231N_1.15.520.rbl and configured Pin 9 and 15 with "DoorSnsrWSleep" (Pin 17 stays with "LED"). After that I initiated a reboot and the smoke detector came back with "Door: time until deep sleep: x", where x is a countdown from 60 seconds to zero.
    When reaching zero I cannot ping the smoke detector's IP address anymore. Great.

    When pressing the test button it takes around 10 seconds until the smoke detector answers my ICMP pings and I get an MQTT message (OpenBK_1/0/get = 1). GREAT, "DeepSleep until something happens" seems to work.
    60 seconds later the smoke detector falls in deep sleep mode again.
    I did as well a test with real smoke and this wakes the smoke detector up as well. Yeaaah !!

    What's not working is the tamper button on the backside. When I open the lid, the smoke detector keeps sleeping.

    Excellent work so far. Thank you very much!
    best regards
  • #42 20467927
    p.kaczmarek2
    Moderator Smart Home  
    Thanks, it is a very early version.

    Which IO is the tamper button and how do you configure it?

    When I was testing, I was getting about 5 second delay from wakeup to HA status change. See:
    https://www.elektroda.pl/rtvforum/topic3960149.html#20465020

    The next problem to solve would be how much do we shorten the current 60s time until next sleep. .We could prolong battery life much by going to sleep earlier. Maybe even after 10 seconds, but.... we would need to support some kind of "configuration mode" and currently firmware is not able to tell which pin was used to wake device up.
    Helpful post? Buy me a coffee.
  • #43 20467948
    DSF4ever
    Level 6  
    Should be PIN 9 and I configured "DoorSnsrWSleep", same as for PIN 15.

    This I found on the first page of this topic:

    "
    This equipment doesn't look like a tuyaMCU, it just has a 10-pin chip with the inscription BA50F1V V5K00KG3 .

    in pin settings:
    9 dinput (back cover button)
    17 LED (front red LED)
    15 dinput (high while smoke is inside)
    28 dinput (reset button, high but stays low after being pressed for 3 seconds. then it goes back to high)

    The front button doesn't seem to have a connection with the CBU chip, it just silences the buzzer and does the test. and he does it without needing configuration as well as the blue LED.
    "

    And when the smoke detector is alive and I open the lid to switch the tamper button I get a MQTT message (same as for smoke and test button -> OpenBK_1/0/get = 1 ).

    For the smoke detector the 60 seconds until next sleep shouldn't be a problem, because the detector should not be often alive (hopefully ;-) ). But this would make a lot of sense for the "door/window sensor without TuyaMCU".
  • #44 20467980
    p.kaczmarek2
    Moderator Smart Home  
    No, only the sensor pin should have sensor role.

    You can set "Button" role for a Button and it will still wake up the device. Can you check if that works for you?

    Altough... maybe you are right with that dInputs. I am not sure yet. The problem with wake up is that if you press a button for a very short time, the device will wakeup but it won't be able to yet tell what has woken it because button state will already return to normal. I must implement some kind of quick GPIO scan just after boot, so the device can tell it was woken up by a configuration button and not by the smoke sensor. At the current state of things, device is not able to tell which GPIO has awoken it and all input GPIOs supports wakeup (so dInput, DoorSensor and Button all will wake up device).
    Helpful post? Buy me a coffee.
  • #45 20468006
    DSF4ever
    Level 6  
    the following I tried on PIN 9:

    - DoorSnsrWSleep -> did not wake up
    - dInput -> did not wake up
    - Btn -> did wake up !!! but I do not see always the switch in ON/OFF state in the web view. Sometimes this works, but often not. With that also the red LED does not work when the lid is open.

    br
  • #46 20497756
    toboxx
    Level 3  
    I was very busy and did not have time to look into this deeper. But I updated my device and set the Pins to DoorSnsrWSleep - now it sleeps and wakes up on tampering or button press. But all states remain 0 in home assistant (they seem to be updated to zero).

    Does anyone have a "full config" example on how to setup the smoke detector, so that it comes up nicely in home assistant?

    Actually, one of the main reasons I bought a smart smoke detector was the ability to detect low batteries in advance. I was far too often annoyed by beeping smoke detectors with low batteries at night...

    Regards and thanks for all your work! Very well spent 10 Euros!
  • #47 20500701
    DSF4ever
    Level 6  
    Hi Folks!

    to be busy seems to be common at the moment, the same is valid for me, as I was the last 4 weeks on business trip during the week and on weekend there was just time to fix the real necessary things in the house :-)

    But the real good news: my smoke detector works still quite well. Means battery is more or less stable at 1.22 Volt since weeks. The drop from 1.5 to 1.22 Volt is probably from playing around a lot at the beginning.

    When pressing the button or open the bottom (tampering) the smoke detector wakes up. What's not perfect, is the fact that there is no stable notification for the buttons. Sometimes I get this MQTT state change: from "OpenBK_1/0/get = 0" to "OpenBK_1/0/get = 1" but not always.

    Actually even with that disadvantage it is enough for me to bring my smoke detectors in live operation, because I get always the MQTT state notification from "OpenBK_1/connected = offline" to "OpenBK_1/connected = online". And when the smoke detector changes to "online", then I get notified (by an OpenHAB rule in my case). If the smoke detector wakes up, because of tampering, or test button or real smoke.... actually i don't care, I need to have a look in any case. People near by should be alarmed by the siren anyway.

    And that's why I ordered another 6 of this smoke detectors at Aliexpress right now :-)

    best regards dsf

    PS: but I am still hoping that fancy features like battery warning, etc. will come up in the future.
  • #48 20502747
    toboxx
    Level 3  
    How could we get battery warnings to work? Connect a lab power supply and decrease the voltage to see what happens? With the original firmware or with openbeken?

    I still never see value 1 for my inputs, they are always reported as 0. Let's hope the "latch inputs on wake up" helps to remedy that situation.

    The missing battery warning is the last thing keeping me from installing the smoke detectors in the house...
  • ADVERTISEMENT
  • #49 20502801
    p.kaczmarek2
    Moderator Smart Home  
    Hello, are you using a raw ADC to measure battery voltage, or a mechanism by @dheenhasty ?

    It should be possible to do something line that in script:
    Code: text Expand Select all Copy to clipboard
    
alias battery_warning publish battery low
alias do_battery_check if $CH2>10&&$CH2<500 then battery_warning
addRepeatingEvent 10 1 do_battery_check

    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md
    I haven't tested it, but it basically says:
    - 10 seconds after reboot, do a battery check (repeats count is 1)
    - in battery check, check if channel 2 is higher than 10 and lower than 500 (customize those variables - the higher than 10 is just to make sure we don't get a fake warning when something is wrong with ADC configuration and CH2 has value 0)
    - if the battery is low, publish topic "battery" with "low" payload

    Added after 40 [seconds]:

    I will test this code later, tell me if you need anything and how it works for you. NOTE: it assumes that ADC pin is set for channel 2 and that ADC in this device can measure battery voltage.

    Added after 1 [minutes]:

    You also may need to increase delay, depending on how fast MQTT connection is... or I may modify the script to check every now and then in a loop until MQTT is on...
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #50 20502979
    toboxx
    Level 3  
    If the battery is connected to the ADC, that could work. However, we would have to regularly wake up to do battery measurement. If the battery voltage is controlled by the other chip, there may be a dedicated GPIO that indicates low battery. I will see what I can find out.

    Added after 33 [minutes]:

    Battery Voltage seems to be present on pin 11 (P22) as long as the OpenBK is off or in deep sleep. When the chip wakes up, it goes down to 0. Strange.
  • #51 20567927
    array81
    Level 6  
    Hi,
    I bought one of these smoke detectors. I thought I could install Tasmota to use it with Home Assistant but unfortunately I also received the YG400A-W model and not the YG400A.
    It's my first experience with OpenBeken. Reading the posts I understand that OpenBeken now supports this sensor. Has the battery life issue been resolved? Does the sensor now wake up in case of smoke and give the alarm?
  • #52 20567948
    p.kaczmarek2
    Moderator Smart Home  
    Battery issue has been resolved and OpenBeken works well on this sensor with DoorSensor driver (pin role DoorSnsWthSleep, or how it was called). The DoorSensor driver will put device into deep sleep and change on GPIO will wake it up.

    You can also choose not to use DoorSensor driver at all and go with dInput or dInput_noPullUp (idk which one will work, see posts above) and script all the behaviour yourself. In autoexec.bat use waitFor to wait for MQTT connection, report state, and go to deep sleep again.
    Examples: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md
    Commands: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/commands.md
    Docs: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/README.md

    See this topic for info on the mechanism used for Deep Sleep on door sensor:
    https://www.elektroda.com/rtvforum/topic3972898.html
    Also see this thread:
    https://www.elektroda.com/rtvforum/topic3960149.html
    Helpful post? Buy me a coffee.
  • #54 20569439
    p.kaczmarek2
    Moderator Smart Home  
    Well, I apologize, it seems that there is indeed no full template for this device yet. It seems you need to read this thread and check what worked for other users. Most likely no one submitted it yet.

    I have also bought a smoke detector for one of the users here, but it arrived with ESP, so I'd have to do a transfer first...

    Unless...
    @DeDaMrAz , do you happen to have such a smoke detector? Maybe we can help @array81 with setup!
    Helpful post? Buy me a coffee.
  • #55 20569916
    array81
    Level 6  
    Thanks for your reply.
    as said it's my first time with OpenBeken. After installing the firmware and doing some tests, I now have this configuration:
    Code: text Expand Select all Copy to clipboard
    
{
  "vendor": "Tuya",
  "bDetailed": "0",
  "name": "Full Device Name Here",
  "model": "enter short model name here",
  "chip": "BK7231N",
  "board": "TODO",
  "flags": "1024",
  "keywords": [
    "TODO",
    "TODO",
    "TODO"
  ],
  "pins": {
    "9": "DoorSnsrWSleep;54",
    "15": "DoorSnsrWSleep;1",
    "17": "LED;46",
    "28": "Btn;35"
  },
  "command": "",
  "image": "https://obrazki.elektroda.pl/YOUR_IMAGE.jpg",
  "wiki": "https://www.elektroda.com/rtvforum/topic_YOUR_TOPIC.html"
}


    Initially the red led was on, but I must have changed something and now it's always off. When should it turn on?
    The values 35, 46 and 54 I got them from GPIO Finder but I didn't understand if they are just references or if they have some meaning instead.
    I'd like the sensor to send the current PIN status via MQTT on startup so that I have reference values. Without waiting for the first activation of the PIN. It's possible?
    You say "In autoexec.bat use waitFor to wait for MQTT connection, report state, and go to deep sleep again."
    I haven't figured out how to do this yet and I haven't. I would like to understand why I need to do this.
    Lastly, is there a way to send the battery status via MQTT when the sensor starts up (or when it wakes up)? Above you talk about it but I don't quite understand how to do it.
  • #56 20569926
    DeDaMrAz
    Level 20  
    Here is what I found out so far, this is based on Holtek BA45F5220 MCU, that is the IC on the board marked - BA50F1V(!!) and and Tuya CBU module.

    Here is the what the configuration should look like but I need to test it further:

    P9 - tamper switch pulled up by 1Mohm
    P28 - the reset switch also pulled up by 1Mohm
    P26 - configured to be pulled down as a batt relay
    ADC - used in conjunction with P26 for batt reading
    P15 - the probably the output from this onboard MCU (need to confirm and test further!!)
    P17 - RED LED

    The bottom switch is controlled by that MCU so is the "alarm" LED (just a guess at this point).

    I will continue testing it tomorrow and report my findings here with more details and findings.

    Also original FW backup is attached.
    Attachments:
  • #57 20575781
    toboxx
    Level 3  
    @DeDaMrAz glad to hear you are working on this, especially the battery reading! Do you have some code snippets to periodically (maybe once a day?) set P26 and read the ADC and send a message on low battery?
  • #58 20578834
    array81
    Level 6  
    When should the red LED light up? With my configuration it is always off (even if the alarm is triggered or the tamper is activated). There is only the blue LED which lights up every 40 seconds.
  • #59 20588381
    p.kaczmarek2
    Moderator Smart Home  
    I am working on this sensor with @DeDaMrAz , currently looked into battery measurement, here are details:
    https://www.elektroda.com/rtvforum/topic3959103.html#20588380


    array81 wrote:
    When should the red LED light up? With my configuration it is always off (even if the alarm is triggered or the tamper is activated). There is only the blue LED which lights up every 40 seconds.

    It depends on how you've configured it. You can do whatever you want with LED in OBK. Which channel have you set for LED? Is it the channel of smoke sensor? Or other channel?
    Helpful post? Buy me a coffee.
  • #60 20588779
    array81
    Level 6  
    Thanks for your reply.

    About "battery measurement". How do I use the code on my device? Do I need to update the firmware? As?
    About "channel". I honestly didn't understand what the channel values correspond to. I also tried looking at the documentation but didn't find what I was looking for. I therefore left the values that the firmware set for me by default:
    Code: text Expand Select all Copy to clipboard
    
  "pins": {
    "9": "DoorSnsrWSleep;54",
    "15": "DoorSnsrWSleep;1",
    "17": "LED;46",
    "28": "Btn;35"

    They are wrong?
    The problem is also the fact that I immediately changed the firmware, so I don't know what the correct behavior of the red led was with the TYUA firmware. That is when the red LED lights up.
Reply | New topic
Report a violation of the law

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.
Popular Topics
ADVERTISEMENT