Closed 1286840533 closed 1 year ago
Ok, maybe this helps:
What it is: Transfer at Address = 0x00? , if the sensor address is 0x70
I have no idea, but it happens quite often:
That is, some kind of crooked sensor that does not work according to the description in the documentation. A defective batch of sensors?
I2C specification: 0x00 - resrved addres
I think we are getting somewhere. General call is mentioned in the datasheet. But only for reset (0x0006). But the data shown in my picture (0x7ca2) is a valid command (Read T first)
So maybe instead of it's real address the sensor somehow only works with the general call address.
When creating a "General Calling Address", the next byte must indicate the address of the device. But according to the oscillogram, everything is not so.
https://www.pololu.com/file/0J435/UM10204.pdf
"3.1.13 General call address"
I'll try to make a "special curved interface" for CGDK2 variants...
Sure, it violates every spec. It seems, just replace 0x70 with 0x00 for commands where no other bus access has occured since the first addressing of the 0x70 device.
How do I know which commands didn't have responses for sensors I don't have? Will this work for those who have a normal sensor? The ID is required that the sensor is different.
Test of operation on defective SHTv3 sensors. CGDK2_v42.bin replaced.
It still displays only zeros.
_20:49:59: Received device infos are correct 20:49:59: Login successfull 20:50:06: File: CGDK2_v42_test.bin 20:50:06: File size: 78372 bytes 20:50:06: Count: 4899 20:50:08: Start DFU 20:50:29: Update done after 20.555 seconds 20:50:30: Disconnected. 20:51:17: Searching for devices 20:51:38: Connecting to: Qingping Temp RH Lite 20:51:50: Hardware Revision String: 2.1.0 20:51:50: Detected custom Firmware 20:51:50: Hardware Version: CGDK2 2.1.0, Software Version: 4.2, Sensor: SHTC3 (SHTV3) 20:51:50: Custom config HEX string: 55012000002804a9313186b4000000 20:52:07: File: Original_OTA_CGDK2_v1.1.10223.bin 20:52:07: File size: 116100 bytes 20:52:07: Count: 7257 20:52:11: Start DFU 20:53:10: Update done after 58.157 seconds 20:53:14: Disconnected.
On Thursday, I think I will have time to search for a I2C logger and record the whole communication.
It's useless. If it does not work for you, then this means that the "measure" command was executed by the sensor at address 0x70 and confirmed by ACK. Reading data after the "measure" instruction has been executed requires a NACK check. While the measurement is being performed, the sensor will respond to any address with NACK. Until the data is ready.
Ultimately, auto-detection of the bad sensor is not possible without expending a large increase in battery consumption.
Requires special firmware for bad sensor thermometers. But there is no way to determine that the sensors are defective.
The manufacturer is completely indifferent to the fact that the batary consumption of their CGDK2-x firmware is huge. They sold it - it works, but that the battery will soon be planted is none of their business.
CGDK2 has the highest sleep consumption of all thermometers. When the temperature drops, the LCD goes out and is buggy. In the new version of CGDK2 with bad sensors, the power capacitor is not soldered. What's even worse is the impact on battery consumption and worked stability. CGDK2 is an unfortunate version of thermometers. Support for "new" CGDK2 should be excluded.
On the CGDK2 version without BLE, after a few months, the battery died and was replaced. On the official version of the CGDK2 firmware with BLE, it is similar. Options flashed with custom firmware work for me and the battery has not changed.
20:50:06: File: CGDK2_v42_test.bin
This is not the file. Then there was an auto-include in TelinkMiFlasher.html (v4.2 beta). Now CGDK2n_v42.bin is temporarily available with commands at 0x00 without any auto-recognition, and "Beta v4.2" has been restored.
Flashed the above CGDK2n_v42.bin and now it displays temperature and humidity. I was able to reconnect to it and set the advertisement to BTHome mode. It's not picked up by the HA BT integration so far... but at least this seems like progress.
And I spoke too soon! Changed to the Mihome type and it is now integrated into HA.
20:50:06: File: CGDK2_v42_test.bin
This is not the file. Then there was an auto-include in TelinkMiFlasher.html (v4.2 beta). Now CGDK2n_v42.bin is temporarily available with commands at 0x00 without any auto-recognition, and "Beta v4.2" has been restored.
Works like a charm!
This patch is for testing purposes only and is not suitable for regular CGDK2 firmware. On a normal sensor, such firmware does not work... It is required to somehow identify the wrong sensors.
This patch is for testing purposes only and is not suitable for regular CGDK2 firmware. On a normal sensor, such firmware does not work... It is required to somehow identify the wrong sensors.
I2C Scan for 0x70. Then reading the values in the regular way. If they are Zero (Wich should never happen with a real measurement), reading the values with 0x00 address.
此补丁仅用于测试目的,不适用于常规 CGDK2 固件。在普通传感器上,这样的固件不起作用...... 需要以某种方式识别错误的传感器。
The temperature and humidity are still a constant, but at least not zero. Status: Hardware Version: CGDK2 2.1.0, Software Version: 4.2 Vbat: 2717 mV , Temp: 60.07°C, Humi: 36.25%, ID: 2, Reed switch counter: 3, flg: 0x05:r1/t0
after flash v39, same issue happen(both temp & humi display 0). flash https://github.com/pvvx/ATC_MiThermometer/blob/master/Original_OTA_CGDK2_v1.1.1_0223.bin back make device work again.
@yuchangyuan How did you manage to flash the device back. After the "E2" error im not able to connect to the device again.
I can still connect to the sensor, maybe I replace battery as @Sawadee2u do, I forget the details. Replace with a new battery maybe necessary because flashing will consume a lot of power.
19:08:36: Searching for devices 19:08:38: Connecting to: Qingping Temp RH Lite 19:08:42: Not found Telink OTA service! 19:08:42: Disconnected.
In my case, with the SW displaying "E2" I only was able flash it via USB.
Ok I will try it. How did you manage to open the device without destroying the enclosure?
after flash v39, same issue happen(both temp & humi display 0). flash https://github.com/pvvx/ATC_MiThermometer/blob/master/Original_OTA_CGDK2_v1.1.1_0223.bin back make device work again.
@yuchangyuan How did you manage to flash the device back. After the "E2" error im not able to connect to the device again.
I can still connect to the sensor, maybe I replace battery as @Sawadee2u do, I forget the details. Replace with a new battery maybe necessary because flashing will consume a lot of power.
19:08:36: Searching for devices 19:08:38: Connecting to: Qingping Temp RH Lite 19:08:42: Not found Telink OTA service! 19:08:42: Disconnected.
In my case, with the SW displaying "E2" I only was able flash it via USB.
Ok I will try it. How did you manage to open the device without destroying the enclosure?
Use a small screwdriver to get the inner cover (the part with the hole for the battery) out. It is not glued in and requires very little force.
after flash v39, same issue happen(both temp & humi display 0). flash https://github.com/pvvx/ATC_MiThermometer/blob/master/Original_OTA_CGDK2_v1.1.1_0223.bin back make device work again.
@yuchangyuan How did you manage to flash the device back. After the "E2" error im not able to connect to the device again.
I can still connect to the sensor, maybe I replace battery as @Sawadee2u do, I forget the details. Replace with a new battery maybe necessary because flashing will consume a lot of power.
19:08:36: Searching for devices 19:08:38: Connecting to: Qingping Temp RH Lite 19:08:42: Not found Telink OTA service! 19:08:42: Disconnected.
In my case, with the SW displaying "E2" I only was able flash it via USB.
Ok I will try it. How did you manage to open the device without destroying the enclosure?
Use a small screwdriver to get the inner cover (the part with the hole for the battery) out. It is not glued in and requires very little force.
Thanks! This was much simpler then expected. Will figure out how to flash it now from USB.
I am unable to get a second of the four CGDK2-wacko devices to program without the resulting zeros for Temp and Humid after getting one (F525) to work.
MAC for these four devices received at the same time F51A zeros with v41 and v42 and CGDK2n_v42.bin F525 This was the first one I tried to program and got zeros with v41 and v42 but it took CGDK2n_v42.bin dated 2/22 F536 zeros with v41 and v42 and CGDK2n_v42.bin F558 zeros with v41 and v42 and CGDK2n_v42.bin
I can get the three, that will not work with CGDK2n_v42.bin, to take the factory FW 1.1.1_0223 and work with Home Assistant through the Xiaomi BLE app with a proper binding key. These show Temp, Humid, Battery Voltage, Battery %, and Signal in dbm. F525 shows up in BT Home app and shows Temp, Humid, Battery Voltage, Battery %, Signal in dbm, Packet id, and Power. F525 updates data every 10 seconds which is programmable but the other three with factory FW update about every 10 mins.
I just don't know why I can't get these other three to work with any version of the custom FW. Must be doing something different but can't understand what.
And the next one with the 0° 0% Problem. Three devices only work after flashing back to FW 1.1.1_023. HW Version is 2.1.0 @pvvx Do you want me to send one to you for further analysis?
I do not accept any donations except information. I have not yet been able to buy an CGDK2 with faulty sensors when buying in four stores... If there is a desire to speed up the process, then an example of working code with these sensors or documentation is desirable.
The latest firmware has built-in I2C bus scanning commands. https://github.com/pvvx/ATC_MiThermometer#control-function-id-when-connected Code "03". The answer will be shown in the log TelinkMiFlasher.html.
There is also the possibility of accessing I2C devices. Code "04....". But this universal command has a complex syntax.
/* Universal I2C/SMBUS read-write transaction struct */
typedef struct _i2c_utr_t {
unsigned char mode; // bit0..6: The byte number of the record for the new START (bit7: =1 - generate STOP/START)
unsigned char rdlen; // bit0..6: Number of bytes read (bit7: =0 - the last byte read generates NACK, =1 - ACK)
unsigned char wrdata[1]; // Array, the first byte is the address, then the bytes to write to the bus: i2c_addr_wr, wr_byte1, wr_byte2, wr_byte3, ... wr_byte126
} i2c_utr_t;
For example, the command "0400007cf3c8" will cause the LCD controller to flash the screen. (BU9792FUV LCD controller)
For today, about CGD2 with defective sensors are unknown:
Thanks for the quick response. Unfortunately command 0x03 does not provide any output on the CGD2
12:04:47: Searching for devices
12:04:52: Connecting to: CGD_14FF31
12:05:16: Hardware Revision String: 2.1.0
12:05:16: Software Revision String: V4.2
12:05:16: Detected custom Firmware
12:05:16: Hardware Version: CGDK2 2.1.0, Software Version: 4.2, Sensor: SHTC3 (SHTV3)
12:05:16: Custom config HEX string: 55011000002804a9313186b4
12:05:26: Settings 0370 was send successful
12:05:48: Settings 4 was send successful
12:05:49: I2C Read/Write fault! (255)
12:05:59: Settings 3 was send successful
12:06:43: Settings 2 was send successful
12:06:44: Sensor: I2C addres 0x70, LCD driver: I2C addres 0x3E
I also tried the 0x03 command on some LYWSD03MMCs and a MHO-C401 . But no output to be seen on the console. @pvvx Does it require a parameter?
And what do you exactly mean by working code here:
If there is a desire to speed up the process, then an example of working code with these sensors or documentation is desirable.
I also downloaded the development environment today. So I could help more actively here.
Chrome -> F12 -> console The response of the "03" command is displayed only in the Chrome console.
Well aye! JavaScript debugging console. Sorry, now the bell rings.
Anyhow I can provide this from the console:
Send cmd (3303): Query 3 measurements
TelinkMiFlasher.html:1630 Send cmd ok
TelinkMiFlasher.html:1630 Custom (0x1f1f) Notifications id: 0x33 [00]
TelinkMiFlasher.html:1630 Vbat: 2772 mV , Temp: 0.00°C, Humi: 0.00%, ID: 0, Reed switch counter: 0, flg: 0x00:r0/t0
TelinkMiFlasher.html:1630 Vbat: 2773 mV , Temp: 0.00°C, Humi: 0.00%, ID: 0, Reed switch counter: 0, flg: 0x00:r0/t0`
Ok, the [00] is the response.
One of my LYWSD03MMCs provided 0x78e0 as an answer, see:
LYWSD03MMCs resonse to 0x03
Send: 3
TelinkMiFlasher.html:1630 Custom (0x1f1f) Notifications id: 0x03 [78e0]
TelinkMiFlasher.html:1630 Vbat: 2406 mV , Temp: 19.66°C, Humi: 51.40%, ID: 5536, Reed switch counter: 0, flg: 0x0E:r0/t1
But for the CGD2: why does the scanner return 0x00 while the display shows 0° and 0% hum and the battery symbol? At least the display is addressed well. Stranissimo!
LYWSD03MMC B1.4 02 -> Sensor: I2C addres 0x70, LCD driver: I2C addres 0x3C 03 -> Custom (0x1f1f) Notifications id: 0x03 [78e0]
LYWSD03MMC B1.9 02 -> Sensor: I2C addres 0x44, LCD driver: I2C addres 0x3E 03 -> Custom (0x1f1f) Notifications id: 0x03 [7c88]
CGG1-M 2022 02 -> Sensor: I2C addres 0x70, LCD driver: I2C addres 0x00 = (E-Ink/EPD SPI) 03 -> Custom (0x1f1f) Notifications id: 0x03 [e0]
MJWSD05MMC V2.3 02 -> Sensor: I2C addres 0x44, LCD driver: I2C addres 0x3E, RTC: I2C addres 0x51 03 -> Custom (0x1f1f) Notifications id: 0x03 [7c88a2]
CGDK2 2.1.0 02 -> Sensor: I2C addres 0x70, LCD driver: I2C addres 0x3E 03 -> Custom (0x1f1f) Notifications id: 0x03 [7ce0]
...
LYWSD03MMC:
HW | LCD I2C addr | SHTxxx I2C addr | Note |
---|---|---|---|
B1.4 | 0x3C | 0x70 (SHTC3) | |
B1.6 | UART! | 0x44 (SHT4x) | |
B1.7 | 0x3C | 0x44 (SHT4x) | Test original string HW |
B1.9 | 0x3E | 0x44 (SHT4x) | |
B2.0 | 0x3C | 0x44 (SHT4x) | Test original string HW |
Stable I2C speed limited by the elements on the PCB:
The starting speed of I2C applied at the first initialization for all is 100 kHz
The worst of all supported thermometer options in terms of battery consumption is CGDK2. Consumption of a working LCD controller and screen - from 9 µA. Plus, in all the latest released versions of CGDK2, power capacitors are not soldered. In the old versions, they were soldered. This reduces the battery life by another 40%. And leads to instability of the main SoC. The LCD controller is buggy at subzero temperatures. Now some CGDK2 sensors are defective... At the same time, the price of CGDK2 is overstated and is equal to thermometers on E-Ink. It's time to remove them from support.
After reading the entire entry I flashed CGDK2n_v42.bin with the patch and now it the device shows correct values. Somehow this patched version is not in the current repository anymore. So I recompiled it.
The worst of all supported thermometer options in terms of battery consumption is CGDK2. Consumption of a working LCD controller and screen - from 9 µA. Plus, in all the latest released versions of CGDK2, power capacitors are not soldered. In the old versions, they were soldered. This reduces the battery life by another 40%. And leads to instability of the main SoC. The LCD controller is buggy at subzero temperatures. Now some CGDK2 sensors are defective... At the same time, the price of CGDK2 is overstated and is equal to thermometers on E-Ink. It's time to remove them from support.
Do you know the value of the capacitor? Just for those who are crazy enough to retrofit them.
The reason is that there is no way to accurately determine the version with bad sensors for devices with Qingping CGDK2 firmware. The differences are only in the "Firmware Revision". But the old ones also work with such a "Firmware Revision". In TelinkMiFlasher.html I'll insert a warning:
addAlog("Warning! The device with this Firmware Revision is not supported!");
Do you know the value of the capacitor? Just for those who are crazy enough to retrofit them.
I don't see the point in buying and modifying bad things.
I don't see the point in buying and modifying bad things.
Valued Victor. I totally understand your point here. If I would have known how crappy the CGDK2s are I would NEVER HAVE bought them. But since I am having three of them on my table I just want to make the best out of it, instead of chucking them. If the MHO-C401s would have been available, they surely would have been my choice. Hätte hätte ...
Capacitors are different. Some have a large leakage current comparable to the consumption of a thermometer. The general recommendation is an SMD with a capacity from 22 to 47 UF and a voltage of 25 V. The higher the voltage rating, the lower the leakage current. The larger the capacitance of the capacitor, the greater the leakage current. It is necessary to choose the optimum.
v4.3: Added "Sensor ID".
Command 05
SHTV3 "Sensor ID: 00000887"
Hardware Version: CGDK2 2.1.0, Software Version: 4.3, Sensor: SHTC3 (SHTV3)
Settings 05 was send successful
Sensor ID: 00000887
https://sensirion.com/products/catalog/SHTC3/
SHT4x - id 2x16 bits...
@cultur98 - If the new CGDK2 will have a different 'Sensor ID', then auto-detection is possible.
@cultur98 - If the new CGDK2 will have a different 'Sensor ID', then auto-detection is possible.
09:14:08: Hardware Version: CGDK2 2.1.0, Software Version: 4.3, Sensor: SHTC3 (SHTV3)
09:14:08: Custom config HEX string: 55251000002804a9313186b4
09:14:13: Settings 5 was send successful
09:14:15: Sensor ID: 00000000
It is "zero".
So there is also no response to the "Read ID" command. Therefore, this command will not be able to identify the curved sensor.
Hardware Version: LYWSD03MMC B1.9, Software Version: 4.3, Sensor: SHT4x
..
Settings 05 was send successful
Sensor ID: 47D20F9C
Added all SHT4x:
So there is also no response to the "Read ID" command. Therefore, this command will not be able to identify the curved sensor.
This is sad but still a little strange since temperature and humidity are read correctly when applying the
#define BAD_SENSOR 1
patch to firmware 4.3.
Status: Hardware Version: CGDK2 2.1.0, Software Version: 4.3
Vbat: 2841 mV , Temp: 18.26°C, Humi: 52.66%, ID: 2884, Reed switch counter: 0, flg: 0x0E:r0/t1
Well it is probably really not worth spending that much effort.
Since I try to avoid MS Windows I did a build script for Linux which I called MakeAll.sh
#!/bin/bash
SWVER=_v43
make_bin () {
BIN_FILE=$1$SWVER".bin"
echo "============================"
echo " Building $BIN_FILE"
echo "============================"
DEV_STRING=$2
rm -f BIN_FILE
make -s -j PROJECT_NAME=$1$SWVER POJECT_DEF="$DEV_STRING"
}
make_bin "ATC" "-DDEVICE_TYPE=DEVICE_LYWSD03MMC"
make_bin "BTH" "-DDEVICE_TYPE=DEVICE_MJWSD05MMC"
make_bin "CGDK2" "-DDEVICE_TYPE=DEVICE_CGDK2"
make_bin "CGG1" "-DDEVICE_TYPE=DEVICE_CGG1 -DDEVICE_CGG1_ver=0"
make_bin "CGG1M" "-DDEVICE_TYPE=DEVICE_CGG1 -DDEVICE_CGG1_ver=2022"
make_bin "MHO_C401" "-DDEVICE_TYPE=DEVICE_MHO_C401"
make_bin "MHO_C401N" "-DDEVICE_TYPE=DEVICE_MHO_C401N"
There are many options for building projects. For example https://github.com/features/codespaces But I don't have time to do it. And I'm not a professional programmer, but it's just a hobby. I am a developer of electronic equipment and programming is not the most important thing...
This is sad but still a little strange since temperature and humidity are read correctly when applying the
define BAD_SENSOR 1 patch to firmware 4.3.
I have enabled the branching of the program if there is no Sensor ID response.
This fix has not been tested. The sensor may not enter sleep mode and the total consumption will increase greatly. For a complete analysis of the situation, it is required to measure the consumption current on a Power Profiler or similar. The current consumption between the BLE-advertising transmissions with the display turned off should be less than 2 µA. The option to turn off the display was introduced in new versions, but not finalized everywhere, since the commands of all controllers are unknown. It is advisable to restart the power supply after selecting - pull out and insert the battery for more than 5 minutes (for old CGDK2), because if there is a capacitor in the power supply, then its discharge is very long. The old CGDK2 continues to work without a battery for several minutes and there is no reset of the controller.
Ok, I got hold of some measurement gear here. First measurements were taken today but -> were wrong. Next weekend I will have a look at it again!
And v4.3 with autodetect works like a charm!
After flashing the Custom firmware. Temperature and humidity both show 0. E2 is displayed after restoring the original firmware