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).
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.
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:
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:
-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.
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?
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.
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.
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
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.
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.
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.
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 =)
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.
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.
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.
@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.
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 !
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.
- 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.
- 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 !
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:
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:
. 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.
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
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.
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!
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.
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.
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.
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.