With the Covid-19 pandemic still dragging on, it looks like things won't be back to normal in time for Christmas.
At work there was discussion about Christmas parties, team building exercises, and other such things to try to boost morale.
I'm currently working on a project that uses WS2812 RGB LEDs (which'll no doubt wind up published here eventually), and on a whim, wondered if there existed fairy lights that use the same chip.
Turns out, there are. So obviously I had to buy some.
My Christmas tree is positioned so that is can be seen in the background when I'm on Zoom calls with work, so I thought it'd be fun if I could setup some system that would let my colleagues interact with the lights.
Once the lights arrived and I'd tested them, I got to tearing them down.
The power supply/controller is a USB unit. I was powering it from a phone charger adapter. That also contained an infra-red receiver for the included remote. I thought about potentially working that angle, but the remote had limited options, and I wanted to offer more granular control.
From the controller to the lights was just 3 leads, which I rationalised must be +5V, Ground, and Data.
I cut the wire, figured out which was which, and connected in an Arduino. It wasn't able to provide enough current to drive the LEDs itself, to I made use of the existing charger - the charger continued to be connected to +5V and Ground, sharing the ground with the arduino's ground, and then the data line connected to the arduino.
|The circuit. It works fine like this for short periods, although I later found adding a 470 Ohm resistor between arduino D12 and the first LED increased reliability over time.|
I ended up using the PololuLedStrip library, and modifying the existing code for that.
Initially I'd hoped to be able to provide full RGB control, but it just seemed that the sheer amount of data being sent meant bytes were being lost, or I had to slow the data rate down to unusually slow.
Eventually I settled on using 10 preset colours, defined with numbers 0-9, being sent as a 100-character serial string - 1 character (colour) per LED. This seemed to be the best trade off of functionality and reliability.
The code can be found here.
This is a simple web server that accepts GET requests for one endpoint, and is simply there to provide a go-between for the messaging apps and the serial port.
As each LED is individually addressable, I wanted to create a format that would give users control at that level. I settled on messages with the following JSON structure
where the numbers are the IDs of the LEDs, and the string is one of the available colours.
This would let them control either an individual LED or a series of them in an individual command.
Hooking into Slack and WhatsApp
As at work we use Slack, and we have some previous integration with it, it seemed like the obvious choice.
However, their API functionality is heavily focused on HTTP endpoints, and requires a server to interface with it. That's fine for 'proper' development, but when I'm just messing around at home, I don't really want to be dealing with opening up my home network and all that entails.
Really what I wanted was some client-side plugin functionality. There isn't an official API or interface for one, so I had to improvise.
Once retrieved, some basic checks are done to make sure that the message is in a usable format and hasn't been acted upon already, it's then passed to a local server via HTTP, where it's processed, converted to the serial format used by the arduino, and sent onward to it.
After realising how useful MutationObserver is for things like this, it was quite trivial to do the same for WhatsApp.
The finsihed product