-
Notifications
You must be signed in to change notification settings - Fork 15
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.
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
Add support for a transition argument to power{On,Off,Toggle} #5
Comments
Thanks lopter, this will help free me from cloud dependence with my use case! |
You could use |
Hello @chendo, Sorry I never followed-up on that, it's a very good tip and I see it's supported as far back as firmware 1.5 of the Original 1000! Unfortunately, the state of the bulb doesn't get updated with this command (i.e: the brightness isn't updated and power is set to toggled immediately), so I'll still emulate the feature as I described. It's actually cool, it will make me add an internal effects API in lightsd that I'll leverage to implement other features. |
Ah, as you want it to block the method until he transition completes?
|
I'm not sure what you mean by block, I just want the state of the bulb to reflect the transition in real time. |
As in you want the physical state of the bulb or what LightState reports to reflect the transition in real time? |
Yes! |
Yes to which one? |
I mean, yes as in LightState should reflect the transition in real time. |
Power transitions are reflected through the |
Ah I did notice that however I'm clamping the value to 0 or 0xffff (I think I have seen some LIFX code do the same thing) since the documentation explicitly says only those values are supported. How is this value related to the brightness? Is there a (mathematical) formula/function to convert between the two? Thanks for the help! |
Yeah, you can only set 0 for off and non-zero for on for power. I'd have to check the code to be sure but I assume the brightness is multiplied by the percentage of power. If you want to handle transitions nicely, I have logic in the HTTP API that does stuff like set a 0-brightness version of the desired colour before turning the bulb on, then do the transition to the desired colour to fade on properly, so you can do something similar if you want to deal with that nicely. |
Hmm, I think I get it, SetPower is just misnamed, it should be named SetBrightness am I correct? Edit: Hang on, I'm confused. |
Ok, here is how I get it: SetPower is indeed SetPower and works in a boolean way. However StatePower does uses the full 0-65535 range, and its value isn't related to the brightness or the power level, but is instead the transition: if I do SetPower with a 4s transition at t 0s StatePower will be 0 at t 2s StatePower will be 32767 and at t 4s StatePower will be 65535 not matter what the targeted brightness is. So I'll keep doing what I was saying because it will naturally reflect the absolute brightness value as I'm already sampling the bulbs with Get. |
That'll work assuming that the user exclusively only uses lightsd for control. The HTTP API and the app does use SetPower with transitions where applicable as to preserve the brightness level before off. |
No worries, lightsd will implement it in a correct way, you can actually see my work in progress in the lightsd-mq repository. |
Equivalent to:
The LIFX REST API doesn't seem to update the state (color) of the bulb during the transition, but this will.
On top of my head:
The text was updated successfully, but these errors were encountered: