Is there a way to keep the Blinks from going to sleep?

I realize this actually belongs in it’s own topic :slight_smile:

The simple answer is No. The reason for this is to protect battery life.

This is a good opportunity to describe exactly how sleep works. A Blink will go to sleep if:

  1. It’s button has not been pressed in the last 10 minutes
  2. One of it’s neighbor’s (including an entire cluster) in the last 10 minutes has not had its buttons pressed in the last 10 minutes

Therefore, having a button interacted with or connecting with any Blink that has had it’s button interacted with will reset that 10 minute sleep timer, so ideally, all Blinks fall asleep together after 10 minutes of inactivity.

That’s right, this is to protect those precious batteries :wink:. To keep Blinks from going to sleep, a player must press a single button in a cluster once every 10 minutes to keep all Blinks in that cluster awake.

For a little background: The design goal was to have Blinks stay awake while being played with, but not risk them being left awake while no one is playing. They will go to sleep if there hasn’t been “gameplay actions” for 10 minutes, where gameplay actions is defined as a button interaction. Of course, gameplay actions being defined as a button press is a limited view. I’ve spent some time thinking of ways to safely extend or disable this, but I don’t have a good one and ultimately, for shipping games, we won’t ship a game that can accidentally kill batteries.


Hey @jbobrow, a different question kind of related to this one.

Is there a way to keep the Blinks from going to “Teach Mode”?
Something we can add to the code to overdrive the LongLongPress?

Edit: I’ve founded something like this while looking on the SDK:
uint8_t sterileFlag=1; // Make this game sterile.
Can I use that if i don’t want my blink to be able to teach other blinks?

1 Like

@Confus3d I actually asked something similar a while back - Hold Down Button Indefinitely?. It sounds like it is possible, but implementing it wouldn’t be pretty. I’d be curious to see if that’s changed though with some of the API changes we’ve seen since then.

1 Like

Yes, this is what that flag is meant for - but note that you must be using the latest version of the blinklib package for this to work (it is a relatively new feature).

This branch definitely has it…

…I do not think it has made it into the general release branch yet… but soon!

1 Like

Good to know!!!

I think I can just stay on the general release, and add this feature in the future :grin:

Is just a feature on the SDK or I have to update BlinkOS?

I know almost nothing about the guts of the BlinkOS, so for me sounds amazing how you guys are able to add new features based on the same code and same OS.

Waiting to see more cool features like this one in the next SDK release!

This is in the blinklib SDK which is included with your code each time you compile. This makes it an easy and low risk place to include new features (or entirely different programming models and languages!). LMK if you have any other feature requests you’d like to see here!

Thanks for the explanation!

Now you say it, I’m curious about the space management. Did you said that if I include that flag, I will have more space? (Now I can’t find the message) Edit: Now I remember, I readed it on the SDK on GitHub!

I’m really curious about it, if you use that flag, the compile will skip the sync feature? Can I skip more features compiling and save more space?

As long as you include the flag statically, then the compiler can figure out that the sync code will never run and is smart enough to leave it out.

By statically, I mean that it is in a form that the compiler can evaluate to true completely at compile time. So, far example, including the line…

uint8_t sterileFlag=1; // Make this game sterile.

…outside any code block in your program will statically define sterileFlag as true as long as you do not assign a value to sterileFlag anywhere in your code.

If, instead, you have something like…

if (buttonPressed()) {

…inside your code then this is not a static assignment since the sync feature could be called depending on conditions.

The compiler and linker are pretty smart about omitting code that is never called (called “dead code elimination”), so this should generally happen automatically. For example, if you never call the map() function then it will not be included in the executable.

That said, remember that the blinklib code itself may use some functionality so it will be included even if you do not use it. A good example of this is the Timer class, which is used internally to keep track of when the blink should go into warm sleep mode.