-
Notifications
You must be signed in to change notification settings - Fork 6
Hub sensor regularly doesn't update #127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Another thing I noticed was the log after restarting yesterday:
It says '21 API calls today' (yesterday whole day). Seems pretty low, but I don't know what is counted. 21 seems to be the number of requests sent from my own flows to control the IR-devices. |
Most updates come via a webhook, so the app only polls devices that don't use them or have some capabilities that are not updated via a webhook. Occasionally, the webhook system does run slowly, but I'm not sure if it's Athom or SwitchBot. My bet is SwitchBot. |
Thx for the reply. I didn't know webhook enabled devices were only updated through webhooks, I thought is was a combination (regular update via API, larger changes via webhooks). Is there no way to also update via the API? I know the calls are limited, but in this case there are a ton of calls left. You can think of something like an API update when there has been no webhook update for some time, like 15 minutes. Even half an hour will be a big improvement in case the webhooks fail. Or let the user decide to enable API update calls for certain (or all) devices (for example default off, the accommodate users with many non-webhook devices) By the way, during those 4 hours without webhook updates for Hub 2, other devices were still updated very regularly. This error situation occurs almost every day. Even when its Switchbots fault, I highly doubt they see it as an issue, because the API still works in this case. Is there anything I can do in my situation? A workaround or something? |
The webhooks should (and normally do) publish updates as soon as the change happens, but the key is only when a change occurs. It's possible the event only occurs if the temperature changes by 1 degree or humidity changes by 1%. That reduces the load on both Homey and the servers. |
I have exactly the same problem with My Hub 2!! I propose to have a 'then-card' that allows updating the status manually in a flow: #134 |
There is a limit on the number of API calls and polling can easily cause your account to be locked. |
And what alternative do you offer? Because our Hub2 are not updating at the moment... I don't see much of a problem with allowing users to manage it manually if they want, in the end those who have it working won't use it, and with a name like "not recommended", "for developers only", "might block your account"... you scare away the basic users. Only those who already have problems will use it, like us I have tried to program a solution with HomeyScript but there is no way because it does not have the crypto js library for request auth header 😞 PD: What do you think @rudolfterp ? |
I agree that something could be done at the Homey side, but I also understand that Adrian can't simply implement a feature that has a chance of making it worse. But maybe we can think of something. But I also filed this issue with switchbot, and this was their response:
Even though it looks like they have a solution here (at the end of September?), I'm not completely confident that this will completely fix the problem, or that the problem won't come back in the future. So i am still looking for a reliable way to fix this problem. In the meantime I made an automated flow to check if the updates differs from the API:
I have 3 sensors:
Result: So not only Hub 2 is affected, but the (older) indoor sensor doesn't seem to be affected at all. If it is only a performance problem, I would think all devices are affected. But it could also be the result of some (attempt of) load-balancing or a certain fixed order in which webhook-messages are created for different devices. One side note: I use the outdoor sensor in the bath-room to control a fan when someone is taking a shower, and it never fails to switch on the fan within a minute. Within this minute there are multiple updates in de Switch-bot app (up to 10), because of the rapid change in humidity and temp. So in practice there is always at least 1 webhook message coming through. The core of the problem is probably that a certain percentage of webhook updates are not coming through. Edit: I'm sure there are better flow-desings to think of, but this one is relatively simple and sufficient. My goal is not to detect all errors, but to follow whether the errors are increasing or decreasing. |
Abe from Athom has just put me in contact with the Director of Products at SwitchBot as my previous contact has left. Hopefully this will result in a better integration and more support. |
My Hub 2 sensor (temp, humidity, light) regularly has old values in Homey compared to Switchbot own app.
This was yesterday evening:
Homey:

Switchbot:

As you can see, there were several changes in temp and humidity in the last 4 hours (after the vertical line), but these values weren't send to Homey.
The last update (4 hours ago) was via webhook:
(My timezone is UTC+2)
Seems to me there were no updates via the regular API-way?
When I use 'Get status' I get the correct values (different from the ones shown on the Homey device):

Only after I restarted the Switchbot Homey app, the correct values were finally updated to the Hub 2 Homey device.
I have 4 Switchbot devices:
Apart from the updating problem, everything works fine. I use the hubs to control two IR-devices, via homey flows. This works perfectly.
The update problem seems to be limited to Hub 2, but i'm not entirely sure: the other sensors are in places where temp and/or humidity change a lot more. These devices get a lot of webhook-updates, like several per hour.
It seems that webhook updates are only sent for medium and large changes, and the Hub 2 sensor is in a very temp/humidity stable area. But these small changes over time (hours) is exactly what's important. I have some flows that notify me when certain threshold values are reached. But these are not working properly now.
The text was updated successfully, but these errors were encountered: