8000 Improve bulb API, force turn on for all light changes as offline changes are not supported by rytilahti · Pull Request #76 · python-kasa/python-kasa · GitHub
[go: up one dir, main page]
Skip to content

Improve bulb API, force turn on for all light changes as offline changes are not supported #76

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 2 commits into from
Jul 6, 2020
Merged

Improve bulb API, force turn on for all light changes as offline changes are not supported #76

merged 2 commits into from
Jul 6, 2020

Conversation

rytilahti
Copy link
Member
@rytilahti rytilahti commented Jun 20, 2020 •
edited
Loading
  • Add ignore_default to lights to allow setting directly into a specific light state
  • Force bulb on when changing the settings
    • KL60 does not allow changing the brightness without turning on
  • Allow defining brightness for set_color_temp (to allow changing both brightness and color temp in a single call)
  • Add a couple of new API methods (get_light_details and get_turn_on_behavior)

@rytilahti rytilahti mentioned this pull request Jun 20, 2020
Closed
@kirichkov
Copy link
Contributor

It looks like the pipeline error is not related to the code, but to the CLI not setting brightness.

@rytilahti
Add ignore_default to lights to allow setting to specific light state…
527009e 
…, force bulb on when changing the settings, allow defining brightness for set_color_temp, add a couple of new API methods
@rytilahti rytilahti force-pushed the feature/improve_light_api branch from 722fdb7 to 527009e Compare June 30, 2020 00:36
@rytilahti
Copy link
Member Author

I did rebase this PR on top of the current master, and it's currently failing on missing update()s in the tests. However, this made me to have second thoughts on the stance "all changes require a separate update()", considering that the devices I have (HS110, KL60, KP303) return their state (or a success code) as part of the response.

KL60 (setting brightness to 20):

DEBUG:kasa.protocol:< (169) {'smartlife.iot.smartbulb.lightingservice': {'transition_light_state': {'brightness': 20,
                                                                        'color_temp': 2000,
                                                                        'err_code': 0,
                                                                        'hue': 0,
                                                                        'mode': 'normal',
                                                                        'on_off': 1,
                                                                        'saturation': 0}}}

KP303 (turning a single socket off):

DEBUG:kasa.protocol:> (119) {"context": {"child_ids": ["xxx25B67C3Fxxxxxx"]}, "system": {"set_relay_state": {"state": 0}}}
DEBUG:kasa.protocol:< (45) {'system': {'set_relay_state': {'err_code': 0}}}

HS110 (turning off):

DEBUG:kasa.protocol:> (45) {"system": {"set_relay_state": {"state": 0}}}
DEBUG:kasa.protocol:< (45) {'system': {'set_relay_state': {'err_code': 0}}}

That will be a yet another PR and requires a bit effort which pushes the release back, but I think it still makes sense to do that. Opinions?

@rytilahti
Copy link
Member Author

On the other hand, if there is no exception raised, the user can either parse the response themselves or trust that the given action was done..

@rytilahti rytilahti merged commit 44e2998 into python-kasa:master Jul 6, 2020
@rytilahti rytilahti deleted the feature/improve_light_api branch July 6, 2020 14:09
@rytilahti rytilahti mentioned this pull request Jul 28, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@rytilahti @kirichkov
0