Rationalize the LED color scheme to show sensor status

[johnwalicki]

The firmware currently blinks the LEDs with a bunch of colors depending on its status.

We should implement a different breathe pattern - some LED indication that the sensor is running the STA/LTA on the edge. Nothing interesting is happening but the ADXL355 sensor is active.

[johnwalicki]

We have a conversation thread underway in the OpenEEW slack workspace
https://openeew.slack.com/archives/C01FD7LL56X/p1617119922029300

[johnwalicki]

Current implementation:

#define LED_CONNECTED     1 // Cyan breath
#define LED_FIRMWARE_OTA  2 // Magenta
#define LED_CONNECT_WIFI  3 // Green
#define LED_CONNECT_CLOUD 4 // Cyan fast
#define LED_LISTEN_WIFI   5 // Blue
#define LED_WIFI_OFF      6 // White
#define LED_SAFE_MODE     7 // Magenta breath
#define LED_FIRMWARE_DFU  8 // Yellow
#define LED_ERROR         9 // Red

[johnwalicki]

The colors were selected to loosely follow the Particle color scheme. That is insufficient to represent all the OpenEEW sensor states.

The LEDs are NeoPixels so there are thousands of colors it can display.

There are three LEDs on the OpenEEW device. Currently, we set them all to the same color when displaying a "state", We could also cycle them in a "strip". Not certain if the cycle would be recognizable but its a possibility.

Or we could set each LED to a different color. (Beware that its hard to stare at the LEDs so not recommended)

We can also dynamically set the LED brightness. That's what it does now to slow "breathe".

Net: we could make the LEDs flash in different sequence "patterns" if we wanted to.

[johnwalicki]

We should have a dispassionate discussion on the OpenEEW states. Match up colors to these states.

All sorts of tricky implementations are possible if people want to experiment here.

[johnwalicki]

Todo:

• Document these OpenEEW device states and LED colors in a firmware readme file.

[johnwalicki]

Maybe instead of a giant color chart of states, we allocate different LEDs to show different status?

One LED could represent connectivity - disconnected, wifi, ethernet, smartconfig scanning
One LED could represent MQTT status - connected, publishing data, receiving commands
One LED could represent the ADXL355 accelerometer - STA/LTA edge processsing, Shake Detected transmitting, off

There's other states too. OTA firmware upgrade initiated, NTP Time Sync, SmartConfig success, etc

[johnwalicki]

Do we need this feature for v1.5.0 and the Caribbean deployment?

[neilh10]

Would a system "user view" state(s) variable work, and the colour(s) are mapped from those states.
I haven't received a board, but there is a hierarchy of events/actions, from receipt of the device, self provisioning, user provisioning, maintenance, and of course one sub-state is some form of altering.
I'm just looking at the code for the 1st time, openeew-firmware\WatsonIoT , it built :) , I found the LED_CONNECTED but not dug deeper

I have the https://www2.purpleair.com/collections/air-quality-sensors/products/purpleair-pa-i-indoor and its self documenting intro "PA-I-Indoor PM 2.5 sensor’s full-color LED, the resulting glow indicates air quality at a glance from across the room."

What if the design for colours shown "Be Friendly" above all else.

[andygrillo]

Agreed with Be Friendly as the guiding principle. John, I like the idea of different LEDs but the lid is a diffuse material so can be hard to see which one is which. Id suggest we just keep to single colors on all as we have it. However your 3 groupings (connectivity, mqtt status, accelerometer), could make sense for groups. Perhaps each one shares a unique pattern (breathing, chasing ,pulsing) ? I do think that unique colors are important to differentiate each function.

…

On Thu, 1 Apr 2021 at 09:02, neilh ***@***.***> wrote: Would a system "user view" state(s) variable work, and the colour(s) are mapped from those states. I haven't received a board, but there is a hierarchy of events/actions, from receipt of the device, self provisioning, user provisioning, maintenance, and of course one sub-state is some form of altering. I'm just looking at the code for the 1st time, openeew-firmware\WatsonIoT , it built :) , I found the LED_CONNECTED but not dug deeper I have the https://www2.purpleair.com/collections/air-quality-sensors/products/purpleair-pa-i-indoor and its self documenting intro "PA-I-Indoor PM 2.5 sensor’s full-color LED, the resulting glow indicates air quality at a glance from across the room." What if the design for colours shown "Be Friendly" above all else. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABP5GHNAVES25EGLW6QOA33TGSDKBANCNFSM42GCNSJQ> .

-- Andres Meira *m* +52 (55) 12246468 *skype *andresmeira

[andygrillo]

@vkuna has modified the colors now in the latest main firmware. The messaging LED blinking is also reduced in brightness as we had user complaints! can we close this out?