[CB3S/BK7231N] Temperature/Humidity Sensor with TuyaMCU - Diagram, Reverse Engin

p.kaczmarek2 25527 63

Treść została przetłumaczona

Zobacz oryginalną wersję tematu

Report a violation of the law

Reply Cool? Ranking DIY | New topic

Notify about new articles

Listen:

Reverse engineering Tuya battery temperature/humidity sensor protocol

Post #1 20564338 03 May 2023 08:43

Here I will present an in-depth analysis and reverse engineering of the Tuya battery temperature/humidity sensor implemented on the basis of the TuyaMCU protocol, i.e. having a separate microcontroller (always on, but using sleep mode) and a WiFi module (its power supply activates the MCU when you need to report the status). Here I will show the protocol of this product, including variable roles (dpID TuyaMCU), its schematic, and finally I will change its firmware to free it from the cloud and pair it with Home Assistant.

The theme was created in collaboration with @DeDaMrAz. We worked on the sensor remotely, I led the activities, and a colleague did packet capture, PCB analysis and drawing its schematic, as well as final tests with Home Assistant.

Sensor purchase
It is one of the most popular sensors of this type in the network. It is available in Zigbee and WiFi versions, here we discuss the WiFi version. You can buy it for several dozen zlotys. Below is a screenshot of an example auction:

I do not even discuss the Tuya application and pairing, it has been described many times. Here we will focus on technical details and firmware changes .
Instructions for pairing with the SmartLife application (if we want to use an open-source sensor, it is unnecessary for us):

The inside of the sensor
We look inside. What do we see first?

This is a device based on TuyaMCU. We have a separate WiFi module (CB3S, i.e. BK7231N) and a microcontroller.
TuyaMCU is a UART based protocol through which this MCU communicates with the WiFi module.
CB3S pinouts are known:

pin number	Symbol	I/O type	functions
1	RST	I	Low-level reset, high level active (the pin has been pulled high internally), correspond to CEN of the IC
2	ADC3	AI	ADC pin, which corresponds to P23 of the IC
3	CEN	I	Enabling pin, which is pulled high internally to be compatible with other modules
4	P14	I/O	A common GPIO interface, which corresponds to P14 of the IC
5	P26	I/O	GPIOP_26, which corresponds to P26 of the IC, PWM 5
6	P24	I/O	GPIOP_24, which corresponds to P24 of the IC, PWM 4
7	P6	I/O	GPIOP_6, which corresponds to P6 of the IC, PWM 0
8	VCC	P	Power supply pin (3.3V)
9	GND	P	Power supply reference ground
10	P9	I/O	GPIOP_9, which corresponds to P9 of the IC, PWM 3
11	TXD2	I/O	UART2_TXD (used to display the module internal information), which corresponds to P0 of the IC
12	CSN	I/O	Production test control pin. If it is used as a common I/O pin, it must be connected to the VCC externally. Do not connect it to the ground before the module is powered on.
13	P8	I/O	GPIOP_8, which corresponds to P8 of the IC, PWM 2
14	P7	I/O	GPIOP_7, which corresponds to P7 of the IC, PWM 1
15	RXD1	I/O	UART1_RXD (user serial interface), which corresponds to P10 of the IC. Do not connect it to the VCC. By default, the MCU serial port should be in low-level or high-impedance state.
16	TXD1	I/O	UART1_TXD (user serial interface), which corresponds to P11 of the IC. Do not connect it to the VCC. By default, the MCU serial port should be in low-level or high-impedance state.
17	ADC3	AI	(Not recommended. If needed, please use Pin 2) ADC port, which corresponds to P23 of the IC. Programmed SPI
18	P22	I/O	(Not recommended ) GPIOP_22, which corresponds to P22 of the IC. Programmed SPI
19	CSN	I/O	The pull-up resistor is needed during usage of customers. Do not connect it to the ground before the module is powered on. Correspond to P21 of the IC.
20	P20	I/O	(Not recommended. ) GPIOP_20, which corresponds to P20 of the IC. Programmed SPI
21	NC	-	-
22	NC	-	-

The MCU has not been identified, but this is how they are connected in general:

It's just that in the case of TuyaMCU in battery devices, the MCU additionally controls the power supply of the WiFi module.
Here is the diagram (drawn by a friend):

ESP12 in the diagram is illustrative, in fact it is CB3S. The CB3S power supply is controlled by the MCU via a MOSFET. The WiFi module communicates with the MCU via UART, through the TuyaMCU protocol. The MCU itself reads the measurements from the SHT30 via I2C (you can even see the pull up resistors).

So what will have to be done to change the firmware of the WiFi module, i.e. to free the device from the manufacturer's cloud?
- you need to properly handle communication with the MCU (TuyaMCU protocol)
- you have to deal with the fact that the MCU will turn off the WiFi module during operation ...

Power consumption in sleep mode
By the way, you can do a small measurement - how much does the MCU itself consume with the WiFi module turned off?

5µA . I recommend to contrast this result with my sleep measurement of the WiFI module with BK7231 (in deep sleep mode) from this topic:
https://www.elektroda.pl/rtvforum/topic3960149.html
I got 6µA there. That's a 1µA difference, assuming the measurements are accurate enough to judge it. Just remember, the MCU sleeps here and the WiFi module has VDD completely disconnected, and the linked topic mentions the sleep of the WiFi module itself (which can be woken up by GPIO).

TuyaMCU protocol
This device uses the TuyaMCU protocol for battery powered devices. The documentation is here:
https://developer.tuya.com/en/docs/iot/tuyacl...niversalserialaccessprotocol?id=K95afs9h4tjjh
I also discussed the basis of TuyaMCU in this topic:
https://www.elektroda.pl/rtvforum/topic3880546.html
A related battery powered door open sensor on TuyaMCU I discussed here (except its protocol was a bit simpler, there was no dpCache):
https://www.elektroda.pl/rtvforum/topic3914412.html
You can use my analyzer to analyze TuyaMCU:
https://www.elektroda.com/rtvforum/topic3970199.html#20528459
Here is a pre-processed UART dump from my program:


//S 4/30/2023 8:49:32 PM WiFi send:
55AA0001000000
//R 4/30/2023 8:49:32 PM WiFi received:
55AA000100247B2270223A226279757376756D656D65356969636164222C2276223A22312E302E30227D20
//S 4/30/2023 8:49:33 PM WiFi send:
55AA000200010305
//R 4/30/2023 8:49:33 PM WiFi received:
55AA0002000001
//S 4/30/2023 8:51:50 PM WiFi send:
55AA000200010406
//R 4/30/2023 8:51:56 PM WiFi received:
55AA0002000001
//R 4/30/2023 8:51:56 PM WiFi received:
55AA001000010010
//S 4/30/2023 6:18:06 PM WiFi sent:
55AA00100002010012
//R 4/30/2023 8:51:58 PM WiFi received:
55AA0005000801020004000000FC0F
//R 4/30/2023 8:51:58 PM WiFi received:
55AA0005000802020004000000273B
//R 4/30/2023 8:51:58 PM WiFi received:
55AA00050005030400010112
//R 4/30/2023 8:51:58 PM WiFi received:
55AA00050005090400010017
//R 4/30/2023 8:51:58 PM WiFi received:
55AA000500080A0200040000021C3A
//R 4/30/2023 8:51:58 PM WiFi received:
55AA000500080B020004FFFFFF88A2
//R 4/30/2023 8:51:58 PM WiFi received:
55AA000500080C0200040000005A78
//R 4/30/2023 8:51:58 PM WiFi received:
55AA000500080D0200040000000A29
//R 4/30/2023 8:51:58 PM WiFi received:
55AA000500050E040001021E
//R 4/30/2023 8:51:59 PM WiFi received:
55AA000500050F040001021F
//R 4/30/2023 8:51:59 PM WiFi received:
55AA00050008110200040000000124
//R 4/30/2023 8:51:59 PM WiFi received:
55AA00050008120200040000000125
//R 4/30/2023 8:51:59 PM WiFi received:
55AA0005000813020004000000052A
//R 4/30/2023 8:51:59 PM WiFi received:
55AA0005000814020004000000082E
//R 4/30/2023 8:51:59 PM WiFi received:
55AA00050005150100010020
//R 4/30/2023 8:51:59 PM WiFi received:
55AA0005000801020004000000FD10
//R 4/30/2023 8:51:59 PM WiFi received:
55AA0005000802020004000000273B
//S 4/30/2023 8:52:13 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:15 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:17 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:19 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:21 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:23 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:25 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:27 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:29 PM WiFi send:
55AA000500010005

Below is the same but with comments from my analyzer:


Sent by WiFi module:
55 AA	00	01		00 00		00	
HEADER	VER=00	Product		LEN		CHK	

Received by WiFi module:
55 AA	00	01		00 24	7B2270223A226279757376756D656D65356969636164222C2276223A22312E302E30227D	20	
HEADER	VER=00	Product		LEN	{"p":"byusvumeme5iicad","v":"1.0.0"}	CHK	

Sent by WiFi module:
55 AA	00	02		00 01	03	05	
HEADER	VER=00	McuConf		LEN	03	CHK	

Received by WiFi module:
55 AA	00	02		00 00		01	
HEADER	VER=00	McuConf		LEN		CHK	

Sent by WiFi module:
55 AA	00	02		00 01	04	06	
HEADER	VER=00	McuConf		LEN	04	CHK	

Received by WiFi module:
55 AA	00	02		00 00		01	
HEADER	VER=00	McuConf		LEN		CHK	

Received by WiFi module:
55 AA	00	10		00 01	00	10	
HEADER	VER=00	ObtainDPcache		LEN		CHK	

