I’m adding more stats to the app to diagnose the issues. I have also added a fallback polling call if no valid advertisements arrive for a while.
ATM, it looks like the new advertisements are very often missing the service data. The reason I didn’t notice is I use my ESP32 hubs and they are very reliable, so all my devices update very quickly.
yes with detailed logs, it look like this for me (for one timestamp):
* 2026-08-12T09:56:26.382Z
* [detailed] BLE advertisement payload received for e38f7322c945: {
"_events": "...",
"_eventsCount": "...",
"_maxListeners": "...",
"__peripheral": "...",
"__client": "...",
"__ble": "...",
"uuid": "e38f7322c945",
"address": "E3:8F:73:22:C9:45",
"addressType": "unknown",
"connectable": true,
"manufacturerData": {
"type": "Buffer",
"data": [
105,
9,
227,
143,
115,
34,
201,
69,
143,
2,
1,
152,
57,
0
]
},
"serviceUuids": [],
"rssi": -70,
"timestamp": 1786528586381
}
* 2026-08-12T09:56:26.385Z
* [detailed] Unparsed BLE advertisement for e38f7322c945 (no-service-data)
* 2026-08-12T09:56:26.387Z
* [detailed] Unparsed BLE advertisement for e38f7322c945 (no-service-data)
* 2026-08-12T09:56:26.389Z
* [detailed] Unparsed BLE advertisement for e38f7322c945 (no-service-data)
* 2026-08-12T09:56:26.391Z
* [detailed] Unparsed BLE advertisement for e38f7322c945 (no-service-data)
* 2026-08-12T09:56:26.393Z
* [detailed] Unparsed BLE advertisement for e38f7322c945 (no-service-data)
* 2026-08-12T09:56:26.395Z
* [detailed] Unparsed BLE advertisement for e38f7322c945 (no-service-data)
* 2026-08-12T09:56:26.396Z
* [detailed] Unparsed BLE advertisement for e38f7322c945 (no-service-data)
* 2026-08-12T09:56:26.399Z
* [detailed] Unparsed BLE advertisement for e38f7322c945 (no-service-data)
* 2026-08-12T09:56:26.401Z
* [detailed] Unparsed BLE advertisement for e38f7322c945 (no-service-data)
* 2026-08-12T09:56:26.403Z
* [detailed] Unparsed BLE advertisement for e38f7322c945 (no-service-data)
* 2026-08-12T09:56:26.404Z
* [detailed] Unparsed BLE advertisement for e38f7322c945 (no-service-data)
by the way: is it correct that for all devices it says “for e38f7322c945” ? shouldn’t there be different values?
Hello, I have same issue here with all my T&H sensors : temp and humidity updates are sticked to a value during indefinite duration.
I tried to uninstall and reinstall the sensors, but problem is still here.
Do you have any recommendation ? Or is it possible to go back to previous software version ?
Hi Adrian,
I’m having an issue with my SwitchBot Outdoor Meter via BLE in Homey.
It worked correctly for about three months, but recently Homey stopped showing temperature and humidity values.
The Outdoor Meter itself is working correctly. In the official SwitchBot app I can currently read 27.0°C and 41% humidity without any problem.
I removed and re-added the device in Homey as Temperature & Humidity (BLE). Homey detects the device with MAC address:
E8:76:C4:46:27:5E
However, temperature, humidity, battery and RSSI remain empty (-).
I enabled Full Information logging in the SwitchBot Homey app. Homey is clearly receiving BLE advertisements from the sensor every few seconds, with a very strong signal of approximately -32 to -39 dBm.
Example from the log:
BLE advertisement received for e8:76:c4:46:27:5e (e876c446275e)
manufacturerData: [105, 9, 232, 118, 196, 70, 39, 94, 106, 14, 6, 154, 41, 0]
serviceData: []
So the BLE connection itself appears to be working correctly and Homey is receiving the advertisements, but the SwitchBot Homey app does not seem to decode the temperature and humidity values anymore.
As mentioned, this same Outdoor Meter worked correctly in Homey via BLE for approximately three months before this problem started.
Could this be related to a change in the BLE advertisement format or the Outdoor Meter BLE driver?
I can send the full diagnostic log if that would help.
Thanks!
Can you try the new test version.
I have added a fallback polling if not valid advertainments are received.
2.0.85 Test installed and working again. Thanks for the fast fix !!!
I just noticed my 4 temp sensors (over BLE) hadn’t updated for 2-3 days, and the test version solved it. Thanks!
This test version solved it for me. Thx!
Hello Adrian, a question on the reported RSSI value of my Curtain 3 drivers. I control them via your ESP32 BLE Hub.
In the hub’s Registered Devices page I see different (lower/better) RSSI values than the new Statistics tab in the SwitchBot app shows. The latter are also shown on the sensors tab in the device tile.
Could it be that the SwitchBot app reports the RSSI info based on Homey’s internal BLE antenna instead of the actual RSSI based on the ESP32 hub? Shouldn’t the ESP32 values be reported instead?
The ESP32 hub also communicates those lower RSSI values back to Homey/the SwitchBot app as part of the message’s payload.
The new stats page in the app is all from Homey. I added it to see if the missing service data was related to the signal strength. Also it gave me some information to pass on to Athom.
I have also added a similar stats table to the ESP32 code for comparison, but I haven’t published that yet.
Basically it shows that the ESP32 doesn’t miss any service data and processes about 5 times as many advertisements.
Hello again!
I received and setup the SwitchBot Presence Sensor today, which is rapid in detecting occupancy and no occupancy in the SwitchBot app. I have added it to Homey (via HUB) and it seems to be very slow to update occupancy/no occupancy. Is this because it is taking 10-20 seconds to send the information to Homey or should it be quicker?
It should get notifications via a webhook. Mine used to update in a couple of seconds, but I tend to use the BLE driver now with my ESP hub as that is much quicker.
If you have a Homey Pro, open the app settings, select the Log tab and set the Log level to Webhook Information and Log Source to Hub Only. Then watch for message as you trigger the sensor and see how long it takes in there.
Thanks for your swift reply.
I did what you said and the notifications are as speedy as in the SwitchBot app. The issue is that the Presence Alarm takes 20-30 seconds (I decided to actually time it) to update after that notification.
What version of the app are you using?
I’m using the experimental one, version: v2.0.85.
Can you try the new test version. It’s possible the webhook lookup was not correctly matching the driver and therefore falling back on the polling.
I’ve been wondering for the last few days why the motion detector didn’t react so quickly when the light was switched on. Thanks for fixing. It’s super fast for me again.
