Elektroda.com
Elektroda.com
X
Elektroda.com

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

p.kaczmarek2 2136 11
This content has been translated flag-pl » flag-en View the original version here.
  • Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    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:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    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.
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    The product is advertised (truthfully) as compatible with the Tuya and SmartLife applications:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06

    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".
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    The packaging is in SmartLife blue (Tuya has orange), but it's all the same ecosystem:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    The set includes instructions, screws and tape for fixing:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Instructions (pairing mode can be entered by pressing RESET for more than 7 seconds):
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    The sensor requires two AAA batteries:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06

    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:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    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:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Inside there is a CB3S WiFi module (BK7231N) and a microcontroller (no marking):
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    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 - -

    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    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:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    However, there is not much on the bottom:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    On the basis of the collected knowledge, I have prepared a sketch of the connections:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    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:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    The artwork is from the official one Tuya documentation .
    The method of reporting data by the sensor is illustrated by this algorithm:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    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:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06 Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    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:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06

    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.
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Code:

    55AA0001000000F8

    Let's break down the contents of the package:
    Code:

    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:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    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:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    How do we try to ask him about his condition?
    Code:

    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:
    Code:

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

    Below is the entire transaction:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Broken answers:
    Code:

    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



    Code:

    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


    Code:

    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):
    Code:

    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:
    Code:

    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:
    Code:

    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:
    Code:

    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:
    Code:

    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):
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    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:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06

    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):
    Code:

    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):
    Code: yaml
    Log in, to see the code

    I have not done the battery reading yet - I will post the full version in the next topic.
    Screenshot from the panel:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    View in HA:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06

    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:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Sending data (current flows about 70mA here)
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06

    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:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    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):
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    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
    Level 27  
    Offline 
    p.kaczmarek2 wrote 2159 posts with rating 3937, helped 94 times. Been with us since 2014 year.
  • #2
    noyo
    Level 18  
    Or maybe someone noticed this type of sensor, but a smaller one for the CR2032 battery and after BT?
  • #3
    p.kaczmarek2
    Level 27  
    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
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    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
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
  • #4
    piotr_go
    DIY electronics designer
    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
    sortes
    Level 11  
    I use several similar sensors:

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

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

    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
    krzbor
    Level 24  
    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
    piotr_go
    DIY electronics designer
    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
    krzbor
    Level 24  
    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
    noyo
    Level 18  
    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
    krzbor
    Level 24  
    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
    noyo
    Level 18  
    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
    p.kaczmarek2
    Level 27  
    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:
    Energy-saving (?) Battery-operated door / window sensor for WiFi DS06
    Code: c
    Log in, to see the code