Sent by WiFi module:
55 AA	00	10		00 02	0100	12	
HEADER	VER=00	ObtainDPcache		LEN		CHK	

Received by WiFi module:
55 AA	00	05		00 08	01020004000000FC	0F	
HEADER	VER=00	Unk		LEN	fnId=1 Val V=252	CHK	

Received by WiFi module:
55 AA	00	05		00 08	0202000400000027	3B	
HEADER	VER=00	Unk		LEN	fnId=2 Val V=39	CHK	

Received by WiFi module:
55 AA	00	05		00 05	0304000101	12	
HEADER	VER=00	Unk		LEN	fnId=3 Enum V=1	CHK	

Received by WiFi module:
55 AA	00	05		00 05	0904000100	17	
HEADER	VER=00	Unk		LEN	fnId=9 Enum V=0	CHK	

Received by WiFi module:
55 AA	00	05		00 08	0A0200040000021C	3A	
HEADER	VER=00	Unk		LEN	fnId=10 Val V=540	CHK	

Received by WiFi module:
55 AA	00	05		00 08	0B020004FFFFFF88	A2	
HEADER	VER=00	Unk		LEN	fnId=11 Val V=-120	CHK	

Received by WiFi module:
55 AA	00	05		00 08	0C0200040000005A	78	
HEADER	VER=00	Unk		LEN	fnId=12 Val V=90	CHK	

Received by WiFi module:
55 AA	00	05		00 08	0D0200040000000A	29	
HEADER	VER=00	Unk		LEN	fnId=13 Val V=10	CHK	

Received by WiFi module:
55 AA	00	05		00 05	0E04000102	1E	
HEADER	VER=00	Unk		LEN	fnId=14 Enum V=2	CHK	

Received by WiFi module:
55 AA	00	05		00 05	0F04000102	1F	
HEADER	VER=00	Unk		LEN	fnId=15 Enum V=2	CHK	

Received by WiFi module:
55 AA	00	05		00 08	1102000400000001	24	
HEADER	VER=00	Unk		LEN	fnId=17 Val V=1	CHK	

Received by WiFi module:
55 AA	00	05		00 08	1202000400000001	25	
HEADER	VER=00	Unk		LEN	fnId=18 Val V=1	CHK	

Received by WiFi module:
55 AA	00	05		00 08	1302000400000005	2A	
HEADER	VER=00	Unk		LEN	fnId=19 Val V=5	CHK	

Received by WiFi module:
55 AA	00	05		00 08	1402000400000008	2E	
HEADER	VER=00	Unk		LEN	fnId=20 Val V=8	CHK	

Received by WiFi module:
55 AA	00	05		00 05	1501000100	20	
HEADER	VER=00	Unk		LEN	fnId=21 Bool V=0	CHK	

Received by WiFi module:
55 AA	00	05		00 08	01020004000000FD	10	
HEADER	VER=00	Unk		LEN	fnId=1 Val V=253	CHK	

Received by WiFi module:
55 AA	00	05		00 08	0202000400000027	3B	
HEADER	VER=00	Unk		LEN	fnId=2 Val V=39	CHK	

Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN		CHK	

Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN		CHK	

Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN		CHK	

Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN		CHK	

Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN		CHK	

Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN		CHK	

Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN		CHK	

Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN		CHK	

Sent by WiFi module:
55 AA	00	05		00 01	00	05	
HEADER	VER=00	Unk		LEN		CHK

And now a step-by-step analysis.
1. The MCU turns on the power to the WiFi module. The WiFi module sends a request for identification to the MCU (package 0x01 - Query product information), and it responds and gives {"p":"byusvumeme5iicad","v":"1.0.0"} :

2. Now WiFi successively reports the connection status (type 0x02 - Report the network status of the device), first status 0x03 (WiFi connected), MCU confirms receipt, and then status 0x04 (cloud connected - in our OBK as MQTT):

Only these WiFi states 0x03 and 0x04 appear during normal operation. Below are all possible states:

Status	Description	status value
Status 1	smartconfig configuration mode	0x00
Status 2	AP configuration status	0x01
Status 3	Wi-Fi has been set up but is not connected to the router	0x02
Status 4	Wi-Fi is set up and connected to the router	0x03
Status 5	Wi-Fi is set up, connected to the router and to the cloud	0x04

3. Then there is the ObtainDPCache data exchange, which exists only in devices with configuration remembered on the MCU, e.g. the door opening / closing sensor does not have it:

Nothing has been sent in the screenshot above, but if we changed the reporting frequency in the settings, for example, this packet would contain information about it.

ObtainDPCache works in such a way that when we want to, for example, set the time between measurements, the WiFi module downloads it from the cloud when the MCU turns it on and then waits for the MCU to ask it about these ObtainDPCache. The MCU first asks for ObtainDPCache and the WiFi module replies with a list of dpID/type/value variables. The MCU picks it up and saves it. Thus, the MCU knows how often to wake up and pass the measurement on.

4. Then TuyaMCU reports variable values separately (package type 0x05 - Report the real-time status):

5. Then, after sending these variables to the cloud, the module sends confirmations as many times as it received variables:

By guessing and testing with the Tuya application, the following variables (dpID) can be distinguished:

fnID1	temperature as an integer multiplied by 10 - so 23.1 as 231
fnID2	% humidity
fnID3	battery level ( 0=Low, 1=Medium, 2=High)
fnID9	choice of unit, C or F (0 = C and 1 = F)
fnID10	minimum temperature setting
fnID11	maximum temperature setting
fnID12	maximum humidity setting
fnID13	minimum humidity setting
fnID17	temperature measurement frequency
fnID18	humidity measurement frequency
fnID19	temperature accuracy (sensitivity) times 10.5 means 0.5C
fnID20	humidity accuracy in %
fnID21	switch state (1 or 0, role unknown)

So let's summarize what's going on in this communication, in a nutshell:
- The MCU turns on the WiFi module by turning on its MOSFET transistor on the power supply
- the WiFi module talks to the MCU, the MCU identifies itself
- WiFi module informs about connection status, MCU confirms
- The MCU asks for any settings such as reporting time, the WiFi module sends them if they are
- MCU sends new measurements etc, WiFi module confirms
- The MCU goes to sleep after the last confirmation and disconnects the power to the WiFi module

The only new thing here compared to mine about the door status sensor there is a packet 0x10, the so-called Obtain DP cache command , i.e. downloading settings from the WiFi module. Here are two examples of its use. This is what the transaction looks like when the WiFi module does not set anything:

This is how the same transaction looks like when we change the reporting frequency to 1 minute in the app (for temperature and humidity):

Final configuration of OpenBeken
OpenBeken can be uploaded to this sensor very easily. Follow the steps:
1. temporarily disconnect the UART between the MCU and the WiFi module, e.g. by unsoldering the resistors from the diagram (or cutting the paths), because the same UART port is used to upload the firmware. We artificially power the WiFi module from our 3.3V.
2. upload OBK according to:
https://github.com/openshwprojects/BK7231GUIFlashTool
3. We configure OpenBeken. We configure our WiFi, device names, MQTT, and also place the script autoexec.bat in Web App -> LittleFS OBK:


startDriver TuyaMCU
startDriver tmSensor

// may be needed, depends on device, some also use 9600
tuyaMCU_setBaudRate 115200

// dpID 1 is tempererature div 10
setChannelType 1 temperature_div10
linkTuyaMCUOutputToChannel 1 val 1
// dpID 2 is % humidity
setChannelType 2 Humidity
linkTuyaMCUOutputToChannel 2 val 2
// dpID 3 is battery state - low(0), mid(1) and high(2)
linkTuyaMCUOutputToChannel 3 enum 3
setChannelType 3 ReadOnlyLowMidHigh
setChannelLabel 3 Battery
//
// setup dpCache - temperature interval
//
// Show textfield for that
setChannelType 5 TextField
// setup display name
setChannelLabel 5 Temperature Interval
// Make value persistant (stored between reboots), 
// start value -1 means "remember last"
SetStartValue 5 -1
// set default value if not set
if $CH5==0 then setChannel 5 1
// link dpID 17 to channel 5, the type is val, extra '1' means that its dpCache variable
linkTuyaMCUOutputToChannel 17 val 5 1

setChannelType 6 TextField
setChannelLabel 6 Humidity Interval
SetStartValue 6 -1
if $CH6==0 then setChannel 6 1
linkTuyaMCUOutputToChannel 18 val 6 1

The autoexec.bat above scripts the dpID handling from TuyaMCU. Maps dpID to OBK channels. It sets the types of these channels, so Hass Discovery knows what this sensor offers. In addition, it displays the fields and values for the corresponding channels.
OBK documentation:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/README.md
This is what the OBK panel looks like then:

4. We also pair with HA then.
In the latest version of OBK, it supports Home Assistant Discovery even for scripted devices. Just select Discovery from Options and HA will see the device itself:

5. Finally, when everything is ready, disconnect the programmer, disconnect the artificially connected 3.3V, reconstruct the UART paths and the sensor should start reporting data to the HA.

Note: OBK supports setting the reporting time through visible fields on the panel. In this case, the dpID of the reporting period (17 and 18) have been mapped to channels 5 and 6. It is enough to set these channels to, for example, 60, and the module will wake up and report every 60 minutes. You can set it to 1 - it will report every minute. E.t.c.

Here is an example of the final effect in HA:

Short wake up and reporting test
It is also worth checking how long the entire report cycle lasts. At the moment it comes out to 11 seconds, although static IP can probably improve it, as well as the implementation of the system will be improved.


