Energy-saving (?) Battery-operated door / window sensor for WiFi DS06

p.kaczmarek2 7047 38

This content has been translated

View the original version here.

Reply Cool? Ranking DIY | New topic

Notify about new articles

#1 23 Aug 2022 01:18

I will present here the interior of the Tuya WiFi door / window sensor implemented on the basis of two separate systems - a microcontroller (powered all the time) and a WiFi module (here: CB3S / BK7231N; powered only when you need to send information via WiFi) communicating via UART (TuyaMCU protocol but in version 0x00, not 0x03). I will also try to measure its power consumption in sleep mode. It will be a slightly different type of sensor than previously reviewed made on the XR809 / XR3 WiFi module itself:

In this topic, I will focus on the operation of the DS06 sensor and its TuyaMCU communication protocol with the WiFi module.

Purchase of a sensor
I bought the product at the direct request of one of the users. You can find it on the web under the name "AVATTO Tuya WiFi Door Sensor, Smart Door Open / Closed Detectors, Smart Life APP Wifi Window Sensor Work with Alexa, Google Home" as well as under the model name: D06 / DS06. It costs about PLN 40.

The product is advertised (truthfully) as compatible with the Tuya and SmartLife applications:

Kit contents
I waited a few weeks for the package again. It was brought by Pocztex, although it was given by "Sinotrans in the name and on behalf of Cainiao".

The packaging is in SmartLife blue (Tuya has orange), but it's all the same ecosystem:

The set includes instructions, screws and tape for fixing:

Instructions (pairing mode can be entered by pressing RESET for more than 7 seconds):

The sensor requires two AAA batteries:

Test with applicationTuya
The sensor is repainted with SmartLife and the QR code leads to the SmartLife application, but is also compatible with the original, "orange" Tuya application:

You can create automation in it, but this has already been discussed in the forum several times.

Interior of D06
It is enough to pry the housing with a knife:

Inside there is a CB3S WiFi module (BK7231N) and a microcontroller (no marking):

Leads of CB3S - from Tuya documentation:

Pin number	Symbol	I / O type	Function
1	RST	AND	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	AND	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	-	-

In order to analyze the tile in more detail, I first removed the binder with the braid and then removed it from the plastic base:

However, there is not much on the bottom:

On the basis of the collected knowledge, I have prepared a sketch of the connections:

This door / window opening sensor works quite differently than the one I described in the past sensor realized on XR809 (XR3) . Here, the WiFi module is normally turned off - only the microcontroller is still working. The microcontroller can only turn on the power CB3S through the MOSFET transistor with P channel A19T when needed. This microcontroller communicates with the CB3S via the TuyaMCU protocol, but in the version for battery-powered devices, i.e. 0x00 and not 0x03.
Simply put, the connection looks like this:

The artwork is from the official one Tuya documentation .
The method of reporting data by the sensor is illustrated by this algorithm:

The WiFi module works for a really short period of time, normally only the microcontroller in the low power consumption mode listens for changes on the sensor.
I do not describe the changes of the CB3S batch here, because it was discussed e.g. for CB2S, but I will only emphasize that the linesRX / TX are occupied by TuyaMCU, so if we want to program, we have to cut them off or unsolder that IC ...

A twin product - flood sensor W06
As in the case of the previously discussed window opening / door sensor based on the XR809 module (but without TuyaMCU), this product is also sold in the form of a flood sensor - it is just the same PCB, the same circuits, but instead of the reed switch, the contacts are just brought out moisture sensor:

I performed the tests below on both devices - they work similarly.
The only difference is that we as a user know that the door open sensor is reporting Open / closed and the moisture sensor reports wet / dry . The packages themselves are identical.

Captured TuyaMCU packets to UART
I intercepted at baud 9600. I leave packages here, among others. for myself for the future, when I will implement / finalize the support of this TuyaMCU version in OpenBeken .
I described the basics of TuyaMCU here (it was a slightly different version, but most of it fits):
TuyaMCU protocol - communication between the microcontroller and the WiFi module .
When analyzing packages, I recommend using the official documentation:
Serial Communication Protocol
Activation.
CB3S ships:

Quote:

55 AA 00 01 00 00 00

We have here (hex):
- heading - 55 AA
- version - 00
- command code - 01
- data length - 00 00
- checksum - 00
Command code 0x01 is getting product data - Query Product Information.
TuyaMCu replies:

Quote:

55 AA 00 01 00 24 7B 22 70 22 3A 22 65 37 64 6E 79 38 7A 76 6D 69 79 68 71 65 72 77 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D 24

The content of this packet (0x24 bytes long, i.e. 36 bytes in decimal) is ASCII text:

Quote:

55 AA 00 01 00 24 {"p": "e7dny8zvmiyhqerw", "v": "1.0.0"} $

Device ID + version.
Already paired, contact closed when power was applied.
(in the following quotes I have not divided separate request-reply pairs, only in the form of one block, I gave first what the CB3S sends and then what the microcontroller corresponds to)
CB3S ships:

Quote:

00 00
55 AA 00 01 00 00 00
55 AA 00 02 00 01 04 06
55 AA 00 08 00 01 00 08
55 AA 00 08 00 01 00 08 00

TuyaMCu replies:

Quote:

00
55 AA 00 01 00 24 7B 22 70 22 3A 22 65 37 64 6E 79 38 7A 76 6D 69 79 68 71 65 72 77 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D 24
55 AA 00 02 00 00 01
55 AA 00 02 00 00 01
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 01 00 01 01 23
55 AA 00 08 00 0C 00 01 01 01 01 01 01 03 04 00 01 02 23 00

