Posted on Leave a comment

Install & configure apps with the App Fairy

In order to make our devices more accessible for customers who do not feel at home with PlatformIO or the Arduino IDE we developed the App Fairy. The App Fairy is a self-contained app store for your computer. It allows to install and configure applications for our devices without editing any source code. Best of all? The App Fairy does not require installation itself. Just click and go!

Demo

Get the App Fairy

Want to try for yourself?

The App Fairy 3.0 is ready for download without installation at https://github.com/ThingPulse/app-fairy. The only requirement is that you install a Serial-to-USB driver first to allow for your device to receive data from your computer. We look forward to start building devices using the new Espressif ESP32-S2 and -S3 modules as they speak USB natively.

Moreover, we would love to hear about your App Fairy experience by email or @thingpulse.

Motivation

IoT devices usually fall into one of two categories:

  • Single purpose “end” devices with the firmware installed by the manufacturer. Depending on the use case and the complexity such devices are either
    • ready to use immediately OR
    • they need to be configured by the user (often requiring WiFi credentials)
  • (Barebone) hardware devices for makers, developers, engineers or other tech-savvy people. Vendors expect users to be familiar with at least some basic programming skills. In order to use such devices you have to install code editors, tool chains and the like.

Being makers at heart we at ThingPulse have primarily been serving the maker market since our inception. Hence, our customers usually transferred applications to their devices like we do: compile, link and flash from within an IDE or the CLI. For some of our products this was intentional. They are educational IoT kits where learning this process is the whole point. Or they are development boards. Yet, even when we offered pre-compiled binaries of the single-purpose app for a device (e.g. ESPaper Kits) the configuration user experience was ok but not great.

ThingPulse Icon64
ThingPulse Icon64

When we launched the Icon64 LED & audio device depicted left we faced a couple of new challenges:

  • It is an end user device but it is extremely versatile (tough to market, but that’s another topic). We wanted to offer several useful sample applications for the non-makers. How should they install applications?
  • Also, even if we could provide some easy means to transfer app binaries from a customer’s computer to the device how would they configure the application? Can we offer something that does not require installing more applications or a lengthy process? And can we do that within the tight time constraints of the lean startup methodology we follow?

The App Fairy does not address all the configuration user experience issues single-handedly. However, given the constraints that we have and the downsides of the alternatives (see below) we feel it is definitely a step towards a better experience for our non-maker customers.

Addressing the Configuration User Experience

Over the years IoT device vendors and platform providers came up with a number of different approaches to configure devices. We are familiar with many of them and applied some of them successfully ourselves. Here is why still felt the need to come up with something new.

Captive Portals

One of the standard approaches built into countless IoT devices is to turn the device into a captive portal or WiFi access point. The process is usually comprised of a variation of the below steps:

Captive Portal for a ThingPulse app in use
  • You push a button or a combination of buttons on the device for a certain duration.
  • The device turns itself into a WiFi access point (AP) and it starts a tiny HTTP server.
  • On your computer, smartphone or tablet you switch the WiFi to connect to the device AP.
  • Either automatically or by you entering a URL into an internet browsers the device serves a configuration page through its HTTP server.
  • You complete the configuration and hit a “Save” button.
  • The device applies this configuration and switches back to normal mode usually by restarting.

We implemented such a process a couple of times ourselves (e.g. for the calendar app on the left). Also, we used libraries like the tzapu WiFiManager for ESP8266, Khoi Hoang’s ESPAsync WiFiManager for ESP32, and Dave Steele’s Comitup for the RaspberryPi.

Nowadays this process works mostly ok and it is usually quite reliable. In the early days it was often limited to only allow setting WiFi credentials. These days all such libraries allow you to customize the configuration form to accept additional parameters required by your application.

Yet, turning the device into config mode and switching WiFis on your non-IoT device can be seen as a usability obstacle and might hamper user acceptance. On the other hand, the great advantage is its ability for you to change configuration at runtime over the air – if you have physical access to the device that is.

Mobile Apps / Bluetooth Provisioning

To address the swith-to-config-mode-and-connect-over-WiFi issue of the previous approach one could resort to Bluetooth for provisioning WiFi credentials and other properties to an IoT device.

For this to work your device needs to speak Bluetooth in the first place. Good for ESP32-line of devices. Not so good for the earlier ESP8266-based devices to which you would have to add Bluetooth capabilities additionally.

In addition, someone has to build these mobile apps and customers need to get them from the Google or Apple app store. While there are some “generic” mobile apps out there for Espressif WiFi chips (even from Espressif itself) they usually only allow setting the WiFi credentials for your IoT devices.

Remote Configuration

Ideally you should be able to configure an IoT device remotely after you put it into production. That addresses situations where you do not have physical access to the device anymore. However, for some this is a controversial topic for security and privacy reasons.

  • As a first line of defense your device should not run in “host mode”. That means it should not be accessible from the outside i.e. you should not be able to connect to it live. The device should fetch its configuration from somewhere rather than you actively pushing it to it. A publish/subscribe model (e.g. over MQTT) works well here.
  • Also, be mindful about proprietary vendor-offered cloud solutions. Make sure your IoT device does not turn into a useless brick if the vendor or is cloud offering ever vanishes. We have seen this happen all too often in the past.
  • Likewise, assess what measures such vendors took to ensure your device configuration is safe. Except for you and your devices nobody else should be able to read it.

App Fairy Under the Hood

If you are interested in learning how the App Fairy does what it does then please head over to part 2 of this mini-series.

Leave a Reply

Your email address will not be published. Required fields are marked *