The initial setup problem

The typical end-user of your IoT products wants them up and running fast, with minimum hassle once they bring them home. They don’t want to be presented with initial configuration mechanisms/options they don’t understand, and their enthusiasm quickly diminishes if you make them struggle to get the product going.

A colleague once said “If you can’t explain how it works to your grandma in five minutes, you don’t understand it well enough”, I’d re-phrase that to “If the end user can’t get your product all configured and running in five minutes, you haven’t done good enough work on designing it”. That, of course, raises the bar for the developer. Ease of use comes at the cost of increased analysis/development/testing time, but all that pays off with improvement in customer experience.

When designing IoT hardware you are often balancing product cost vs ease of use. One of the old-school approaches to hardware configuration was to have DIP switches on your PCB, which of course only allows for limited configuration options (not to speak about the complexity for the end-user). Basic LCD graphical UIs with keys ease up this task, but add to the product cost. Configuration over serial connection or re-flashing the product with correct parameters is out of question for a product that claims to be user-friendly.

With the appearance of cheap, Wi-Fi enabled SoCs like the ESP8266 things rapidly changed. It is now possible to send Wi-Fi connection credentials to a non-connected ESP8266 through Espressif’s version of TI’s Smart Config, or use Wi-Fi Protected Setup (WPS) to configure your product’s connection with the simple push of a button. Alternatively one can simply have the ESP8266 start up a Wi-Fi access point with DNS captive portal configuration UI. This means you have a configured, Internet connected product within a minute of plugging it in.

Using a dedicated cloud M2M server you can even eliminate the need to configure the local firewall, avoid software environment setups, and have full control of the connected device in no time. Naturally, security is essential and running things over TLS channel is a must. Firmware over the air updates capability ensure the hardware runs latest bug-free code and gives you peace of mind.

I’m working on a line of next generation connected projects that utilize these (and many more) techniques and putting the the accumulated experience to work.


Page views: 2605

4 thoughts on “The initial setup problem

  1. “Using a dedicated cloud M2M server you can even eliminate the need to configure the local firewall, avoid software environment setups, and have full control of the connected device in no time.”

    Please could you do tell this in more details, i’m looking for such a solution. Currently i can communicate with the ESP8266 directly via soft ap and port #### via an pc or a mobile app. this setup stops working after 3 concrete walls, so i would expand the range by using the internet and a relay server. On the PC side i have only access to the internet via port 80 and 443 as it is configurated by a firewall which is out of my hands. The Esp8266 side could be conneted via a mobile 3G access point on the final stage. I already searched the net including stackoverflow, but google failed me this time so far (Maybe i just can’t google tell, what i really want).

    Which software hardware configuration did/do you use for your M2M connection?

    Here is a real would example, out of my reach – but still very funny (the car has a 3G connection)

    ps. For the Esp8266 software currently i am using the Arduino IDE and i dont have any hesitation to change the underlying C/C++/SDK code to make things work.

    • It’s rather complex from here on, I’ll make a dedicated blog post some day. Basically connection has to be initiated from inside the firewall to a cloud hosted server that will proxy for you; I have it all working in a prototype, and am currently teaming up with some local folks to develop it further.

  2. Pingback: Local hostname for connected devices | Martin's corner on the web

  3. Pingback: The initial setup problem #IoT « Adafruit Industries – Makers, hackers, artists, designers and engineers!

Comments are closed.