Of course, I forgot that light has WiFi for a direct connection.
The log is showing and error EAI_AGAIN which is a DNS error. That means Homey can’t find the API URL address to log in. That is either a network issue or a Homey issue. I used to see these from time to time on my old HP2019 on WiFi, but my HP2023 on Ethernet not so much. Unfortunately, there is nothing I can do about that error as it is at a lower level than the app has control over.
It sounds like you are saying it runs into a temp connection issue so it bails out instead of just trying again. Do I have that right? I’m not noticing any other similar problems. It’s just the Switchbot app that needs to be relogged into a couple times per week.
Not at all, it will keep retrying, but if it keeps getting the same error it won’t be able to connect.
The log you sent is only a few lines long, so I have no idea how long the issue last. Can you keep looking at the log to see if it eventually gets a response?
The observed behavior is they work but often with large delays.
At some point, and I’m not sure if it’s a set multiday interval or random multiday interval, the app disconnects and does not work at all. Invariably, I need to log the app back on before they work again for a number of days before the process repeats. The process has repeated since I bought them about a month ago. I don’t have any other Switchbot devices. Hopefully this is helpful.
As this is an issue I haven’t seen before, all I can suggest is to send a new log just before you log back on so I can see if there are any other errors that lead up to the lost connection.
Hi,
Since version 2.0.87 was installed, the Homey Last Seen value seem to be updated more selldom?
Been using Switchbot app for years and doing scripts checks for Last Seen /30 minutes without any problems. The temp/hum values are very stable/changing slow.
Observed the (brilliant) Statistics Tab table in Sw-bot app together with script capabiliy check and noticed that RSSI value going up/down a few dB in Statistics do not trigger Last Seen. Understand if it is ‘filtered’ not to update evey 30 s. but wonder if the ‘filtering’ was changed i 2.0.87?
Best Regards and Thank You for Your efforts
Jan
The later versions of the app use the new Homey Advertisements feature (when available) and only poll the device if it has not been seen for 120 seconds.
The RSSI doesn’t trigger the last updated information as that is part of the top level package, which is quite reliable. So I only update the last seen when a successful packet that contains all the information is detected.
My apologies, I was wrong in the earlier reply as not all paths would retry on that error. If I had looked at the time stamp more closely before I would have realised the error was not during the login but for a command, so as I was looking in the wrong place I fed back incorrect information.
I have now published a new test version that should treat the transient error as a retry in all call paths, so could you see if that is better now?
Thank you for your answer.
So then I suppose there is no way to decide whether the temp/hum has been stable for 6 hours or the sensor died?
Best Regards
Jan
That is true, but it has always been that way. The new system will still poll the device if it’s not advertised for 2 minutes and Homey has only ever changed the last updated time of a capability if the value actually changes.
How were you detecting the the last seen before?
Been using variants of published Homey scripts based on reading ‘capability.lastUpdated’ and alarming if older than eg. 30 minutes. Worked good on Switchbot even under steady temp/hum. Never investigated why it worked, just glad it did :-). So when it now started alarming I started to wonder why. Discovered the Statistic table and the RSSI varying but was not reflected in lastUpdated.
So my wondering was what was earlier doing the ‘beacon’-like effect.
In the Statistics tab, are you seeing any devices with long last updated times?
No, all device’s ‘Last Seen’ (..ago) column roll from approx 0 secs to 30 in 10 sec step and then restarting at 0.
Ok, so all the devices are updating, so there shouldn’t be any difference than before.
Thanks for investigating anyway.
Best Regards
Jan
SwitchBot Meter BLE sensors stopped updating after v2.0.82
I have several SwitchBot temperature/humidity sensors connected directly via BLE to a Homey Pro (Early 2019).
One SwitchBot sensor had been working reliably with Homey for a long time. Around the beginning of August 2026 it suddenly stopped updating. I noticed that SwitchBot app v2.0.83 was released on August 2, so I suspect the problem may have started with the BLE-related changes introduced in or after v2.0.83.
I have since added additional SwitchBot temperature/humidity sensors, but none of them provide sensor data to Homey.
Current situation and tests performed:
Homey model: Homey Pro (Early 2019)
SwitchBot Homey app tested with v2.0.87 and v2.0.89 TEST
All temperature, humidity, battery and RSSI values remain null in Homey.
The sensors show current temperature and humidity correctly in the official SwitchBot app.
Restarting the SwitchBot Homey app does not solve the problem.
Completely restarting the Homey Pro does not solve the problem.
Homey cannot discover the sensors when trying to add them as new SwitchBot devices.
Bluetooth range does not appear to be the problem. I tested a sensor approximately 10 cm from the Homey Pro, without any change.
However, Homey Developer Tools → BLE does detect the SwitchBot sensor, which suggests that the Homey BLE hardware itself is receiving the advertisement.
For one of the sensors, Homey Developer Tools shows:
RSSI: -67
Advertised Service Data:
[{"uuid":"fd3d","data":"778064"}]
Advertised Manufacturer Data:
6909eb6b05464b28420a028c5c00
So Homey appears to receive the BLE advertisement and service/manufacturer data, but the SwitchBot Homey app does not seem to process this into temperature, humidity, battery or RSSI values.
Because the original sensor worked reliably before the beginning of August, I suspect there may be a BLE advertisement parsing regression introduced in v2.0.83 or after v2.0.82, possibly specifically affecting Homey Pro (Early 2019).
Could you please check whether the BLE changes introduced around v2.0.83 could cause this behaviour?
If useful, I am also willing to temporarily install v2.0.82 to confirm whether the sensors immediately start working again. This could help determine whether the issue is indeed a regression introduced after v2.0.82.
Homey Diagnostics Report ID: 671c76ae-e61a-43f8-b5e7-e04cf335b63b
Thanks!
Can you try the new test version 2.0.90
