Off-the-shelf IoT device setup methods and how we do it at Augury

gal brandwine
Machines talk, we tech.
7 min readAug 24, 2022

IoT devices have crawled into our lives in the past few years, improving them. And enabling us to set up "routines" by operating a set of these devices under some logic or get some insights about things that used to be out of reach.

Some say these are vulnerabilities, exposing our private lives to WWW. Others say it's bliss, leveraging control over our lives and "things" surrounding us.

Either way, all these devices use some setup process to connect to the internet. We'll review these setup methods, compare them to how we do it in Augury, and try to improve these methods :)

Blog-post content

  • Real-world examples
  • How we do it in Augury
  • Can we make it better?
  • Risks and vulnerabilities
  • Conclusions

Let us dive in :)

These devices come with various interfaces, such as buttons, Bluetooth and WIFI. Setting them up involves using a combination of them in some sort.
Sometimes, when not appropriately designed — It also involves frustration and disappointment.

Real-world examples

  1. Smart ceiling light — Yeelight jade smart led ceiling light c2001

This is a smart WIFI ceiling light.

Setup steps:

  • Particular power cycle (on/off * 5 times)
  • Insert the lamp into its pairing mode (Advertising hot spot)
  • The user needs to "Connect" to it using a particular App
  • Then insert local wifi credentials
  • After pressing "enter," The lamp transitions from WIFI hot spot to WIFI client. Connects to WIFI

From now on, the device is accessible from WWW.

Interfaces used (power cycles don't count as an interface):

  • WIFI
  • Special App

PROS

  • Using already existing wifi in the house — thus don't need 3rd party accessory.
  • Fast to setup

CONS

  • There's no feedback for WiFi-credential success — one needs to retry repeatedly until the device is successfully connected to the internet.
  • Must be within range of WIFI router

2. The Xiaomi Mijia Honeywell BT smoke detector

This example uses a different IoT approach: It requires a "Gateway" (one could always inquiry the device locally via Bluetooth)

Setup steps (locally):

  • Turn on
  • Pres 3 times on the (only one) button
  • detector enters pairing mode
  • Access dedicated App
  • pair with the smoke detector BLE
  • detector exits pairing mode
  • Data streams while the BLE connection is live

Interfaces used:

  • Button
  • Bluetooth
  • Dedicated App

Setup steps (Using BLE gateway):

  • Turn on
  • Pres 3 times on the (only one) button
  • detector enters pairing mode
  • Access the gateway using its special App
  • pair the smoke detector
  • detector exits pairing mode
  • Data is streamed over BLE to the gateway, then over WIFI anywhere

Interfaces used:

  • Button
  • Bluetooth
  • WIFI (of the Gateway)
  • Dedicated App

3rd party devices used:

  • BLE gateway

PROS

  • Since BLE IoT devices connect to a Gateway, WIFI-connected devices have less load.
  • BLE communication is [as the name describes] low energy —Edge devices that use such communication can run on battery for years

CONS

  • IoT device that uses BLE requires another device called BLE gateway — this gateway is the door to the internet.

3. One last example — A project of my own:

The Minioniser

Yep, there's such a thing :)
It's a DIY project I made a couple of months ago. It's an IoT device that samples Augury's Google calendar and visualizes the progress bar of the meetings I attend (inside a giant red rocket :) ).

You are welcome to visit the TheMinioniser post, and here's the git-code

Main components:

  • Minion doll
  • ESP32-CAM
  • Some addressable LEDs

Setup steps

Like many IoT devices, it also needs to be initialized first. Then upon each reboot, it remembers the last work mode into the previous working mode and starts from there.

Interface used:

  1. Hotspot
  2. Web browser

PROS

  • The interface is cross-platform (No need for a special app)
  • Using WIFI to connect to the internet — stable, simpler and easier than using a Gateway
  • In HOTSPOT mode, Exposing an HTTP server allows insights into what is going on under the hood (Like CPU temperature, memory left, etc.) without needing to connect to the internet.

CONS

  • There's no way of knowing if the WIFI settings were entered correctly before pressing OK. The user needs to wait for a reboot and hope for a WIFI connection success.

How we do it in Augury

In Augury, we use proprietary gateway devices. We connect our Edge devices (aka EP's) to the internet through them.

Augury pioneered its IoT edge-devices (EP's) first setup simplicity — there are no setup :).

They are just mounting and turning them on.

As for the gateway, the story is quite different.

Setting up steps

Well. It's not that easy, and there are many possible obstacles along the way. But we designed it robust enough while keeping the installation process friendly to our 3rd party installation companies.

Interface used:

  1. Hotspot (first boot of the Node is in "pairing Mode")
  2. Special App (to connect the Node's hotspot)
  3. Once completing the first setup, the Node reboots
  4. WIFI — once the Node is connected to the internet, we start our authentication & configuration steps
  5. Once the Node is connected to the cloud, it gets its configuration and begins to communicate with its EP's (via BLE)

PROS

  • Using a hotspot for connecting the Node — enables and stable, secure connection to the Node.
  • Using WIFI to connect to the internet. Enables the customer to install it wherever moreover; WIFI communication has enough bandwidth for our needs.

CONS

  • There's no way of knowing if the WIFI settings were entered correctly before pressing OK. The user needs to wait for a reboot and hope for a WIFI connection success.
  • The Node must be connected to the cloud at least once to start communicating with its EPs.

Is there a best practice?

All methods covered above use different approaches for setting up an IoT device. The best practice approach comes when there's a repetition in how the user does stuff. All the covered examples do have some things in common:

  1. The switch between "pairing" mode to "Connected-to-the-internet" mode.
  2. Most of the devices rebooted when the mode changed.
  3. If connectivity credentials were wrong, there's no way of knowing it on-the-fly. But restarting the whole process.

How we can improve IoT setup methods?

By providing a way to reflect the connectivity status of the IoT device on the fly — the user could easily know if the setup is done correctly without the need to restart the whole process (one good example is: providing real-time information about wifi connectivity status)

Is rebooting between changing workmode necessary? I know that it is not :) — reducing waiting time betwine changing modes will accelerate the setup of an IoT.

Why should we care about IoT setup process stability & length?

If you only install a smart ceiling lamp in your home, you probably shouldn't care. But if you have hundreds of IoT devices installed at customers weekly, time is money. Shorter installation time leads to more installation, and stability reduces IoT setup retries, eventually leading to more installation.

Personal thoughts
Although BLE's disadvantages over WIFI, I like the usage of a gateway — Connecting multiple BLE IoT devices into one gateway reduces WIFI clients, and it's a must with the increasing amount of wifi peripherals.

Cheers, Gal

--

--