IOT Holiday Lights

This tutorial will walk you through setting up a string of colorful holiday lights that connect to the internet. The lights can display many types of animations and colors based on information sent to it using Adafruit’s IO service. Once connected and programmed, IFTTT can be used to set date triggers as well as change animations based on your GPS location, the weather report for the day, and even when you are getting a call from your mother.

The hard stuff is already done and with just a bit of soldering and a few code edits, you will be deep into the beast known as the Internet of Things. Continue reading IOT Holiday Lights

ESP8266 and MQTT disaster averted…

Fair warning, this is going to be a super geeky IOT post. Just an hour ago I figured out a rather frustrating glitch in the code I was using to connect 2 ESP8266 chips to a local MQTT Broker. For some reason the code worked perfectly on both devices until I plugged them both in. Then they would constantly disconnect form the server.

I am using the PubSubClient library for handling MQTT interaction with my local Mosquito server running on a Raspberry Pi model B. I recently got a stable interaction going with some NeoPixels when I decided it was time to connect a few of them up for unified and individual control.

Think of this as like Phillips Hue, but with full animations, locally controlled, and at a fraction of the prices.

Anyway, the moment I got more than one turned on, both start continuously looking network connection. Packets get lost and the lights go form near bullet proof to buggy as hell. Unplug one and the other returns to near stable operation.

I checked to see that both devices were pulling unique IP addresses and just to be safe I even changed the topics that they were subscribed to. I hunted for people having the same issue, but nothing. At last I ran across two posts that mentioned an issue with matching Client ID’s clashing on the same MQTT servers on remote APIs.

I hunt through the exsample code to see what is going on and sure enough. They are using the same Client ID every time on Reconnect. I changed it to a unique one.


All fixed. Now I need to add a random number to the end of the Client ID so that I never have to worry about this ever again.

Why care about MIT App Inventor?

The other day I made a post about using App Inventor to create a simple UI for the Particle Photon. I have also been working on a project that involves an internet connected Weather Cloud. To make it easy for the owner to control this cloud, I have put together and Android app.


This works much faster that using something like IFTTT and requires no additional libraries like Blynk.

This brings up an interesting observation when it comes to IOT. If you want to interact with your devices, there are not a lot of good ways to go about it.
You can throw some Ajax onto your web server. If you have a web server that is.
Connect your devices API to another companies API and send your data on an epic journey when you are often in the same room as the device you are sending data to.
Make your own API and take pride that you have joined a legacy of frustrated developers world wide. Then scrap it all to use IFTTT just so much easier.
You could add a few new libraries to your firmware so that it can talk to a custom UI app like Blynk. This is actually not a bad option except that I should not have to add a new library to exploit the basic HTTP interaction protocol that comes standard with the Particle API.
Going back to the web server thing, you can just use a simple HTML page and form data for interaction. This just leaves your device credentials open for the world to see.

This is the problem with IOT right now. There are lots of ways to interact with devices, but no really good way to just go from user to device for the average person. App Inventor gives us a quick fix by letting us create an app that just uses HTTP GET and POST requests while keeping the credentials private. However, we need something better. An app that uses basic the preexisting protocol with an intuitive UI.

This is what I am working on at the moment with Vince at SoDo MakerSpace. An app like Blynk with no additional libraries, IFTTT without the additional API hooks, and Ajax without all of the coding.

I feel like this will help to open the door to the dream of IOT for the masses.

IOT Holiday Lights

Holiday lights_bb

Weather Cloud Project Update

I have ported the code over to the Particle Photon and am working on some new lighting and sounds to represent data being sent to the device.

Thanks to James Bruce and hisĀ How to Build a Cloud Lamp with Sound Reactive Lightning tutorial, I think I have found a cool Thunder animation. Continue reading Weather Cloud Project Update

The Cloud connected Weather Cloud

What better way to visualize cloud data than with an actual cloud. This project sets out to create a device that will visualize information using light and sound surrounded by a white fluffy cloud.


The Weather Cloud connects to and pulls the current forecast for your location. Weather conditions are pre-programmed into the cloud that will put on a light and sound performance for each weather condition that comes up. You can use IFTTT to set up the connection to as well as a schedule for the cloud to follow so that it is already showing you what to expect for your commute.

Aside from the default weather stuff, you can manually trigger any of the weather performances you want. It may be raining outside, but the sun is shining and the birds are chirping inside. Fall asleep to the soothing sounds of a rumbling thunderstorm.

Other notifications can also be added to the cloud. Use IFTTT to set up the cloud to blink red when you have new email or change from Blue to Green when the Seahawks game is on.

Now for the techy stuff, this device is powered by the Adafruit HUZZAH ESP8266 Wi-Fi board along with the SoundFX board and some NeoPixels. and IFTTT provide the interaction between the user and device.

Limitations to overcome
All of the functions of the cloud works as described, however it dose take a moderate understanding of how to program the chip as well as update the API to get this all set up. This makes the initial setup not so user friendly… This needs to become more streamlined.

Connecting to the internet
Currently the Wi-Fi SSID and Password are set into the Arduino sketch that is flashed to the ESP8266 along with the credentials. We need too get things set up so that this can all be setup and changed by connecting directly to the ESP8266 as a host. The ability to store multiple SSIDs would be cool while we are at it.

Now it’s time for data
The internet of things is not very good at doing things without an API to communicate with. Setting up accounts, managing feeds and public keys are not things that everyone considers as cool.

These are all issues that are easy to solve, but take time. Perhaps the first iteration of this kit will require a bit of technical knowledge, but will be easily fixed with a software patch. I am hoping that this will be a good gateway drug for IOT.

Just in case you are really interested, I recorded the entire prototyping process for this device. You can see all 4 hours of the process in the following videos:

Sorry that the audio is not super good. I am working on it :)