ThermoPro TP25 and Switchbot Meter

Hi all,
I recently found out about this project, and it looks like a great solution for integrating several devices into my smart home ecosystem.

I have 2 devices that i would be interested in knowing if they can be supported. One is a 4 channel Thermometer (ThermoPro TP25), and the other one is the SwitchBot meter standard.
Both devices are ble, however, they require a connection. I read in the code docs that OpenMQTTGateway does not support devices that require a connection, however, i also have read in this forum of instances where these kind of devices are added.

Could these devices be integrated into OpenMQTTGateway? i was able to establish a connection to the meat thermometer with nrfConnect, after sniffing the connection from the original app.

Thank you very much for your response!

Hi @ricardol ,

Your SwitchBot Meter (Standard) should already be supported since OpenMQTTGateway v0.9.13 as it freely transmits its status via BLE braodcasts - that is, if no encryption has been enabled for it through the SwitchBot app. No connection should be required for this device. Possibly some hardware revision changes might also affect the data structure.

If you are not seeing any decoded messages for your SwitchBot Meter, could you show us the messages with the raw servicedata and service uuid etc. showing up in your MQTT broker, best viewed with an app like MQTT-Explorer

Similarly for your ThermoPro TP25 I would assume that it freely transmits its status messages through BLE as well, without necessarily requiring a connection, similar to the ThermoPro TP357 & TP358 thermometers we included in Theengs Decoder (the BLE decoding library OMG uses) just a few days ago. But again, a verification and examination of the undecoded manufacturerdata would be required to confirm this.

So with your help in supplying some of the currently undecoded raw data for the two devices, best along with the corresponding temperatures at the time, I’m pretty confident that we can get them corrected/integrated.

Hey @DigiH,

I haven’t snooped the Switchbot Meter connection yet, but The Thermopro TP25 appears to require a connection (the app requires you to pair the device). I have a PCAP file with the communication between the Thermopro on the app if that helps. I am happy to share the PCAP file, and to create one when i can get the SwitchBot meter available. Would that be enough?


Hi @ricardol,

The snooping and any PCAP would be more than is actually required and not very helpful here, as Theengs Decoder, being the BLE decoding library for OpenMQTTGateway, really only supports decoding of freely broadcast messages and not directly connecting to devices.

The best way forward is monitoring your MQTT broker for any undecoded messages these devices send out.

Which MQTT broker are you using - possibly Mosquitto?

If you haven’t got an MQTT broker yet, you will need one to incorporate OpenMQTTGateway, or any other MQTT publishing gateways, into your smart home ecosystem. More information can be found at

Using an app like the above mentioned MQTT-Explorer you can connect to your MQTT broker and easily monitor all the messages OMG picks up from your devices, decoded and undecoded. The app also allows you to copy any undecoded messages for pasting here for further investigation.

Alternatively, since you have already been using nRFConnect, you can also post a screenshot of the devices’ main page, which includes the Advertised Services

Hello DigiH,
I use mosquitto, and have mqtt-explorer. Sounds like i would have to install OpenMqttGateway for this? would the Theengs Android app work too?


It would be best to install OpenMQTTGateway on an ESP32 for the reception and decoding of your devices, especially if you want constant monitoring.

Or alternatively Theengs Gateway

Or for a quick check, with its MQTT broker functionality activated, the Theengs App as well, although I’m not sure if it already has the SwitchBot Monitor decoding included.

May I ask which smart home ecosystem you are using? For Home Assistant there is a quick and easy Theengs Gateway HA-addon if applicable.

Hope this helps.

I am using openhab. I have an esp32 device laying around, but since i use a bunch of tablets for remote control, i thought it would be great to double their functionality installing the theengs app on them.

I just double checked, the current release of Theengs App does not have the SwitchBot Meter decoder included yet, as can be seen at

The other issue with using Theengs App as the main and only BLE gateway is that whenever the tablet goes to sleep or when the app is in the background the monitoring gets interrupted/stopped - due to Android OS limitations and restrictions.

For any constant BLE device monitoring, which you would probably want at least for the SwitchBot Meter, OpenMQTTGateway on an ESP32 or Theengs Gateway on a Raspberry Pi or similar device on which you are possibly already running OpenHAB, is the preferred solution.

If you install OpenMQTTGateway on your ESP32 - the default esp32dev-ble binary/environment will be suitable for your devices - you will probably see that your SwitchBot Meter is already being decoded :slight_smile:

Got it, thanks for the explanation. I will probably go with the esp32 then…will post back with any information as it becomes available.

Hi again,

