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.