Christmas Lights 2023 - Baby bouncer controlled lights

Back in 2020 I made some Christmas lights that could be controlled via Slack and WhatsApp so that Christmas spirit could cross the void created by Covid-19 and its lockdowns.

In subsequent years I added more features, such as morse code.

So now adding to my over-engineered Christmas lights has become something of its own tradition.

In early December this year, while setting up the decorations and mulling over what new silliness I was going to add to the lights, I was asked to fix my son's baby bouncer/cradle thing.

It's a Fisher Price Kick & Play Calming Vibrations bouncer, which has switches in the foot area which I believe are supposed to trigger lights and sounds.

This particular one was a hand-me-down which had been sat in storage, and the battery terminals are all corroded, making it non-functional.

Fixing it wouldn't really be a big deal, but I remembered that like most newborns, my son loves anything that's bright and shiny and blinky, like Christmas lights.

 

So obviously you can see where this is going...

The arch of the chair detaches, and you can see in one of the mounting points 4 pins.

A quick probe with the multimeter shows that these are two pins for each of the two 'pedal' switches.

To interface this with the existing light setup, I decided to again use the GPIO interface of the PCDuino.

Using the guide from before, I identified the GPIO identifier for two pins that I wanted to use, and enabled them as below. Pin 4 (232) is an input and pin 7 (233) is an output that is set to high simply provide a source, as I wanted to keep the main source pins (3v3 etc) free.

echo 232 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio232/direction
chown -R ant:ant /sys/class/gpio/gpio232
echo 233 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio233/direction
chown -R ant:ant /sys/class/gpio/gpio233/value
echo 1 > /sys/class/gpio/gpio233/value

The two pins were connected with a resistor to create a pull up effect. I had initially tried to have it as a pull down but it seemed to still have a lot of flicker in the output.

I picked the switch with the red foot as this tends to be more how Sam would sit. one side of the switch was connected to ground, and the other to pin 4.

The code

I added a thread to the main application which would read the value of the pin and change the lights accordingly.

Because of the way that /sys/class/gpio/gpio232/value is not actually a real file, it was not possible to hold the file open and continually read the input. Instead I had to create a loop which would constantly open the file and read the value. This does cause some overhead, but isn't too bad because the file is never more than one character long.

I had initially planned that when a change is detected, it would hook into the main code to change the lights, however I found this was causing a lot of deadlock issues. 

Instead, the new thread works very independently - it will pick one of the basic colors at random, and make a simple HTTP request to localhost to invoke the change.

The result

I'm not sure if he's aware of the causation between him moving and the lights changing, but like most babies there's twinkling, blinking and sparkly stuff, he's a fan, so he certainly seems to enjoy it.

View this post on Instagram

A post shared by Anthony (@darkmidnight_diy)

Slack/Whatsapp controlled colour-changing and morse code Christmas lights

Several years ago I made some Christmas lights that could be controlled via Slack and WhatsApp, and every year since I find that I need to update the interface to these platforms to account for the changes that they make during the year. 

Usability updates

This year whilst I was doing that, I took the opportunity to add a few new features and simplify the interface.

Now it responds to some key words – all, top, bottom, half, alternate, led, and allows the user to specify certain colours by word and all colours by hex code.

Additionally I refined the serial interface to speed things up.

Moving to a single-board computer

 
For my home implementation of this, previously I would just run a USB extension lead from my desktop. 

I have now migrated the code to a PCDuino2 single board computer. This is a 1Ghz Allwinner A10 chip SBC, which also contains Arduino pin headers.

The board is discontinued (I bought this one from Maplin years ago during their closing down sale), and as a result there is little in the way of official repositories or archives for the Ubuntu variant distribution that it runs. Plus it looks like there’s some sketchiness around the official firmwares around the allwinner chip that powers it.

I found a version of Armbian linux for this platform and burnt it to a micro SD card.
This allowed me to get the PCDuino to boot to Armbian.

Unfortunately it looks like there is no real support for installing Armbian to the NAND storage which is on the PCDuino. However, leaving it on the micro SD has some advantages such as easily being able to image and back up the install.

Then it was simply a case of connecting it to the network and updating it, enabling SSHD for ease of maintenance going forward, and installing required tools for the Christmas lights server (JDK and Arduino).

As the PCDuino is not a typical Arduino development board it needs its own board definition to be used with the Arduino IDE, so for now I decided to continue using an externally connected Arduino.

 

Implementing morse code

 
One of the downsides to the set up the I currently have is that the serial data transmission can be disrupted by the update process transferring data from the Arduino to the lights.

The changes I have made reduce the amount of data that is transmitted via serial and so minimize the problem.

However there is additional functionality that I wish to add that will require further data to be transmitted – that is to have a set of lights which flash similarly to regular Christmas lights, but instead of a standard or random pattern, they blink out morse code, based on a message input from the control application.

Rather than cram more functionality into the WS2812 lights that I am currently using, I plan to leave them be and use a regular set of plain white fairy lights for this. Typically I have always decorated our Christmas trees with a multi colours set and a plain white set, so this fits with what I would typically do anyway.

The lights I used are powered from 3xAA batteries (4.5v), which can easily be substituted for USB and powered from a USB hub. To toggle their on and off state, I have used an optocoupler which will be toggled from the PCDuinos GPIO pins.

The ‘arduino-style’ pins of the PCDuino board can be reached in be linux file system via GPIO – similar to the way I toggled an output pin on the frequency switch project.

Seeing is this makes it quite easy to simply toggle a pin on and off, I should be able to use this for the morse code without having to depend on the rather outdated and no longer supported PCDuino board definitions.

