Closed stjohnjohnson closed 6 years ago
Eh, this actually isn't a good plan of attack. I'm getting rate limited at the device handler level. :(
Maybe less frequently but also on demand?
It's not about frequency, is about the number of commands I send to the bridge in a short time. It limited me to something like 15 calls in a second before cutting me off. I have about 30 devices with 2-3 properties each. That's 60-90 calls normally.
I might have to make a batch API. On Thu, Feb 2, 2017 at 06:09 kylerw notifications@github.com wrote:
Maybe less frequently but also on demand?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/stjohnjohnson/smartthings-mqtt-bridge/pull/71#issuecomment-276966859, or mute the thread https://github.com/notifications/unsubscribe-auth/AAl98aRehHU3Ja5aiTFpwec_dgXIDcaHks5rYeOHgaJpZM4L0z8n .
-- -St. John
Any progress with the rate limits? Is it possible to use something like runin() to go through every device in smaller groups over time, then wait until it's been X minutes since the first device in the list was updated and repeat?
Any updates on this? I'd really like my battery information to be sent over and this PR should fix it.
I've almost moved completely off SmartThings (API was too limiting and it's entirely cloud based still). So I'm not really working on this right now. You're welcome to take the code I've put here and fiddle with it yourself. Honestly, the best route is to have some sort of bulk API to receive an array of events.
Closing as there isn't really a clear plan forward. I'll leave the branch around but SmartThings has some hard limits.
This will push the current state of all attributes every 30 minutes, so if the bridge was down, it will eventually recover to current state.
Should replace #67 and resolve #61, #51, and #66.