The blossoming Internet of Things space is becoming pervasive across the commercial, consumer, industrial and health sectors and sits at the core of the Smart City movement. With 6.4 billion 'things' estimated to be connected to the Internet by the end of 2016, the IoT is a business opportunity many of us cannot ignore.
I’ve been lucky enough to be involved in designing and building a few IoT products over the past year from a smart beermat to a web connected knee brace. The challenges that come with creating any new product are vast but there are specific sets of issues that pop up when building an IoT device.
Here are seven questions you should ask yourself to be better prepared for the twists and turns connected product design will throw at you.
Have you defined the scope of your product?
Start small and build functionality iteratively. We always go for a Minimal Viable Product (MVP) prototype which usually includes a Proof of Concept (POC) as part of the build.
Establishing the core feature(s) of your MVP is quite important as the success of a prototype advancing depends on whether you made the right call early on. Test and iterate your versions. You may need to do a small run of products up to 90% fidelity to get some proper user insights and data before unleashing a final product on the world.
Will it move around?
Is the device going to be fixed in one place like a Nest thermostat or Phillips Hue light? Is it a wearable like a Fitbit or is it a new component for an automobile dashboard? A simple question but this affects two big things – how it connects to things and how it’s powered.
How does it connect to the Internet?
How you incorporate the 'I' in IoT is pretty much limited to BLE, WiFi, network cable or cellular.
Most fixed IoT objects in the home, shop or workplace can leverage WiFi. They need a lot of energy but on the upside they can always be on, always collecting, listening and sending data and can draw power from wall sockets.
Bluetooth Low Energy (BLE) is better suited for devices synced to a mobile. They require less power and use the phone’s ability to communicate with the cloud. However, this gets you into native app territory.
If neither of these is viable, cellular kits can be implemented into the device itself, like the Photon Electron, to ensure sensor data is pushed where it needs to be at any time.
What hardware should you use?
Before you fire up the laser cutters and fret about circuit board milling, know that there’s quite a good competitive mix of off-the-shelf hardware providers out there. As far as microcontrollers and micro processing boards go look for the ones that suit your project:
Does it have the right connectivity? What are power usage options? Is it the right size? Are there enough input/output pins? And is it programmable in a language you’re comfortable with?
Small processor boards like the Spark Photon come with onboard WiFi chips where a similar sized LightBlue Bean have BLE built in. If size doesn’t matters, products like the Arduino family or Raspberry Pi can offer more processing power and connectivity options.
Components like accelerometers, temperature and proximity sensors are also a dime a dozen and easy to find from suppliers like Adafruit.
You shouldn’t need a team of engineers and a machine shop to get a working prototype up and running.
How is it powered?
Unless your IoT product doesn’t go beyond an NFC tag it will probably need electricity to do its thing. Can it be plugged in to the wall or can it run on a coin battery and for how long? Do you go rechargeable? How about solar or ambient RF charging?
If your device is low power (uses BLE or infrequent monitoring) you can probably get away with a smaller battery that last for weeks or requires infrequent charging. A WiFi approach or regular data transfer activity will need more juice.
Head's leg brace needed quite a bit of power but also had to be light and wearable. We used a small mobile phone charger that could run the micro controller for 24 hours while in constant use. Managing your voltage is a huge factor in designing your device.
How will users interact with the device?
Software, the other side of the coin. Where does your data live (locally or in the cloud) and how is it presented back to the user in a useful way? Where does the processing take place – on the device, on a mobile, in the cloud or a mix of all 3?
If you’re not dependent on mobile, a web-app option might be a quicker and cheaper route to go down. You can use all the responsive and visualisation tools you want (D3.js, Bootstrap) and have your user log into a dashboard on any device. Websockets can open up some interesting 2-way communication options if you want to control the device form a browser.
If you need a mobile device to connect to the web and process data then you’re looking at native app territory. That’s cool as it probably means your device is smaller and more energy efficient plus you get the benefit of BLE synchronization and local storage. App design, distribution and management however should not be taken lightly.
What’s on the outside?
Can it take a knock? How does it stay in place, with adhesives or bolted to a wall? Does it clip onto your chinos or do you wear it around your neck? What happens if it gets wet?
Choosing the right housing materials is another important round of decision-making. Protecting your hardware from the elements might be one thing but also consider how user features are integrated (buttons, displays, LEDs), and how weight and branding influence its effectiveness.
3D printing will let you test a variety of materials (often mixed) ranging from ABS, metallic, flexible rubber and clear Perspex.
It’s all about understanding options and making decisions
Sensors, components, micro processors and shields are abundant and cheap. Open source dev languages, free CAD tools, deployment platforms and cloud services all help speed getting something built and launched for testing.
If you’re worried how something looks there’s always the 3D printing option to help sell it up the chain of decision makers.
Challenges are going to be specific to your own project coupled with other factors like budgets, working processes and skill sets. On the upside, with all the resources available today there’s never been a better time to enter the IoT game and start building something.
Sourced from Robert McFarlane, Head of Labs, Head