Getting strange output from the sample code

[paulhart]

Describe the bug I just set up my ESP32 with the sample code from the site, and the logged output is... off. I'm quite close to the sensors (within 15 feet) so I hope the issue is not simply distance.

To Reproduce Steps to reproduce the behavior:

1. Step1 Update the BLE IDs for the devices to be measured (redacted in the output below), build and upload the sketch
2. Step2 Watch the output

Expected behavior "Reasonable" numbers for the temperature and humidity (and battery!).

Debug Log A sample output from the serial port is pasted below: 17:12:43.731 -> Sensor 0: a4:c1:38:XX:XX:XX 17:12:43.731 -> -163.84°C 17:12:43.731 -> 212.81% 17:12:43.731 -> 35.595V 17:12:43.731 -> 64% 17:12:43.731 -> -78dBm 17:12:43.731 -> 17:12:43.731 -> 17:12:43.731 -> Sensor 1: a4:c1:38:YY:YY:YY 17:12:43.731 -> -166.40°C 17:12:43.731 -> 243.57% 17:12:43.731 -> 62.219V 17:12:43.731 -> 199% 17:12:43.731 -> -90dBm 17:12:43.731 ->

Embedded Device (please complete the following information):

• Board: "Chip is ESP32-D0WDQ6 (revision 1)" (Some random ESP32-WROOM board)
• Arduino Version: 1.8.19
• Library Version 0.0.2
• Pinning/Wiring

Additional context Add any other context about the problem here.

[matthias-bs]

Hi, Which sensor model are you using? Which HW version?

Did you flash your sensors with the custom firmware from https://github.com/pvvx/ATC_MiThermometer? Which version?

Best Regards Matthias

[paulhart]

Great questions... The sensors are "old", flashed a couple of years ago from the original https://github.com/atc1441/ATC_MiThermometer code. I'll see if I can get specific details for you, but I bought them shortly after the Hackaday article about this firmware came out.

[matthias-bs]

The RSSI values seem to be o.k., so I think it is not a range problem.

I'm fairly sure the encoding of the BLE advertising data does not match the lib's expectations. Some python script I used as a reference had some variants, but in my SW only one of those is implemented.

[matthias-bs]

See https://github.com/JsBergbau/MiTemperature2/blob/master/LYWSD03MMC.py, starting from line 636: "ATC1441 format" vs. "custom format". Looks like I implemented "custom format".

You could either try to modify the decoding or to update your firmware.

[Aughboy]

This was a good coincidence, I am new to ESP32 and Arduino IDE and I ran into the same issue today. Thanks to this post I was able to identify the issue.

I too was using the custom firmware from atc1441/ATC_MiThermometer updating to the custom firmware (v0.39) from pvvx/ATC_MiThermometer fixed the issue but my ESPHome sensors (- platform: atc_mithermometer) wouldn't work, so best option was to modify the way the data was read. These are my modifications (I left in the commented out lines for reference) I expect there is a better way but I haven't codded in C for 20yrs and I was never a good programmer anyways. in ATC_MiThermometer.cpp

                // Temperature
//                int temp_msb = foundDevices.getDevice(i).getServiceData().c_str()[7];
//                int temp_lsb = foundDevices.getDevice(i).getServiceData().c_str()[6];
                int temp_lsb = foundDevices.getDevice(i).getServiceData().c_str()[7];
                int temp_msb = foundDevices.getDevice(i).getServiceData().c_str()[6];
                data[n].temperature = (temp_msb << 8) | temp_lsb;

                // Humidity
//                int hum_msb = foundDevices.getDevice(i).getServiceData().c_str()[9];
                int hum_msb = 0;
                int hum_lsb = foundDevices.getDevice(i).getServiceData().c_str()[8];
                data[n].humidity = (hum_msb << 8) | hum_lsb;

                // Battery voltage
//                int volt_msb = foundDevices.getDevice(i).getServiceData().c_str()[11];
//                int volt_lsb = foundDevices.getDevice(i).getServiceData().c_str()[10];
                int volt_lsb = foundDevices.getDevice(i).getServiceData().c_str()[11];
                int volt_msb = foundDevices.getDevice(i).getServiceData().c_str()[10];
                data[n].batt_voltage = (volt_msb << 8) | volt_lsb;

                // Battery state [%]
//                data[n].batt_level = foundDevices.getDevice(i).getServiceData().c_str()[12];         
                data[n].batt_level = foundDevices.getDevice(i).getServiceData().c_str()[9];         

printing the data in the sample code then changes to

      Serial.printf("%.2f°C\n", miThermometer.data[i].temperature/10.0);
      Serial.printf("%d%%\n", miThermometer.data[i].humidity);
      Serial.printf("%.3fV\n",  miThermometer.data[i].batt_voltage/1000.0);
      Serial.printf("%d%%\n",   miThermometer.data[i].batt_level);

Hope this helps.

[matthias-bs]

Thanks for your feedback and providing the code! The format can be detected automatically as in https://github.com/JsBergbau/MiTemperature2/blob/master/LYWSD03MMC.py, so the lib can be improved to decode both versions:

if len(strippedData_str) == 26: #ATC1441 Format...

[matthias-bs]

Hi,

while looking for a way to integrate the Inkbird IBS-TH2 Bluetooth Thermometer Hygrometer, I found this nice project: https://decoder.theengs.io/ It is also built on NimBLE-Arduino, runs on ESP32, seems to decode both variants of the alternative LYWSD03MMC firmware and many devices more.

Regards Matthias

[matthias-bs]

Hi,

I just added decoding of the ATC1441 format: https://github.com/matthias-bs/ATC_MiThermometer/commit/eac96443d039c7761dc139d45c13f31a655fb939

Please note that the changes are on the matthias-bs-patch-1 branch.

Additionally, I have changed debug output from the DEBUG_PRINT(F) macros to the Arduino logging function - to see some output, you have to set "Core Debug Level: DEBUG" in the Arduino IDE.

After some struggling (you have to flash the original firmware first), I was able to flash the ATC1441 for testing - it worked.

My good deed before Christmas...

Best regards Matthias

[matthias-bs]

Merged into main branch.

[matthias-bs]

Thank you very much @Aughboy for your contribution!

BTW: You can leave the scaling in the sketch as it was. The output from the lib will be the same, regardless of the firmware. The reason for passing integer values from the lib to the sketch is that those are shorter and better to handle for transmitting (e.g. via LoRaWAN).

[matthias-bs]

Hi @paulhart, Did you already find the time to test it? Can this issue be closed? Thanks and regards Matthias

[paulhart]

Hi, I've moved to using the Theengs decoder instead as it already supported the format. I'll close the issue.