Hey FastLED community!
I seem to be having trouble with my first project. Everything runs great except the rotary encoder. It is all over the place and nothing I try seems to fix it. Any suggestions from the community? Thanks!
Encoder: https://www.adafruit.com/products/377
Code: http://pastebin.com/Ty8QK07m
Hi, here’s a link…
that someone posted a while back.
I hope this helps as I have not personally tried this.
@JP_Roy Thank you for the link. In fact, I used some of that code in my project. No matter what I do, however, the mode selection is out of control and way too sensitive. 
Unfortunately I do not have one of those encoders on hand and have never played with one.
Hopefully someone else with hands-on experience will help… Good luck!
Have you made a simple sketch (without FastLED) to confirm the encoder works the way you expect? Is it a debounce issue? For taking care of debounce I wired that exact encoder like this:
You might have more success using a rotary encoder with a 4 wire strip like the APA102 or LPD8806 since they don’t care about being interrupted, or try using a Teensy with your WS2811 strip.
^^ encoders traditionally work using interrupts; FastLED disables those interrupts so you may have some weird issues. I switched to a teensy to pick to pick up the clock signals from an RTC and it’s worked perfectly. Maybe there’s a encoder library that works without interrupts, or if you don’t end up finding library, make a simple function that checks the last state of the encoder vs current state at each frame and update it next time around.
You may encounter a problem if you go more than 4 ticks in 1 direction, but otherwise it should at least function.
Also, check with a serial monitor for the fact that you’re actually getting only 1 encoder tick per movement; I had a buggy library that was giving me 4 pulses per movement and it threw off my code as well.
@01001101_01010111 Thank you for the link. I had it working fine with a button but with so many modes I thought a rotary dial would be faster. Darn thing kinda works, but randomly and with flaky performance. I will post the code if/when I get it working.
@marmil I have not tried it without FastLED. Good thought. I will write up a simple sketch.
@Jarrod_Wagner I get the feeling this is exactly my problem – That is, the interrupts are not set correctly. I’ve tried a few configurations and cannot find the sweet spot. Arg…
Thanks again for the help! It’s my first project and I’m still learning. I have a few months before the project goes live so hopefully I will either solve this or just use a button! 
What µController are you using? Arduino or Teensy?
Arduino Uno. Thinking about ordering a Teensy as well to test.
There are a few Adafruit Encoders in the mail. When I got them I’ll test it. Teensy Interrupts are different to Arduino; didn’t try them yet.
@Juergen_Bruegl That’s great. Let me know when you get them. Also, thank you for the initial code that got me going. Again, the encoder sorta works but seems to skip between modes and there does not seem to be any logic in which mode it chooses. That is, if I’m on mode 5 and turn left one click it might jump to mode 10 or 1. If I try to correct this and go right one click it jumps to mode 12 or 2. I could just spend 5 minutes switching modes until I land on the one I want but that will look pretty bad when the project is live.
The encoders aren’t here yet but I looked through your code, and saw that your counter did not work correctly (this is what @Jarrod_Wagner suggested to check).
I put the updated code here with more comments:
http://pastebin.com/d7fGzXaf
I observed that some FastLED functions do suspend the interrupts. Well, if you are in such a function you might have to dial again.
Sketch should work, just turn down the brightness in the test phase (it freaked out my wall-wart).
Don’t forget to post the LED Scooter Video !!
@Juergen_Bruegl 
Thank you so much! The updated code seems to have helped the encoder some but mode selection is off. Here’s a video to better demonstrate: https://youtu.be/bKk7n5FOnCY
BTW, which encoder do you use? If it’s a matter of getting something else that might make some sense.
Didn’t have a chance to run through your specific code on the Teensy but I can verify that the Encoder library and FastLED do play nicely.
Put together a quick sketch to use the encoder values to change the hue and it worked a charm.
You should be set to go if you’ve gone so far as to order a Teensy 
@Jarrod_Hiscock I will order a Teensy anyway for testing. It looks like a nice platform for this type of project. In the meantime, I went back to button mode. It is much more reliable, except for getting stuck on mode 9. Not sure why.
Hi Kenneth,
I happen to have a few of those in my box of salvaged parts:
http://www.digikey.com/product-detail/en/62A11-02-060C/GH7386-ND/1834966
and was shocked when I saw the price! That’s nothing I would suggest to the community. When the Adafruits come in I will have a look with the scope at them. Maybe we need to debounce:
@KJC11 Having a quick peek at the above code… It’s probably because you’re using delays for the updates. While you’re displaying black/orange you’re halting the processor which inhibits checking the button state. Have you tried holding the button down between flashes to get it to catch in the main loop?
The rest of the loops use a frame by frame update while the blinking code uses delays. Maybe try implementing a simple blink without delay if(millis()…) to see if that remedies your woes.
just saw that I’ve forgotten in the modified code to set the trigger to zero.
put this at the very end of the loop:
lastCount = count; // reset the counter
trigger = 0; // and re-arm the trigger
} // end of loop
Then open the serial monitor and look at the number the encoder gives you. Also add whether the trigger is armed or not (0 or 1).
@Juergen_Bruegl if you’re resetting the trigger at the end of each loop, shouldn’t that halt the display?
Most of the functions pulled from the FastLED pallate samples rely on running each time through the loop with a subtle change to the static variable assigned to the color; only letting it run through once will give you the first frame, and then halt.
In any case, you’re only going to sporadically pick up interrupts while using an Uno (although it sounds as if @KJC11 switched to buttons instead).
You can wrap all your blinking functions up into a single function and pass the individual colors and delays as arguments and save some copy and pasting, similarly could be done for the solid fills.
!UNTESTED CODE!
http://pastebin.com/6ABsgV41
!UNTESTED CODE!
^^ certainly isn’t the best code as it may give you a hiccup on the first blink occurrence… realistically you should have a flag for whether the array has been updated or not because there’s no need to continue to update the leds more than once every desired delay period, however, it should function and allow you to get out of the Caution loop.