mqtt_pass hass_pass_secret
mqtt_clientID temp_test
mqtt_host 192.168.0.124:1883
Info:MAIN:Time 6, idle 114159/s, free 71192, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Boot complete time reached (5 seconds)
Info:CFG:####### Set Boot Complete #######
Info:TuyaMCU:TUYAMCU received: 55 AA 00 02 00 00 01 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 2 (MCUconf) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
Info:MAIN:Time 7, idle 181106/s, free 71232, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:mqtt_connection_cb: Successfully connected
Info:MQTT:mqtt_subscribed to temp_test/+/set
Info:MQTT:mqtt_subscribed to temp_test/+/set
Info:MQTT:mqtt_subscribed to cmnd/temp_test/+
Info:MQTT:mqtt_subscribed to cmnd/temp_test/+
Info:MQTT:mqtt_subscribed to temp_test/+/get
Info:MQTT:Publishing val temp_test to temp_test/host retain=0
Info:MAIN:Time 8, idle 183495/s, free 71232, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val Build on May  1 2023 21:06:42 version 1.17.88 to temp_test/build retain=0
Info:MAIN:Time 9, idle 190408/s, free 71232, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val 1c:90:ff:2f:c0:f8  to temp_test/mac retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 02 00 00 01 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 2 (MCUconf) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
Info:TuyaMCU:TUYAMCU received: 55 AA 00 10 00 01 00 10 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 16 (Unknown) with 8 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 16
Info:MAIN:Time 10, idle 192374/s, free 71232, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:GEN:dhcp=0 ip=192.168.0.100 gate=192.168.0.1 mask=255.255.255.0 mac=1c:90:ff:2f:c0:f8 
Info:GEN:sta: 1, softap: 0, b/g/n
Info:GEN:sta:rssi=-46,ssid=5G_FULL_POWER,bssid=ac:d5:64:2f:7f:f5 ,channel=6,cipher_type:CCMP
Info:MQTT:Publishing val 2 to temp_test/sockets retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 05 00 08 01 02 00 04 00 00 00 E3 F6 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 5 (WiFiSelect) with 15 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 1, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 227
Info:GEN:CHANNEL_Set channel 1 has changed to 227 (flags 0)

Info:MQTT:Channel has changed! Publishing 227 to channel 1 
Info:MQTT:Publishing val 227 to temp_test/1/get retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 05 00 08 02 02 00 04 00 00 00 29 3D 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 5 (WiFiSelect) with 15 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 41
Info:GEN:CHANNEL_Set channel 2 has changed to 41 (flags 0)

Info:MQTT:Channel has changed! Publishing 41 to channel 2 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic temp_test/1/get
Info:MQTT:Publishing val 41 to temp_test/2/get retain=0
Info:MAIN:Time 11, idle 205603/s, free 71232, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic temp_test/2/get
Info:MAIN:Main_Init_Before_Delay
Info:CFG:####### Boot Count 767 #######
Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 22 changes count.
Error:CMD:no file early.bat err -2
Info:GEN:PIN_SetupPins pins have been set up.
Info:MAIN:Main_Init_Before_Delay done
Info:MAIN:Main_Init_Delay
Info:MAIN:Main_Init_Delay done
Info:MAIN:Main_Init_After_Delay
Info:MAIN:ssid:5G_FULL_POWER key:MyP@ssw0rd
Info:MAIN:Using SSID [5G_FULL_POWER]
Info:MAIN:Using Pass [MyP@ssw0rd]
Info:MQTT:MQTT_RegisterCallback called for bT temp_test/ subT temp_test/+/set
Info:MQTT:MQTT_RegisterCallback called for bT temp_test/ subT temp_test/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/temp_test/ subT cmnd/temp_test/+
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/temp_test/ subT cmnd/temp_test/+
Info:MQTT:MQTT_RegisterCallback called for bT temp_test/ subT temp_test/+/get
Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Started TuyaMCU.
Info:MAIN:Started tmSensor.
Info:GEN:Channel 1 type changed to temperature_div10
Info:GEN:Channel 2 type changed to Humidity
Info:GEN:Channel 3 type changed to ReadOnly
Info:MAIN:Time 1, idle 283411/s, free 70904, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:TuyaMCU:TUYAMCU received: 55 AA 00 01 00 24 7B 22 70 22 3A 22 62 79 75 73 76 75 6D 65 6D 65 35 69 69 63 61 64 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D 20 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 1 (QueryProductInformation) with 43 bytes
Info:TuyaMCU:TuyaMCU_ParseQueryProductInformation: received {"p":"byusvumeme5iicad","v":"1.0.0"}
Info:MAIN:Time 2, idle 186205/s, free 70840, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 3, idle 67724/s, free 71024, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 4, idle 0/s, free 71024, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 5, idle 0/s, free 71024, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING - 1
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:MQTT:mqtt_userName homeassistant
mqtt_pass hass_pass_secret
mqtt_clientID temp_test
mqtt_host 192.168.0.124:1883
Info:MAIN:Time 6, idle 109039/s, free 71208, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Boot complete time reached (5 seconds)
Info:CFG:####### Set Boot Complete #######
Info:MQTT:mqtt_connection_cb: Successfully connected
Info:MQTT:mqtt_subscribed to temp_test/+/set
Info:MQTT:mqtt_subscribed to temp_test/+/set
Info:MQTT:mqtt_subscribed to cmnd/temp_test/+
Info:MQTT:mqtt_subscribed to cmnd/temp_test/+
Info:MQTT:mqtt_subscribed to temp_test/+/get
Info:MQTT:Publishing val temp_test to temp_test/host retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 02 00 00 01 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 2 (MCUconf) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
Info:MAIN:Time 7, idle 171518/s, free 71040, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val Build on May  1 2023 21:06:42 version 1.17.88 to temp_test/build retain=0
Info:MAIN:Time 8, idle 180693/s, free 71248, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val 1c:90:ff:2f:c0:f8  to temp_test/mac retain=0
Info:MAIN:Time 9, idle 187841/s, free 71248, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val 3 to temp_test/sockets retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 02 00 00 01 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 2 (MCUconf) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
Info:TuyaMCU:TUYAMCU received: 55 AA 00 10 00 01 00 10 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 16 (Unknown) with 8 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 16
Info:MAIN:Time 10, idle 188069/s, free 59552, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:GEN:dhcp=0 ip=192.168.0.100 gate=192.168.0.1 mask=255.255.255.0 mac=1c:90:ff:2f:c0:f8 
Info:GEN:sta: 1, softap: 0, b/g/n
Info:GEN:sta:rssi=-49,ssid=5G_FULL_POWER,bssid=ac:d5:64:2f:7f:f5 ,channel=6,cipher_type:CCMP
Info:MQTT:Publishing val -47 to temp_test/rssi retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 05 00 08 01 02 00 04 00 00 00 E3 F6 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 5 (WiFiSelect) with 15 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 1, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 227
Info:GEN:CHANNEL_Set channel 1 has changed to 227 (flags 0)

Info:MQTT:Channel has changed! Publishing 227 to channel 1 
Info:MQTT:Publishing val 227 to temp_test/1/get retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 05 00 08 02 02 00 04 00 00 00 29 3D 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic temp_test/1/get
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 5 (WiFiSelect) with 15 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 41
Info:GEN:CHANNEL_Set channel 2 has changed to 41 (flags 0)

Info:MQTT:Channel has changed! Publishing 41 to channel 2 
Info:MQTT:Publishing val 41 to temp_test/2/get retain=0
Info:MAIN:Time 11, idle 176355/s, free 71248, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic temp_test/2/get
Info:MAIN:Main_Init_Before_Delay
Info:CFG:####### Boot Count 768 #######
Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 22 changes count.
Error:CMD:no file early.bat err -2
Info:GEN:PIN_SetupPins pins have been set up.
Info:MAIN:Main_Init_Before_Delay done
Info:MAIN:Main_Init_Delay
Info:MAIN:Main_Init_Delay done
Info:MAIN:Main_Init_After_Delay
Info:MAIN:ssid:5G_FULL_POWER key:MyP@ssw0rd
Info:MAIN:Using SSID [5G_FULL_POWER]
Info:MAIN:Using Pass [MyP@ssw0rd]
Info:MQTT:MQTT_RegisterCallback called for bT temp_test/ subT temp_test/+/set
Info:MQTT:MQTT_RegisterCallback called for bT temp_test/ subT temp_test/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/temp_test/ subT cmnd/temp_test/+
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/temp_test/ subT cmnd/temp_test/+
Info:MQTT:MQTT_RegisterCallback called for bT temp_test/ subT temp_test/+/get
Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Started TuyaMCU.
Info:MAIN:Started tmSensor.
Info:GEN:Channel 1 type changed to temperature_div10
Info:GEN:Channel 2 type changed to Humidity
Info:GEN:Channel 3 type changed to ReadOnly
Info:MAIN:Time 1, idle 275646/s, free 70904, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:TuyaMCU:TUYAMCU received: 55 AA 00 01 00 24 7B 22 70 22 3A 22 62 79 75 73 76 75 6D 65 6D 65 35 69 69 63 61 64 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D 20 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 1 (QueryProductInformation) with 43 bytes
Info:TuyaMCU:TuyaMCU_ParseQueryProductInformation: received {"p":"byusvumeme5iicad","v":"1.0.0"}
Info:MAIN:Time 2, idle 184552/s, free 70904, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 3, idle 64678/s, free 71152, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 4, idle 0/s, free 71152, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 5, idle 0/s, free 71152, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING - 1
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:MQTT:mqtt_userName homeassistant
mqtt_pass hass_pass_secret
mqtt_clientID temp_test
mqtt_host 192.168.0.124:1883
Info:MAIN:Time 6, idle 108018/s, free 71080, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Boot complete time reached (5 seconds)
Info:CFG:####### Set Boot Complete #######
Info:MQTT:mqtt_connection_cb: Successfully connected
Info:MQTT:mqtt_subscribed to temp_test/+/set
Info:MQTT:mqtt_subscribed to temp_test/+/set
Info:MQTT:mqtt_subscribed to cmnd/temp_test/+
Info:MQTT:mqtt_subscribed to cmnd/temp_test/+
Info:MQTT:mqtt_subscribed to temp_test/+/get
Info:MQTT:Publishing val temp_test to temp_test/host retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 02 00 00 01 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 2 (MCUconf) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
Info:MAIN:Time 7, idle 176336/s, free 71312, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val Build on May  1 2023 21:06:42 version 1.17.88 to temp_test/build retain=0
Info:MAIN:Time 8, idle 359945/s, free 59616, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:MQTT:Publishing val 1c:90:ff:2f:c0:f8  to temp_test/mac retain=0
Info:MAIN:Time 9, idle 184565/s, free 71072, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val 2 to temp_test/sockets retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 02 00 00 01 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 2 (MCUconf) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
Info:TuyaMCU:TUYAMCU received: 55 AA 00 10 00 01 00 10 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 16 (Unknown) with 8 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 16
Info:MAIN:Time 10, idle 189494/s, free 71312, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:GEN:dhcp=0 ip=192.168.0.100 gate=192.168.0.1 mask=255.255.255.0 mac=1c:90:ff:2f:c0:f8 
Info:GEN:sta: 1, softap: 0, b/g/n
Info:GEN:sta:rssi=-38,ssid=5G_FULL_POWER,bssid=ac:d5:64:2f:7f:f5 ,channel=6,cipher_type:CCMP
Info:MQTT:Publishing val -46 to temp_test/rssi retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 05 00 08 01 02 00 04 00 00 00 E4 F7 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 5 (WiFiSelect) with 15 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 1, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 228
Info:GEN:CHANNEL_Set channel 1 has changed to 228 (flags 0)