The message type 0x02 is a setting of the WiFi working status, and 0x08 is already sensor data, but more on that in a moment. First, a few more examples.

Already paired, device in sleep mode, I woke it up by closing the contact.
CB3S ships:

Quote:

00
55 AA 00 01 00 24 7B 22 70 22 3A 22 65 37 64 6E 79 38 7A 76 6D 69 79 68 71 65 72 77 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D 24
55 AA 00 02 00 00 01
55 AA 00 02 00 00 01
head vr id size FL YY MM DD HH MM SS ID TP SIZE VL CK
55AA 00 08 000C 00 02 02 02 02 02 02 01 01 0001 00 22
head vr id size FL YY MM DD HH MM SS ID TP SIZE VL CK
55AA 00 08 000C 00 01 01 01 01 01 01 03 04 0001 02 23

Under the package I wrote what is what - head (header), vr (version), id (package identifier), size (size), FL (flag), then date values, then ID (dpID / fnID, i.e. the name of the variable) , TP (type), SIZE (variable value size), VL (value - its value), CK - checksum, checksum.

Already paired, device in sleep mode, I woke it up by opening the contact.
CB3S ships:

Quote:

00
55 AA 00 01 00 24 7B 22 70 22 3A 22 65 37 64 6E 79 38 7A 76 6D 69 79 68 71 65 72 77 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D 24
55 AA 00 02 00 00 01
55 AA 00 02 00 00 01
head vr id size FL YY MM DD HH MM SS ID TP SIZE VL CK
55AA 00 08 000C 00 02 02 02 02 02 02 01 01 0001 01 23
head vr id size FL YY MM DD HH MM SS ID TP SIZE VL CK
55AA 00 08 000C 00 01 01 01 01 01 01 03 04 0001 02 23
00

Packets of the 0x08 type (data) contain date / time (incorrect here), marked by me as YY MM DD HH MM SS, a flag that determines the correctness of the date (my FL designation) and additional data, the so-called data point, ID (variable id), TP (its type), SIZE (its size) and VL (its value).
It is the VL value that determines the state of the door sensor.
Below are screenshots describing the structure of this package from the documentation:

Already paired, device in sleep mode, I woke it up by pressing the RESET button.
CB3S ships:

Quote:

00
55 AA 00 01 00 00 00 (01 = Query Product Information)
55 AA 00 02 00 01 03 05 (02 = MCU Conf)
55 AA 00 02 00 01 04 06 (02 = MCU Conf)
55 AA 00 08 00 01 00 08 00 (08 = Query State)

TuyaMCU replies:

Quote:

00
55 AA 00 01 00 24 7B 22 70 22 3A 22 65 37 64 6E 79 38 7A 76 6D 69 79 68 71 65 72 77 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D 24 (01 = Query Product Information)
55 AA 00 02 00 00 01 (02 = MCU Conf)
55 AA 00 02 00 00 01 (02 = MCU Conf)
head vr id size FL YY MM DD HH MM SS ID TP SIZE VL CK
55AA 00 08 000C 00 01 01 01 01 01 01 03 04 0001 02 23 00 (08 = Query State)

Experiment: what does CB2S send itself when we cut off RX and TX paths and reboot?
Just for the sake of principle - it should be clear.


55AA0001000000F8

Let's break down the contents of the package:


55AA 00 0100 00 00 F8

Let me remind you, we have in turn:
- 55AA - header
- 00 - version
- 0100 - length 1 byte
- 00 - data
- 00 - checksum
The repeating F8 / F9 looks like a glitch, it is not part of the packet.
Experiment: what does TuyaMCU itself send after cutting off TX and RX?
Surprisingly, however, it sends something - probably to keep the connection:

A zero byte every few seconds. Or it's a disruption.

And what if after starting the power supply, we will send a request for identification to TuyaMCU:

Quote:

0x55 0xAA 0x00 0x01 0x00 0x00 0x00

Response:

Quote:

55 AA 00 01 00 24 7B 22 70 22 3A 22 6A 35 33 72 6B
64 75 35 35 79 64 63 30 66 6B 71 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22
7D 43

Yes - this is already the packet discussed with an ASCII value of type {"P": "vHXEcqntLpkAl ***", "v": "1.0.0 "} ;
Screenshot:

How do we try to ask him about his condition?


0x55 0xAA 0x00 0x08 0x00 0x01 0x00 0x08

No answer.
You have to send the configuration first, then you can ask for Data Points 0x08:


0x55 0xAA 0x00 0x02 0x00 0x01 0x04 0x06

Below is the entire transaction:

Broken answers:


55 AA 00 02 00 00 01
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 01 26
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 01 26
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 00 25
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 01 26
55 AA 00 08 00 0C 00 01 01 01 01 01 01 03 04 00 01 02 23


55 AA 00 02 00 01 04 06
55 AA 00 02 00 00 01
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 01 26
55 AA 00 08 00 0C 00 01 01 01 01 01 01 03 04 00 01 02 23
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 00 25 
55 AA 00 08 00 0C 00 01 01 01 01 01 01 03 04 00 01 02 23
55 AA 00 02 00 01 04 06
55 AA 00 02 00 00 01
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 00 25
55 AA 00 08 00 0C 00 01 01 01 01 01 01 03 04 00 01 02 23 
55 AA 00 08 00 0C 00 01 01 01 01 01 01 ID TP LENG  VL CH


