LED key keeps glowing when the keyboard is plugged in

I don’t think this is intended. In the default firmware code:

  // We start with the LED effect that turns off all the LEDs.


LEDOff.activate() has no effect on the LED key. So how do I turn it of on start up?

Are you using &BootGreetingEffect? This pulses the LED key for 10 seconds on boot. You can just remove it from the Kaleidoscope.use() list if you don’t want it.


That solved the issue indeed. Thank you!

Strange. One would think that LEDOff.activate() would actually turn all the leds off. Especially if LEDOff.activate() is the very last statement in setup().

Edit: Also, that Led key was glowing permanently, not just for 10 seconds.
Could be that ledoff.activate was overriden by the bootgreetingeffect.

Hmm, it’s not supposed to. Sounds like it could be an issue with the BootGreetingEffect then.

I’ve seen that same behaviour, if I don’t switch LED modes. I’m not sure how LED modes work, but is it possible that if nothing else explicitly sets the LED colour (e.g. if one has the LEDs off) it never gets overriden?

I’ll try to look at it later tonight. I’ve seen the same behavior, I’m pretty sure.

The way the LED effect works, once the time limit is reached, it seems like it just stops updating the LED color. So it’s working “as programmed.” It’s an easy change to make it so that the LED shuts off at the time limit…I was able to make it do that with just a slight modification.

There is one (I’m sure unintended) consequence of using the BootGreeting: once the time limit is reached, the LED button doesn’t revert back to using whatever LED theme is currently activated. Example: while the BootGreeting is running, swap to a solid color theme. You’ll see that it just stays a dim blue while the rest of the board is the other color.

Suggested changes:

  1. Perhaps BootGreeting should immediately end (done_ = true) its effect when the LED button is pressed so that the new theme can take over. I’m not really sure how to make this happen.
  2. Change the main loop so that it shuts down the LED after the time limit is hit. This will prevent the LED from remaining a dim blue after the breathing has completed.

In terms of bugs, this is probably not high on the list of things to fix, but it is something that would make the final product a little more “polished.”

The correct way to handle this is LEDControl.refreshAt(). Maybe I’ll submit a patch for this.

Actually, seems a fix for this was merged about 3 days ago. @rumpel, @james.nvc, @ejinks4 - updating to the most recent version of the plugins might solve this. (Or if you have updated, then the fix wasn’t sufficient and we should try to troubleshoot that.)


Nice changes. Looks like it should work pretty much perfectly now. Thanks!