Peter Hoddie calls for (local area) networking services to enable the Indie IoT — an excellent direction of inquiry. Let’s explore what implications this has.
[As for context, I have been using the term “Indie IoT” to describe a so-far aspirational Internet of Things that is controlled by the owners of IoT devices, not by the vendors. It contrasts with today’s prevalent, silo’d, “overlord” IoT in which a small number of very powerful vendors attempt to own and control every thing with electronics in it that you and I might buy or use. This migration to an Indie IoT is very desirable for users and vendors alike — except for the few would-be overlords — as it is likely produce many more solutions to many more problems, with more privacy, more flexibility and at a lower cost, than that the overlords can provide.]
So: if we don’t want some would-be overlord to be in control of our homes, chances are the devices we put on our homes should not depend on the vendor’s cloud. [That doesn’t mean there can’t or shouldn’t be one; only that things need to work without that 3rd party cloud.]
If we have multiple devices in the home, this means they need to be able to do function together on their own. Indie IoT local network services are the means to accomplish this. Let’s look at what the principles are we need to use this; what’s the lay of the land for this architecture?
First: base protocol. There is a large number of communications protocols in use for IoT applications, from serial to high-speed WiFi, with everything in between, such as Bluetooth in various versions, Zigbee, Z-Wave and many others. In the real world, chances are that systems will use more than one of those at the same time, which creates difficulties. But where have we heard of this problem before? Oh yes, a long time ago. Some smart people got together to figure out how they could make their various networking protocols communicate, and they came up with an inter-networking protocol today known as “the internet”. If it worked for them … we should do the same thing.
If we choose IP-based communication as the base protocol, then several consequences follow:
- devices that don’t natively speak IP (wired or wireless) will need to use a protocol converter or bridge of some kind to connect to the IP-based network. That’s fine, and of course already state of the art: many IoT products connect to the internet with gateways and devices like that. We just want those gateways to primarily connect to other devices on the local network, not some overlord’s cloud castle.
- things — sensors, actuators etc — that can natively speak IP can get their own IP address on the local network.
- things that aren’t able to natively speak IP, or things that have more than one sensor and/or actuator in the same package will all have the same IP. So IP addresses themselves are insufficient to address “Things”, or sensors, or actuators.
- ergo we need an addressing scheme that can uniquely identify everything that matters on the local network, such as sensors and actuators, that provides more resolution that an IP address.
Where have we heard that one before? Have two or more logically distinct network endpoints at the same IP address? Oh yes, the web! It actually provides two solutions for this problem:
- we can have several URLs at the same hostname, such as http://example.com/sensor1 and http://example.com/sensor2.
- we also can have several services running on the same device, but at different virtual hostnames, such as http://sensor1.example.com/ and http://sensor2.example.com/ (we will see later how that will come in handy)
This produces a very simple and straightforward base architecture:
- everything important on a homework has a distinct URL
- this distinct URL is served on the local network
- and the base way of accessing sensors, actuators, controllers etc is through operations defined on those URLs, such as the REST methods with GET, PUT, POST etc.
- Of course we can do many other things, like making things available on the public internet, and using more efficient protocols for streaming and the like. But they are improvements on the base table stakes that I have just outlined.
(Hmm, I think I just made the case that the Indie IoT is best implemented as “Web of Things“.)
But, if we think about it a bit more, it does turn out to be a bit more complicated than that. Here are some considerations:
- Timeliness. While I don’t think the Indie IoT needs to directly support “hard real-time” requirements, users do expect things to happen quickly. For example, let’s say I have an Indie IoT light switch, which speaks IP and REST, and an Indie IoT light bulb, which also speaks IP and REST. I connect them (how, we discuss later) so that the light goes on or off based on whether the switch is on or off. It is a very reasonable customer requirement that this should happen instantaneously:
- So polling the state of the light switch, for example, via HTTP GET, is definitely not going to work.
- We might have the light switch perform an HTTP POST on the light bulb, on the other hand, and that could be rather instantaneous.
- Alternatively, the light switch might broadcast its state change on the network, as Peter proposes as Decentralized Ambient Synchronization. The light bulb can listen and react immediately.
- One could use web sockets, as the folks at Mozllla IoT propose. The downside of this is that it is more expensive to do so (in terms of protocol support, power consumption etc).
- Security. We do need to do better than the state of the art in IoT, which is dismally low. So assuming an impenetrable security perimeter, also knows an “nobody will guess the WiFi password” is not good enough at all. And there are a number of different requirements. Let’s go back to the switch and the light bulb as a basic example:
- the light bulb must be quite certain that it was the authorized light switch that gave the command to turn itself on. It cannot simply listen to anybody who tell is to. (Imagine this is isn’t a light bulb but the door to the house safe; the protocol should be the same for lights and safes.)
- the switch must be quite certain that it isn’t being tricked into sending its commands to somebody else than the light bulb. (Imagine that would notify a 3rd party that you are home)
- of course, nobody on the network should be able to eavesdrop on the content of the conversation between switch and bulb
- everybody needs to be certain that communications can’t be replayed (i.e.recorded and re-sent by a third party). Again, think of the safe.
- The web, as we have it in 2019, after an amazing run of 25+ years, unfortunately does not provide all the necessary security features out of the box. Some of us :-) have been lamenting the lack of an internet identity layer for a long time, and even worked on it for a long time. Here is yet another example where it is required. But it does not exist yet. So we can expect having to do significant work on identity and security to make the Indie IoT secure; something absolutely required.
Enough for today, this is a good start. To summarize: The web is a great platform from where to build an Indie IoT that serves us instead of some distant overlord.
Like this? Disagree? Want to discuss? Get in touch, or comment below!