55 AA 00 02 00 00 01
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 01 26 
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 00 25
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 01 26
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 01 26
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 01 26 
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 01 26 
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 00 25 
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 01 26
55 AA 00 08 00 0C 00 01 01 01 01 01 01 03 04 00 01 02 23  
55 AA 00 08 00 0C 00 01 01 01 01 01 01 ID TP LENG  VL CH

Packages collected on a twin flood sensor (identical layout and protocol, only a different sensor).
Wet (or actually putting the sensor in the water):


55 AA 00 02 00 01 04 06
55 AA 00 02 00 00 01
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 01 26
55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 00 25
55 AA 00 08 00 0C 00 01 01 01 01 01 01 03 04 00 01 02 23 
55 AA 00 08 00 0C 00 01 01 01 01 01 01 ID TP LENG  VL CH
55 AA 00 02 00 01 04 06
55 AA 00 02 00 00 01

(you can see the change of the variable with ID = 01 from VL 01 to VL 00)
Dry:


55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 01 26
55 AA 00 08 00 0C 00 01 01 01 01 01 01 03 04 00 01 02 23    
55 AA 00 08 00 0C 00 01 01 01 01 01 01 ID TP LENG  VL CH

Can you see the difference?
Please do not pay attention to the last value, it is a checksum, you know that it changes.
Wet:


55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 00 25
55 AA 00 08 00 0C 00 01 01 01 01 01 01 ID TP LENG  VL CH

Dry:


55 AA 00 08 00 0C 00 02 02 02 02 02 02 01 04 00 01 01 26
55 AA 00 08 00 0C 00 01 01 01 01 01 01 ID TP LENG  VL CH

A packet with ID 0x01 (dpID or fnID 0x01) changes the value from 1 (VL, Value) to 0.
We also have ID 0x03:


55 AA 00 08 00 0C 00 01 01 01 01 01 01 03 04 00 01 02 23

... but this is the state of the battery (value, VL, 02).

Finally, I did a test in OpenBeken - both systems powered separately from 3.3V, the microcontroller awakened, the strange 00 00 00 in the tuyaMCU buffer appear when the microcontroller is asleep (its UART is turned off) and the WiFi module works in an artificial way (we additionally powered it):

OpenBeken is able to receive the MCU Identification packet.
However, if we send the 0x02 configuration package ourselves (in the screenshot by the uartSendHex command), then CB3S will also send us the 0x08 package with the variable states:

Summarizing, the above data shows that two variables TuyaMCU (data points) in the package 0x08 are used in these sensors:
- dpID 1 - sensor status, 0 or 1 (for a door sensor it is open / close, for a moisture sensor it is wet / dry)
- dpID 3 - battery status, from 3 (full) to 0 (or 1 - not checked).
These data are reported by TuyaMCU after the WiFi module has been identified.

Configuration in OpenBeken
My OpenBeken it already supports this sensor, but I haven't fully tested the full functionality yet.
To support this sensor, you need to turn on two "drivers", one TuyaMCU and the other tmSensor. TuyaMCU handles the UART communication base, and the tmSensor itself sends out state inquiries (remember - the WiFi module first responds to TuyaMCU via UART).
Here is the OpenBeken command line (I entered it in the startup command to be executed at startup):


backlog startDriver tuyaMCU; startDriver tmSensor; linkTuyaMCUOutputToChannel 1 val 1; setChannelType 1 ReadOnly; linkTuyaMCUOutputToChannel 3 val 3; setChannelType 3 ReadOnly;

