FAQ
TL;DR: For owners of this CB3S smoke detector, 9600 baud is the working baseline, and one expert conclusion was: "this device can be marked as working." Capture TuyaMCU UART before flashing, keep the detector powered from its 9V battery contacts, and map dpID 2/14/15 in OpenBK7231T for smoke and battery reporting to Home Assistant. [#21436840]
Why it matters: This thread shows the exact conditions needed to make a battery-powered Tuya smoke alarm usable with OpenBK7231T instead of guessing at wiring, power, and dpID mapping.
| Option |
What it replaces |
Reported result in this thread |
Main limitation |
| OpenBK7231T |
CB3S Wi-Fi module firmware |
Confirmed working at 9600 baud with smoke and battery entities |
Needs correct autoexec.bat and battery-style power behavior |
| ESPHome |
Wi-Fi-side integration/logging |
UART logs captured, but HA use was described as ineffective |
Device may stay in low-power mode |
| Tasmota |
Wi-Fi module firmware only |
Same TuyaMCU model as OBK conceptually |
Still depends on original MCU and dpID discovery |
Key insight: The onboard MCU, not the Wi-Fi module, controls when CB3S powers up. If you force 3.3V onto the module, TuyaMCU transactions may never start at the right time.
Quick Facts
- Hardware identified in the thread: CB3S Wi-Fi module, CX32L003F8 additional MCU, and an optical smoke detector sensor path. [#20690604]
- Power behavior matters: the detector is battery-powered from a 9V battery, and the Wi-Fi module only wakes long enough to report state. [#20715500]
- Confirmed datapoints on this model: dpID 2 = smoke value 0-100, dpID 14 = battery enum, dpID 15 = battery percentage 0-100%. [#21436840]
- Observed smoke thresholds were practical, not binary-only: one user saw beeping at about 20% smoke, while heavy smoke drove the reported value near 99. [#21436840]
- For programming access, full CB3S removal can be avoided by removing R20 and R23 on the UART lines during flashing. [#21436840]
How do I capture TuyaMCU UART packets on this CB3S + CX32L003F8 smoke detector before flashing OpenBK7231T?
Capture both UART directions before flashing. 1. Power the detector normally from its battery contacts. 2. Start a live UART log and trigger one event at a time, such as tamper or smoke. 3. Stop the log and note which dpID changed for that single event. That method was recommended because the useful goal is not just raw traffic, but mapping each dpID to a meaning before OpenBK7231T replaces the CB3S firmware.
[#20719397]
What is a TuyaMCU device, and how does it differ from a standalone Wi-Fi smoke detector?
A TuyaMCU device uses two processors, not one.
"TuyaMCU" is a dual-chip control architecture that keeps the original MCU in charge of sensors and power, while a separate Wi-Fi module handles cloud and network communication. In this detector, CB3S is the Wi-Fi side and CX32L003F8 is the additional MCU. A standalone Wi-Fi detector would not need this MCU-to-Wi-Fi dpID exchange to expose smoke and battery data.
[#20691641]
What is a dpID in TuyaMCU communication, and how do I figure out which dpID matches smoke, battery, or tamper status?
A dpID is the data-point identifier used by TuyaMCU packets.
"dpID is a protocol field that labels one device variable, such as smoke level, battery state, or tamper state, and pairs it with a value type like enum or integer." To identify each one, trigger exactly one action per capture and record which dpID changes. In this thread, dpID 2 matched smoke, and dpID 15 matched battery percentage.
[#20719397]
Why does this battery-powered Tuya smoke detector need to be powered from its battery contacts instead of an external 3.3V supply when sniffing UART traffic?
It must use the battery path because the MCU decides when the Wi-Fi module gets power. The thread states the MCU switches CB3S on only to report status, so forcing external 3.3V onto the Wi-Fi module does not recreate normal timing. That is why a forced supply can leave you with no meaningful transaction, even though the module itself is powered.
[#20716538]
How should I wire RX, TX, and GND to log UART traffic from the Tuya Smart Wi-Fi smoke detector without interfering with the MCU?
Use a passive logging setup and avoid powering CB3S externally. Connect GND and one UART receive path at a time for capture, first RX, then TX, while the detector stays powered as in normal use. The thread explicitly says not to power the Wi-Fi module externally, because the MCU may still sleep and no valid exchange will occur.
[#20716538]
Which autoexec.bat settings work for this CB3S smoke detector in OpenBK7231T, including dpID 2, dpID 14, and dpID 15?
The working baseline uses TuyaMCU and tmSensor at 9600 baud with three linked datapoints. Use
startDriver TuyaMCU,
startDriver tmSensor,
tuyaMCU_setBaudRate 9600, then map dpID 2 as smoke percent, dpID 14 as battery enum, and dpID 15 as battery percentage. One confirmed config used
SmokePercent,
ReadOnlyLowMidHigh, and
BatteryPercent channel types, and it worked in Home Assistant.
[#21436840]
Why do all sensors stay at 0.0 in OpenBK7231T even after creating an autoexec.bat for the TuyaMCU smoke detector?
The usual cause is that the Wi-Fi module is powered in the wrong way or the UART session never starts correctly. In this thread, one user saw only
0.0 on all configured sensors after creating autoexec.bat, while another later confirmed the same type worked at 9600 baud on a similar board. That points to a board-version difference, wiring issue, or missed TX2 logging, not proof that the detector family is unsupported.
[#20807426]
How does OpenBK7231T compare with ESPHome or Tasmota for TuyaMCU smoke detectors that power the Wi-Fi module only on demand?
OpenBK7231T fits this detector better when you need TuyaMCU mapping and automatic Home Assistant discovery. The thread says Tasmota, like OBK, replaces only the Wi-Fi module firmware and leaves the MCU running original logic. ESPHome was useful for UART logging, but one user said it was hard to make effective with Home Assistant because the device likely forced Wi-Fi into low-power mode.
[#20803879]
What do dpID 1, dpID 2, dpID 14, dpID 15, and possibly dpID 16 do on this Tuya smoke detector?
On this detector, dpID 2 is the smoke value, dpID 14 is battery state, and dpID 15 is battery percentage. A later working report said dpID 1 appeared present but stayed at
1 all the time, so it was not needed for useful HA reporting. The same post also suggested dpID 16 might be a siren-silencer toggle, but it was not confirmed as required for basic operation.
[#21436840]
How can I safely flash the CB3S module without fully desoldering it, and what is the purpose of removing resistors R20 and R23 during programming?
You can flash it without fully removing CB3S by isolating the UART lines. One successful report says removing resistors
R20 and R23 is enough during writing, because those parts sit on TX and RX and prevent the rest of the board from loading the programming signals. That approach reduces rework and avoids complete module desoldering.
[#21436840]
Why does the official Tuya or Home Assistant integration sometimes fail to update the smoke alarm state on this detector?
It can miss events because this detector does not stay continuously online. One user tested real smoke and said the official Home Assistant integration failed to update the smoke alarm entity, even though the hardware alarm occurred. Another later observed the detector stays on Wi-Fi only about
15-20 seconds after the test button, which explains why cloud or integration updates can be inconsistent.
[#20807426]
How can I restore the original firmware and RF/MAC data after a failed OBK flash that leaves the device with MAC C8:47:8C:00:00:00?
Restore the RF area from a valid
2MB backup. The thread describes failed writes that revived devices with MAC
C8:47:8C:00:00:00, and the direct reply says RF can be easily restored if you have the backup. Without that dump, re-pairing and Tuya cloud behavior may remain broken, so backing up flash before experiments is the safe path.
[#20807459]
What is the best way to use quick connect or fast reconnect so this battery-powered smoke detector stays online long enough to report alarms to Home Assistant?
Enable quick connect and rely on the detector’s normal wake cycle. A working report says that after pressing the test button, the device joins Wi-Fi and stays up for about
15-20 seconds, which is enough time to reach the web app and update config. The same user enabled the quick connect flag and reported practical smoke handling, including alarm behavior around
20% smoke.
[#21436840]
How do I invert a TuyaMCU enum or value in linkTuyaMCUOutputToChannel when SmokeStatus reports the opposite state?
Use the optional inverse parameter at the end of
linkTuyaMCUOutputToChannel. The thread gives the exact parameter order:
[dpId] [varType] [channelID] [bDPCache] [mult] [bInverse]. For inversion, set dpCache to
0, multiplier to
1, and bInverse to
1. That tells the driver to invert the value before saving it to the channel.
[#21694358]
How can I convert the smoke status from this TuyaMCU detector directly into a BinarySensor in autoexec.bat?
This thread does not provide a confirmed BinarySensor-ready line for this detector. The user tried mapping dpID 1 as an enum with inversion on firmware
1.18.176, but reported the result stayed at zero after the change. The only confirmed working setup in the thread is the value-based approach, where smoke uses dpID 2 as a percentage instead of relying on dpID 1 as a binary state.
[#21694639]
Generated by the language model.
