[From the last episode: we looked at the notion of idempotenceA property of a command or operation such that doing it once or more than once yields the same result. and why it matters for the IoT]

Here’s a question: if IoTThe Internet of Things. A broad term covering many different applications where "things"  are interconnected through the internet. devices are going to talk to each other and the cloudA generic phrase referring to large numbers of computers located somewhere far away and accessed over the internet. For the IoT, computing may be local, done in the same system or building, or in the cloud, with data shipped up to the cloud and then the result shipped back down., they have to do so based on some kind of rules. Like, “If the temperature falls below 68 degrees F, then turn the heater on.” And, of course, there are many more interesting things that devices do that work based upon an internal program. In fact, that’s why being able to update your device is important: that program may need changing.

But those programs cover a lot of ground – basic stuff, like how to connect to the cloud and securityRefers to whether or not IoT devices or data are protected from unauthorized viewers. and all kinds of housekeeping issues. It’s not all about the rules. In fact, sometimes it’s the cloud that handles the rules. So how are these things programmed, whether on the device or in the cloud?

This is another topic about abstractionFor our purposes, it’s the removal of all unnecessary details, leaving only what’s required for operation.: how much detail does a developer want to program? There are some IoT cloud setups that give the “programmers” high-level ways to create so-called “business rulesRules that say, "if this happens, then do that." Like, "if the ground is too dry, then turn on the sprinkler."” – like when to turn on the heater. That’s probably as abstract as you can get, and it’s really not programming in any serious way.

But there are things that need programming, and there are two fundamentally different ways to approach the problem depending on how abstract you want to be. Frankly, these two approaches largely reflect completely different tech communities: folks who design low-level hardwareIn this context, "hardware" refers to functions in an IoT device that are built into a silicon chip or some other dedicated component. It's distinct from "software," which refers to instructions running on a processor. devices and folks who program for the web.

To Cook or Not to Cook

Let’s step back for a sec for a completely unrelated analogy. Let’s define two different groups of people: those who have the time for and interest in cooking from scratch and those who simply need to fill their bellies to continue on.

• People who cook get complete control over what’s in the food. They can pick fresh from the garden or from their favorite farm stand if they have either. They can select the meat they want to use. They can season and spice to their own taste.
• The other group can get food that’s mostly pre-cooked or prepped delivered to their homes, where they can assemble and heat. No low-level fiddly operations; just a few easy steps and boom! – you’re eating. The low-level details have been taken care of for you – but you also have no control over them.

This is exactly the way it can be with programming, and there are two IoT communications protocolsAn agreed way of doing something. Like a convention, except that protocols tend to be related to processes. that reflect this duality. They’re called MQTTA lightweight transport protocol for Layer 4; may be more appropriate for IoT equipment. and CoAPA communications protocol that uses the RESTful approach for small systems such as those used for the IoT.. MQTT tends to follow the home chef model, while CoAP is closer to the “I just want to eat” model. And they tend to be used by programmers from different communities.

C vs. REST

On the detailed side you have MQTT. This is more likely to appeal to programmers that do every detail – often in an old, reliable, completely ubiquitous language called CA programming language that gives low-level control of all the details.. Yep, just C. C let’s you do pretty much anything, and it’s very frequently used by people writing programs for devices that have microprocessorsA computer chip that does computing work for a computer. It may do general work (like in your home computer) or it may do specialized work (like some of the processors in your smartphone). in them.

But having that level of control means that you have to take care of all of the details yourself. And there are lots of details! Not only that, you can get yourself in trouble if you screw up or don’t know what you’re doing – there’s no protection. Just like when cooking, if you take on the duty of seasoning your food, you might accidentally use a tablespoon of salt instead of a teaspoon. You got the control; you can also get into trouble.

The other kind of programming uses a model referred to as REST, and it’s born out of web programming. It’s much higher level, and there are really only four different instructions you can use. You can still do a lot of things with those instructions, but it gives you nowhere near the control and detail that C gives you. Nor the risk of screwing up as badly.

C programmers are more likely to go with MQTT for machineIn our context, a machine is anything that isn't human (or living). That includes electronic equipment like computers and phones. communication; REST (or some call the adjectival form RESTfulA way of programming that has evolved out of web programming, and it’s more abstract than other older languages like C.) programmers are more likely to use CoAP. That’s an over-simplification, but hopefully you get the gist.

Again with the Abstraction!

There’s always a balance to be struck between low-level access and efficiency. When cooking, if you’re making breakfast, you might toast some bread. If you really want control, you’d bake that bread yourself. Unless you happen to like doing that (which, as it turns out, I do), there’s really no reason to. There are lots of good bread options readily available, so, in this day and age, no one has to bake bread. We’ve abstracted that above the flour and other ingredients you’d otherwise use. Likewise with sewing and making your own clothes: some like to; most don’t.

The same thing happens in tech. In the early days, people build things from the only “basic ingredients” available: low-level stuff. Individual transistors if you’re designing a computer chipAn electronic device made on a piece of silicon. These days, it could also involve a mechanical chip, but, to the outside world, everything looks electronic. The chip is usually in some kind of package; that package might contain multiple chips. "Integrated circuit," and "IC" mean the same thing, but refer only to electronic chips, not mechanical chips.; low-level softwareIn this context, "software" refers to functions in an IoT device that are implemented by running instructions through some kind of processor. It's distinct from "hardware," where functions are built into a silicon chip or some other component. if you’re programming. But as technologies mature, engineers start to build blocks of things that they or others can reuse.

• There are entire businesses selling pre-designed circuits that you can buy and include in a computer chip.
• There is open-source software that you can download off the web for free and use as is or modify to your heart’s content. You can also buy software modules.
• There are pre-built circuit boards that you can buy and plug a few things into to make them work without having to design your own board.

This kind of abstraction is very much a thing in IoTland. The guy making a thermostat just wants it to work without having to get a new college degree to make it happen. That’s where abstraction is really important. It’s just like the busy person who doesn’t like to cook or sew or whatever. Yes, they could learn to do it themselves, but why would they do that if they don’t love the actual process? There’s no reason to.

This isn’t to say that, between MQTT and CoAP, one is better than the other. For those of you reading this, it’s more about knowing that there are different levels of abstraction available to the folks designing your gadgets, and different communities that may develop them.