Skip to content

priority/configurable repetitions #1

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ettisan
Copy link

@ettisan ettisan commented Dec 1, 2015

Hey,

I've partly implemented a way to a) configure the command repetitions and b) prioritize commands.

The idea behind this is to allow for faster switching times (especially when switching multiple bulbs at once): You could then set "reps" to 1 and add every command to be issued three times (with different priorities). This way the module tries to first switch all the bulbs correctly and then repeats all the commands in case a bulb didn't respond.

I am not yet completely sure if this does interfere with the "synchronization"? I haven't really implemented it completely - so please take it as a suggestions - how would you implement this features?

* make command-repetitions configurable
@happyleavesaoc
Copy link
Owner

Hm, I like where this idea is going. I need to look closer at the commit, but consider these repetition possibilities:

  • Some commands must not repeat (white bulb temp/brightness)
  • Some commands must always repeat (on/off)
  • Some commands change repetitions based on context (see rate decorator): For example, transition brightness reps is 1 while regular brightness is 3. This is because a transition can afford to skip one step in order to go faster (that is, fit more commands into the allotted time for a smoother transition). This is why groups look at their own reps member instead of the bridge's reps.
  • Some commands actually require two (anything with select=true): when no group is specified in the requested command (example: color) and the previous group was different.

@ettisan
Copy link
Author

ettisan commented Dec 3, 2015

Ah, i see. I think i haven't really thought this through completely. I'll try to have a more detailed look at some time

happyleavesaoc pushed a commit that referenced this pull request Feb 12, 2017
Support for RGBWW saturation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants