Name : Tuya smoke detector Producer : MBG Line Model : VS-P443W
Sensor purchased on Allegro for PLN 118. It has a smoke ppm indicator, battery level indicator and an alarm trigger if the smoke level is exceeded. Works with the Tuya app.
teardown:
Disassembly of the sensor is very easy - the housing is on plastic latches, and the PCB has only one screw. On the board, apart from CB3S, there is also CX32L003(F8) and it is to it, not to CB3S, that the pins RXD, TXD, GND and +3V and +3V, GND, SWC, SWD are visible.
Probably the main microcontroller here is ARM, and CB3S is used to receive data digitally and transmit it over Wifi. Given that it is not ESP, the only alternative may be OpenBeken, but at the moment I have no idea how to run this sensor on an alternative fw.
The MCU runs all the time and controls the CB3S power supply. CB3S is only enabled when status needs to be reported. The MCU via UART (the same as for programming, i.e. TX1 and RX1) reports data to CB3S via the TuyaMCU protocol, and when the WiFI module forwards them, the MCU turns it off again.
TuyaMCU reports variables described as dpID + type + value, you will have to guess what dpID means. Probably the smoke detection status will be 1 or 0 and type bool, and e.g. battery level type enum (or value?) and values 0, 1, 2 and 3.
Then you need to write autoexec.bat for OBK where you map dpID to channels and give them meanings (channel types), HASS discovery should work in this case (it was improved at the beginning of May).
Then you need to upload OBK, here is also a bit of fun, because the MCU will turn off the WiFi module and block the UART line, so you must probably cut the UART paths and connect your own power supply ...
I recommend trying to run it as part of sports, quite a lot of work has already gone into supporting this type of device so maybe it will go smoothly.
PS: There is always an alternative - throw out the MCU and if the smoke detector with the hardware (I didn't analyze it in depth) shows 0 or 1 digits then it can be done on OpenBeken itself just like the door contact without the MCU (use OBK deep sleep and pin wake).
I pulled the sensor data through Tuya IoT Platform using API Explorer → Smart Home Device System → Device control → Get Device Specification Attribute :
Here is the dpID list for this device:
Code: JSON
Log in, to see the code
Automatic OBK Tuya config loading and missing smoke channel types
Can you elaborate on how you got it, or write a mini-tutorial about it? One person already mentioned this, but I'm not familiar with this approach. Additionally, do you have this data in some JSON or XML pretty? Maybe it would be possible to automatically generate the OBK configuration.
By the way, in recent days, I added automatic device configuration with OBK, but without TuyaMCU. If you use the latest version of the flasher: https://github.com/openshwprojects/BK7231GUIFlashTool then cfg Tuya will load itself, it will appear in a new window and may even upload to OBK if you enable this option. You can also download the Tuya configuration from the already programmed OBK device (it is not overwritten) via Web App -> Flash -> Download Tuya Config and drag and drop the bin file to our tool:
Coming back to the topic... now you have to enter this into autoexec.bat while respecting the OBK channel types: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/channelTypes.md Not all types will probably be present, I can add something if needed. But I can see that BatteryLevelPercent already is, is also ReadOnlyLowMidHigh , apparently there is no special type dedicated to detection status...
In case of need, you can always give the type TextField or ReadOnly and it will also work, only the automatic Hass Discovery will not know how to connect it.
If you want, wait, I'll find a moment, I'll add the missing channel types along with their Hass Discovery, from what I see, at least SmokeState (1 or 0), SmokeLevel (0-100) is missing
I edited the post and added info on how to extract dpID (you can also use Debug device in a more limited form, but API Explorer has all the info right away).
As for the GUI flasher, I don't know how now, but when I was messing with the door opening sensor under Linux, it started up via mono, but I was unable to download or upload the firmware with it, so I had to use uartprogram. As far as I know, I'm not the only person who encountered this error:
Going to start reading at offset 0x00...
Reading 0x00... failed with serial.BytesToRead 4095 (expected 4111)
The beginning of buffer in UART contains 040EFF01E0FCF4061009000000200069 data.
Failed! There was no result to save.
This Hass Discovery of custom channel types is only a week or two old, so it's constantly being improved.
nihildiximus wrote:
As for the GUI flasher, I don't know how now, but when I was messing with the door opening sensor under Linux, it started up via mono, but I was unable to download or upload the firmware with it, so I had to use uartprogram.
On the flasher you can drag and drop the 2MB bin file or even the Tuya Config partition itself downloaded from the OBK Web App and it will also work. You don't necessarily need to read data via UART.
nihildiximus wrote:
As far as I know, I'm not the only person who encountered this error:
If you have any idea what could be wrong, let me know, I don't know why it loses bytes. Is this error from you? First bytes match, looks like some bytes get lost after that, except initial 0x04 0x0e 0xff 0x01 0xe0
Maybe something works differently on the systems... maybe this timeout is messing it up? If I gave you the exe version with this changed (or exported to CFG), would you test if it helps? EDIT: But this timeout should not spoil, then I check BytesToRead in a loop until they reach the expected number of bytes ... I don't know, but if you have the opportunity to test it, I'll add some configuration of it and we'll see.
In fact, you can think about adding to this flasher or to other tools the option of extracting the dpID or even the entire configuration of the device via the Tuya API after entering the Access ID and Access Secret, which would allow you to create a ready configuration for the FW based on a json file.
Added after 2 [minutes]:
p.kaczmarek2 wrote:
If I gave you the exe version with this changed (or exported to CFG), would you test if it helps? EDIT: But this timeout should not spoil, then I check BytesToRead in a loop until they reach the expected number of bytes ... I don't know, but if you have the opportunity to test it, I'll add some configuration of it and we'll see.
You can drop it in your spare time I'll test it on this sensor.
Make sure stock options: what do they change, and exactly, in turn, whether: 1. Does changing cfg_readReplyStyle from 0 to 1 and then read help anything? 2. Does changing the multiple times (in both cases), e.g. to 10 (10 times longer timeouts) help anything?
Attachments:
flashertest-20230515.zip(444.49 KB)
You must be logged in to download this attachment.
I'm just thinking loud...
When only powering the CB3S with the Tuya original firmware, I get the following bytes in TuyaMCU Explorer/Analyzer:
//R 07.07.2023 16:50:50 WiFi received:
55AA0001000000
//R 07.07.2023 16:50:52 WiFi received:
55AA0001000000
Does it mean, that the CBS3 wants to tell the MCU 'I am present'?
As the Tuya MCU itself is not powered, it cannot answer. Unfortunatelly this message every second is preventing BK7231 Easy UART Flasher to work properly.
So, either the CB3S can be convinced to shut off (how? 1st grounding its RST pin or 2nd pulling down CEN pin did not help in my case) or...
Would it help, if the Flasher recognises this message and would somehow quieten the CB3S before starting?
Whereas I did not understand, why 2nd did not work here. And it is the question, whether the Flasher could start without pulling down CEN?
At the moment I see no way to flash my Tuya smoke sensor. Had somebody success, meanwhile?
✨ The discussion revolves around the Tuya smoke detector model VS-P443W produced by MBG Line, focusing on its teardown and functionality. Users analyze the device's architecture, identifying it as utilizing the TuyaMCU protocol for communication between the MCU and the CB3S Wi-Fi module. The MCU manages power and reports data, including smoke detection status and battery level, through UART. Participants share insights on extracting device specifications via the Tuya IoT Platform, including dpID values for various functions. There are also discussions on flashing the device firmware, troubleshooting UART communication issues, and integrating with Home Assistant for enhanced functionality. The conversation highlights the potential for automatic configuration extraction from the Tuya API to streamline firmware updates. AI summary based on the discussion. May contain errors.
TL;DR: For a PLN 118 VS-P443W smoke detector, “capture UART packets first” is the safest expert path: this FAQ helps CB3S/BK7231N users identify TuyaMCU dpIDs, plan OpenBeken mapping, and avoid flashing failures on a battery-powered Tuya smoke sensor. [#20581006]
Why it matters: A smoke detector is a life-safety device, so firmware changes must preserve alarm behavior, battery reporting, and reliable Wi-Fi event delivery.
Option
Specific value in this thread
Main benefit
Main risk
Original Tuya firmware
CB3S with Tuya app
Known app support and cloud dpIDs
Cloud dependency remains
OpenBeken on CB3S
BK7231N alternative firmware
Local integration and Home Assistant discovery
Flashing can be blocked by MCU power control
Remove/bypass MCU logic
OBK deep sleep plus pin wake
Simpler local design if detector output is digital
Requires deeper hardware analysis
Key insight: The CX32L003F8 appears to run the detector logic continuously, while CB3S wakes for Wi-Fi reporting. Treat the device as a battery TuyaMCU product before flashing or mapping OpenBeken channels.
Quick Facts
Model and price: MBG Line VS-P443W Tuya smoke detector, bought on Allegro for PLN 118, with smoke ppm, battery level, and alarm reporting. [#20580704]
PCB and chips: PA-443W_V.1.1 dated 2021.06.15, CB3S based on BK7231N, plus CX32L003F8 ARM Cortex-M0+ 32-bit controller. [#20580704]
Tuya IoT category is ywbj; exposed dpIDs include 1, 2, 14, 15, and 16 for smoke, battery, and muffling functions. [#20581469]
UART analysis should start at 9600 baud or 115200 baud, then decode TuyaMCU frames with TuyaMCUAnalyzer. [#20581006]
A reported flasher failure showed serial.BytesToRead 4095, while the tool expected 4111 bytes during BK7231 reading under Linux/Mono. [#20581520]
What components are inside the MBG Line VS-P443W Tuya smoke detector with CB3S/BK7231N?
The detector contains a CB3S Wi-Fi module, a BK7231N chipset, and a CX32L003F8 ARM controller. The PCB marking is PA-443W_V.1.1, dated 2021.06.15. The device also exposes pads marked RXD, TXD, GND, +3V, SWC, and SWD. The author bought this MBG Line VS-P443W Tuya smoke detector for PLN 118 on Allegro. [#20580704]
How do you disassemble the MBG Line VS-P443W Tuya smoke detector without damaging the plastic latches or PCB?
Open the housing by releasing the plastic latches, then remove one PCB screw. Use light pressure around the case edge, because the thread states the disassembly is “very easy.” After opening, lift the board carefully and avoid pulling on soldered points near RXD, TXD, GND, and +3V. The PCB has only one screw, so forcing the board is unnecessary. [#20580704]
What is TuyaMCU and how does it work in a battery-powered Tuya smoke detector?
TuyaMCU is the control protocol and architecture where a low-power MCU reports datapoints to a Tuya Wi-Fi module. "TuyaMCU is a serial device-control scheme that sends dpID, type, and value fields between a main MCU and Wi-Fi module, letting battery devices power Wi-Fi only when status must be reported." In this detector, the MCU powers CB3S only when smoke or battery status needs reporting. [#20581006]
How can I extract dpID information for a Tuya smoke detector using the Tuya IoT Platform API Explorer?
Use Tuya IoT Platform API Explorer to read the device specification attributes. The procedure is:
Open API Explorer.
Choose Smart Home Device System → Device control.
Run Get Device Specification Attribute for the smoke detector.
This returned category ywbj and the dpID list for the VS-P443W, including status and function entries. [#20581469]
Which dpIDs are used by the MBG Line VS-P443W smoke detector for smoke status, smoke value, battery state, battery percentage, and muffling?
The VS-P443W uses dpID 1 for smoke status and dpID 2 for smoke value. Battery state uses dpID 14, and battery percentage uses dpID 15. Muffling uses dpID 16 as a Boolean function and status. Smoke status is an enum with alarm and normal; battery state is low, middle, or high. [#20581469]
How do I map TuyaMCU dpIDs to OpenBeken channels in autoexec.bat for a BK7231N smoke detector?
Map each TuyaMCU dpID to an OpenBeken channel, then assign the closest channel type. Use dpID 15 as BatteryLevelPercent and dpID 14 as ReadOnlyLowMidHigh. For dpID 2, OpenBeken added SmokePercent with Home Assistant Discovery support. If a dedicated type is missing, use TextField or ReadOnly, but Home Assistant discovery will be less specific. [#20581500]
OpenBeken vs original Tuya firmware — which is better for a CB3S-based smoke detector?
Original Tuya firmware is better for an unmodified life-safety detector, while OpenBeken suits local-control experiments. The Tuya firmware already reports smoke, battery, and muffling through known dpIDs 1, 2, 14, 15, and 16. OpenBeken can support TuyaMCU devices, but flashing may require cutting UART paths and powering CB3S separately. Use OpenBeken only after confirming alarm behavior remains reliable. [#20581006]
Why does the CX32L003F8 ARM microcontroller appear to be the main controller while CB3S only handles Wi-Fi in this smoke detector?
The CX32L003F8 appears central because the visible UART, power, SWC, and SWD pads connect to it, not CB3S. The thread describes the ARM MCU as controlling CB3S power. CB3S wakes only when the detector must report status over Wi-Fi. That layout matches a battery-powered design that keeps Wi-Fi off most of the time. [#20580704]
How can I capture and analyze TuyaMCU UART packets from a CB3S smoke detector using RealTerm and TuyaMCUAnalyzer?
Capture the UART traffic between the CX32L003F8 and CB3S, then decode it with TuyaMCUAnalyzer. Connect to TX1, RX1, and GND, record serial frames in RealTerm, and import the captured data into TuyaMCUAnalyzer. The expert advice was direct: “capture UART packets” before writing the OpenBeken autoexec.bat mapping. [#20581006]
What baud rate should I try when sniffing TuyaMCU communication between CX32L003F8 and CB3S?
Try 9600 baud first, then 115200 baud if frames do not decode correctly. The thread names both baud rates for TuyaMCU packet capture. Valid TuyaMCU frames commonly begin with 55AA, as shown later by the repeated packet 55AA0001000000. Record enough traffic to see smoke, battery, and status events. [#20581006]
How can I flash OpenBeken to a battery-powered Tuya smoke detector when the MCU controls power to the CB3S Wi-Fi module?
Power CB3S independently and isolate UART if the MCU blocks flashing. The MCU can turn off the Wi-Fi module and occupy the UART line. The suggested approach is to cut the UART paths if needed, connect an external 3V supply, and then flash OpenBeken directly to CB3S. This is more complex than mains-powered BK7231 devices. [#20581006]
Why does BK7231 Easy UART Flasher fail with serial.BytesToRead errors on Linux or Mono when reading BK7231 firmware?
The flasher can lose or miss bytes during UART reading under Linux/Mono. One reported read expected 4111 bytes but received serial.BytesToRead 4095. The buffer began with 040EFF01E0FCF4061009000000200069, but the operation failed without saving a result. The thread suggests timeout or reply-style differences as possible test points, not a confirmed root cause. [#20581520]
What does the repeating TuyaMCU packet 55AA0001000000 from a CB3S module mean when the main MCU is not powered?
The packet 55AA0001000000 is a repeated TuyaMCU Wi-Fi message from CB3S when the main MCU cannot answer. In the report, it appeared every second while only CB3S had power and the Tuya MCU was off. The user interpreted it as a possible “I am present” signal, and it interfered with BK7231 Easy UART Flasher. [#20645800]
How can I stop or bypass CB3S UART messages that interfere with BK7231 Easy UART Flasher on a Tuya smoke sensor?
Isolate the flashing UART or control CB3S power so the repeated TuyaMCU messages cannot collide with the flasher. Grounding RST or pulling CEN down did not help in one reported case. Cutting UART paths and using a separate 3V supply was the earlier suggested workaround for battery TuyaMCU devices. A flasher-side filter for 55AA0001000000 was only proposed, not confirmed. [#20645800]
What safety precautions should I consider before modifying firmware or hardware on a Tuya smoke detector used for fire detection?
Do not rely on a modified smoke detector for fire safety until you retest alarm, battery, and reporting functions. This model reports smoke status on dpID 1, smoke value on dpID 2, battery state on dpID 14, and battery percentage on dpID 15. Flashing can disrupt MCU power control or UART communication. Keep a certified, unmodified detector active during any experiment. [#20581469]
AI summary based on the discussion. May contain errors.