Info:MQTT:Channel has changed! Publishing 228 to channel 1 
Info:MQTT:Publishing val 228 to temp_test/1/get retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 05 00 08 02 02 00 04 00 00 00 29 3D 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 5 (WiFiSelect) with 15 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 41
Info:GEN:CHANNEL_Set channel 2 has changed to 41 (flags 0)

Info:MQTT:Channel has changed! Publishing 41 to channel 2 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic temp_test/1/get
Info:MQTT:Publishing val 41 to temp_test/2/get retain=0
Info:MAIN:Time 11, idle 202098/s, free 71312, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic temp_test/2/get
Info:MAIN:Main_Init_Before_Delay
Info:CFG:####### Boot Count 769 #######
Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 22 changes count.
Error:CMD:no file early.bat err -2
Info:GEN:PIN_SetupPins pins have been set up.
Info:MAIN:Main_Init_Before_Delay done
Info:MAIN:Main_Init_Delay
Info:MAIN:Main_Init_Delay done
Info:MAIN:Main_Init_After_Delay
Info:MAIN:ssid:5G_FULL_POWER key:MyP@ssw0rd
Info:MAIN:Using SSID [5G_FULL_POWER]
Info:MAIN:Using Pass [MyP@ssw0rd]
Info:MQTT:MQTT_RegisterCallback called for bT temp_test/ subT temp_test/+/set
Info:MQTT:MQTT_RegisterCallback called for bT temp_test/ subT temp_test/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/temp_test/ subT cmnd/temp_test/+
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/temp_test/ subT cmnd/temp_test/+
Info:MQTT:MQTT_RegisterCallback called for bT temp_test/ subT temp_test/+/get
Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Started TuyaMCU.
Info:MAIN:Started tmSensor.
Info:GEN:Channel 1 type changed to temperature_div10
Info:GEN:Channel 2 type changed to Humidity
Info:GEN:Channel 3 type changed to ReadOnly
Info:MAIN:Time 1, idle 280929/s, free 70904, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:TuyaMCU:TUYAMCU received: 55 AA 00 01 00 24 7B 22 70 22 3A 22 62 79 75 73 76 75 6D 65 6D 65 35 69 69 63 61 64 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D 20 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 1 (QueryProductInformation) with 43 bytes
Info:TuyaMCU:TuyaMCU_ParseQueryProductInformation: received {"p":"byusvumeme5iicad","v":"1.0.0"}
Info:MAIN:Time 2, idle 187005/s, free 70840, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 3, idle 65855/s, free 71024, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 4, idle 0/s, free 71024, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 5, idle 0/s, free 71024, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING - 1
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:MQTT:mqtt_userName homeassistant
mqtt_pass hass_pass_secret
mqtt_clientID temp_test
mqtt_host 192.168.0.124:1883
Info:MAIN:Time 6, idle 121870/s, free 71208, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Boot complete time reached (5 seconds)
Info:CFG:####### Set Boot Complete #######
Info:MQTT:mqtt_connection_cb: Successfully connected
Info:MQTT:mqtt_subscribed to temp_test/+/set
Info:MQTT:mqtt_subscribed to temp_test/+/set
Info:MQTT:mqtt_subscribed to cmnd/temp_test/+
Info:MQTT:mqtt_subscribed to cmnd/temp_test/+
Info:MQTT:mqtt_subscribed to temp_test/+/get
Info:MQTT:Publishing val temp_test to temp_test/host retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 02 00 00 01 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 2 (MCUconf) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
Info:MAIN:Time 7, idle 175294/s, free 71248, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val Build on May  1 2023 21:06:42 version 1.17.88 to temp_test/build retain=0
Info:MAIN:Time 8, idle 186306/s, free 59280, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 3/38 
Info:MQTT:Publishing val 1c:90:ff:2f:c0:f8  to temp_test/mac retain=0
Info:MAIN:Time 9, idle 186065/s, free 71248, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val 2 to temp_test/sockets retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 02 00 00 01 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 2 (MCUconf) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
Info:TuyaMCU:TUYAMCU received: 55 AA 00 10 00 01 00 10 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 16 (Unknown) with 8 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 16
Info:MAIN:Time 10, idle 377667/s, free 71248, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:GEN:dhcp=0 ip=192.168.0.100 gate=192.168.0.1 mask=255.255.255.0 mac=1c:90:ff:2f:c0:f8 
Info:GEN:sta: 1, softap: 0, b/g/n
Info:GEN:sta:rssi=-48,ssid=5G_FULL_POWER,bssid=ac:d5:64:2f:7f:f5 ,channel=6,cipher_type:CCMP
Info:MQTT:Publishing val -49 to temp_test/rssi retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 05 00 08 01 02 00 04 00 00 00 E4 F7 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 5 (WiFiSelect) with 15 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 1, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 228
Info:GEN:CHANNEL_Set channel 1 has changed to 228 (flags 0)

Info:MQTT:Channel has changed! Publishing 228 to channel 1 
Info:MQTT:Publishing val 228 to temp_test/1/get retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 05 00 08 02 02 00 04 00 00 00 29 3D 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 5 (WiFiSelect) with 15 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 41
Info:GEN:CHANNEL_Set channel 2 has changed to 41 (flags 0)

Info:MQTT:Channel has changed! Publishing 41 to channel 2 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic temp_test/1/get
Info:MQTT:Publishing val 41 to temp_test/2/get retain=0
Info:MAIN:Time 11, idle 205611/s, free 70712, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic temp_test/2/get
Info:MAIN:Main_Init_Before_Delay
Info:CFG:####### Boot Count 770 #######
Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 22 changes count.
Error:CMD:no file early.bat err -2
Info:GEN:PIN_SetupPins pins have been set up.
Info:MAIN:Main_Init_Before_Delay done
Info:MAIN:Main_Init_Delay
Info:MAIN:Main_Init_Delay done
Info:MAIN:Main_Init_After_Delay
Info:MAIN:ssid:5G_FULL_POWER key:MyP@ssw0rd
Info:MAIN:Using SSID [5G_FULL_POWER]
Info:MAIN:Using Pass [MyP@ssw0rd]
Info:MQTT:MQTT_RegisterCallback called for bT temp_test/ subT temp_test/+/set
Info:MQTT:MQTT_RegisterCallback called for bT temp_test/ subT temp_test/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/temp_test/ subT cmnd/temp_test/+
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/temp_test/ subT cmnd/temp_test/+
Info:MQTT:MQTT_RegisterCallback called for bT temp_test/ subT temp_test/+/get
Info:CMD:CMD_StartScript: started autoexec.bat at the beginning
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Started TuyaMCU.
Info:MAIN:Started tmSensor.
Info:GEN:Channel 1 type changed to temperature_div10
Info:GEN:Channel 2 type changed to Humidity
Info:GEN:Channel 3 type changed to ReadOnly
Info:MAIN:Time 1, idle 281763/s, free 70840, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:TuyaMCU:TUYAMCU received: 55 AA 00 01 00 24 7B 22 70 22 3A 22 62 79 75 73 76 75 6D 65 6D 65 35 69 69 63 61 64 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D 20 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 1 (QueryProductInformation) with 43 bytes
Info:TuyaMCU:TuyaMCU_ParseQueryProductInformation: received {"p":"byusvumeme5iicad","v":"1.0.0"}
Info:MAIN:Time 2, idle 187527/s, free 70840, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 3, idle 65471/s, free 71024, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 4, idle 0/s, free 71024, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Time 5, idle 0/s, free 71024, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING - 1
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:MQTT:mqtt_userName homeassistant
mqtt_pass hass_pass_secret
mqtt_clientID temp_test
mqtt_host 192.168.0.124:1883
Info:MAIN:Time 6, idle 114146/s, free 71200, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MAIN:Boot complete time reached (5 seconds)
Info:CFG:####### Set Boot Complete #######
Info:MQTT:mqtt_connection_cb: Successfully connected
Info:MQTT:mqtt_subscribed to temp_test/+/set
Info:MQTT:mqtt_subscribed to temp_test/+/set
Info:MQTT:mqtt_subscribed to cmnd/temp_test/+
Info:MQTT:mqtt_subscribed to cmnd/temp_test/+
Info:MQTT:mqtt_subscribed to temp_test/+/get
Info:MQTT:Publishing val temp_test to temp_test/host retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 02 00 00 01 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 2 (MCUconf) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
Info:MAIN:Time 7, idle 185104/s, free 71240, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val Build on May  1 2023 21:06:42 version 1.17.88 to temp_test/build retain=0
Info:MAIN:Time 8, idle 182657/s, free 71240, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val 1c:90:ff:2f:c0:f8  to temp_test/mac retain=0
Info:MAIN:Time 9, idle 186337/s, free 71000, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:Publishing val 2 to temp_test/sockets retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 02 00 00 01 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 2 (MCUconf) with 7 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: TUYA_CMD_MCU_CONF, TODO!
Info:TuyaMCU:TUYAMCU received: 55 AA 00 10 00 01 00 10 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 16 (Unknown) with 8 bytes
Info:TuyaMCU:TuyaMCU_ProcessIncoming: unhandled type 16
Info:MAIN:Time 10, idle 189701/s, free 71008, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:GEN:dhcp=0 ip=192.168.0.100 gate=192.168.0.1 mask=255.255.255.0 mac=1c:90:ff:2f:c0:f8 
Info:GEN:sta: 1, softap: 0, b/g/n
Info:GEN:sta:rssi=-38,ssid=5G_FULL_POWER,bssid=ac:d5:64:2f:7f:f5 ,channel=6,cipher_type:CCMP
Info:MQTT:Publishing val -39 to temp_test/rssi retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 05 00 08 01 02 00 04 00 00 00 E4 F7 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 5 (WiFiSelect) with 15 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 1, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 228
Info:GEN:CHANNEL_Set channel 1 has changed to 228 (flags 0)

