My home is IoT'd to the max. My lights are Philips Hue, my heating consists of a prototype Rio Arc Heaters, my music and tv is voice controlled and all of it connected... And. It's. Amazing.
That is, it's all amazing until the internet goes down, or my BT HomeHub decides to kick everything off the WiFi... then it becomes a mixture of normal and terrible. The heating will continue doing its thing without the internet - I can even control them using the buttons on the heaters themselves.
However, the TV and Music won't work so I am left reading a book in silence, but that's not the end of the world.
Most painfully, the lights won't switch on... at all... no manual override... so it's candles and phone flashlights in order to read!
When O2 fell over last week it was not just our access to data from phones which failed, it was any IoT device which used O2's network to connect to the internet; the TFL's digital bus timetables showed busses were never going to come, you couldn't hire a TFL bike and some payment systems went down, including Barclaycard's mobile card readers.
When designing an IoT solution it's more important than ever to consider all the failure points and what your system will do if something important goes down. There's not much you can do if your main point of contact to the internet fails (although the aforementioned Barclaycard readers can be switched to other networks, so there is some redundancy there). If your device cannot connect or something else goes wrong, it should error gracefully - in this instance the TFL bus timetable app did a splendid job as pictured above (unless, of course, you were planning on visiting their website on a phone using O2 data...)
So we see things go wrong, even the biggest companies. Even the ones who have been riding the cutting edge of this tech. From personal experience, Apple Home and Philips Hue fall out pretty regularly - repeating a command usually sorts out any glitches - but even these power houses are still finding their feet.
When we look at an IoT solution we identify all the points of failure up front and then storyboard out the impact. You can capture most of the failure cases this way and then design in behaviour which impacts the user the least. We'll also just try to break it during development and test to highlight any scenarios we might not have considered up front.
So if you do not want your product to be featured on The Internet Of S***'s twitter account: , you need to consider these five things (at a minimum!):
Not all failures are technical in nature. I put this one first because it's so important and one which almost every product I have used could improve upon.
It is key that your users do not need a computer science degree or the mind of a drug crazed physicist to set up and start using your IoT device. I tried to set up a Tesy heater as part of some market research into a IoT heater project on which we are working. It was the most painful, unintuitive, teeth-grindingly frustrating process I have ever seen. And one which NEVER ENDED IN success!
But it's not just cheap Chinese imports which have this issue - if you compare the set up of Google Home to Amazon's first generation Echo, you'll note how much easier it is to set up the Google Home. This is simply because Google uses Bluetooth to 'discover' the device in the Google Home app - open the app, discover the device and then it's automatically set up and you're done.
However, to set up Amazon's first two versions of the Echo you must first connect to the Echo's ad-hoc WiFi network in your phone's settings... go to the Alexa app, set up the Echo and then you go back and re-connect to your normal WiFi when you are done*. A more painful process than Google's, and it's getting the small things like this right which is the difference between a clunky first experience and a magical one**.
Needless to say, in the projects we do here, we tend to follow Google and Apple's lead on user on-boarding
*The latest version of the Echo now uses Google's method to connect, so Amazon have sorted it - good job Amazon!
**I know, I know it sounds like hyperbole and like I am pretending to be Jony Ive (who's design I love, but voice overs I loathe) - but when something works really well in tech, it can feel magical - so suck it up.
IoT is all about allowing something to connect to the internet and be controlled from somewhere else. You therefore need to take security very very seriously. Nothing will thrust your product into the limelight and kill your reputation quicker than a story about how easy it was for a hacker to gain control and turn the machines against your customers. And nothing is sacred as this article from wired highlights detailing the hacking of IoT sex toys - it's a serious, if not hilarious, problem.
There are a many ways to ensure your IoT solution is as secure as possible, too many to go into here, but keep an eye on our blog as we'll publish an article on this later.
If a device find's itself orphaned from the network, is there anything it can usefully do? Can it continue to operate until connection is restored? Can the user access manual overrides?
For a project we are building, which allows the remote control of electric heaters throughout the house, we store the heater's settings information on the heaters themselves, so if they do fall offline they will be able to work off local data. The user can also adjust them on the heaters themselves.
In lots of use cases knowing the state of a device is important and often the state is accessible from multiple access points (e.g. mobile app, Alexa, website, the device itself). A communication error, delay of message or two conflicting updates from two devices can cause something like this. How will the solution rectify it? Will there be an automated process which 'fixes' it based on some rules? Will the user be prompted to action something?
Again, for the Heater project, there is a central server application which monitors all the user's heaters and is able to identify when something falls out of sync. We decided to flag the issue to the user in the mobile apps for the first version. This represented a more simple technical approach and put the onus on the user to decide how they wanted to resolve the issue.
Each IoT device will be running its own firmware and there will be times when this needs updating and this will probably need to be done over the air (if you want your product to work with Apple's HomeKit it's a requirement). However this is not as simple as pushing out a new mobile app or publishing a new website. The software needs to be installed remotely over WiFi or Bluetooth, checked for a valid installation and the device re-booted, more often than not on devices with no user interface at all. Lot's can go wrong here so you'll want this process as robust as possible.
To continue with the Rio Heater case study; we update the firmware on the Heaters over their WiFi connection using the same MQTT service we use to send the heater its commands, however there is also a mechanism which allows the firmware to be updated via Bluetooth as a fallback to this option.
There will no doubt be other things you'll need to look out for which are specific to your project, like managing date and times in a global world etc.
IoT solutions are an amazing opportunity to develop something which is truly awesome, but they are inherently complex. If you keep early versions simple and plan for various failure states properly you are in a good place for a successful project.
If you want to find out more about IoT or App development get in touch :)