Tag Archives: hacking

I made a Wi-Fi controlled Owl lamp

Owl LED Nightlight

A couple of years ago, I picked up a simple LED nightlight on Amazon, with the intention of hacking it into something else. The lamp could be powered with AAA batteries or a micro-USB connection, and contained multicolour LEDs that shone up into a perspex sheet in the shape of an owl.

It was always my intention to do something “interesting” with this, for example to make it into some kind of notification light attached to my home network, but — as with many side projects — it languished in a box of bits, and I never got around to it.

This weekend, I finally started to exhume some of my old projects, and to re-examine them. As luck would have it, in the case of the owl light, I recently read about an interesting project called WLED (in part due to a series of posts I stumbled across from Tyson Nichols).

Alitove LED pack

The neat thing about WLED is that it is basically an all-in-one replacement firmware for inexpensive ESP8266 microcontrollers, like the Wemos D1 Mini that I used in this project (many other NodeMCU and related boards are compatible). If you can attach compatible LED strips to the board, you can control them over Wi-Fi. I had a few small microcontrollers sitting in my “bits box”, the only thing I was missing was an appropriate strip of LEDs.

I picked up a 5m pack of Alitove WS2812B weatherproof LEDs.

Inside the original lamp

Once I had all the parts available, the next step was to dismantle the lamp and figure out how best to replace the existing innards. With the battery base unscrewed and the plastic clips pried apart, a simple circuit board was revealed. This had three buttons to toggle the colour state of the LEDs and increase or decrease brightness; three multicolour LEDs; and a sliding on/off switch. On initial inspection, I considered slotting the Wemos D1 Mini into the same space, but it was just a bit too deep, and the USB connection was on one of the short sides, rather than the long back of the board. I also knew I was not going to run the new lamp from batteries, so this base insert could really all go.

ESP8266 wired to a strip of 3 LEDs

I’m a fan of WLED at this point, but I have to say that getting the firmware installed was a lot less straightforward than I had hoped! I’ve been working on building up a Raspberry Pi 400-based setup for coding and general making, and attempting to flash the latest firmware using esptool (before I added any connections) resulted in the board not broadcasting an SSID. I tried the same with another (non-Wemos) NodeMCU board, and encountered the same issue. I tried a workaround from one of the related forums, flashing an older version, and still hit a wall. In the end, what worked for me was flashing a 0.8.x firmware using the Thonny editor on Raspberry Pi OS; getting the board onto my home network; and then, using the OTA flash feature to flash the most recent firmware. I can only assume something weird was going on with the esptool options.

Once the board was working with WLED firmware, and I’d soldered on a short strip of LEDs to replace those on the board in the lamp, it was time to get things installed. I used a Dremel to cut a larger hole into the back of the base so that I could feed the micro-USB cable directly inside, and used a substantial amount of black electrical insulating tape to position the LED strip. Some hot glue was applied to keep everything in place, the D1 was folded inside, and the original battery panel clipped back to keep everything in place.

I’m aware that there’s no huge innovation here – the WLED project itself was 90% of the work, all I did was replace the insides of a nightlight with something more interesting. Now though, I can control it via Alexa or Wi-Fi (web and mobile apps), and I’ll be able to MQTT-enable it to hook up to Node-RED for alerting, in the future.

I put the process together into a very quick video.

Wi-Fi Owl Lamp

Prototyping – Arduino and Ubuntu


My Arduino Uno board, via instagr.am and iPhone, on Flickr

One of those things I’ve been meaning to getting around to doing for ages is to explore this exciting new world of prototyping and hacking my own hardware devices together. A lot of my fellow eightbars and of course many of the HomeCamp community are big fans of the Arduino platform. I’ve also been dying to have a go with the MQTT client for Arduino that Nick has created (although I’ve recently also come across another platform called mbed, and MQTT has been ported to it, of which more to come soon). In fact, I’ve had one of the lovely Arduino starter kits from ::oomlout:: sitting on my desk for a while now, tempting me with its gadgetry and neatly-arranged components in a funky partitioned box… but life has been so hectic that it has taken me until today to finally crack it open!

I’m not going to spend long talking about the Arduino today, except to mention that it was unexpectedly tricky to get working under my OS of choice, Ubuntu 10.10. I’d read on Anton’s blog recently that the new UNO board (which I have) needed a firmware update in order to avoid some weirdness on the serial port, so I thought I’d go ahead and fix that first – his instructions were very clear, and the device seemed to report something, well, expected as I ran the commands. All good, or so I thought!

Português: Logotipo Arduino Uno.

Português: Logotipo Arduino Uno. (Photo credit: Wikipedia)

I installed the Arduino IDE from the Ubuntu repository and attempted to start it from the new Electronics submenu. Nothing happened. At that point I decided to try running “arduino” from the command line, and got back a Java stack trace containing java.lang.UnsatisfiedLinkError: rxtxSerial indicating an issue with some of the libraries. At that point a quick DuckDuckGo search (yes, I’m not using Google much these days) led me to an Ubuntu PPA which contained a fixed version of the IDE.

I was then able to fire up the toolkit and excitedly started looking at the Basic samples. However, as soon as I tried to upload one to the board, I got an error avrdude: stk500_recv(): programmer is not responding which suggested that the board was not being “seen” by the IDE. The only interface the toolkit recognised was ttyS0 and I knew the Arduino wasn’t there… looking in /var/log/messages I could see that it created an interface /dev/ttyACM0 when I plugged it in, but the toolkit wasn’t seeing that. I then tried creating a symlink from /dev/ttyUSB0 (where the wikis and documentation were telling me to expect the Arduino) to /dev/ttyACM0 – and presto, it worked.

Creating static symbolic links in /dev is a bit hokey these days, of course, so I moved across to udev and created a new rule for the UNO in a file called /etc/udev/rules.d/80-arduino-uno.rule

KERNEL=="ttyACM*", ATTRS{product}=="Arduino*", SYMLINK+="ttyUSB%n"

dead simple: if a new device pops up in the kernel named ttyACMsomething, and it has a USB product ID string starting Arduino (which mine does, I checked using the command usb-devices), add another symlink to it at ttyUSBsomething, thanks. Result:

Dec 21 19:18:50 agrippa kernel: [21501.209012] usb 1-1.1: new full 
speed USB device using ehci_hcd and address 17
Dec 21 19:18:50 agrippa kernel: [21501.303198] cdc_acm 1-1.1:1.0: 
ttyACM0: USB ACM device
andyp@agrippa:/etc/udev/rules.d$ ls -l /dev/ttyU*
lrwxrwxrwx 1 root root 7 2010-12-21 19:18 /dev/ttyUSB0 -> ttyACM0

That all seems to have done the trick. I’m just waiting on a couple of shields for the board, not least something that will let me connect it to a network, and then the experiments will continue! Weather-permitting the next lot of electronics should appear in the next day or so. More to come, on both Arduino and mbed hackery…