Tuya Smart Wi-Fi Smoke Detector: Exploring WiFi Module CB3S & MCU CX32L003F8

Question

WiFi module: CB3S Additional MCU: CX32L003F8 Sensor type: optical smoke detector same chips as on but PCB layout and maybe sensor look different

p.kaczmarek2 · Answer

Thanks, it looks like a TuyaMCU device. Have you tried to capture the TuyaMCU packets?

arhismece · Answer

Yes, looks pretty similar to topic3978070 but with slightly different PCB and sensorNo I'm in the middle of the move and setting up a new lab, so all my equipment is in boxes + I need to go on vacation in a few days, so total clusterfsck here. Need to find some PSU and some LA and some UART2USB adapter, and I'll sniff the communication and update the topic.If I understood properly, openBK only replaces the CB3S part of the code, so the 32-bit ARM on board will run the original firmware and turn CB3S on/off as originally designed? I'll try to get this data sniffed before I leave for vacation. I have a whole bunch of switches and sockets too (total clusterf too, I purchased one to test 3 years ago when I purchased this house, it was ESP8266 / ESP8265 based ecosystem, when I was ready to install as the renovation was ending I ordered over 100 devices assuming they are ESP, what came is Tuya system with WB3S )

p.kaczmarek2 · Answer

It's the same with Tasmota. Tasmota also replaces only WiFi module firmare, and the MCU runs original one. We have TuyaMCU support so we just need packet captures to figure out dpIDs and types of the variables. By the way, it also looks like your device is battery-powered. It means that the MCU controls the power of WiFI module via transistor. It only powers on the WiFI module to report the state to the cloud. It may be problematic to flash such devices, but I've managed to get them working with OBK as well. We have some threads on that topic here on the forum.

aleshinalekseya · Answer

I have this device. How can I help? I want an alternative firmware. Do I need to flash OpenBK7231T first? Added after 3 [minutes]:The original firmware shows nonsense

p.kaczmarek2 · Answer

It can't show nonsense, unless it's broken. Doing a full UART capture from both RX->TX and TX->RX lines certainly can help and should be done before flashing new firmware. We need to know dpIDs of variables, etc, which dpID is which variable, etc Try doing capture from the second UART lane.

aleshinalekseya · Answer

This device is powered by Added after 11 [minutes]:Do I need device power or just 3V UART power?How to connect correctly? UART RX-TX onlyMain device power Added after 4 [minutes]:

p.kaczmarek2 · Answer

In order to get a proper transaction capture, you need to power the device from the battery in a way that is powered during usage. Do not power WiFi module externally. Just connect GND and RX to get UART capture. First capture from RX, then from TX, I assume you know how UART works, if not, ask here and I will give more details. Powering WiFi module makes no sense here because MCU would be sleeping anyway so the transaction still won't happen. We need to know which dpIDs are present and what are their meaning. We are looking some data points like: - alarm state - 1 or 0? - tamper state - 1 or 0? - battery state - maybe enum with 3 values, maybe something else - maybe something more as well... We need to know dpIDs before flashing OBK.

aleshinalekseya · Answer

Something happened. It's enough?

aleshinalekseya · Answer

1. Power on2. Tamper push3. Smoke alarm4. Tamper push stop alarmIt seems to be something like this

p.kaczmarek2 · Answer

Well, this capture is good, and we can see dpIDs and their types and values, but do you know the meaning of each dpID? Usually I connect UART to do realtime capture, then start capture, press (for example) the tamper sensor, stop capture, and see which exact dpID changed. And then repeat the same process for each variable... for each possible option. So we can map dpIDs to their meaning.

aleshinalekseya · Answer

It seems to be something like this

aleshinalekseya · Answer

Battery state:fnId=15 Val V=100 - 100%fnId=15 Val V=67 - 72%fnId=15 Val V=33 - 36%fnId=15 Val V=4 - 4%Smoke Detect:fnId=2 Val V=0fnId=2 Val V=99

p.kaczmarek2 · Answer

So smoke detection is dpID 2, which is a value, and can have values between 0 and 100? That's nice, i was rather expecting just a boolean.

aleshinalekseya · Answer

The value changes depending on the level of smoke. More likely. So, when trying to turn off the siren with a tamper, the smoke level was lower and the value was 18.

aleshinalekseya · Answer

So. How next step?

moustic999 · Answer

It looks like there are similar smoke sensors for many DptIds:At least for these 4 Dpts: Code: text Expand Select all Copy to clipboard    {         code: smoke_sensor_status,         dp_id: 1,         type: Enum,         values: {range:[alarm,normal]}       },       {         code: smoke_sensor_value,         dp_id: 2,         type: Integer,         values: {unit:,min:0,max:100,scale:1,step:1}       },       {         code: battery_state,         dp_id: 14,         type: Enum,         values: {range:[low,middle,high]}       },       {         code: battery_percentage,         dp_id: 15,         type: Integer,         values: {unit:%,min:0,max:100,scale:0,step:1}       },Dpt 1 is 0 when alarm, 1 when normal

p.kaczmarek2 · Answer

Now you need to write autoexec.bat with TuyaMCU and tmSensor drivers, use linkTuyaMCUOutputToChannel to link dpIDs to channels. For now, you may keep powering WiFi module from external 3.3V, so you can operate easily, but for the testing, you will need to disconnect 3.3V and allow the TuyaMCU to control power of the WiFi. I think we can look here on forum for some autoexec.bat for other device which we can modify to suit our needs here. There were already topics about TuyaMCU humidity+temperature sensor (@dedamraz had one?), and a TuyaMCU PIR sensor (@spin55 was working on one)

wtv · Answer

Is there a config I could simply import? The device is listed but not functional right now.

