Beacon of Hope
The Problem
Being able to quickly build and release any of our products to gather feedback is the cornerstone of our product division and the way we do software development.
In 2014, the build status of all Redgate products could only be determined by trawling through our build server, Teamcity and inspecting each product. With well over 30 products and shared components, this was somewhat laborious, and therefore never happened! This led to the creation of the Lightboard.
Version 1 of the lightboard was a manually operated affair to change a set of LEDs mounted on the glass wall. These LEDs represented the build status of a handful of projects. Once this concept had been proven useful, version 2 soon followed. This new version was driven from data obtained from Teamcity, and the system was able to represent the build status of every product RG currently supports, and 4 years later, it’s still in use!
However, one of the major limitations of the lightboard is that it’s only visible if you are sat adjacent to it or walk past it. Many teams have their own dashboards, but if they cannot see the lightboard, they are missing out on the LED pixel goodness.
So, the “Beacon of Hope™” was born.
The brief would have been (if there was a brief!) to have some sort of flashing light in a team area to alert the team to a build failure. The data was already available via the lightboard service, so I set about looking for easy ways to build such a device.
If you’re not interested in how I built it, then you can skip the technical stuff
The Build
The first instinct was to get an Arduino board, and drive LEDs from that. The board would need some sort of network connectivity via a WiFi or ethernet shield, and I knew they could drive the pixels directly having done so with an Arduino Uno on a previous project at home.
Then the ‘Rob Factor*’ came into play (* Rob is our resident electronics guru. What he doesn’t know isn’t worth knowing!)
I looked them up, £6 per board… £6!!! Plus they have WiFi built in. Too good to be true surely.
Version 1
With nothing to lose (except £6), I ordered one and with some WS2811 pixels I had lying around at home, I set about prototyping a device. Once I’d proved I could connect to my WiFi, create a small webservice on the ESP8266 device, and drive a small 3 LED pixel strip, I scaled it up by wrapping LED pixel strip around a cut-up coke bottle. I also found a screw-top beaker to use as the beacon housing (must remember to buy a new one for my wife!). Most of the beaker was clear plastic but some judicious use of sandpaper plus an additional lining of greaseproof paper created a somewhat diffused effect.
This worked ok, although with the LED pixels being 12v, and having to do some funky voltage converting for the pixels, the board and the data lines, it introduced significant noise that resulted in flickering of the pixels. After wasting far too much time failing to resolve it (despite more help from Rob!) with capacitors to smooth and filter the signals, I decided to move onto version 2 sooner than planned.
Version 2
Version 1 consisted of WS2811 LED pixel strip which consists of 3 LED units per ‘pixel’ running at 12v, and as I already had a load of this lying around, this was the cheapest option for the prototype. Version 2 uses WS2812B pixels, with 1 LED unit per ‘pixel’. This gives a far greater granularity and control over animation, with the advantage of being 5v. With the ESP8266 board running from 5v too, there would be no voltage conversion needed, thus simplifying the system and reducing noise.
All the while, this was being driven by hitting endpoints defined in the device (e.g. http://11.22.33.44/green)
In short order, v2 was built (using a cardboard tube this time — surreptitiously requisitioned from my daughters craft supplies!), and this was rock solid. No flickering, no data corruption (apart from my own dodgy soldering).
Integration
The beacon finally made it into the office and work started on integrating it with the lightboard. The lightboard code had changed significantly since I originally wrote it back in 2014 (and that’s a good thing!), so it took a while to figure out how to drive the device. I decided that the easiest way was to add a network address field to the lightboard project object, then drive the device when the lightboard project was updated. This takes advantage of the existing data and means very few changes to existing lightboard code.
Fairly quickly, this was locally done and the lightboard code was driving my device. Then, various other changes were made including being able to associate a single device with several projects, and shutting the device down overnight.
Deployment
Then, on Friday 3rd May, the “Beacon of Hope” was deployed to one of our teams (atop a MVP beacon stand — a box!) … and then almost immediately pulled! I had not accounted for an extended period of disconnection from the network, and the driving service fell over! A quick fix later (short time-to-recovery!), and the beacon was deployed again, this time working flawlessly!
It shows green when the selected projects have passed… and a rotating red beacon if any of them have failed. Other animations or colours could be added later. The device has an endpoint for each of the lightboard project status enum values, so these could be handled in a different way if so desired.
What’s next?
The endpoints called by the lightboard service were designed such that they could be used by any device hardware or otherwise. So we hope other teams will be inspired by this, and build their own devices. I already have some ideas for some fun devices so watch this space Michael ;-)
