Investigating MQTT as an “IoT protocol” for the ESP8266 wristband

I have recently had a rethink about how I will link my wristband to an alert source.

To demo my first prototype, I hosted a web page on the ESP8266 device itself. Selecting a button on the web page posted a value, which activated the chosen vibration pattern. This is a very convenient way to demo the concept, but, in the real world it has some significant drawbacks.

The first drawback is that the whole submit / refresh cycle of a web page is not particularly fast, which also probably means that the web server on the ESP8266 is having to do a relatively large amount of work. I therefore had originally planned to eliminate some of this overhead by following the approach in the ESP8266 IoT example of using http methods and json, which can be called from anything (e.g. from another pc/server by using the curl command).

But this does not solve a second issue, which is that the ESP8266 server has to be “always on”, waiting for a command from the remote web page. This is likely to make power savings measures (sleep cycles) difficult, which is less than ideal given that Wi-Fi is not as power efficient as Bluetooth – notwithstanding that Wi-Fi continues to evolve.

The third problem is the direction of the link. To communicate with the wristband requires that you initiate a connection. This is not a problem if you are on the same network (and also assuming you always know the ip address of the wristband). However, if the source of the alert is from outside the network, a firewall port will need to be opened and forwarded – something that will usually be out of the question on most corporate networks.

With this background, and inspired by Peter Scargill’s exploits, I decided to investigate MQTT. Potentially if offered to solve all three of my issues:

  • It is a lightweight protocol, optimized for resource-constrained devices (like the ESP8266) – refer to here and here.
  • Because it uses a broker in the middle, both the client and the (wristband) device talk to the broker, not to each other. This allows for an asynchronous communication scenario in which I could allow the wristband to, for example, check the broker for messages and then go to sleep for a second, yet be guaranteed not to have missed a message when it next checks at the end of that second. Such a duty-cycle could dramatically lower the overall power consumption.


  • The broker architecture also solves the firewall problem by reversing the direction of the connections. Now the wristband will initiate the connection to the broker, which can thereafter communicate without the need for port forwarding.

Continue reading

“Haptic Bracelet” published by Hackaday… and working on the next version

It was fantastic to see my vibrating wristband appear on

Brian Benchoff did a great job writing his article.

Meanwhile, I am working on my next prototype. The main goals are to:IMG_4268s

  1. Make the action of each vibration motor more specific. This will be done by eliminating the plastic backbone (which conducts vibrations). I will instead use a fabric band with compartments to keep components in the right place.
  2. Make everthing smaller by designing a pcb to hold all of the electronic components.
  3. Use the ESP-03 version of the ESP8266, as it is smaller and has more outputs that are broken out.
  4. Move beyond the web server / page demonstration to connect the device to a message source elsewhere on the web.


I have managed to get a newly arrived ESP-03 working on a breadboard, including properly latching the shift register during updates, as I mentioned I intended to do.IMG_4271s

With the previous ESP-01 version, I tried making an adapter to reuse the ESP8266, but it all went wrong when the solder flowed more than I intended. It then struck me that the modules are so cheap that it is not worth going to all the effort – just keep one permanently for breadboard prototyping.


I have been making extensive use of the SDK examples to work out what to do. But, when faced with a bunch of c modules and headers for the first time, it can be difficult to get an overview of how they interconnect and interrelate.

There must surely exist some good (and free) tools to generate these “call graphs“. After all, this capability is built into any compiler?

Continue reading

Vibrating Wristband Alert

Welcome to this first post on my blog. Over the years I have enjoyed following and using the work of many others across the Internet, so have decided to contribute my efforts to the community as well.

I have always had a passionate interest in electronics (refer to About), but these days it is very much a hobby. So, if you look around my site, you will notice placeholders for projects that I still plan to write up – sometime in between work and family life.

The Concept

I was motivated to develop a vibrating wristband communication device after reading “Enchanted Objects” by MIT Media Lab’s David Rose. In the book, he imagines a future based not around the “cold slab of glass” of our smartphone screen, but instead on “technology that can enhance our five senses and optimize our physical abilities – by accommodating and responding to the way we already operate in the world”.


As I planned my device, I drew up the following wish-list:

  1. The device should communicate with us in an immediate way that bypasses our usually overworked visual sense.
  2. The device should have multiple vibrating actuators to be able to deliver a richer message than can be achieved by using “Morse code” like on-off pulses to a single actuator.
  3. It should use Wi-Fi to connect directly to other devices over the internet. This is in contrast to almost any other similar device either available or being proposed. Of course, the use of Wi-Fi instead of BLE does mean a higher power consumption. But for this proof of concept, I wanted a device that was a “first class citizen”, not requiring tethering to a smartphone or other device. The power issue could be dealt with later, hopefully with sleep modes, advancing technology, etc.
  4. In keeping with the Internet of Things (IoT) ethos of ubiquity, the device needed to be low cost. This is particularly important for the wristband, because it is explicitly designed as a single function device, not to be all-in-one and consequently complex-to-use as seems to be the current trend.

The ESP8266

The technology required to make this possible (at least from a hobbyist perspective) only became available late last year, in the form of the ESP8266. This remarkable module is tiny, has built in Wi-Fi, a programmable CPU able to control GPIO pins, and costs only about 3 dollars (including free shipping from China!)


The drawback is that documentation is scarce – although this situation is gradually improving due to a few intrepid developers out there (refer links for details). It also does not run Linux like some other development boards, which means that you have a limited choice of development options (at least currently).

I initially started coding the wristband using Lua, which becomes possible by flashing the ESP8266 with the NodeMcu firmware, using ESPlorer. Although certainly an easy way to get started, in my case the results were flaky. I was constantly getting module resets, and wasn’t sure why. Memory also seemed to run out quite quickly. However, I may not have persevered enough, or the environment may have improved since then. So don’t let me put you off trying – here is a link to download my wristband_lua code.

As a result, with some trepidation, I moved onto using the Unofficial Development Kit by Mikhail Grigorev, which turned out be an excellent piece of work. It does require that you develop your code in C, which may not be to everyone’s taste. In my case, it is my preferred development language and so, quite a few hours later, I had ported across my wristband code into the “esphttpd” example provided in his SDK.

To my delight, this proved to be stable. Also, the serial bit-banging loops were running 250x times faster as measured on an oscilloscope – not essential for my application, but nonetheless satisfying.

The First Prototype

The main objective was to find out how the multiple vibrating actuators would actually feel when on your arm. Was this a feasible approach to communicate a variety of different messages?

Continue reading