Info:MQTT:Channel has changed! Publishing 228 to channel 1 
Info:MQTT:Publishing val 228 to temp_test/1/get retain=0
Info:TuyaMCU:TUYAMCU received: 55 AA 00 05 00 08 02 02 00 04 00 00 00 29 3D 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 5 (WiFiSelect) with 15 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 2, dataType 2-DP_TYPE_VALUE and 4 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 4 int: 41
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic temp_test/1/get
Info:GEN:CHANNEL_Set channel 2 has changed to 41 (flags 0)

Info:MQTT:Channel has changed! Publishing 41 to channel 2 
Info:MQTT:Publishing val 41 to temp_test/2/get retain=0
Info:MAIN:Time 11, idle 183799/s, free 71008, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic temp_test/2/get

Summary
This sensor is based on the TuyaMCU protocol. It can work with both the Tuya app and OpenBeken. The frequency of reporting can be changed in a large range, from a minute to 2 hours or more - we did not check longer periods. In deep sleep mode, it draws about 5µA. This is a good result, although the BK7231 itself, according to my tests, draws about 6µA in deep sleep mode with GPIO wake-up. Changing the firmware is a bit of work, because as usual, TuyaMCU is on the same UART port that is used for programming, but after a single upload everything should work fine. The topic contains ready-made scripts for this sensor.
Thanks again to @DeDaMrAz for helping me develop this topic (we worked remotely together on this sensor).
PS: It's worth seeing an older topic by another user with a similar sensor, here , there is also a sample YAML code for Home Assistant, which is now no longer needed since OBK supports HASS Discovery.

Attachments:

tuyaMCU thermostat backup.zip (1011.15 KB) You must be logged in to download this attachment.

Cool? Ranking DIY

Helpful post? Buy me a coffee.

W pełni konfigurowalna automatyzacja domu - prezentacja Fox Wi-Fi Quad Input [sponsorowany]

About Author

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Offline

p.kaczmarek2 wrote 14770 posts with rating 12913, helped 659 times. Been with us since 2014 year.

ADVERTISEMENT
#2 20565972 04 May 2023 09:51

pier pier

Level 24

Posts: 2446

Help: 40

Rate: 1895
» | Helpful post? (0)

Post #2
20565972 04 May 2023 09:51

Temperature is measured in percent, interesting.
ADVERTISEMENT
#3 20567264 05 May 2023 09:38

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14770

Help: 659

Rate: 12913
» | Topic author Helpful post? (+1)

Post #3
20567264 05 May 2023 09:38

Classic copy/paste error by the graphic designer, it was supposed to be humidity. But they still have to admit that, taking into account other Chinese products and offers, their English is quite understandable here. I hope that at least now, in the times of ChatGPT and good translators, the translations of Chinese products and instructions will be better and better.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#4 20584248 17 May 2023 17:47

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42
Helpful post? (0)

Post #4
20584248 17 May 2023 17:47

I just saw this thread thanks to your link in the pir motion thread and I must confess that I had not seen it. Very good work.

I see that you handle command 10 to vary the frequency of data updates. It would be interesting for the pir, to shorten the 1 minute 16 seconds that it currently has for the reset interval of the motion sensor.
ADVERTISEMENT
TuyaMCU dpCache flag needed for ObtainDPCache replies
#5 20584330 17 May 2023 18:46

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14770

Help: 659

Rate: 12913
Topic author Helpful post? (0)

TuyaMCU dpCache flag needed for ObtainDPCache replies
Post #5 20584330 17 May 2023 18:46

Hello @spin55 , the following work was done with @DeDaMrAz , I do not have this device physically myself, but according to his testing, command 10 (ObtainDPCache) is working well and can indeed set report time.

Command 10 (ObtainDPCache) is different than a typical TuyaMCU communication, because in case of ObtainDPCache , the MCU first asks the WiFi module for data and WiFI module has to reply with data from the cache. So, when linking OBK channel to dpID and variable type, for TuyaMCU, you must also add "1" as a dpCache flag:
Code: text Expand Select all Copy to clipboard
// link dpID 17 to channel 5, the type is val, extra '1' means that its dpCache variable linkTuyaMCUOutputToChannel 17 val 5 1

If you do something like that, then at the time of 10 (ObtainDPCache ) processing, the OBK device will send the value from channel 5 to the dpID 5 with type "val" to TuyaMCU.

If you want OBK to remember the channel between reboots, you can use start value -1 (magic value meaning "remember last"):
Code: text Expand Select all Copy to clipboard
// Make value persistant (stored between reboots), // start value -1 means "remember last" SetStartValue 5 -1

Then it is remembered in the flash memory, but don't worry about flash wear - our flash system is limiting the number of erase cycles, we erase once per many writes, so flash memory will not wear out too fast... and also, in this case, I'd think that people do not change the Report Interval often.

I have tried recently ordering some more devices for testing, I've chosen two battery powered ones, but they came without MCUs:

Both devices from photos are working 100% good with OBK with DeepSleep system, but they are not TuyaMCU.

I will order more when I get some more donation funds, but don't worry, the research is not closed! I will work on TuyaMCU more and do my best to ensure it's all good and well supported.

@spin55 if you want to try to use command 0x10 to configure your TuyaMCU device sleep time, let me know, and maybe show some UART logs. I am not sure about that PIR sensor because, as far as I know, PIR sensor is not waking up periodically (or maybe just to check battery?), it's waking up when a movement is detected, so that's a different thing.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

TuyaMCU datapoint dump for temperature and humidity sensor

#6 20584368 17 May 2023 19:07

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42

TuyaMCU datapoint dump for temperature and humidity sensor

Post #6 20584368 17 May 2023 19:07

Thank you very much for the detailed explanation.

//S 4/30/2023 8:49:32 PM WiFi send:
55AA0001000000
//R 4/30/2023 8:49:32 PM WiFi received:
55AA000100247B2270223A226279757376756D656D65356969636164222C2276223A22312E302E30227D20
//S 4/30/2023 8:49:33 PM WiFi send:
55AA000200010305
//R 4/30/2023 8:49:33 PM WiFi received:
55AA0002000001
//S 4/30/2023 8:51:50 PM WiFi send:
55AA000200010406
//R 4/30/2023 8:51:56 PM WiFi received:
55AA0002000001
//R 4/30/2023 8:51:56 PM WiFi received:
55AA001000010010
//S 4/30/2023 6:18:06 PM WiFi sent:
55AA00100002010012
//R 4/30/2023 8:51:58 PM WiFi received:
55AA0005000801020004000000FC0F
//R 4/30/2023 8:51:58 PM WiFi received:
55AA0005000802020004000000273B
//R 4/30/2023 8:51:58 PM WiFi received:
55AA00050005030400010112
//R 4/30/2023 8:51:58 PM WiFi received:
55AA00050005090400010017
//R 4/30/2023 8:51:58 PM WiFi received:
55AA000500080A0200040000021C3A
//R 4/30/2023 8:51:58 PM WiFi received:
55AA000500080B020004FFFFFF88A2
//R 4/30/2023 8:51:58 PM WiFi received:
55AA000500080C0200040000005A78
//R 4/30/2023 8:51:58 PM WiFi received:
55AA000500080D0200040000000A29
//R 4/30/2023 8:51:58 PM WiFi received:
55AA000500050E040001021E
//R 4/30/2023 8:51:59 PM WiFi received:
55AA000500050F040001021F
//R 4/30/2023 8:51:59 PM WiFi received:
55AA00050008110200040000000124
//R 4/30/2023 8:51:59 PM WiFi received:
55AA00050008120200040000000125
//R 4/30/2023 8:51:59 PM WiFi received:
55AA0005000813020004000000052A
//R 4/30/2023 8:51:59 PM WiFi received:
55AA0005000814020004000000082E
//R 4/30/2023 8:51:59 PM WiFi received:
55AA00050005150100010020
//R 4/30/2023 8:51:59 PM WiFi received:
55AA0005000801020004000000FD10
//R 4/30/2023 8:51:59 PM WiFi received:
55AA0005000802020004000000273B
//S 4/30/2023 8:52:13 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:15 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:17 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:19 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:21 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:23 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:25 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:27 PM WiFi send:
55AA000500010005
//S 4/30/2023 8:52:29 PM WiFi send:
55AA000500010005

