As mentioned in the previous log entry, I had an one meter WS2801 led strip and a mbed LPC1768 micro-controller. The goal was to connect all of this to the network, poll the local Jenkins instance for job status and present it on the led strip, one LED for each job. As one soon may realise this will not provide very detailed information about what is running on the Jenkins instance or how it is doing. Instead it provides as quick and convenient overview of the status and motivates the team to keep the LEDs, and inevitably the jobs green. For example, suppose that you come to the office on Monday morning and you see that most of the LEDs are red, then you know that you will have a though start of the week. But on the other hand, if you see that it is all green, then you know that you can start coding right away. It also provides a good visual indicator for other teams whether the team is knee deep in build problems and do not want to be interrupted at this point to discuss some unrelated matter.

The goal can be broken down into several technical challenges that needs to be addressed in order to get it working:

• How to communicate between WS2801 and the micro-controller
• How to extract and interpret the information from the Jenkins server
• How to connect the mbed LPC1768 to the network
• How to write software which opens a TCP socket to the Jenkins server

The first three tasks was pretty straight forward. Unlike WS2811, which only has an data line and fixed timing protocol, the WS2801 has one data and one clock line. This means that the master controls the clock speed which makes life easier when it comes to implementation. The communication can simply be implemented either using built in hardware SPI or by bit-bang in software. I went with the later as it is quick and easy to implement and the amount of data to output is low.

Extracting and interpreting data from a Jenkins server is also straight forward. Jenkins provides a great XML and JSON API by default. Simply append /api/ to almost any Jenkins URL and you will see the output which is available. For example, go to the url /api/json?tree=jobs[name,lastBuild[result]]&pretty=true and you will get a list of all job names and the result for the last build of each job. There are two nice-to-know arguments in the request, the pretty argument which makes debugging easier. But, most important the tree argument, it allows for server side pruning of the response and is very powerful as it allows you to select exactly the data you ar interested in. By using this argument you limit the amount of data sent but also makes the life easier for the server as it doesn't have to spend as much time generating the query response.

Connecting the micro-controller of choice, LPC1768, to the internet is easy. The module has pins which allows you to connect a RJ45 connector, that connector can then be used to connect a regular ethernet cable. There is one thing worth mentioning, please use a RJ45 connector with built in magnetic transformers. Although it seems like it works without magnetic transformers it might fry the micro controller as there is no galvanic isolation between the micro controller and what ever is on the other end of the ethernet cable.

With these three pieces of the puzzle done it might seem like we are close to done. Wrong, far from done! It was easy to bodge together some code which sent a TCP request to the Jenkins server, retrieved the data and parsed the information. Unfortunately I never got it to work reliably. Turns out that there is/was, at least back in 2013, a problem with the ethernet stack in the micro controller which causes it to crash after a few dozen of requests. Even modifying simple examples to make recurring network requests ended up crashing after running for a while.

In the end, after a lot of debugging I gave up on this approach and decided that the LPC1768 and mbed stack wasn't ready and up for the task! Instead, it was time for a second attempt using a first gen raspberry pi...