What I have learned deploying small-scale, high-value IoT devices

by Jalada

Everyone focuses on large scale consumer Internet of Things products such as Nest, but it turns our there is also a huge amount of scope for small scale & high value B2B IoT. This is where Wine Cloud fits – a project I am the technical lead on.

At Wine Cloud we connect between 6 and 60 off-the-shelf wine dispensers up to the cloud so people can pour wine via their phones, tracking and rating the wines they like in the process, and ultimately placing an order through the app. It’s great for wine shops, wine exhibitions, tasting events, pop-ups and so on.

We adopted a very lean approach when developing Wine Cloud ahead of having any real customers and we went from a blank canvas to a live installation in about 3 months, including developing a mobile web application and of course all the IoT architecture to allow people to pour wine over the Internet.

Because of our timescale and the nature of the business our approach to attaching hardware to the Internet was very different to a company like Nest or Little Printer. With that in mind here’s some alternative suggestions on how to do IoT on a relatively small scale.

Don’t be afraid of x86

Everyone loves the Raspberry Pi, but I have an unpopular opinion: they are toys. They are great for teaching and learning, but I would not deploy one in an environment where reliability is important. The new version may be better (I hear it doesn't corrupt your SD card quite so often…), but you have to remember the goal of the Raspberry Pi; to be cheap. The design of the Pi intentionally cuts corner to reduce cost, and cheaper/fewer components will tend mean worse reliability as a rule of thumb.

There are more reliable ARM platforms out there, but it will still be performance-constrained, and not as well supported in the community as x86, and that’s going to hinder your flexibility.

Similarly, Arduino is a great platform, but you are going to spend a lot of time reinventing the wheel and writing code to achieve simple functionality. That‘s not very lean.

Our solution? Intel NUCs and hardware communication over serial/USB with off-the-shelf adapters where necessary. Not cheap, but you have the flexibility of an entire Linux machine on site and x86 architecture at your disposal, and all the reliability and support that brings. We have deployed seven NUCs in the wild in varying situations without any issues, and we can provision a new one with a 2 day JIT turnaround (order one next day, provision and ship back out next day). Seven is a small number (but it is growing!), but remember these are high value acquisitions so that isn’t insignificant.

Treat your platform like IT infrastructure

It’s important to have visibility on what your devices are doing, what environment they are in, and what state they are in. The holy grail of monitoring IoT is that you can contact your customers to tell them there is a problem before they have even noticed the problem. This is achievable with off-the-shelf IT infrastructure management systems like Puppet, Nagios and Papertrail.

All our deployed nodes are provisioned using Puppet, communicating with a Puppet Enterprise server. We chose PE because of the centralisation it provided; out of the box you get immediate metrics and information about deployed nodes and they regularly phone home so we can keep tabs on them. It also handles intermittent connectivity well. We can also push down updates to software or configuration very quickly and easily and we know it’s robust and erosion resistant.

Don't lock yourself out

The last thing you want to have to do is go and visit every installation to perform a software update. Ideally you want as much of the system to be updateable over-the-air as possible. This allows you to improve and iterate at low cost, and also quickly rollback any changes that have introduced problems.

Wine Cloud was very much an MVP when we first deployed it in the wild. By running Puppet we had a reliable way of pushing updates out without having to do any development on the methodology for achieving this. The value of this cannot be overstated: being able to provision anything and know it probably wouldn’t brick the devices was a massive safety net when going live.

You can always refactor

Although it’s appealing to build a fantastically minimal device with low power and low component cost, what happens if you need more functionality than that provides in the future? What happens if you need to pivot and you’ve wasted all that time and money architecting your solution?

I’m not denying that deploying x86 machines in the wild is expensive and (literally) has quite a few moving parts. And I’m not saying that your internet-connected light bulb project should have an entire PC running to power it. But I think it’s very easy to overlook the seemingly heavyweight option of over-provisioning power and functionality, and I think you should at least consider it.

And if you’re started off with an entire computer powering your IoT product, you can only go smaller! At Wine Cloud we’re already starting to do this: we’re spending some R&D time looking to replace the USB side of our solution with wifi-connected Arduino-based platforms and pushing the rest of the logic into the cloud. But our current solution has got long legs, and has helped us rapidly iterate and learn about how our product is used in the wild, and that is helping us make much better decisions about architecture in the future.

Example

Here are the components that make up the hardware solution for Wine Cloud:

  1. Off-the-shelf wine dispensers with existing electronics, including an existing CAN bus connector.
  2. Off-the-shelf CANUSB adapter.
  3. Intel NUC.
  4. Node.js application communicating over USB to devices & Socket.io to our cloud infrastructure.

Here are some alternatives we considered that would’ve all taken longer, but are more traditional IoT solutions:

  • Replace the CAN bus inside the dispensers with some kind of WiFi or ethernet-connected Arduino that acts as a bridge & speaks directly to the cloud.
  • Replace the CAN bus with Zigbee or similar.
  • Replace the Intel NUC with an embedded solution (e.g. Raspberry Pi).
  • Put an ARM-based system inside every dispenser.
  • Reprogram and extend the existing electronics (Atmega based) to connect to the cloud & attach an Ethernet or WiFi chip (probably the polar solution to the one we chose).