Could you explain why there is that jet lag?

//R 4/30/2023 8:51:56 PM WiFi received:
55AA001000010010
//S 4/30/2023 6:18:06 PM WiFi sent:
55AA00100002010012

Empty 0x10 packet means no data to report
#7 20584528 17 May 2023 20:38

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14770

Help: 659

Rate: 12913
Topic author Helpful post? (0)

Empty 0x10 packet means no data to report
Post #7 20584528 17 May 2023 20:38

spin55 wrote:

Could you explain why there is that jet lag?

Code: text Expand Select all Copy to clipboard
//R 4/30/2023 8:51:56 PM WiFi received: 55AA001000010010 //S 4/30/2023 6:18:06 PM WiFi sent: 55AA00100002010012

That 8:51:56 PM vs 6:18:06 PM lag should be ignored, it's just editing error. I had multiple dumps, also taken separately by first probing RX and then TX and I was composing them by hand into something more readable for humans. The following situation does not happen in reality.

That being said, I will also note that latest BK7231 GUI Flasher can do dual UART capture, but it is still somewhat problematic, because it has turned out that COM/serial/USB to serial/whatever lag is so big that sometimes still gets packet order wrong so human post processing of packet capture is still required in some cases.

Btw, the example you are quoting:
Code: text Expand Select all Copy to clipboard
//R 4/30/2023 8:51:56 PM WiFi received: 55AA001000010010 //S 4/30/2023 6:18:06 PM WiFi sent: 55AA00100002010012
[/quote]
is an empty 0x10 packet reply, basically it says "There is nothing to report".

If you want to capture some 0x10 data along with dpIDs, you must take following steps:
1. setup capture
2. then in Tuya app, change some kind of parameter, maybe "report period"
3. then check capture for 0x10 packet and it should contain report period dpID, value and type.
It will be like:
Code: text Expand Select all Copy to clipboard
55AA0010001201021102000400000001120200040000000155

Another thing worth mentioning is that you can also extract dpIDs from Tuya API, but I don't know much about that. It was mentioned here:
https://www.elektroda.pl/rtvforum/topic3978070.html#20581469

Btw, if you are interested in TuyaMCU protocol in OpenBeken, you can also peek into our automatic self test system, which basically simulates TuyaMCU use cases and checks if the firmware is responding as expected. For example, see this file:
https://github.com/openshwprojects/OpenBK7231...rc/selftest/selftest_tuyaMCU_batteryPowered.c
This can be run on Windows build of OBK and it used to automatically check if TuyaMCU still works as expected after doing firmware changes and updates. Of course, it's not as good as testing on physical device, but it's better than nothing.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Dual UART capture still needs manual packet reordering
#8 20584759 17 May 2023 22:52

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42
Helpful post? (0)

Dual UART capture still needs manual packet reordering
Post #8 20584759 17 May 2023 22:52

p.kaczmarek2 wrote:
That being said, I will also note that latest BK7231 GUI Flasher can do dual UART capture, but it is still somewhat problematic, because it has turned out that COM/serial/USB to serial/whatever lag is so big that sometimes still gets packet order wrong so human post processing of packet capture is still required in some cases.

Do you use two identical USB? I say this because I have a CP2102 that captures in Realterm at a speed of 20 characters per second (CPS: 20), and another FTDI232 that captures only 5 characters per second (CPS: 5). And that is very noticeable in the listings.
Need for low-level SerialPort callback in C#
#9 20584984 18 May 2023 08:32

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14770

Help: 659

Rate: 12913
Topic author Helpful post? (0)

Need for low-level SerialPort callback in C#
Post #9 20584984 18 May 2023 08:32

I have two identical, CH340 dongles.

The issue is software related, I've tried even creating a thread per each port and constantly polling BytesToRead, but it still turned out to be problematic. It would be great to have some kind of immediate low level callback in C# for SerialPort, but I haven't found it so far. Maybe DataReceived? I will check it in the free time.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#10 20585103 18 May 2023 10:16

rakalexei rakalexei

Level 8

Posts: 21

Rate: 4
Helpful post? (0)

Post #10
20585103 18 May 2023 10:16

>>20584330

Hey, I have 3 PIR sensors like that, I successfully flashed them, but couldn't figure out the correct config. Could you please share your?
#11 20585139 18 May 2023 10:43

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42
Helpful post? (0)

Post #11
20585139 18 May 2023 10:43

I don't know if it will be the same, but the one I have has this configuration:

Code: JSON
Log in, to see the code

Autoexec.bat
Code: text Expand Select all Copy to clipboard
setChannel 3 1 addRepeatingEvent 30 -1 publishFloat "4" $CH4 delay_s 60 PinDeepSleep
Sleep earlier and add a 60-second deep-sleep fallback
#12 20585154 18 May 2023 10:52

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14770

Help: 659

Rate: 12913
Topic author Helpful post? (0)

Sleep earlier and add a 60-second deep-sleep fallback
Post #12 20585154 18 May 2023 10:52

@rakalexei do you have 2MB firmware backup, so we can extract GPIO with this tool:
https://github.com/openshwprojects/BK7231GUIFlashTool

@spin55 your autoexec.bat is working, but it's not optimal. You can reduce energy consumption by going to sleep earlier.
WARNING! The following template and script is for a device WITHOUT TUYA MCU. Please do not confuse it! The device from first post is TuyaMCU.
Something like:
Code: text Expand Select all Copy to clipboard
// set LED on??? setChannel 3 1 // every 1 second, publish value, just to be sure, should be not needed addRepeatingEvent 1 -1 publishFloat "4" $CH4 // wait for MQTT connection to establish waitFor MQTTState 1 // extra delay delay_s 3 // go to sleep PinDeepSleep

My script also has one drawback, it will wait forever if MQTT server is offline, you can fix it by adding a line:
Code: text Expand Select all Copy to clipboard
// after 60 seconds from now, force PinDeepSleep, even if MQTT was off addRepeatingEvent 60 -1 PinDeepSleep

of course, it must be added before WAITFOR.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Sleep earlier to reduce energy use
#13 20585196 18 May 2023 11:18

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42
Helpful post? (0)

Sleep earlier to reduce energy use
Post #13 20585196 18 May 2023 11:18

p.kaczmarek2 wrote:
@spin55 your autoexec.bat is working, but it's not optimal. You can reduce energy consumption by going to sleep earlier.
WARNING! The following template and script is for a device WITHOUT TUYA MCU. Please do not confuse it! The device from first post is TuyaMCU.

The autoexec.bat is for reference. Logically you have to play with the values of:
addRepeatingEvent 30 -1 publishFloat "4" $CH4 and delay_s 60 to adapt it to the needs of each one.

Without a doubt, your autoexec is best optimized for immediate use.
#14 20585200 18 May 2023 11:21

rakalexei rakalexei

Level 8

Posts: 21

Rate: 4
Helpful post? (0)

Post #14
20585200 18 May 2023 11:21

>>20585154

No, I don't have a dump.
Questioning the 30-second publish interval and 2MB backup value
#15 20585204 18 May 2023 11:26

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14770

Help: 659

Rate: 12913
Topic author Helpful post? (0)

Questioning the 30-second publish interval and 2MB backup value
Post #15 20585204 18 May 2023 11:26

spin55 wrote:

The autoexec.bat is for reference. Logically you have to play with the values of:
addRepeatingEvent 30 -1 publishFloat "4" $CH4 and delay_s 60 to adapt it to the needs of each one.

I am also not sure, why do you have value 30 here? Every 30 seconds?
It won't hurt to do a publish even every 1 second, if you have nothing against a little spam... just be sure.
Still, if channel is used, OBK should publish it automatically on change. So in reality there may be no need for a manual publish. So, where did the 30s value came from?

rakalexei wrote:

No, I don't have a dump.

I don't know which method you are using for flashing, but in general, 2MB backup is now very, very useful because we can extract GPIO from that.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Forced 30-second publish for battery value testing
#16 20585224 18 May 2023 11:43

spin55 spin55

Level 17

Posts: 209

Help: 17

Rate: 42
Helpful post? (0)

Forced 30-second publish for battery value testing
Post #16 20585224 18 May 2023 11:43

p.kaczmarek2 wrote:
I am also not sure, why do you have value 30 here? Every 30 seconds?
It won't hurt to do a publish even every 1 second, if you have nothing against a little spam... just be sure.
Still, if channel is used, OBK should publish it automatically on change. So in reality there may be no need for a manual publish. So, where did the 30s value came from?

I put this in because OBK (same as TuyaMCU) only posts when there is a battery value change. And I put every 30 seconds so it wouldn't do more than one forced post. I did it because in the tests I feed the equipment with a 3.3V source and I needed to verify that the battery value was published in HA.

Surely feeding the equipment with batteries or batteries, this command will not be necessary because when a variation occurs it will be published (I suppose, since I have not verified it).
C# port sniffer needs timeout tuning
#17 20645711 07 Jul 2023 15:48

mkmunichmk mkmunichmk

Level 7

Posts: 32

Rate: 2
Helpful post? (0)

