In Part 1, I introduced the Smart Shelf concept, the sensor used, and the web page for displaying real-time updates.

Since then, I have also created a short video to demonstrate the project:

Part 1 explained how I used the Sparkfun ESP8266 Thing and the C SDK. For reliability reasons (in my case, when presenting / demonstrating in front of a live audience you ideally want things to work!), I have always preferred to use the C SDK, especially after the problems I experienced with Lua causing frequent reboots when I tried that approach a year ago.

But with the arrival earlier this year of the Arduino IDE, there is now a compelling alternative, which seems to work well (based on my limited experiments). So, as illustrated in this post, if you are an Arduino user, my view is that connecting a NodeMCU board and programming using the Arduino IDE is no more difficult than developing using an official Arduino board. The advantage is that you get built-in Wi-Fi, a smaller form factor and all this at a fraction of the cost. So for many applications, using an ESP8266 dev board like the NodeMCU might be the approach to consider first. Continue reading →

• Part 1 uses a Sparkfun ESP8266 Thing and the C SDK.
• Part 2 uses a NodeMCU and Arduino IDE.

ESP8266 Dev Boards

I have realised, after spending some time building small projects using the ESP-01, ESP-03 and ESP-12 modules running off battery power, that it can be quite time consuming and tedious to build the necessary power supply circuit and wire up serial connectors each time. Also, where space is not critical (unlike in my train project), it becomes quite compelling to consider dev boards that integrate an ESP8266, together with other features, in an-easy to use (bread-boardable) form factor.

This is even more the case if you look at the falling prices of, for example, the NodeMCU board on AliExpress, You are not likely to be able to build your own equivalent at a lower cost, even discounting the time it would take.

In my type of interactive projects (where the ESP8266 cannot be put into deep sleep for extended periods), operating off battery power realistically means using LiPo/LiIon. As a result, I found myself having to disconnect the battery, attach it to a LiPo charger and then reconnect for every charge cycle.

This is when I saw that the Sparkfun ESP8266 Thing “includes a LiPo charger, power supply, and all of the other supporting circuitry”. Very convenient for what I had in mind…

But before I get to that, I want to be clear that the Sparkfun ESP8266 Thing is actually not my favourite module for the following reasons:

• It is relatively expensive (more than 5 times the price of one of those NodeMCU boards listed above, including shipping)
• Programming is not done neatly via the USB port like in the NodeMCU, so requires an additional 3.3V FTDI USB converter (or equivalent).
• Unfortunately, the serial programming lines interfere with debugging via the serial port after programming, which requires that you install terminal software (e.g. RealTerm) that can disable toggling the DTR line, as described in the Sparkfun Hookup Guide. I have not yet tried the Adafruit Huzzah, but it does not appear to have this problem, although requires you to fiddle about with buttons to get into programming mode. In contrast, the NodeMCU board simply handles (transparently in the background) toggling GPIO0 low for a programming cycle.

It is worth noting that Sparkfun’s newer ESP8266 Thing – Dev Board fixes these issues (other than the price) – but then does not include a LiPo charger!

It would be interesting to find an inexpensive LiPo charger/management board that one could pair with a NodeMCU, if anyone knows of such a thing?

Smart Shelf Concept

Continue reading →

One of the most important reasons that I considered using MQTT for my haptic wristband project was because of its ability to handle devices that are intermittently connected. IOT devices, even if nominally switched on, may at any given time be unavailable due to sleep modes (even although this direction did not prove as promising on the ESP8266 for my application as I’d initially hoped), or simply because the device has temporarily lost Wi-Fi connectivity.

Whatever the cause of disruption, the MQTT architecture provides for the broker to store any important messages (i.e. those flagged with high qos or “quality of service”) to be later delivered to a client that had been previously subscribed, also with high qos, but is at that point in time disconnected.

For my project this is crucial. I have always envisaged my wristband to be an additional “priority” channel to cut through the barrier of noise created by the visual overload of our multiple screens, through the beeps and buzzes representing emails, meeting requests, tweets, texts, phone calls and missed calls – which are themselves competing for (hopefully) the majority of your attention directed at real people and real objects around you as you do your job and live your life!

Therefore, as a device that handles relatively few but very important notifications, a missed message is unacceptable.

Unfortunately, as I hinted at last week, I struggled to get this MQTT mechanism to work. The main problem I was having was that I was not sure where the fault lay – and even wondered if I was misunderstanding the way that MQTT should work. I began to suspect that the free MQTT broker that I was using did not support this more advanced behaviour. As it transpired, and thanks to some timely help from Carl at CloudMQTT support, the MQTT broker turned out to be fine – it was both the ESP8266 client and the MQTT test software that I was using that were dropping the ball.

After wading through many documents on the web, I also realised that this whole area of MQTT persistence is quite confusing and not well explained from the point of view of someone actually wanting to make use of it. So, in this post, I aim to first explain how persistence should work, and then afterwards provide all the details for someone to actually try it out for themselves. Along the way I also discover a couple of great new products. Continue reading →

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 →