Finding the pin reference

 
A ‘gotcha’ about using the sysfs GPIO interface is that the pin numbers as they may have silk screened on the board do not necessarily correlate to the pin numbers in the file system.

The first thing to do is figure out what the pin identifier would be. In this instance, I found some config files for the PCDuino on GitHub.

There lists the PCDuinos GPIO pins and there corresponding identifier, summarised below.

GPIO Pin	Pin ID
0	PI19
1	PI18
2	PH07
3	PH06
4	PH08
5	PB02
6	PI03
7	PH09
8	PH10
9	PH05
10	PI10
11	PI12
12	PI13
13	PI11
14	PH11
15	PH12
16	PH13
17	PH14
18	PH15
19	PH16

I’d decided to use GPIO 8, so the relevant ID is H10

The Sunxi wiki demonstrates how to calculate the relevant GPIO number from that ID

(position of letter in alphabet - 1) * 32 + pin number

so with H10, H is the 8^th letter so

(8-1)*32 + 10 = 234

So with that number calculated, we can export the pin with

echo 234 > /sys/class/gpio/export

which will make ‘gpio234’ available under /sys/class/gpio.

From there we can make it an output, and change the ownership so of it’s value file so that a regular user can write to it.

echo out > /sys/class/gpio/gpio234/direction

chown -R ant:ant /sys/class/gpio/gpio234/value

Then to switch the lights on,

echo 1 > /sys/class/gpio/gpio234/value

and

echo 0 > /sys/class/gpio/gpio234/value

to turn them off

A demo video is below, and as usual the source is available on GitHub.

View this post on Instagram

A post shared by Anthony (@darkmidnight_diy)

Merry Christmas!

 

 

Fallout New Vegas inspired "Sunset Sarsaparilla" lamp

In Fallout New Vegas there is a fictional drink - Sunset Sarsaparilla - and in various locations throughout the game there are these bottle lamps, which served as the inspiration for this project.

 

 

I'm not trying to make a perfect replica, but instead just follow the general format of the design.

Lamp

The base lamp I am re-purposing is a basic  bedside lamp. It has a simple stem that lends itself well to this kind of project

Bottle

I found a beer bottle which had no embossing or branding on it other than an easily removed label.

To drill the hole in the bottom of the bottle I created a single-use jig to hold the bottle upside down. I filled the curved base of the bottle with water to act as coolant and lubricant, as excess heat can be a big problem when drilling glass. An abrasive drill bit, normally meant for drilling tile, was used, which worked very well.

In it's simplest guise, the project would just be "Drill hole in bottom of bottle, thread lamp through bottle, done."

 

Switch

Although I didn't want to make this project an on-the-nose gaming build, I do have some Sunset Sarsaparilla branded bottle caps, which I wanted to use as the switch. However I don't want the sharp-ish edges of the cap exposed, so I encased it in two-part epoxy resin.

This sat atop a simple toggle push-switch poking through from the bottom of the base.

Assembly

Starting with the stem of the lamp, I drilled a small hole in its side, to thread the fairy lights through.

Then the connector end of the fairy lights are threaded through that hole, and the lights themselves wound fairly tightly around the stem

A second, plain brass, bottle cap was drilled to fit the stem of the lamp, and threaded onto the lead for the main bulb.

This was then attached to the top of the stem, and the lead threaded through.

This assembly was then put into the bottle. Before pushing the bottle cap down entirely, by pinching the end of the fairy lights and then rotating the stem, the lights could be unwound, so that they expanded into the bottle.

At this point the fairy lights were tested (with just battery power) to ensure no wires were broken or damaged during assembly.

 

 

Power

The original lamp runs on regular mains voltage.

However I'd like to reduce it so that I can add some fairy lights in the bottle for some additional lighting.

There exist 12v DC bulbs for the type of fitting this lamp has (E14 SES), which would typically be used in caravans etc. Obviously it's not just a case of switching the bulb over, else the 12v DC bulb will just get destroyed.

So firstly, I'm removing the plug from the lamp, so it's not connected back to direct mains by accident.

I intend to simply use a 12V wall-wart, which the new bulb can be powered directly from.

The fairy lights that I'm using are powered by 2 CR2032 coin cell batteries (6v), so I'll still need to reduce the voltage to power them.

To do this I'm using a LM317 regulator, with 4.7k and 1.5k ohm resistors to create a 5.4v output voltage

I'm also including a small current-limiting diode on the output to the fairy lights for added protection.

Base

The base of the original lamp, aside from a weight, was hollow. I took the base and flattened it into a simple metal disc.  

My router was broken, so had to be
creative with a forstner drill

I took a piece of chestnut wood, and cut a new base from that, hollowing out the enough to recess the original base disc, and house the additional electronics.

 In the top another hole was drilled from the button

The button that the bottle cap will sit on

 

 

End Result

View this post on Instagram

A post shared by Anthony (@darkmidnight_diy)

Slack & WhatsApp controlled Christmas Tree Lights

December 2022 update: I've developed this idea further, giving the project more features, including the ability to blink lights in morse code. The original post remains below.

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.

Wiring

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.

 

Arduino code

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.

 

The 'server'

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

[1,"colour"]

or

[[1,2,3], "colour"]

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.

Using the web-browser interface, and making use of Firefox's Javascript console, I added a MutationObserver to the page, and made use of the DOM to narrow in on the message elements, and get the contents of the latest message in whatever chat/channel the user was in.

The javascript for Slack can be found here.

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 finished product

View this post on Instagram

A post shared by Anthony (@darkmidnight_diy)