C# port sniffer needs timeout tuning
Post #17 20645711 07 Jul 2023 15:48

p.kaczmarek2 wrote:
low level callback in C#

@p.kaczmarek2 As I wrote in another thread, I wanted to develop a bidirectional Port sniffer in C#.
In the past I'd used this approach to access serial USB ports and to be close to 'real time'. My gaol was to record 2 ports in parallel - you have been quicker than me
Also in your Analyzer ther is a build-in decoding of the Tuya MCU messages, which is not in my code
The port functions in your code are the same. I figured out, that the time-outs must be configured to get 'real time'. You might have a look at the source code https://github.com/MkMunich/SniffUART/tree/master/SniffUART

Best regards mkMunich
#18 20645869 07 Jul 2023 18:49

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14770

Help: 659

Rate: 12913
Topic author Helpful post? (0)

Post #18
20645869 07 Jul 2023 18:49

Your link is giving me 404 error:
https://github.com/MkMunich/SniffUART
So you're saying you've managed to get reliable realtime capture without messing packets order? How did you configure time outs?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
ReadLoop and ReadBytes handle serial timeouts
#19 20645901 07 Jul 2023 19:20

mkmunichmk mkmunichmk

Level 7

Posts: 32

Rate: 2
Helpful post? (0)

ReadLoop and ReadBytes handle serial timeouts
Post #19 20645901 07 Jul 2023 19:20

p.kaczmarek2 wrote:
Your link is giving me 404 error:

Sorry, forgot to make the project public.

Class PortHandler is handling the stuff. The timeouts are set in c'tor.
Reading is split up to the inner function to ReadBytes() which is either timing out or delivering received bytes and ReadLoop() which is looping until a chunk of bytes had been received and providing the bytes with a time stamp to the form to get displayed.
Sounds a bit strange, but is needed, as the Form is a seperate thread...
#20 20645910 07 Jul 2023 19:24

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14770

Help: 659

Rate: 12913
Topic author Helpful post? (0)

Post #20
20645910 07 Jul 2023 19:24

I was trying to do that in the separate thread but failed. Thank you for sharing. I will analyze your code later, but maybe you are interested in contributing to the Analyzer? You could just open the pull request and propose your changes there.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Analyzer setup for dual UART serial capture
#21 20645958 07 Jul 2023 20:09

mkmunichmk mkmunichmk

Level 7

Posts: 32

Rate: 2
Helpful post? (0)

Analyzer setup for dual UART serial capture
Post #21 20645958 07 Jul 2023 20:09

p.kaczmarek2 wrote:
contributing to the Analyzer

well, interested yes - if it would help. I worry, that your code would get merged into mine... and to maintain 2 different versions of the same thing makes no sense to me. Its up to you to decide. I suggest, that you have a look first.

