Who kept the dogs out?
Paul Egan, Principal Consultant, blogs for IoTUK about the lessons IoT businesses should learn following the recent media attention a connected pet feeder received after suffering an outage.
For those of us with experience developing products that contain even a small amount of tech, the issue of testing feels all too familiar. It is no small task to get it right even with multiple product “spins”. This is why the old tech adage, “it always takes longer than you think” to get to a stable, reliable product is so apt.
One of the recurring concerns about connected devices is their reliance on persistent, reliable networks, a five nines availability of cloud hosting and services, and devices with a “fail safe” mode.
When developing a connected product selecting suitable system architecture, proven design methodology, review and testing processes are key to establish from the very start. Doing this will not only make a great connected product but is essential if we, as the buying public, are to truly trust these new kinds of products and services.
Last week we saw an example of what can go wrong. Petnet, an in-home connected pet feeder, hit the headlines for their ten-hour long service outage that left around 10% of their active users unable to feed their pets at scheduled feeding times. To make matters worse some users reported that the ‘manual’ feeding of their pets via their iOS app also failed to work.
There are few details as to the exact nature of the issue, other than it was a problem with the Petnet servers. Often third party cloud services, used by companies like Petnet, are provided by corporations such as Google, Amazon and Microsoft. Following the outage, all Petnet services were restored and a ‘fix’ is now being rolled out in the form of a firmware update across all devices to make sure there is a ‘fall back’ in case of further connectivity or service issues.
Petnet’s outage only further highlights to consumers the anxiety of connected devices, which I discussed in a previous blog following the bricking of Nest’s connected home automation system Revolv.
This is why when designing connected products, I’d advocate the overall goal must include a duty to “do no harm” to end-users and to prove that all necessary steps have been carefully considered, including unplanned and unexpected scenarios.
It may be asking too much of the IoT industry at this early stage to carry out full regression testing for such things, but losing connectivity or cloud services must be one of the more predictable and common issues.
I also know that startups need a cash flow to establish themselves and shipping the MVP early is all too tempting. However, by sending your product to market without a thorough understanding of its behaviour (both designed and unplanned), the trust of your customers will be even harder to earn than the next round of investment.