[BK7231N /CB3S] Smoke detector MBG line VS-P443W Tuya - teardown

Hello, thanks for showing the inside of this device. I'll try to clarify the situation.

This sensor is most likely based on TuyaMCU, more specifically TuyaMCU for battery powered devices.
https://developer.tuya.com/en/docs/iot/tuyacl...niversalserialaccessprotocol?id=K95afs9h4tjjh

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.

These types of devices are supported by OpenBeken, but to be sure, first capture UART packets, baud is 9600 or 115200, you can use RealTerm and then analyze them in TuyaMCUAnalyzer:
https://www.elektroda.pl/rtvforum/viewtopic.php?p=20528459#20528459
https://github.com/openshwprojects/TuyaMCUAnalyzer

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 ...

And that's how it should go.

As related materials, it is worth recommending these topics, here I remotely started at @DeDaMrAz the humidity sensor on TuyaMCU:
CB3S/BK7231N] Temperature/humidity sensor with TuyaMCU - Diagram, reverse engineering
Here I was running the door sensor on TuyaMCU:
Energy-saving (?) battery door/window sensor for WiFi DS06

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:

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:

I just added the SmokePercent channel type along with Home Assistant Discovery.

Only tested on Simulator (Windows):



Works:

Unfortunately, in the available device_class from HA I did not find one ready for Smoke:
https://developers.home-assistant.io/docs/core/entity/sensor/#available-device-classes
So Discovery will be classless..

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.

I'm posting Flasher build for testing.

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?