Fix for badly behaving RGB smart lights with HomeKit color picker #17
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I added 3 optional settings to the config that help tremendously with my inovelli smartlights to stop sending multiple commands to set the color or level. By default when either the level or color is changed, homekit will send an on and setLevel command or a setHue and setSaturation command. This can cause the light to flicker as it cycles between both settings. In the worse case scenario, it appears that homekit will get confused and switch the hue and saturation back and forth and not set the combined command values when sending both as individual commands. This changes the plugin to look to see if two compatible commands are sent in very close proximity of each other. It delays sending the first one until the second is received, then sends a setColor command, if a second command isn't received within 50ms (configurable) or so, it sends just the first command by itself. If none of the config values are specified, the default behavior isn't changed.
New config values are below:
"use_set_color": true, // This turns on setColor processing and will combine setHue and setSaturation commands that are received within dedupe_command_delay_ms of each other
"dedupe_command_delay_ms": 10, // The amount of time to wait for a second command
"squash_on_commands": ["setLevel"] // This is a list of commands that receive an 'on' command before a setLevel, this will squash the on command and just send a setLevel command