wyze-sdk icon indicating copy to clipboard operation
wyze-sdk copied to clipboard

No caching support

Open jslay88 opened this issue 3 years ago • 3 comments

To try and keep on the good side of Wyze, the sdk should implement caching on the api "get" calls (where states are not changing, etc), and add args to methods to override cache (global override for cache time/disabling cache, as well as per method calls). Could even add caching to "set" calls if the args/props (device, color, etc) are the same as well with short expiry. I am having a hard time thinking of a scenario where one would need to send the exact same "set" type request to the same device, within a timespan of say, 1 second. Could even experiment with increasing the defaults overtime as behavior becomes more apparent.

There are several methods for doing this (decorators, inline, etc), as well as existing modules/libraries from pypi that could be used.

Every attempt that can be made to allow the SDK to naturally be kind to the API (even if the SDK is poorly implemented by the end user), should be taken with best efforts. I don't think Wyze is naturally against projects like this, but these kind of implementations can go a long way into garnering "unofficial official" support.

jslay88 avatar May 17 '21 05:05 jslay88

I second this request! I implemented wyze-sdk as an interface in Pytomation. Most of the other Pytomation interfaces work with local hardware, instead of cloud based providers, and perform polling updates once every few seconds.

As such, I was reluctant to code the update methods until I have reasonable throttles in place (i.e. check on a light status more frequently if the code believes there is occupancy in the room the light is in.) Caching within the wyze-sdk would help a lot!

anthonystabile avatar Aug 12 '21 02:08 anthonystabile

Hey @anthonystabile, I'm not sure that this library is the correct place to add caching support. In my opinion, this is "low-level" code to abstract the various API patterns/endpoints that Wyze uses into a common pattern of methods and models. It should be the next level up (the "application" layer) that adds support for caching and other performance-related functionality.

tl;dr; I don't plan on adding caching support, but would be happy to consider a pull request that adds it.

shauntarves avatar Aug 12 '21 13:08 shauntarves

Shaunarves, sort of off point, but I'm playing with your code (great job; thanks!). Does a msg go over-the-wire to the cloud (to mix metaphores) every time I change something (bulb color, brightness) -- or only for the 1st call to instantiate a Client? Also, is the behavior the same as for my phone app?

dhysom avatar Oct 28 '21 18:10 dhysom