Let’s say I’d like to use MQTT to make the doorbell in my house communicate with the living room lights. I think what would have to happen is this:
- the doorbell and the living room lights would have to be an MQTT client each
- somewhere in my house I’d run an MQTT server
- doorbell and living room lights need to find that server, and register with it, one as a “producer” of information, one as a “consumer”
- some piece of code that runs the logic (“If somebody rings the doorbell like …—…, flash the living room lights in red”) must run somewhere in my house
- that piece of code would subscribe to appropriate topics as producer and consumer on that MQTT server
Am I getting this about right?
My response outgrew an email so I’m posting it here.
At a high level, yes that’s about right. There are some nuances worth pondering, though.
First, there is always a broker but there need not necessarily be a central rules engine. It is possible for the devices to interact directly, although this is more for the simple cases. For example, the light might subscribe to an actuation topic and the doorbell might publish directly on that topic. That said, my ideal implementation includes a rules engine and a standard set of actuation topics. This is similar to Windows events where you don’t need to wire the default sound up to everything that might produce it. You wire the default sound clip to the default sound event and things publish to that event. Also, as in Windows, it would be possible to plug custom events into the event framework. So there would most likely be standard event topics defined for, say, fire alarm, but you might add a custom one for “motion at bird feeder.”
So I see a rules engine in there for most useful implementations. Maybe it’s in the house (preferably) but I’m sure vendors will supply a default version so new device owners don’t need to set anything up. I also imagine people selling secondhand routers with Tomato firmware burned in and running a broker with zero configuration setup. The device publishes to the same address as the TCP Gateway.
Another thing to consider is, as a device programmer, what is involved in reporting state using REST? Right now it’s common for devices to talk directly to manufacturers over HTTPS. Now let’s say that manufacturer wants to allow the device to talk to two things. Two REST calls for each event notification? Three things = three REST calls? Four things = four REST calls? It doesn’t scale. However, with a true pub/sub like MQTT the device publishes each event once and it is capable of being subscribed by an unlimited number of other things.
Now imagine you with to subscribe to state of something using HTTP. Poll. Poll again. Poll again. Poll and got a value! Poll again. Poll again.
Now subscribe to three events. Poll, poll, poll. Poll, poll, poll again. Poll, poll, poll again. Poll, poll, poll again.
With MQTT you maintain a single connection, subscribe to as many topics as you want, and the broker pushes events to you as they are published. For most hardware, you will saturate your bandwidth before exhausting the broker’s capacity.
My use case for this is that something like an LED bulb should publish first to the local MQTT hub. The homeowner can then have their rules engine subscribe to that publication. Because it is a topic hierarchy, it is possible to subscribe or publish to all lights at once, arbitrary groups of lights, or individual lights. So out of the box you get addressability with tunable levels of granularity as simply as changing a string in the publish or subscribe call. No complicated logic required to make groups of things. Also no configuration changes to add or decommission a device. Since the rules engine subscribes to “lights” it doesn’t need to know about “light_127” specifically, it just gets any publications that light_127 makes after you screw the bulb in somewhere. Take that bulb out and no need to tell the rules engine it’s gone.
Now consider the case that you decide to publish the device events to the vendor because they offer some compelling functionality. You simply make an administrative subscription that wires up the topic the device publishes to with the URL provided by the vendor. Done. In a reasonably functional dashboard app, you just click a radio button.
Let us further suppose that some other vendor provides functionality based on the same events. Rather than relying on the device vendor for the integration, they can do it themselves and advertise the service. You simply wire the URL they give you to the topic the device publishes on. For example, LED bulbs, fans and other devices that can be dimmed, slowed or stopped might participate in discretionary load control. The utility tells you which devices it understands and you wire those up to the URL they provide. Remember, the device publishes once and only once and requires no firmware updates to do any of this, no matter how many integrations can use its data.
Want to publish to your Kynetx cloud? Wire a topic up to the URL they provide.
Want to publish to IFTTT.com? Wire a topic up to the URL they provide.
You can do any or all of these things without changing the device and without requiring the vendor too invest in the integration. It is this ability to scale that gives us the connection density which fulfills the promise of Internet of Things.
Imagine you were trying to simulate a brain and had to wire up all 10,000 connections from each node and doing it with REST polling. Now imagine how you want to change the configuration dynamically.
Now imagine the same thing with pub/sub where each node makes one publication and subscribes to the 10,ooo other nodes it talks to and it has the ability to aggregate those subscriptions by subscribing to high level topics like “lights” instead of to light_01, light_02, etc. Now imagine changing that dynamically. You add a new light and the subscription…well, it doesn’t even need to change because it already subscribes to “lights.” Take a light away and also no change.
This is why we cannot scale to trillions of devices using point-to-point protocols and polling but pub/sub and push does the trick. I don’t know that MQTT will be the thing that wins, but I’m certain whatever wins will be pub/sub for this reason. We’ll need to add topics to DNS or make a parallel global namespace like DNS, and we’ll need to route publications over the Internet. Once we do that, devices and REST will be history.
I believe that once we have some basic problems addresses – like on-boarding devices and a decent dashboard app for the home user, the pub/sub integration will become much more obviously compelling. The problem is that if only the initial implementation is considered – much as the problem statement posed by Johannes posited a single point-to-point connection – pub/sub seems more complicated and it is new whereas REST solves the problem and is well known. But once you begin to consider many-to-many integrations, pub/sub and push becomes the clear winner and the on-ramp for the connection density that delivers on the promise of Internet of Things.
Does it have a chance of winning? Charles Brett at GigaOM wrote:
It would be nice to believe the right solution will win, especially given the cost of today’s mobile data and the wastage consumed by synchronous mobile communications. But don’t hold your breath. History has shown that synchronous is the default, even when asynchronous should be chosen. The danger is that yet again we will not learn from history.
Time will tell.