Progressive Internet of Things Appliances

I’ve been thinking a lot about IoT recently. Mostly because we built these foosball tables for Google I/O 2016.

At the same time, my friends in the web world have been talking about Progressive Web Apps (PWA) for a while.

The general idea, I think, is that applications “work for every user because they’re built with progressive enhancement as a core tenet”. But to look over the general requirements from the point of view of an IoT application, we can see there is a surprisingly good mapping! Here are two of the most important aspects of Progressive Web Apps that apply to IoT appliances.

Connectivity independent

This must be the most important factor of a good IoT appliance. I can’t say how many times I have giggled at the Internet of Shit Twitter stream. Seriously, build your appliance in a way that can work offline.

In the case of our foosball tables, they kept score on the table itself, as well as in the cloud. The devices receive notifications from the cloud to update local state which would fix an unlikely mismatch.

Every connection, whether it be to a central hub in the house, or a distant server should be degradable into a reasonable experience. Of course, a smart X should always be better than an X even without the internet!

This appliance is good offline, and better online

Sounds like the “progressive” approach to me.

Safe

They say “safe”, we can say “secure and private”. And this must be the equal first most important thing about an IoT appliance. ZOMG we are just opening up HTTP port 80 servers all over the place (go for it, it’s the 90s). SSL should be a requirement everywhere, and here is a really unfortunate and secret truth:

Classical Arduino-style hardware doesn’t have enough juice for SSL

That’s right, the ethernet shields and various other things won’t work with SSL. The AVRs just won’t run it. This is sad because those AVRs have the best development experience — they have all the libraries we need with the Arduino IDE.

Enter WiFi chips that are Arduino-IDE-compatible, but have a lot more processing power, like the esp8266 that we use in version 1 (in our microkitchen in the Googleplex) of the foosball tables.

Version 2 (in production at I/O) had a constraint of using ethernet. We ended up using the Arduino Yun, but any linux would have done for us. That was almost secure, but we didn’t have time to fully audit the Yun’s bridge library, and some of the libraries we used, and, well, we should have done a much better general job of security.

I think we may see the rise of chips like the esp8266, combined with classical AVRs to give more GPIO and standard interfaces like I2C and SPI. We really really really really don’t need an operating system like linux sometimes. Another opportunity is for AVRs with dedicated SSL capabilities or combined with dedicated SSL chips.

SSL is just one basic measure. We do an appalling job of security in IoT in general — mostly because it is hard:

I can barely fit a Firebase auth key in the flash of an attiny85!

Progressive Internet of Things Appliances

So, “PIOTA” if you prefer bulshytt. Degrade well with altering network conditions, and put security first. Please.

--

--

--

Google Developer Platform. Advanced Trauma Life Support. Open Source. Abominator Class.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ali Afshar

Ali Afshar

Google Developer Platform. Advanced Trauma Life Support. Open Source. Abominator Class.

More from Medium

How to Use Drag And Drop On HTML5 Canvas Element Using FabricJS

Setting Up Default Rails Controllers

The Web Frameworks That Compiles

QOI: Quite Ok Image format