Hue Control Pause When Overriden
aeonflux last edited by
Just wanted to first off say to the devs that I love love LOVE f.lux and especially the way Hue integration has improved over the years. Having lights that automatically change color based on sunrise/sunset, with minimal configuration, really feels like the future is here. My little gripes like color temperature offset between lights/screen and configurable brightness of bulbs have all been addressed, slowly but surely.
There is just one suggestion that I can make, and I do not know if it is feasible, but I think it is probably on many peoples' wish lists as well:
The automatic pausing of Hue control when a change has been made externally.
For example, if f.lux is controlling all of my lights, but I go into the Hue app on my phone and set my bedroom specifically to be all seven colors of the rainbow - I don't want that immediately overriden by the 1 POST API call f.lux makes a second. Or, say I have friends over and the living room is too dim - if I use my Hue dimmer switch and brighten things up I don't want f.lux overriding that the next second either.
The way I get around this currently is by setting an automation task via TRIGGERcmd which remotely calls either "taskkill /im flux.exe" or starts f.lux when it's off. But this is quite cumbersome. I propose an alternative approach, which is actually what Kelvin (https://github.com/stefanwichmann/kelvin) does:
A. When a light turns on, immediately start controlling it (I feel that f.lux does this already)
B. However, when the light setting is not the one f.lux last sent (i.e. ANY external switch/app has changed brightnes/color), discontinue f.lux control
C. The way to reset B then is intuitive: turn off that specific light and then turn it back on again....which activates A
Now I do think the default user would want a set-and-forget method where f.lux does its continuous calls. So the above could be made a optional switch in the app.
One issue I foresee is: every now and then a f.lux request to Hue probably fails. So if, say, a light is going 2501K -> 2500K -> 2499K and the middle one gets skipped, naive logic in f.lux may think that the user manually changed it back from 2500 to 2501K. So a potential failsafe is to only terminate f.lux control if a bulb has changed a sufficient amount in brightness and/or color.