Modification of polling interval & some questions

[ajamess]

Hey there!

This is an awesome project. Thank you for putting it together! The fact that you created a docker container allows me to migrate off of f.lux (and running a windows PC) to a synology NAS-based solution (which I am cool with running 24/7).

I haven't dug into the code yet, but was hoping to understand a bit more on a few things, with one request.

I noticed that when I enable Kelvin and turn a light on/off again that it mostly updates the light state as I expect. However, it's a little unclear to me how you implemented state detection in terms of how you choose to check if a light state should be "overridden" by Kelvin. For example, here are some of the observations I've made:

• Enable Kelvin -> Turn on a light that was off before Kelvin was enabled -> State changes as expected.

• Enable Kelvin -> Turn off a light that was on before Kelvin was enabled -> Turn it back on again -> Expectation is that Kelvin would "take over" and update all the new lights with the expected "correct" state. Is this the correct expectation to have? Sometimes this doesn't seem to happen.

• Enable Kelvin -> Assume lights reach "correct" state per Kelvin -> Use another app (or a switch) to set a different scene -> Scene runs as expected -> Turn off all lights -> Turn back on again -> Expectation is that Kelvin would "take over" and update all the new lights with the expected "correct" state. Is this the correct expectation to have? Sometimes this doesn't seem to happen. Also, is there a way to quickly get back to "Kelvin" state without turning the lights off and on again (e.g. having a Kelvin Scene) as was suggested in another issue?

• Enable Kelvin -> Turn off lights using dimmer switch -> Turn on lights to "previous state" using dimmer switch -> Expectation is that Kelvin would "take over" and update all the new lights with the expected "correct" state. Is this the correct expectation to have? Sometimes this doesn't seem to happen.

• Enable Kelvin -> Dim lights using dimmer switch -> Expectation is that Kelvin won't take over again until the lights are turned off and on again. Is this the correct expectation to have?

I was thinking that perhaps, with the modification of the polling logic / interval, some of these issues may be able to be solved (or it could just be general Hue Flakiness that is impossible to work around perfectly, I'm not sure). FWIW, I have 40 bulbs connected to a single bridge, so this is a semi-large use-case :). What is the current polling logic / interval today? That might help me to understand, too.

Thanks again for all your hard work here!

[stefanwichmann]

Hi Adam,

thanks for using Kelvin and for your kind words! Glad you like it!

All of your five assumptions above are correct! BUT, as you already suspected, the design and implementation of the Hue API is actually not very stable. Here are a few things I noticed while I worked on Kelvin:

• There is a noticeable lag between the light bulbs and the bridge on the zigbee layer. (Especially if lights appear or disappear)
• If you set a precise state via the API the resulting state of the bulbs can differ significantly
• The precision of the bulb state differs from model to model and feature to feature (for example XY-colors seem to be more precise than color temperature)

Kelvin tries to work around these quirks by doing a fuzzy comparison of all values that get set or read (for the curious have a look at the equals method in lightstate.go). The downside of this fuzzy state handling are the is unexpected behaviour you observed... :-(

Now to your questions:

• The current polling interval is one second
• The current transition time for new states is also one second (both defined in light.go lines 59 and 60)
• You can quickly reactive Kelvin for any light via the webinterface or it's API (PUT http://{IP}:8080/lights/{lightID}/activate). (NOTE: The webinterface is currently considered beta and has to be enabled in the configuration file, see README)
• Another way to quickly enable Kelvin would be via scenes once this has been implemented (see Add the ability to activate Kelvin through a Hue scene #9)

To conclude here are a few tips to get Kelvin working as expected:

• Always update to the latest firmware of the bridge and the lights (Especially the lights were updated three weeks ago for the first time in years! I really hope this fixes some of the observed issues... Haven't done much testing yet)
• Don't change your light state to rapidly. As mentioned I poll every second and there is a delay between the bridge and the lights... In my experience you should wait 3-5 seconds after every action (for example: Turn light off, wait 5 seconds, turn light on -> Kelvin should take over)

Hope this helps. If not, feel free to ask! If you like dig into the code! PRs are always welcome! ;-)