Short instructions:
- Set the UART0 settings to the correct COMx ports of your first serial USB adapter
- Set the UART1 settings to the correct COMx ports of your second serial USB adapter
- A good starting point for a Read Timeout is 100 [ms]
- you might toggle to Hex view
- Save the settings (so they will be available next time when started
Suggests porting PortHandler.cs into TuyaMCU analyzer
#22 20646377 08 Jul 2023 10:13

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14770

Help: 659

Rate: 12913
Topic author Helpful post? (0)

Suggests porting PortHandler.cs into TuyaMCU analyzer
Post #22 20646377 08 Jul 2023 10:13

Your code looks very good. The PortHandler.cs class is very simple and nicely written. It seems that I was very close to figuring this out, because I had basically the same approach, but it didn't work for me for some reason. Maybe I needed to tune timing more.

I do not have the hardware at hand to check it now, but I still have a sensor from @spin55 , maybe I will use it along with it.

I think your changes won't break anything, if you want to port your PortHandler.cs to our TuyaMCU analyzer, feel free to do it.

You would need to modify SinglePort.cs from my source code. Of course, don't forget to include the Invoke for handling data from non-UI thread, but I can see that you have it in your code, so you must be already aware about it.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
SniffUART suggested for TuyaMCU message decoding
#23 20653382 13 Jul 2023 21:30

mkmunichmk mkmunichmk

Level 7

Posts: 32

Rate: 2
Helpful post? (0)

SniffUART suggested for TuyaMCU message decoding
Post #23 20653382 13 Jul 2023 21:30

p.kaczmarek2 wrote:
I do not have the hardware at hand to check it now

Thought you had at least 2 USB adapters? Anyway, they are cheap

If you have time, you might have a look to https://github.com/MkMunich/SniffUART
I started Msg decoding. Luckily I can use the Tuya documentation of the MCU protocol - so I started from scratch as this is more maintainable...
Have anice evening. BR MK_Munich
#24 20654665 14 Jul 2023 22:17

mkmunichmk mkmunichmk

Level 7

Posts: 32

Rate: 2
Helpful post? (+1)

Post #24
20654665 14 Jul 2023 22:17

mkmunichmk wrote:
have a look to https://github.com/MkMunich/SniffUART

Some progress:
- add Save As
- add Import
- add Decoder Form
- further message decoding
Recommend adding a battery-powered TuyaMCU mode selector
#25 20655582 15 Jul 2023 20:25

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14770

Help: 659

Rate: 12913
Topic author Helpful post? (0)

Recommend adding a battery-powered TuyaMCU mode selector
Post #25 20655582 15 Jul 2023 20:25

Sorry for the late reply. Yes, I've seen the progress, very good.

Regarding the question you've sent me, I didn't dig deep enough to differentiate between TuyaMCU battery powered devices protocol and standard TuyaMCU protocol, but, the thing is, user should already know whether the device is battery-powered or a simple one powered through a power supply from mains.

So I would just recommend adding a simple selection option. Something like a combobox, dropdown menu, etc.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
ADVERTISEMENT
Tuya MCU protocol selection before decoding messages
#26 20655740 15 Jul 2023 23:42

mkmunichmk mkmunichmk

Level 7

Posts: 32

Rate: 2
Helpful post? (0)

Tuya MCU protocol selection before decoding messages
Post #26 20655740 15 Jul 2023 23:42

p.kaczmarek2 wrote:
adding a simple selection option

This is exactly, what I've done & uploaded to git.
The consequence is, that a user has to choose one of the following Tuya MCU serial port protocols before decoding messages:
// McuSerPort: https://developer.tuya.com/en/docs/iot/tuya-c...rt-access-protocol?id=K9hhi0xxtn9cb#protocols
// McuLowPower: https://developer.tuya.com/en/docs/iot/tuyacl...niversalserialaccessprotocol?id=K95afs9h4tjjh
// McuHomeKit: https://developer.tuya.com/en/docs/iot/wifi-m...lopment-overview-for-homekit?id=Kaa8fvusmgapc
Best Regards
MK_Munich
#27 20655818 16 Jul 2023 07:28

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14770

Help: 659

Rate: 12913
Topic author Helpful post? (0)

Post #27
20655818 16 Jul 2023 07:28

Your tool is advancing nicely, I think you should create a separate topic for that in our Tutorials section and provide some screenshots, usage information, etc. We are currently in humidity sensor topic and we are doing a little offtopic with that...

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#28 20659220 18 Jul 2023 21:53

mkmunichmk mkmunichmk

Level 7

Posts: 32

Rate: 2
Helpful post? (0)

Post #28
20659220 18 Jul 2023 21:53

p.kaczmarek2 wrote:
our Tutorials section

I'll do this. Perhaps you can give me a hint, where to place it...

Best Regards
MK_Munich
#29 20659282 18 Jul 2023 22:44

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14770

Help: 659

Rate: 12913
Topic author Helpful post? (0)

Post #29
20659282 18 Jul 2023 22:44

Smart Home Tutorials Section:
https://www.elektroda.com/rtvforum/forum517.html

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
Parasitic power from programming wires blocked sensor readings
#30 20739869 20 Sep 2023 07:18

woszu woszu

Level 15

Posts: 287

Help: 2

Rate: 33
» | Helpful post? (+1)

Parasitic power from programming wires blocked sensor readings
Post #30 20739869 20 Sep 2023 07:18

Hello. Yesterday I was running Openbk on a Tuya temperature sensor.
The firmware was uploaded without any problem, but I had some downtime during testing because the sensor did not show any values, even though I was connected to the battery.
However, I did not disconnect the soldered power, ground, RX and TX cables for testing. It turned out that it was important and the wires had to be unsoldered because the BK could be powered parasitically by the programming system.
Ultimately, everything worked fine, including the battery status indication (low, medium, high).
I used this input into autoexec.bat:

Code: text Expand Select all Copy to clipboard
startDriver tuyaMCU startDriver tmSensor linkTuyaMCUOutputToChannel 1 val 1 setChannelType 1 Temperature_Div10 linkTuyaMCUOutputToChannel 2 val 2 setChannelType 2 Humidity linkTuyaMCUOutputToChannel 3 enum 3 setChannelType 3 ReadOnlyLowMidHigh setChannelLabel 3 Battery
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

Reply Cool? Ranking DIY | New topic

Notify about new articles

Listen:

Report a violation of the law

Topic summary

Discussion about reverse engineering a Tuya battery-powered WiFi temperature/humidity sensor based on CB3S/BK7231N and TuyaMCU. The thread covers PCB analysis, schematic reconstruction, UART packet capture, dpID mapping, and OpenBeken firmware replacement to remove cloud dependence and integrate with Home Assistant. It explains TuyaMCU protocol details such as ObtainDPCache, report intervals, battery state handling, persistent channel values, deep sleep behavior, and flashing methods. Later posts compare different sensor variants, identify alternative dpIDs, discuss timing issues in serial sniffing tools, and troubleshoot configuration problems, flashing without cutting traces, and external probe possibilities.
AI summary based on the discussion. May contain errors.

Home page
/
Forum
/
Smart Home
/
Smart Home IoT
/
Smart Home Devices
/
[CB3S/BK7231N] Temperature/Humidity Sensor with TuyaMCU - Diagram, Reverse Engin

FAQ

TL;DR: This FAQ is for OpenBeken users converting a CB3S/BK7231N Tuya TH01-style sensor: it measured about 5µA in MCU sleep, and the key warning is "disconnect the UART" before flashing or testing. It explains TuyaMCU dpIDs, OpenBeken autoexec.bat, Home Assistant MQTT, and common zero-reading failures. [#20564338]

Why it matters: Battery Tuya sensors combine cloud firmware, short wake windows, and MCU-controlled power, so one wrong UART or dpID setting can make Home Assistant show only zeros.

Approach	Hardware path	Sleep behavior	OpenBeken impact
TuyaMCU battery sensor	Separate MCU + CB3S/BK7231N over UART	MCU sleep measured about 5µA	Needs `TuyaMCU`, `tmSensor`, dpID mapping, and often dpCache
BK7231 deep sleep device	WiFi SoC handles sleep itself	BK7231 deep sleep measured about 6µA	Uses `PinDeepSleep`, not TuyaMCU dpIDs
Non-TuyaMCU PIR example	GPIO/ADC directly on BK7231	Script-controlled wake and sleep	Needs pin template, not TuyaMCU UART

Key insight: Treat the MCU as the real always-on controller. OpenBeken must answer its TuyaMCU handshake quickly, publish MQTT, then let the MCU cut CB3S power.

Quick Facts

The analyzed sensor uses a CB3S WiFi module based on BK7231N, a separate unidentified MCU, and an SHT30 temperature/humidity sensor read over I2C. [#20564338]
The measured sleep current with the WiFi module powered off was about 5µA; a BK7231-only deep sleep comparison measured about 6µA. [#20564338]
The captured product information string was { "p":"byusvumeme5iicad", "v":"1.0.0" }, exchanged through TuyaMCU command 0x01. [#20564338]
Reporting interval control used dpID 17 for temperature and dpID 18 for humidity; tested values included 1 minute, and the thread mentions 1–120 minutes on suitable products. [#20973055]
Some visually similar TH01 sensors use different dpIDs, such as 27 for temperature, 46 for humidity, and 101 for battery, so the original autoexec.bat can fail. [#21778134]

What is TuyaMCU and how does it communicate with a CB3S/BK7231N WiFi module in a battery temperature and humidity sensor?

TuyaMCU is the UART protocol between the always-on MCU and the CB3S/BK7231N WiFi module. "TuyaMCU is a UART based protocol that lets the product MCU exchange dpID status and configuration frames with the WiFi module, while the MCU can also control WiFi power in battery devices." In this sensor, the MCU reads the SHT30 over I2C, turns CB3S power on through a MOSFET, then exchanges 55 AA frames at wake-up. [#20564338]

How do I flash OpenBeken on a CB3S/BK7231N Tuya temperature and humidity sensor without keeping it tied to the Tuya cloud?

Flash OpenBeken by isolating the CB3S UART, powering the module with 3.3V, and writing a BK7231N OpenBeken binary. 1. Disconnect MCU-to-CB3S UART resistors or tracks. 2. Power CB3S directly from a stable 3.3V programmer supply. 3. Flash with BK7231 GUI Flash Tool, then restore UART and add autoexec.bat in LittleFS. The thread’s final setup used MQTT and Home Assistant Discovery after flashing. [#20564338]

Why do I need to disconnect or cut the UART lines between the MCU and CB3S before flashing OpenBeken?

You disconnect the UART because the same CB3S UART port serves both TuyaMCU communication and firmware flashing. If the MCU stays connected, it can drive RX/TX during programming or testing. One user found the sensor showed no values until power, ground, RX, and TX programming wires were removed. The module can also receive parasitic power from the programmer, which changes wake and power behavior. [#20739869]

Which TuyaMCU dpIDs are used for temperature, humidity, battery level, reporting interval, and unit settings in the TH01-style sensor?

The original TH01-style mapping uses dpID 1 for temperature times 10, dpID 2 for humidity percent, and dpID 3 for battery state. dpID 9 selects Celsius or Fahrenheit, with 0 for °C and 1 for °F. dpID 17 controls temperature reporting interval, and dpID 18 controls humidity reporting interval. Similar-looking devices may instead use dpID 27, 46, and 101, so UART capture confirms the real map. [#20564338]

How should I write the OpenBeken autoexec.bat for a TuyaMCU temperature and humidity sensor with Home Assistant MQTT discovery?

Use TuyaMCU, tmSensor, and explicit dpID-to-channel links in autoexec.bat. A minimal setup starts both drivers, maps dpID 1 as Temperature_Div10, dpID 2 as Humidity, and dpID 3 as ReadOnlyLowMidHigh battery. Add linkTuyaMCUOutputToChannel 17 val 5 1 and 18 val 6 1 only when the device supports dpCache intervals. Home Assistant Discovery then exposes the scripted channels through MQTT. [#20564338]

What does the TuyaMCU ObtainDPCache command 0x10 do, and how is it used to change the reporting interval?

Command 0x10 lets the MCU ask the WiFi module for cached settings, such as reporting intervals. The WiFi module replies with dpID, type, and value records. In OpenBeken, the extra 1 in linkTuyaMCUOutputToChannel 17 val 5 1 marks that channel as dpCache data. The MCU can then store values like 1 minute or 60 minutes and use them for future wake cycles. [#20584330]

Why does my OpenBeken-flashed Tuya temperature sensor show 0 values for temperature and humidity even though MQTT is connected?

Zero readings mean OpenBeken is not receiving or decoding the correct TuyaMCU data frames. Check four concrete items: UART restored after flashing, correct baud rate such as 9600 or 115200, correct dpIDs, and working MQTT before the MCU sleeps. Some boards use dpID 27 and 46 instead of 1 and 2. Also avoid flashing old backup images; use current OpenBeken binaries and configure the device separately. [#20922287]

How can I save an OpenBeken channel value in flash memory so it survives reboot or deep sleep wake cycles?

Set the channel start value to -1, which tells OpenBeken to remember the previous channel value in flash. For example, SetStartValue 5 -1 keeps channel 5 across reboots. The thread uses this for report interval fields and later confirms it works for cached values. This helps battery devices reuse settings after the MCU powers the CB3S off. [#20973103]

How can I publish the current date and time to MQTT from an OpenBeken device?

The thread asks this question but does not provide a working date-and-time MQTT command. The same post later confirms the basic sensor setup was working, but no complete time-publish script appears there. Use only documented OpenBeken commands for production, and test during the sensor’s short wake window, which was about 11 seconds in the report-cycle test. [#20917074]

What is the difference between a TuyaMCU battery-powered sensor and a non-TuyaMCU deep sleep sensor in OpenBeken?

A TuyaMCU battery sensor uses a separate low-power MCU to control CB3S power and report dpID data over UART. A non-TuyaMCU deep sleep sensor connects signals directly to BK7231 GPIO or ADC and uses PinDeepSleep. The thread warns that PIR scripts using Rel, dInput, ADC, and PinDeepSleep are for devices without TuyaMCU, not the first TH01 sensor. [#20585154]

BK7231N deep sleep vs separate low-power MCU power control — which approach gives better battery life for Tuya sensors?

The measured results were very close: the TuyaMCU sensor drew about 5µA with CB3S VDD disconnected, while BK7231 deep sleep measured about 6µA. The separate MCU design keeps WiFi fully unpowered until reporting, then the MCU turns it on through a MOSFET. The BK7231-only design can wake from GPIO but keeps the WiFi SoC in deep sleep. [#20564338]

How can I sniff and decode TuyaMCU UART communication using BK7231 GUI Flash Tool, MCUAnalyzer, or SniffUART?

Capture both UART directions, then decode 55 AA TuyaMCU frames into commands, dpIDs, types, and values. BK7231 GUI Flash Tool can do dual UART capture, MCUAnalyzer comments frames, and SniffUART added decoder forms and protocol choices. For TuyaMCU, select the correct protocol family, such as standard MCU serial, low-power MCU, or HomeKit MCU serial. A read timeout near 100 ms was suggested for SniffUART. [#20645958]

Why can dual UART captures show packets in the wrong order, and how do USB serial adapters like CH340, CP2102, and FTDI affect logging?

Dual captures can misorder packets because USB serial and software polling add enough latency to disturb timestamps. The thread reports CH340 dongles, CP2102, and FTDI adapters showing different capture behavior. One user measured Realterm rates of 20 CPS on CP2102 and 5 CPS on FTDI232. The author also noted that even dual capture may need human post-processing. [#20584759]

Which chip on the TH01 temperature and humidity sensor PCB actually measures temperature and humidity, such as SHT30, CHT8310, or U4?

The temperature and humidity sensor is the small sensor IC marked as U4 on the PCB photo, and the original analysis identifies the measured device as SHT30 over I2C. Later variants may use a CHT8310 T/H sensor. The MCU, not the CB3S, reads this sensor and then sends values through TuyaMCU dpIDs. [#21330698]

How can I add an external temperature or humidity probe to a Tuya TH01-style sensor, and which pins or sensor types would be compatible?

The thread does not confirm a working external probe mod for the TuyaMCU TH01 board. The key requirement is firmware and hardware support from the MCU that reads the existing U4/SHT30 or CHT8310 sensor. OpenBeken on CB3S cannot directly replace that reading unless the external sensor connects to supported BK7231 pins and the MCU power design still permits it. The author first asked for the MCU marking, such as PHY62220C. [#21333979]

AI summary based on the discussion. May contain errors.