I got around to flash one of my esp32 devices with openmqttgateway, and i can confirm that switchbot meter works , showing the temperature and humidity properly.

For the thermopro device though, i sadly can only see an rssi info packet, as shown below:


Anything that can be done with the ThermoPro device? As i mentioned before, so far, the only way I have been able to get updates on the temperatures is by establishing a connection with nrfconnect.

One more question. I installed the esp32-ble-dev version from the web. Once i configure my wifi and mqtt server, and the esp32 reboots, the web server is not accessible anymore. I get an “ERR_CONNECTION_REFUSED” error, (tried on different devices). Is this normal?

Hi again,

good to hear your SwitchBot Meter is reporting nicely.

Shame about the ThermoPro TP25 only broadcasting its name, even without the model. Unfortunately this means that OMG along with Decoder will not be able to decode any useful information from it.

Did you have to subscribe to a NOTIFY to get the temperature updates, or are they also available through READing a characteristic?

If the latter you could try reading that service/characteristic through the OMG READ command regularly.

Alternatively could there still be a way to get the TP25 to broadcast it’s temperatures. I know with my Qingping Air Monitor Lite it only starts broadcasting BLE messages after it has been paired and set up in the Qingping app. Could this be a similar case with the TP25. Possibly not, but worth a shot trying it out with different pairing/unpairing on the phone and setting it up/deleting it in the ThermoPro app, all while monitoring for differences in the BLE broadcast.

Yes, that is the normal case, AFAIK, as the the WiFi and MQTT broker setup has been done.

But through MQTT system commands you can change the various settings, and ERASE should bring you back to the WiFi Manager - I assume :wink:

Hope this helps

Hi again @DigiH , thanks for your comments.

What i have been able to reproduce is to get the thermopro to be connected and send updates by sending the following packet through nrfconnect:


that equates to writing athe hex string shown in “Value” to the service shown in the packet.

Would i be able to reproduce sending that packet from openmqttgateway by writing the following:


To my config topic, home/OpenMQTTGateway_ESP32_BLE_OH/commands/MQTTtoBT/config ?

I have tried, but i get a success: false response.


I doubt it, as this very likely is the write command to subscribe to NOTIFY which then receives notifications of updated temperatures.

Could you post nRFConnect screenshots of the relevant characteristics listing, which should indicate if its READ/WRITE and/or NOTIFY?

That is a read/write characteristic.

1086fff0334348178bb2b32206336ce8 is the service
1086fff1334348178bb2b32206336ce8 is the characteristic i am writing to in that packet (read/write)
1086fff2334348178bb2b32206336ce8 is the characteristic you write to if you want to enable notify.

Sorry i did not send pics, this was faster.


Yes, the NOTIFY is the problem here, not applicable to OMG.

So unfortunately you won’t be able to currently get its temperatures with OMG.

It is a real shame that the TP25 doesn’t seem to freely broadcast its temperatures in manufcaturerdata, like a lot of other brand BBQ thermometers do, and also as the ThermoPro Bluetooth Hygrometers Thermometers do :frowning:

Hey again @DigiH,

I understand that the notify might be the problem here, but i am a step before that.

When i write the packet i mentioned before, the Thermopro does 2 things:

-It acknowledges the value has been written
-It immediately sends an update with temperature values.

After that, if i want to enable notify, i can. But it does not look like it is required.

Right now am not at the point where i care about enabling notify. I just want to be able to writ the previous packet successfully. Maybe after that, i can just read values periodically, makes sense?


Where and how does it send this update with the temperature values? As a response, like the confirmation of the WRITE success? Or as a broadcast?

Sorry, i realized i made a mistake here.

What actually happens is that, after sending that command, i receive an acknowledgement for the written command.

AFTER that, i can either enable notify on 1086fff2334348178bb2b32206336ce8 , or read the values from that characteristic too. No automatic update with temperature values

1 Like

So periodically programmatically sending that command, waiting for the acknowledgement to be received and then reading the values is a possibility (while an awkward one) to get the temperatures from your TP25 though OMG and your controller.

If I understood everything correctly.

That almost completely correct.

i would only have to send that command once. After that, the TP25 remains connected.
I will have to read the characteristic periodically, however, that in my environment is not as awkward as you would think. The periodic reading can come from my automation software (Openhab)

For this to work though, i need that first command to succeed, and now it is failing. Is there a reason i would not be able to reproduce writing a value to a characteristic (Not a notify characteristic)

On a separate note, and just out of curiosity, is there a possibility openmqttgateway will every support notify scenarios? What is the technical obstacle behind it?