Skip to content
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

System and Application code can both use the LED with well-defined results #569

m-mcgowan opened this issue Aug 22, 2015 · 1 comment · Fixed by #1205


Copy link

commented Aug 22, 2015

There are these issues relating to the LED not functioning correctly when used by both system and application code:


Essentially, when the system wishes to use the LED (listening mode, SOS, OTA update) the LED color isn't respected.

We will split the system LED notifications into various levels of increasing importance - background, normal, important, critical, and two sources system and application, with system notifications taking precedence over application notifications of the same level.

Normal System notifications:

  • connecting to WiFi (flashing green)
  • connecting to the cloud (flashing cyan)

System background notifications

  • resting, WiFI off (breathing White)
  • resting, WiFi on (breathing blue)
  • connected WiFI (breathing green)
  • connected cloud (breathing cyan)

System critical notifications

  • SOS
  • OTA in progress (flashing magenta)
  • setup mode

These are critical notifications because the block user code from running, so have the highest priority to ensure they are seen. When multithreading is added, setup mode and OTA in progress will execute alongside application code and will be reduced to background priority.

A new system service will provide the primary access to the LED, which is used by all aspects of the system (apart from perhaps the SOS handler since it has to be simple.) The LED service allows system and application code to request a LED color with a given priority, brightness, and pattern (steady, blink, fade etc..). The LED service places this request in a list of LED requests, sorted by priority, and uses the head of the list to compute the current "winner". For example, n application attempting to set the LED to blue for a normal notification doesn't replace the LED color of the system which is displaying a critical notification.

For each source (application/system) and urgency (background/normal/important/critical) there can be at most 1 unscoped request and 0 or more scoped requests. The unscoped request has a lower priority than scoped requests, and each scoped request has a higher priority than any scopes already existing for the given source and urgency. Scoped requests are typically short-lived requests that span a given action (such as entering listening mode) which is why they are given higher precedence than unscoped requests.

auto request = system_led_status(rgb(0,0,255),  LEDPattern::Fade, LEDSource::Application, LEDUrgency::Background, LEDScope::Enter);

// ... later on

// removes the previously registered LED status from the LED manager

The enter/exit scheme works well for LED statuses with well defined scope. There are cases where we want to set the led with indeterminate scope, such as with the existing RGB.color() API, or for the current system state. By changing LEDScope::Enter to LEDScope::Unscoped the value is placed in the LED service stack of requests, replacing any other LEDScope::Unscoped value already present for the given source and priority. Unscoped values have a lower precedence than scoped values of the same source and urgency.

The existing RGB led library will wrap the system_led_status() methods and provide a simpler interface for application developers.


This comment has been minimized.

Copy link
Contributor Author

commented Mar 18, 2016

I see the list of critical notifications will need to be dynamic - in threaded mode these notifications don't block application code, and so may not be considered critical.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.