It is holiday season, and I see a pattern with several of my friends. They have started tuning their xmas tree lights. Thus, challenge accepted. Now, I am not going for excessive amount of lights; 240 RGB-pixels are plenty for me,instead I’ll go for the tech in it.
xmas tree lights – blinke’ty blink, so what
Why would anyone have a remote for xmas tree lights? Because we can, and it is an excellent way to demonstrate Internet-of-things -aspect of these devices – I mean, everyone is expecting fridges and toasters to be in the net, but nobody expects xmas tree lights (nor Spanish inquisition) to be there. All the more reason to do it.
Also, I saw FastLED library had a nice implementation and default color palettes in the latest version, and I wanted to see how they work – the words Ocean, Forest, Cloud, Lava, Party sound pretty promising color spaces for a xmas tree light, instead of just blinking red, green, blue, yellow..younameit.
By an accident I just happen to have on the shelf all the basic components:
- Particle.io Photon board – essentially an internet-of-things enabled Arduino (albeit some 10x more performing) + self-made PCB for interconnecting it with various hardware
- A PCB for Photon with logic voltage converter for connecting with LED strip
- Some four meters of APA 102c LED pixel string and 5V/10A power supply
- Self-made small Cordova framework for making simple remote UI with jQuery and jQuery mobile via particle.io cloud
Making a IoT device that only connects to remote controller is trivial as it has virtually no scalability requirements in the back-end. Also, the back end can only handle few connections at a time, with limited amounts of data in them.
Client “remote” app
I wrote a small library to take care of trivial setup operations: login to the messaging cloud, and the device selector (in case user has several devices connecting to cloud – I have as they are 19 USD a piece), when those actions are complete, the client has OAuth access token to keep with the session.
Note that client misses few critical parts: I haven’t written neither the logic to carry out user registration to the cloud, nor the logic to introduce a new Photon to network. (softAP for entering network credentials and registering the device with user account) As this is prototype, I have accepted those limitations. As a workaround I can manually introduce devices during first use, with Particle’s mobile app.
The whole resulting mess is nicely encapsulated to a mobile app by Apache Cordova.
xTree device – hardware
One thing I like about this piece of hardware is it’s size, it can be housed in a match box – and it gets it’s power through the same connector as LED strip. Also the number of external components is very manageable.
The hardware is about as simple as it gets. As Photon MCU logic works on 3.3V and led strips require 5V logic, I used a simple FET-based logic level shifter circuit to drive them properly. In breadboard testing I found out that there are number of factors that may cause disturbances to those when driven with higher speeds – so even if they may work with 3.3V, there is less debugging with proper voltage matching to be expected.
xTree device – software
The embedded software structure is very basic:
- setup – to set up libraries and communication
- loop – to refresh LED strip some 100 times per second, and to show new pixels
- a callback function for network communication – to show indication when color palette is changed, and to change the actual color palette
The whole device end totals less than 100 lines of code – with proper library support the actual code becomes beginner level stuff.
Also, now I got to be green: Instead of buying new LED lights, I made them and I will probably reuse the design – with new software next year.D
Source code here – feel free to take a look, or re-use if you feel brave: https://github.com/takkulan/xtree