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

Add control_light and color_mode to bulb info

Open JRGould opened this issue 2 years ago • 4 comments

resolves: #41

control_light seems to be vestigial and I couldn't find anywhere that it was being utilized aside from being defined in BulbProps. Additionally, the PropDef seems to have been expecting that the value would boolean (0 or 1 from the api) but on color bulbs (MeshBulbs) it seems that the value will be either 1 indicating that it's in 'color' mode or 2 indicating that it's in temperature mode. This commit adds the control_light property to the info output for all bulbs and further adds a computed color_mode property to mesh bulbs that indicates if the bulb is in color mode or temperature mode.

I have found this useful for caching a bulb's state in a reproducable way in order to do things like run color/brightness change sequences and then return the bulb to the original state - this was not possible without knowing if the bulb was originally utilizing the value from color or the color_temp.

Apologies if my code is not idiomatic, this is my first foray into python, happy to make changes if necessary.

I also have not tested with a non-color bulb but I assume that the value for white bulbs will still fall within the range 0-2.

JRGould avatar Apr 01 '22 16:04 JRGould

@JRGould Thanks for submitting this patch! I don't currently have access to a color bulb. We have 2 options at this point. Either I can have you run a few of the tests I typically check manually when adding new functionality or you can share the bulb with my account (temporarily, of course) so I can mess around with it.

Lmk what you prefer. If you want to go the route of running the tests yourself, please run the following script and paste the results here. Assuming all is well, I'll accept the patch.

You'll notice that some tests are for the WLPA19 and some are for the WLPA19C - if you have both kinds of bulbs, it would be great to make sure you didn't break the non-color bulb as well, otherwise just run the tests you can.

What I will generally do is run the commands 1 at a time and go check BOTH the physical state of the device and/or the reported state in the wyze app (for something like timer or away mode).

Note: Replace XXX with the MAC of your actual device

############################################################
# bulbs
############################################################
# // test listing
# for bulb in client.bulbs.list():
#   print(bulb.to_dict())

# // test getting
# bulb = client.bulbs.info(device_mac='XXX')
# print(bulb.to_dict())
# print(bulb.is_on)
# print(bulb.brightness)
# print(bulb.color_temp)

# client.bulbs.turn_on(device_mac='XXX', device_model='WLPA19')
# client.bulbs.turn_off(device_mac='XXX', device_model='WLPA19')
# client.bulbs.set_brightness(device_mac='XXX', device_model='WLPA19', brightness=23)
# client.bulbs.set_color_temp(device_mac='XXX', device_model='WLPA19', color_temp=2650)

# // color bulbs
# bulb = client.bulbs.info(device_mac='XXX')
# print(f"power: {bulb.is_on}")
# print(f"online: {bulb.is_online}")
# print(f"brightness: {bulb.brightness}")
# print(f"temp: {bulb.color_temp}")
# print(f"color: {bulb.color}")

# // test actions
# client.bulbs.turn_on(device_mac='XXX', device_model='WLPA19C')
# client.bulbs.turn_on(device_mac='XXX', device_model='WLPA19C', after=timedelta(hours=3))
# client.bulbs.set_brightness(device_mac='XXX', device_model='WLPA19C', brightness=100)
# client.bulbs.set_color(device_mac='XXX', device_model='WLPA19C', color='ff00ff')
# client.bulbs.set_color_temp(device_mac='XXX', device_model='WLPA19C', color_temp=3800)
# client.bulbs.set_color(device_mac='XXX', device_model='WLPA19C', color='FDFFFF')
# client.bulbs.set_brightness(device_mac='XXX', device_model='WLPA19C', brightness=29)
# client.bulbs.turn_off(device_mac='XXX', device_model='WLPA19C')
# client.bulbs.set_away_mode(device_mac='XXX', device_model='WLPA19C', away_mode=True)
# client.bulbs.set_away_mode(device_mac='XXX', device_model='WLPA19C', away_mode=False)

shauntarves avatar May 01 '22 15:05 shauntarves

Just getting around to this but it looks like I've got a few issues just trying to list the bulbs - will document here to keep it. easy:

these errors are present on master as of 8e1c5d39c39a32a992d86e28beffa3fdb8d6566f

  • running Bulb.to_dict() on any bulb raises WyzeFeatureNotSupportedError("color")
  • I have a newer "white" badged wyze bulb and its model number is reported as HL_HWB2 so not even getting picked up in client.bulbs
  • color bulbs raise wyze_sdk.errors.WyzeFeatureNotSupportedError: delayed power action is not supported on this device when using after arg (works for new white bulb when I add new model number)
  • color bulbs raise AttributeError: 'function' object has no attribute 'type' referring to api/devices/bulbs.py:BulbsClient::_set_away_mode_disabled ("prop": DeviceProp(definition=prop_def, value=False)
  • white bulbs raise AttributeError: 'function' object has no attribute 'pid' referring to api/devices/bulbs.py:BulbsClient::_set_away_mode_disabled (super()._api_client().set_device_property(mac=device_mac, model=device_model, pid=prop_def.pid, value="0"))

added a couple quick fixes to this branch for the new white bulb model number and the _set_away_mode_disabled issues

Not quite sure how to fix the the to_dict issue but that's probably outside of the scope of this PR. Other than that (which I just added a quick workaround for in order to test) - all of the tests worked as expected. I spaced on actually gathering the output though so lmk if you need proof there.

JRGould avatar May 28 '22 01:05 JRGould

@shauntarves happy to share this white white bulb with you for a while if you'd like to poke at it - my commits on this branch are signed with my email address

JRGould avatar May 28 '22 15:05 JRGould

@JRGould I suspect the problems on master that you reported above have a few root causes:

  • there are now a few different generations of bulbs that ALL use different back-end implementations
  • when you added the new model number, it treated the [new] bulb like the old 2019-era bulb, which is probably why you get all the errors. That older bulb behaves completely differently than the newer bulbs/light strip
  • I briefly looked through the app source code to confirm that the new white bulb is going to require different handling than the existing light functionality. So, while some things worked, I'm not expecting anything to work reliably

I sent you an email about sharing the bulb, so that would be super helpful. If you do that, we can collaborate on coming up with new code!

shauntarves avatar Jun 02 '22 20:06 shauntarves

@JRGould These fixes plus others are captured in https://github.com/shauntarves/wyze-sdk/pull/92

Thank you for your help and support!

shauntarves avatar Oct 04 '22 22:10 shauntarves