jasonacox
Rewrite BulbDevice and rework set_multiple_values()
This is a pretty big rewrite to BulbDevice. The fact that it connects to the bulb and calls status() as soon as the version is set has always bugged me, so now it delays that until a command is sent. If a user calls status() themselves before they send a command then it uses the result from that status call instead of calling it again.
Also included are modifications to core: a caching mechanism has been added so devices can try to use cached DP values instead of making calls to the device, and set_multiple_values() has been modified to try and detect devices which fall over if they get sent multiple DPs in a single request. The caching only works when an active persistent connection is open; closing the connection clears the cache since we won't get notified when DPs change.
To access the cache, call d.cached_status(nowait). When nowait=True then the cached value is returned if it is available or None if it is not. When nowait=False then the cached value is returned if it is available or a call to d.status() is made if it is not.
BulbDevice now leans on the cache to try and minimize the number of DPs set in set_white() and set_colour(). This combined with the set_multiple_values() change is to help with bulbs that only accept 1 DP at a time, such as @Anonymouse83's in #504.
Todo: update documentation.
@jasonacox Do you happen to have an example status() response for a Type C bulb? I want to check some of my logic for that bulb type before committing this.
Hi @uzlonewolf , makes sense. However, I don't seem to have one. The Type C Bulb addition came from https://github.com/jasonacox/tinytuya/pull/54 by @davidlie (who may be able to test for us?) and I recall it was for the Feit Electric Smart Light Bulb. I see some on Amazon but not sure if that would be the C type. I thought I picked one up but scanned my devices and no Type C's. 😞
Looking at that PR it looks to be a dimmer switch and not a bulb at all. Using the Internet Archive I found some that look like they're probably it and ordered a couple new-old-stock off ebay. We'll see in a few days.
Yes, I can't recall why it said dimmer switch but PR was for a smart bulb. It wasn't that many years ago, but long enough fo rme to completely forget. 🤷 Thanks for doing the research. 🙏
My dimmer switch came in Saturday and it does identify as a Type C bulb. When it comes down to it, is there really a difference between a dimmer and a single-color (non-CCT) bulb? Anyway, I also have some single-color as well as CCT bulbs arriving today.
The more I think about it the less happy I am with the entire "Type X" thing and am probably going to rewrite it to just use "has feature" (mode, brightness, colortemp, etc). I may or may not try and use the DPS mapping (if it's available) instead of blindly guessing based off DP ID.
Yes, I haven't been fond of the Type X thing either, but I don't know of a better way to represent both the DPS mapping as well as the range differences.
https://github.com/jasonacox/tinytuya/blob/7d8922ee096b5519018fa068ffb698ef43a213cc/tinytuya/BulbDevice.py#L117-L127
Last week I ended up rewriting BulbDevice and almost completely eliminated the Type X thing. I left it in a few places for backwards compatibility and as a quick way to manually set the DP range, but it's otherwise gone. The RGB/HSV range is now selected by a boolean, and the "has X capability" is set by whether a DP is defined or not. I'll push an update once I have the DP detection finished.
I picked up an assortment of bulbs to test with. The new Feit single-color white bulbs are v3.5 and act like what was formerly known as Type B but with a few DPs missing. The older Feit dimmer uses DPs 1-3 with 3 being the "minimum dim" setting, while Geeni bi-color/CCT white only bulbs use DPs 1-3 with 3 being CCT.
Do your latest rewrite efforts (mentioned in the comment above) exist on github? I'd be interested in trying this out! Thanks so much to both of you for all of your work, it's both impressive and incredibly useful.