Channels / dpID the same as above - 1 and 3. One is the state of the sensor, the other is the battery.
Yaml configuration in Home Assistant (this example is for a water sensor, but as I wrote, it's the same system, only a different sensor, the door opening sensor works similarly):

I have not done the battery reading yet - I will post the full version in the next topic.
Screenshot from the panel:

View in HA:

Power consumption in sleep and data upload mode
The microcontroller only activates the WiFi module when data needs to be sent, but how much electricity does it save? Sleep mode:

Sending data (current flows about 70mA here)

Summary
This door / window opening sensor is indeed different from the sensor discussed earlier, which is based on the XR809. Adding a microcontroller that turns on the WiFi module whenever you need to send new information to the server certainly allows to save energy to some extent and extends battery life, but also complicates the system itself and makes it difficult to add its support to my firmware.
My measurements show that the current consumption in MCU sleep mode is about 5 uA. It is worth mentioning that then the MCU even turns off its UART (I checked - it does not respond) and only waits for a signal from the sensor or sensor.
As soon as the signal is received, the WiFi module is on and the power consumption is up to 70mA or more, depending on what the WiFi is doing.
These 5uA is a rather good result - I looked at the ESP8266 datasheet (there is no ESP here, only BK7231N, but I think it's worth comparing) and depending on the sleep mode, the ESP8266 consumes the following currents:

so the manufacturer could actually gain something from this addition of the MCU.
Interestingly, the 5uA result is similar to the ESP32 power consumption in hibernation mode (based on its catalog note):

Of course, the power consumption is also influenced by the power consumption during the operation of the WiFi module - only that it is difficult to judge how much impact it is, because we do not know how often the door will be opened.
The same product also acts as a flood sensor - the system and protocol are identical, the only difference is that a different sensor is soldered.
The sensor itself has already been pre-processed for mine OpenBeken (I added support for it in my firmware) but it's not the final version, so I'll detail it another time.
Does anyone use this type of sensors and if so, how long does the battery last? Feel free to discuss.

Cool? Ranking DIY

About Author

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Offline

p.kaczmarek2 wrote 4859 posts with rating 5193, helped 236 times. Been with us since 2014 year.

#2 23 Aug 2022 08:23

noyo noyo

Level 18

» | Helpful post? (0)

#2 23 Aug 2022 08:23

Or maybe someone noticed this type of sensor, but a smaller one for the CR2032 battery and after BT?
#3 23 Aug 2022 08:36

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (+1)

#3 23 Aug 2022 08:36

I reviewed a sensor that uses a CR1632 that communicates over Zigbee - the Zigbee is generally a bit more energy efficient, but more expensive.
Aqara MCCGQ11LM door opening sensor on Zigbee - test, interior, charts

Really want a sensor with BT communication?

An interesting fact was the door opening sensor charged via USB:
Zigbee door opening sensor charged via USB - BW-IS2 Blitzwolf
#4 23 Aug 2022 10:14

piotr_go piotr_go

DIY electronics designer

» | Helpful post? (+1)

#4 23 Aug 2022 10:14

noyo wrote:
Or maybe someone noticed this type of sensor, but a smaller one for the CR2032 battery and after BT?

I do not recommend. The current capacity of the CR2032 drops significantly at low temperatures.
It will work in summer, not necessarily in winter.
#5 23 Aug 2022 13:27

sortes sortes

Level 11

» | Helpful post? (+2)

#5 23 Aug 2022 13:27

I use several similar sensors:

The battery life depends on how often the sensors are turned on.
The same batteries have been stuck in the basement and in the flood detectors for 2 years.
This is an example of how often Panasonic LR AAA batteries are replaced at the balcony door:

2020/11/04
2021/05/22
2022/01/04
2022/08/10
#6 23 Aug 2022 18:36

krzbor krzbor

Level 25

» | Helpful post? (+1)

#6 23 Aug 2022 18:36

piotr_go wrote:

noyo wrote:
Or maybe someone noticed this type of sensor, but a smaller one for the CR2032 battery and after BT?

I do not recommend. The current efficiency of the CR2032 drops significantly at low temperatures.
It will work in summer, not necessarily in winter.

I have iNODE temperature sensors on BT. I decided to give one outside. On a CR2032 battery, it works very well even in frost. You can see a slight voltage drop when it's very cold, but that doesn't interfere with communication at all.
#7 23 Aug 2022 20:18

piotr_go piotr_go

DIY electronics designer

» | Helpful post? (0)

#7 23 Aug 2022 20:18

I have a Zigbee sensor (cc2530). He always died around November / December. After being brought home, he revived.
I changed the battery to the little Saft and I have a few years of peace.
#8 24 Aug 2022 19:52

krzbor krzbor

Level 25

» | Helpful post? (0)

#8 24 Aug 2022 19:52

noyo wrote:
Or maybe someone noticed this type of sensor, but a smaller one for the CR2032 battery and after BT?

Maybe something like that Link ? Unfortunately, they are not the cheapest.
#9 24 Aug 2022 20:13

noyo noyo

Level 18

» | Helpful post? (0)

#9 24 Aug 2022 20:13

krzbor wrote:

noyo wrote:
Or maybe someone noticed this type of sensor, but a smaller one for the CR2032 battery and after BT?

Maybe something like that Link ? Unfortunately, they are not the cheapest.
I have versions with a motion and temperature sensor. I still bought it when it was cheaper. But then when I tested it, it crashed and needed to be restarted. Maybe I will come back to this and check again. Thanks for reminding me.
#10 24 Aug 2022 23:03

krzbor krzbor

Level 25

» | Helpful post? (0)

#10 24 Aug 2022 23:03

noyo wrote:
I have versions with a motion and temperature sensor. I still bought it when it was cheaper. But then when I tested it, it crashed and had to be restarted. Maybe I'll come back to that and check again. Thanks for reminding me.

Maybe something wrong with the firmware? In general, there should be no problems with communication, because it is one-way - iNODE only sends statuses. I have several temperature sensors - I set the maximum transmit power and the maximum time between packets and turned off the diode - the sensors transmit for over a year on one battery.
#11 25 Aug 2022 22:03

noyo noyo

Level 18

» | Helpful post? (0)

#11 25 Aug 2022 22:03

krzbor wrote:

noyo wrote:
I have versions with a motion and temperature sensor. I still bought it when it was cheaper. But then when I tested it, it crashed and needed to be restarted. Maybe I'll come back to that and check again. Thanks for reminding me.

Maybe something wrong with the firmware? In general, there should be no problems with communication, because it is one-way - iNODE only sends statuses. I have several temperature sensors - I set the maximum transmit power and the maximum time between packets and turned off the diode - the sensors transmit for over a year on one battery.
I wanted to update the firmware, but on andoid 10 the applications from the website are not running, while on andoid 4.4.2 it works, but the "browse .." button to select the firmware file does not respond.
#12 28 Aug 2022 09:56

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

#12 28 Aug 2022 09:56

As for the TuyaMCU protocol for battery powered devices; such a curiosity; I can see that someone, based on my article about XR809 programming, made a simple demo of this protocol only for this platform:
https://github.com/tony-fav/FavTuyaXR3

Quote:

This is an attempt at a custom firmware for the Feit Electric Smart Wi-Fi Water Sensor (https://www.feit.com/product/smart-wi-fi-water-sensor/) which has a Tuya XR3 WIFI Module ( https://developer.tuya.com/en/docs/iot/xr3-datasheet?id=K98s9168qi49g) following the efforts of p.kaczmarek2 on elektroda.com (https://www.elektroda.com/rtvforum/topic3806769. html # 19447386). I got mine from my local Menards after seeing the elektroda post because it seemed like a fun project (https://www.menards.com/main/plumbing/pumps-tanks/pump-well-tank-accessories/feit-electric- smart-wi-fi-water-sensor / senfwag / p-7919224473280192-c-8672.htm).

You have photos of another device from TuyaMCU, this time on XR3, I have not seen one like this before.
Package parsing the code author has here:
https://github.com/tony-fav/FavTuyaXR3/blob/master/project/at_demo/main.c
Although this is only quickly put together, judging by the way it is implemented:

Code: c
Log in, to see the code
#13 24 Dec 2022 15:38

dmitridiavo dmitridiavo

Level 2

Helpful post? (0)

#13 24 Dec 2022 15:38

Hi.
I bought another revision of the water leakage sensor.
It contains cb3s and um8005(tuya?) chips.
I flashed cb3s with the latest firmware OpenBK.
It works, but tuyaMCU needs baud rate 115200. I used startup command "tuyaMcu_setBaudRate 115200"
But there is a problem. Often the first time we get wet, the mqtt doesn't send a message. If you immediately dry it and wet it again, the messages come normally. After a deep sleep, the first message can again be missed.
in the stock firmware all messages arrive correctly
#14 24 Dec 2022 16:06

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
Topic author Helpful post? (0)

#14 24 Dec 2022 16:06

Hello. First of all, have you enabled the MQTT broadcast on the connect?

Code: text Expand Select all Copy to clipboard
Flag 10 - [MQTT] Broadcast self state on MQTT connect

#15 25 Dec 2022 17:33

dmitridiavo dmitridiavo

Level 2

#15 25 Dec 2022 17:33

Thanks for the advice!
Now i have enabled flag 10. As a result, the device sends some statuses over the protocol, but not channels 1 and 3.
log:

Spoiler:

####### Boot Count 170 #######
Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 29 changes count.
Error:CMD:lfs is absent
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:Using SSID [OpenWrt]
Info:MAIN:Using Pass [********]
Info:MQTT:MQTT_RegisterCallback called for bT bathroom/waterleak/ subT bathroom/waterleak/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/bathroom/waterleak/ subT cmnd/bathroom/waterleak/+
Info:MAIN:Started tuyaMCU.
Info:MAIN:Started tmSensor.
Info:GEN:Channel 1 type changed to ReadOnly
Info:GEN:Channel 3 type changed to ReadOnly
Error:CMD:lfs is absent
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Time 1, idle 287961/s, free 82928, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 2, idle 186101/s, free 82928, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 3, idle 186384/s, free 82928, 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 74 35 68 36 34 6E 63 77 61 66 75 72 77 6E 61 79 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D CF 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 1 (QueryProductInformation) with 43 bytes
Info:TuyaMCU:TuyaMCU_ParseQueryProductInformation: received {"p":"t5h64ncwafurwnay","v":"1.0.0"}
Info:MAIN:Time 4, idle 186171/s, free 82928, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 5, idle 180830/s, free 82928, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:ssid:OpenWrt key:********
Info:MAIN:Time 6, idle 184804/s, free 77968, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
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:TuyaMCU:TUYAMCU received: 55 AA 00 05 00 05 01 04 00 01 00 0F 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 5 (WiFiSelect) with 12 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 1, dataType 4-DP_TYPE_ENUM and 1 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 1 byte: 
Info:GEN:CHANNEL_Set channel 1 has changed to 0 (flags 0)

Info:MAIN:Channel has changed! Publishing change 1 with 0 
Info:MAIN:Time 7, idle 184146/s, free 77968, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 8, idle 98345/s, free 77784, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 9, idle 0/s, free 77784, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 10, idle 0/s, free 77784, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:GEN:dhcp=0 ip=0.0.0.0 gate=0.0.0.0 mask=0.0.0.0 mac=a0:92:08:58:30:9b 
Info:GEN:sta: 0, softap: 0, b/g/n
Info:MAIN:wl_status 3
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING
Info:MAIN:wl_status 10
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED
Info:MAIN:wl_status 11
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED
Info:MAIN:Time 11, idle 61056/s, free 77896, MQTT 0(0), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MQTT:Publishing val obk0858309B to bathroom/waterleak/host retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -13 result 0
Info:MAIN:Time 14, idle 188346/s, free 57544, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 4/38
Info:MQTT:Publishing val Build on Dec 21 2022 16:05:20 version 1.15.217 to bathroom/waterleak/build retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -12 result 0
Info:MAIN:Time 15, idle 176233/s, free 77640, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MQTT:Publishing val a0:92:08:58:30:9b  to bathroom/waterleak/mac retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -11 result 0
Info:MAIN:Time 16, idle 181170/s, free 77848, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MAIN:Boot complete time reached (15 seconds)
Info:CFG:####### Set Boot Complete #######
Info:MQTT:Publishing val 18 to bathroom/waterleak/uptime retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -6 result 0
Info:MAIN:Time 19, idle 181609/s, free 77848, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MQTT:Publishing val 77848 to bathroom/waterleak/freeheap retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -5 result 0
Info:MAIN:Time 20, idle 182677/s, free 77848, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:GEN:dhcp=0 ip=192.168.1.109 gate=192.168.1.1 mask=255.255.255.0 mac=a0:92:08:58:30:9b 
Info:GEN:sta: 1, softap: 0, b/g/n
Info:GEN:sta:rssi=-52,ssid=OpenWrt,bssid=9c:9d:7e:85:7b:df ,channel=11,cipher_type:CCMP
Info:MQTT:Publishing val 192.168.1.109 to bathroom/waterleak/ip retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -4 result 0
Info:MAIN:Time 21, idle 180822/s, free 77848, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 22, idle 363949/s, free 77848, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 23, idle 183035/s, free 77848, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38

Hypothesis: the channel changes before the wifi connects. This is strange. the code is expected to connect to mqtt.

Also i enable flag 19 - [MQTT] Always publish channels used by TuyaMCU and set the start value for channel 1 and 3 as '9'. For me it means 'unknown' in HomeAssistant

Success:

Spoiler:

Info:MAIN:Main_Init_Before_Delay
Info:CFG:####### Boot Count 176 #######
Warn:CFG:CFG_InitAndLoad: Correct config has been loaded with 30 changes count.
Error:CMD:lfs is absent
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:Using SSID [OpenWrt]
Info:MAIN:Using Pass [********]
Info:MQTT:MQTT_RegisterCallback called for bT bathroom/waterleak/ subT bathroom/waterleak/+/set
Info:MQTT:MQTT_RegisterCallback called for bT cmnd/bathroom/waterleak/ subT cmnd/bathroom/waterleak/+
Info:MAIN:Started tuyaMCU.
Info:MAIN:Started tmSensor.
Info:GEN:Channel 1 type changed to ReadOnly
Info:GEN:Channel 3 type changed to ReadOnly
Error:CMD:lfs is absent
Info:MAIN:Main_Init_After_Delay done
Info:MAIN:Time 1, idle 287551/s, free 82928, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 2, idle 187113/s, free 82928, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 3, idle 187279/s, free 82928, 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 74 35 68 36 34 6E 63 77 61 66 75 72 77 6E 61 79 22 2C 22 76 22 3A 22 31 2E 30 2E 30 22 7D CF 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 1 (QueryProductInformation) with 43 bytes
Info:TuyaMCU:TuyaMCU_ParseQueryProductInformation: received {"p":"t5h64ncwafurwnay","v":"1.0.0"}
Info:MAIN:Time 4, idle 188359/s, free 82928, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 5, idle 181928/s, free 82928, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:ssid:OpenWrt key:********
Info:MAIN:Time 6, idle 185596/s, free 77968, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
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:TuyaMCU:TUYAMCU received: 55 AA 00 05 00 05 01 04 00 01 00 0F 
Info:TuyaMCU:TuyaMCU_ProcessIncoming[ver=0]: processing command 5 (WiFiSelect) with 12 bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: processing dpId 1, dataType 4-DP_TYPE_ENUM and 1 data bytes
Info:TuyaMCU:TuyaMCU_V0_ParseRealTimeWithRecordStorage: raw data 1 byte: 
Info:GEN:CHANNEL_Set channel 1 has changed to 0 (flags 0)

Info:MAIN:Channel has changed! Publishing change 1 with 0 
Info:MAIN:Time 7, idle 185757/s, free 77968, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 8, idle 99222/s, free 77784, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 9, idle 0/s, free 77784, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 10, idle 0/s, free 77784, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/38
Info:GEN:dhcp=0 ip=0.0.0.0 gate=0.0.0.0 mask=0.0.0.0 mac=a0:92:08:58:30:9b 
Info:GEN:sta: 0, softap: 0, b/g/n
Info:MAIN:wl_status 3
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTING
Info:MAIN:wl_status 10
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED
Info:MAIN:wl_status 11
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED
Info:MAIN:Time 11, idle 60838/s, free 77896, MQTT 0(0), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MAIN:Time 12, idle 182877/s, free 77720, MQTT 0(0), bWifi 1, secondsWithNoPing -1, socks 3/38
Info:MQTT:mqtt_userName waterleak1
mqtt_pass qqqqqqqqqq
mqtt_clientID bathroom/waterleak
mqtt_host 192.168.1.110:1883
Info:MAIN:Time 13, idle 188485/s, free 77640, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MQTT:mqtt_connection_cb: Successfully connected
Info:MQTT:mqtt_subscribed to bathroom/waterleak/+/set
Info:MQTT:mqtt_subscribed to cmnd/bathroom/waterleak/+
Info:MQTT:MQTT client "bathroom/waterleak" request cb: err 0
Info:MQTT:MQTT client "bathroom/waterleak" request cb: err 0
Info:MQTT:Publishing val obk0858309B to bathroom/waterleak/host retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -13 result 0
Info:MAIN:Time 14, idle 182521/s, free 77600, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MQTT:Publishing val Build on Dec 21 2022 16:05:20 version 1.15.217 to bathroom/waterleak/build retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -12 result 0
Info:MAIN:Time 15, idle 183035/s, free 77848, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MQTT:Publishing val a0:92:08:58:30:9b  to bathroom/waterleak/mac retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -11 result 0
Info:MAIN:Time 16, idle 184125/s, free 77848, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MAIN:Boot complete time reached (15 seconds)
Info:CFG:####### Set Boot Complete #######
Info:MQTT:Publishing val 2 to bathroom/waterleak/sockets retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -8 result 0
Info:MAIN:Time 17, idle 176456/s, free 77848, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MQTT:Publishing val -51 to bathroom/waterleak/rssi retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -7 result 0
Info:MAIN:Time 18, idle 185788/s, free 69240, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 3/38
Info:MQTT:Publishing val 18 to bathroom/waterleak/uptime retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -6 result 0
Info:MAIN:Time 19, idle 185675/s, free 77848, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MQTT:Publishing val 77848 to bathroom/waterleak/freeheap retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -5 result 0
Info:MAIN:Time 20, idle 187380/s, free 77848, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:GEN:dhcp=0 ip=192.168.1.109 gate=192.168.1.1 mask=255.255.255.0 mac=a0:92:08:58:30:9b 
Info:GEN:sta: 1, softap: 0, b/g/n
Info:GEN:sta:rssi=-51,ssid=OpenWrt,bssid=9c:9d:7e:85:7b:df ,channel=11,cipher_type:CCMP
Info:MQTT:Publishing val 192.168.1.109 to bathroom/waterleak/ip retain=0
Info:MQTT:[g_bPublishAllStatesNow] item -4 result 0
Info:MAIN:Time 21, idle 364009/s, free 77848, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38
Info:MAIN:Forced channel publish! Publishing val 0 to 1
Info:MQTT:Publishing val 0 to bathroom/waterleak/1/get retain=0
Info:MQTT:[g_bPublishAllStatesNow] item 1 result 0
Info:MAIN:Time 22, idle 197028/s, free 77848, MQTT 1(1), bWifi 1, secondsWithNoPing -1, socks 2/38

If enable only in flag 19 it works too.
Thanks for your project!

#16 13 Jan 2023 20:24

klaudi43 klaudi43

Level 4

» | Helpful post? (0)

#16 13 Jan 2023 20:24

Hey,

First of all, thank you for the great work. Flashing the sensors worked great with the instructions. This is my first attempt at openbeken.
I can also reach the modules via IP address and MQTT. Unfortunately, the sensor does not send any change in contact state. I assume it's a pin configuration issue. I can't find any reference to it. I tested it with different settings but still can't.
TuyaMCU works.
Can anyone give me a hint which setup is still pending? Do I need to adjust anything on the pins? if yes, where?

Thank you and best regards
#17 13 Jan 2023 20:40

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
» | Topic author Helpful post? (0)

#17 13 Jan 2023 20:40

@klaudi43

Please set:

Code: text Expand Select all Copy to clipboard
Flag 2 - [MQTT] Broadcast self state every N (def: 60) seconds (delay configurable by 'mqtt_broadcastInterval' and 'mqtt_broadcastItemsPerSec' commands) Flag 10 - [MQTT] Broadcast self state on MQTT connect Flag 19 - [MQTT] Always publish channels used by TuyaMCU
#18 15 Jan 2023 13:29

klaudi43 klaudi43

Level 4

Helpful post? (0)

#18 15 Jan 2023 13:29

Witam,

Przede wszystkim dziękuję za szybką informację zwrotną. Dostosowałem ustawienia zgodnie z opisem. Niestety oba kanały wysyłają tylko 0.
Zakładam, że jest to związane ze sprzętem. Wydaje się, że jest to nowa generacja czujników. Wygląda więc na to, że to coś większego.
„Bawiłem się” również dostosowywaniem szybkości transmisji i przełączaniem kanałów, ale zawsze uzyskuję te same wyniki.
Zrobiłem zdjęcie modułu. Może to pomaga.
Jeszcze raz dziękuję i pozdrawiam!
#19 15 Jan 2023 13:46

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Topic author Helpful post? (0)

#19 15 Jan 2023 13:46

Wait a minute, is that your device? There is no TuyaMCU on your board.
The TuyaMCU is external microcontroller that is next to the WiFI module:

Your device is not a TuyaMCU one.
You should configure it differently.
What kind of device is that and where was it bought?
#20 15 Jan 2023 14:12

klaudi43 klaudi43

Level 4

Helpful post? (0)

#20 15 Jan 2023 14:12

Kupiłem na Ebayu. Numer zn373141_01 jest wydrukowany na opakowaniu. Odpowiada również zdjęciom na AliExpress i jest oferowany jako Tuya / Aubess.
#21 15 Jan 2023 15:10

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Topic author Helpful post? (0)

#21 15 Jan 2023 15:10

Please attach screenshots from ebay offer to the post. Futhermore, I am still not sure what kind of sensor is that - is this a door sensor or a remote switch? I can't see the sensor part... here's a photo of another door sensor, I am asking about the part marked with arrow:

Futhermore, on .com domain please reply in English and on .pl domain reply in Polish, that is because we have automatic translation between those two sides and it breaks if someone uses wrong language on wrong side of the forum.

Why is the sensor not soldered on your photos? Is your device some other kind of IoT gadget, I don't know, a remote switch?
#22 15 Jan 2023 16:52

klaudi43 klaudi43

Level 4

Helpful post? (0)

#22 15 Jan 2023 16:52

Hi,

these are Door Senors. I've bought them "second hand". The seller used them with tuya software and it has worked (I have to believe this, because I didn't try it.). As I mentioned, I think this is another generation of sensors. It seems, the functionality is in the CB3S - Module. I've seen the missing hall-sensor but - I'm not sure, because of missing documentation, this could be another type of hall-sensor. (Q3 on the picture - 204NS).

Please excuse the language confusion.

Best regards!
#23 15 Jan 2023 17:33

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Topic author Helpful post? (0)

#23 15 Jan 2023 17:33

No problem, i guess the first step would be trying to figure out which IO port of CB3S is used for door state.

You can do this in many ways, including:
1. check with multimeter which IOs are connected where and sketch connections
2. desolder CB3S and just take a look
3. try guessing in firmware?

As for firmware, I'd recommend setting "dInput" role, which is a digital input, with channel, let's say, 0, and then simulating door close and open to see if it changes from 0 to 1.

This way you can figure out which IO is a door state.

Futhermore, you will need a "PowerSave" command in short startup command otherwise battery will drain in HOURS. You will also need a Deep sleep feature soon, but we're working on it.

Please remove MCU code, there is no TuyaMCU on this board.
#24 16 Jan 2023 10:46

klaudi43 klaudi43

Level 4

Helpful post? (0)

#24 16 Jan 2023 10:46

Hello again,

I tried configuring it with the CB3S module. The door contact works on pin 8. Maybe it will be helpful for others in this forum.

In the next step I need to find out how it is possible to monitor the battery level. I think it's realized on another pin.
As you have already written, it currently makes no sense to operate the modules with batteries. So thanks again for the support! Have a good start into your week!

Many greetings
#25 16 Jan 2023 11:02

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Topic author Helpful post? (0)

#25 16 Jan 2023 11:02

Hello @klaudi43 , can you set the ADC role for the ADC pin, assign another channel and see it gives sensible readings?
Where is ADC pin connected? Maybe it's the one we're looking for.
#26 17 Jan 2023 13:24

klaudi43 klaudi43

Level 4

Helpful post? (0)

#26 17 Jan 2023 13:24

Hi,

by using the ACD3 Pin (P23) I get the Value 4096. By trying the same with other Pins, I only get a -1.

Greetings
#27 17 Jan 2023 13:37

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Topic author Helpful post? (0)

#27 17 Jan 2023 13:37

@klaudi43 maybe check on PCB? Do a bit more detailed PCB analysis...

@klaudi43 we have a deep sleep progress, this will be useful for your device: https://www.elektroda.com/rtvforum/viewtopic.php?p=20389704#20389704 we might get your device fully supported really soon.
#28 23 Jan 2023 14:18

klaudi43 klaudi43

Level 4

Helpful post? (0)

#28 23 Jan 2023 14:18

Hi,

I've measured the pins, but I can't make sense of the values. But it's not my world either .

Maybe you can do more with the values. As I said - all soldered pins - except for the ADC always give a -1 out.
Energy-saving (?) Battery-operated door / window sensor for WiFi DS06

This measurement was done between L+ and the Pins - I think this should be enough. The structure seems very simple. Except for a transistor (L6) and LED, there is nothing special on the board. Only a few resisitors and capacitors.
#29 25 Jan 2023 23:10

elbuit elbuit

Level 5
Helpful post? (0)

#29 25 Jan 2023 23:10

klaudi43 wrote:
Hello again,

I tried configuring it with the CB3S module. The door contact works on pin 8. Maybe it will be helpful for others in this forum.

In the next step I need to find out how it is possible to monitor the battery level. I think it's realized on another pin.
As you have already written, it currently makes no sense to operate the modules with batteries. So thanks again for the support! Have a good start into your week!

Many greetings

Hi.
I've same device bought on aliexpress.

But I couldn't manage to install OpenBeken firmware.
I tried with gui flash tool under linux but it showed a UART error.
So I tried to flash with CLI but I got a CRC error.

[/code]
$ ./uartprogram -d /dev/ttyUSB0 -r door_sensor_pati_backup.bin -u
UartDownloader....
Read Getting Bus...
Gotten Bus...
Set baudrate successful
len: 119000
startAddr: 11000
Reading 11000
ReadSector Success 11000 len 1000
4096
Reading 12000
ReadSector Success 12000 len 1000
[...]

ReadSector Success 129000 len 1000
1150976
CRC should be 7f0be275
CRC is 61efceb3
CRC check failed
Wrote 119000 bytes to door_sensor_pati_backup.bin
[/code]

I did it serveral times and I got the same error and the same CRC (61efceb3) so I thought that the CRC error couldn't come from the wires or the USB reader.
So I tried to write the OpenBeken firmware, and it worked.
Code: text Expand Select all Copy to clipboard
$ ./uartprogram -d /dev/ttyUSB0 -w OpenBK7231N_QIO_1.15.384.bin -u UartDownloader.... programm.... Write Successful: |##################################################|[ 10.6k/s]

But unafortunatelly that bricked my device, or at least I couldn't see OpenBeken SSID.

Any advice to unbrick.

Thanks.

NOTE: I used CLI because I coulnd't manage to write OpenBeken firmware with the gui flashtool, I used CLI with an WB2S device and it worked fine but not the mono BK7231Flasher.exe.
#30 25 Jan 2023 23:43

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Topic author Helpful post? (+1)

#30 25 Jan 2023 23:43

Hello @elbuit . You are using uartprogram incorrectly. Please consult manual:
https://github.com/OpenBekenIOT/hid_download_py

You are missing offset.
You can also watch out CB2S flashing video:

Here's the part that should interest you:
Create an account, log in and become active in a forum and ads will not appear. You will receive points by participating in discussions.
Join this discussion.

Log in with Google

Reply Cool? Ranking DIY | New topic

Notify about new articles