p.kaczmarek2 · Answer

Hello @wtv , judging from the previous posts, it seems we still need to write autoexec.bat for this device, but most of the work is done. When writing autoexec.bat, you can refer to a related TuyaMCU sensor to

wtv · Answer

>>20723099 Thank you for your quick response. If I try to import this, it will give me a syntax error. Right now I'm using it just as a Home Assistant ping binary sensor so no battery level or smoke amount. It will connect to network when something happens but it's rudimentary The device is the same, looks the same at least. This is some uart logs I managed to get with esphome: Code: TextLog in, to see the code It was powered externally.

p.kaczmarek2 · Answer

The content in post 17 is not importable conifg, you need to write autoexec.bat for that device, I don't have this device but I can write a draft for you, if you need help. If you have the same device as in the topic, namely the TuyaMCU version of smoke detector, it will not work unless powered through batteries (or their contacts). This is because TuyaMCU on the board is controlling power of WiFi module, and WiFI module starts the transaction with TuyaMCU when it's powered on (by the MCU), so if you manually solder wire to keep WiFI module powered on forever, it will not know when to start the transaction.

wtv · Answer

@p.kaczmarek2 Help would be greatly appreciated!

edwardpoll · Answer

Anyone get any further with this? I have the same device, but am at a dead end.I've got a YAML file that, in English at least, should provide the same configuration for ESPHome, though I'm struggling to get it to work effectively with HA. Maybe it's the WiFi being forced into low power mode, maybe it's me...Thoughts on the attached?

p.kaczmarek2 · Answer

I would not recommend this approach. You should use our OBK automatic HASS Discovery in conjunction with a proper autoexec.bat config. @wtv you should start with this, however I don't know if baud rate setting is correct, maybe you need to comment it out: Code: text Expand Select all Copy to clipboard startDriver TuyaMCU startDriver tmSensor // may be needed, depends on device, some also use 9600 tuyaMCU_setBaudRate 115200 // smoke detect, 0-100 value, dpID 2 setChannelLabel 2 Smoke setChannelType 2 ReadOnly linkTuyaMCUOutputToChannel 2 val 2 // Battery state enumeration, dpID 14 setChannelLabel 14 Battery setChannelType 14 LowMidHigh linkTuyaMCUOutputToChannel 14 enum 14 // Battery state, 1-100 % value, dpID 15 setChannelLabel 15 BatteryPercent setChannelType 15 ReadOnly linkTuyaMCUOutputToChannel 15 val 15 You can modify this config to include more dpIDs, please look up channel types on our docs. See more at:

wtv · Answer

Created autoexec.bat, used baud rate 9600 which had some incoming communication on esphome. No luck, all configured sensors report 0.0 .. Tried to revert to original fw but failed writing with obk flasher. This is a huge problem right now, multiple devices fail to write and when/if revived, they get mac C8:47:8C:00:00:00 and need RF rewrite which I presume breaks tuya cloud because app didn't respond when pressing test and re-pairing fails too.I'm thinking of using the adc to read the speaker output as a confirmation for smoke because simply pinging caused false alarms. Might work with original power source if I enable fast connect.Tested with real smoke when I originally received it, and the official HA integration failed to update the smoke alarm entity so pretty much I'm not at a loss flashing it.

p.kaczmarek2 · Answer

Can you try to capture TX2 log so we know what's happening? RF can be easily restored if you have 2MB backup.

groove6j · Answer

>>20807426 @wtv Did you ever get some communication working?I could try to do that.

groove6j · Answer

I was prepared for logging and debugging, but surprisingly everything worked at first go. @wtv should have worked for you too. Maybe you had a different board version or bad module? I used 9600 baud and BK7231 did receive all the data. dpIDs are similar to other TuyaMCU smoke detectors seen on this forum. Smoke is a percentage on dpID2 exactly as you found out. There seems to be something on dpID1 (and perhaps other dpIDs), but it reports 1 all the time. Anyway it's not needed as Smoke % and battery status are present and shown in HA. There might be a siren silencer toggle on dpID16, should we maybe use it as a switch? My board: High amounts of smoke: No smoke: The autoexec is pretty much the exact same, I only added the channel types: Code: text Expand Select all Copy to clipboard startDriver TuyaMCU startDriver tmSensor tuyaMCU_setBaudRate 9600 // smoke sensor value, Int value, dpID 2 setChannelLabel 2 Smoke setChannelType 2 SmokePercent linkTuyaMCUOutputToChannel 2 val 2 // Battery state lo-mid-hi, dpID 14 setChannelLabel 14 Battery setChannelType 14 ReadOnlyLowMidHigh linkTuyaMCUOutputToChannel 14 enum 14 // Battery state, 0-100 % value, dpID 15 setChannelLabel 15 BatteryPercent setChannelType 15 BatteryPercent linkTuyaMCUOutputToChannel 15 val 15 Additional info: When test button is pressed, the device connects to WiFi and stays for around 15-20s. There is enough time to launch the web application create the autoexec.bat quickly (or make some additional changes to the config). How often it broadcasts its status, I don't know yet. Also fully de-soldering CB3S can be avoided by removing R20 and R23 resistors when writing, which are on the TX and RX line. I bought a few of these devices quite a while ago, the 9V battery works for a long time and they are pretty cheap as well. Nice devices, smoke is also detected very quickly when compared to the round Tuya detector with 2xAAA batteries and no MCU. I saw the detector beeping at 20% of smoke. It then turned on and remained until the smoke cleared out. I also set the quick connect flag. I think this device can be marked as working.

Tuya Smart Wi-Fi Smoke Detector: Exploring WiFi Module CB3S & MCU CX32L003F8

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Topic summary