Esp32dev-ble and ThermoPro TP357 sensor : no packet with temperature

Mific · October 15, 2023, 2:59pm

I have a ESP32-WROOM board using the 1.6.0 version of OMG (binary : “esp32dev-ble”).

I have just received a ThermoPro TP357 sensor bought on Amazon (this device is supported according to Devices | OpenMQTTGateway v1.6.0).

My issue is that the temperature / humidity is not seen by OMG. I can only see an rssi info packet, as shown below:
{“id”:“FF:66:75:66:4A:D5”,“name”:“TP357S (4AD5)”,“rssi”:-45}

It should be noted that the device is working with the mobile application.

Thanks in advance for your help !

DigiH · October 15, 2023, 3:33pm

Hi @Mific,

There has just been the same issue as you are experiencing right now for another user, with the new hardware revision models of the ThermoPro TP357 (now with an extra S at the end of its name and longer advertising data)

github.com/theengs/decoder

Support request for ThermoPro TP357S

opened 08:10PM - 13 Oct 23 UTC

closed 10:45AM - 14 Oct 23 UTC

ewaldc

**Is your feature request related to a problem? Please describe.** ThermoPro ha…s replaced the TP357 by the TP357S, which is recognized only as a generic device and as such no temperature/humidity is being reported. I forked the repo and made the necessary changes to TPTH_json.h (basically just adding the TP357S in the logical OR condition) and was able to recompile the decoder library, but not to regenerate the python package (there is not much info on how to do that). I managed to create a new EGG file once, but subsequent builds failed (MSVC compiler complains about missing stddef.h or some scikit-build integration issue) Manufacturing data produced by the TP357S: ``` {"manufacturerdata": "c2d60043220b01", "name": "TP357S (AEF2)", "id": "FF:AC:31:C7:AE:F2", "rssi": 0} ``` Other than this the gateway solution is working **flawlessly** (created a Systemd service on RPI4 in combination with OpenHab) - congratulation on this great project ! **Describe the solution you'd like** I am happy to contribute with a pull request, but I would need to be able to build and test the python package first. Any hints appreciated. Alternatively, if the development team is willing to add TP357S support directly, this is even a better solution :-). **Describe alternatives you've considered** 1. Contribute the change myself (code change succeeded but rebuild failed). 2. Given a new (test) version, I would be happy to validate and report back. Thanks in advance, Ewald

and as you can read this has been fixed in the latest development branch of Theengs Decoder.

This means it is also be available in the development branch of OpenMQTTGateway at

with the current SHA:cbec42 test build and future test builds at that location.

It will also be included in the next official releases.

Mific · October 16, 2023, 6:17am

Hello @DigiH,

Thanks a lot for your quick response ! I have just tried the SHA:cbec42 test build and it works

The packet is now the following :
{“id”:“FF:66:75:66:4A:D5”,“name”:“TP357S (4AD5)”,“rssi”:-28,“brand”:“ThermoPro”,“model”:“TH Sensor”,“model_id”:“TP35X/393”,“type”:“THB”,“tempc”:22.8,“tempf”:73.04,“hum”:37}

Please find below some pictures of my device : only TP357 is mentioned (and not TP357S) …

DigiH · October 16, 2023, 9:29am

Good to hear it is working fine for you with the latest dev build

Please find below some pictures of my device : only TP357 is mentioned (and not TP357S) …

Thanks for the pictures! The different TP357S name only seems to be in the braodcast advertising data, as also seen in your original undecoded post, and it also marks the longer advertising data, which was the issue with not being decoded before.

Would you grant us the permission to use your front TP357 image in the compatible device listing?

Mific · October 16, 2023, 9:41am

No problem, you can use my front TP357 image.