One of my first attempts to use the PiGlow was to give some indication of the state of a headless Pi Zero as it started up and sorted out its server processes.

The PiGlow has 3 curved arms of 6 different colours LEDS. I chose one of the arms to act as indicators as the various parts of the system booted/initialised, a second arm to act as a rough signal strength indicator and the third arm to indicate CPU load.

These were controlled by a Python script set to start on init (including a fair amount of wrestling with systemd to stop it screwing up the init process). So by the time the script was running the OS was a long way through its startup.

The colour sequence I used for the startup indicator arm was:

LED Activity
White (centre) the indicator script is running
Blue have an IP address (means the wifi is up)
Green accepting SSH connections (sshd is running)
Yellow accepting HTTP traffic (nginx is running)
Orange not used
Red (outer) not used

For the wifi indicator arm, I adapted the "bar graph" example script to light the LEDs from the centre out, increasing the brightness of each LED from dimmest to about half brightness before starting to light the next LED.

In general I try to only light PiGlows to half brightness (about 127), because at full brightness it's quite painful to look at the LEDs.

Note The LEDs don't vary in brightness for every single value of the brightness from 0 to 255. The LEDs light up at about 5, and steps of about 10 are visible if you cycle through them. So setting a range of [5 - 125] in increments of 10 gives you 12 steps from dimmest to brightest for each LED.

For the CPU indicator arm I used a very crude measure - just repeatedly parse the output of a cat /proc/loadavg and grab the 15 min load value. From that I can map onto the LEDs so a load of 1.0 means the green is brightly lit (busy, but ok), 2 lights yellow brightly, 3 lights up orange and anything above that lights up red brightly. Loads below 1.0 are mapped to light the white, blue and green LEDs with an appropriate brightness.

Is it any use?

Well, it depends. I found it fun to do, although my Python scripting is pretty damn ugly. However I probably wouldn't want to set this up as a regular thing to leave running on a headless Pi server. Partly because servers usually aren't visible, they're tucked away and ignored, and partly because the lights usually aren't telling me anything I need to know.

The init indicator arm is quite handy for knowing when I can start connecting to the server after a reboot. However on almost every boot, the slowest indicator to light is blue (ip address). So really I could have just used one LED that lights when the server has a proper IP address (or can ping the wifi router). All the other services had already finished starting up by the time the wifi was ready.

The wifi strength arm is basically pointless here. The strength very rarely varies enough to cause a noticable difference in brightness of the LEDs, it just sits at full brightness. Maybe it'd be more useful if I used the Pi with a battery and wandered round the house looking for low spots in wifi strength.

The load arm was also not much use, I'm the only one using this server, so when I'm not using it the load is basically zero and when I am using it the load cranks up depending on what I'm doing, but I know when I'm making the Pi work hard. It was neat to see just how much the CPU has to work when doing some tasks though.

Previous Post Next Post

© Me. Best viewed with a sense of humour and a beer in hand.