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.
- 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.