[From the last episode: We saw that messages are at the heart of machine-to-machine communication.]

OK, so we know that, in order to say something to another machine, a machine must send a message. But what, exactly, is a message?

First of all, there’s no one answer to that. It’s an “it depends” thing – different messages for different purposes. But we can generalize so that you get a flavor. As with most of this stuff, there are everyday analogs that can help illuminate what the machinesIn our context, a machine is anything that isn't human (or living). That includes electronic equipment like computers and phones. are doing.

Central Command

Let’s start at the most obvious level, which corresponds to the Application layer of our communication stack. Let’s say that we’re trying to tell a thermostat to change the temperature setting from whatever it currently is to 72 degrees Fahrenheit.

Well, the first thing we need is some kind of language, or syntax, that allows us to do that. And that language depends on the systemsThis is a very generic term for any collection of components that, all together, can do something. Systems can be built from subsystems. Examples are your cell phone; your computer; the radio in your car; anything that seems like a "whole." – different ones might have different ways of doing it (which would make for an interop problem if you tried to connect two different systems – they wouldn’t understand each other).

What we need is a command that the thermostat will understand. How do we know what the thermostat will understand? This is where reading the manual helps. As we saw earlier, each device like that will have a so-called Application Programming InterfaceCommands or functions that let a programmer control some other program or object or thing, or get data from some object, without knowing the details of how it works., or API. That interfaceThe point where two different domains meet, like a border. For example, a wall plug could be thought of as the interface between the power grid and the appliances you plug in. hides how the internals of the thermostat works, but it tells you how to talk to it.

We saw some examples of this back when discussing profiles, except  that, in that case, we saw examples of commands for a fan. There are lots of possibilities for a thermostat; let’s say that the command for our thermostat is, “set.Temp 72”. What we have is a two-part statement: the action (“set temperature”) and the value, or parameter, that goes with the action (“72 degrees”). (If it’s a fancier interface, it might also need another parameter – say, “C” or “F” to specify whether “72” is in degrees Celsius or Fahrenheit… Don’t want to get that wrong!)

Packet Seed

What we’re doing here is building up a packetA group of bits being sent from one place to another. How big the group is may vary depending on what kind of packet it is. Long messages -- like an email -- will typically be broken up into many packets, each of which travels independently until it gets to the destination, where they're reassembled into the email.. You can think of a packet as being like a letter in an envelope. It’s more than just the basic message (in this case, the temperature command); it also has information about the destination address and potentially many other things. So we start with the command and value, which, together, are called the payloadThe main contents of a message. Using an analogy, when you receive a letter in the mail, the letter itself is the payload; the envelope is merely a carrier.. This is the thing you’re trying to communicate to the other machine; everything else is just management stuff (like the address).

The payload will look something like this. Notice that I’ve given both a vague, abstract picture and then tried to make it more concrete. What we’re doing here is building up a string of bitsThe smallest unit of information. It is a shortened form of "binary digit." Since it's binary, it can have only two values -- typically 0 and 1. with a specific meaning. So I made up a numeric code for the command, and then, for the value, I used the binaryA base-2 counting system (rather than the base-10 system we usually use). Digits can be 0 or 1. value for “72.”

Why the numeric code? Because, in the end, machines talk 1s and 0s. You might be able to send text over instead of a code, but, eventually, 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. somewhere – on the sending or receiving end – will turn the command into a code. Cuz that’s what machines like.

This takes care of what we need in the application layer, but you may recall that a message will travel down the stackRelated to communications: A way of organizing parts of a complicated process (like communications) so that any task relies on tasks below it and feeds the tasks above it. Related to computing: A place in memory where you store “where was I?” information when you go from, say, one function into another. Before starting a new function, you store where you were in the old one so that, when the new function ends and you’re back in the old one, you can figure out where you were and continue on. to the bottom, then get physically transmitted to the other machine, and then travel back up the stack to the application layer on the other machine. Well, at each layer, you may get some more management information; the details depend on what standardA way of doing something specific that has been agreed by multiple parties in an official manner. Some "standards" aren't official standards; the best ones have been established in an open fashion, where anyone with an interest can contribute and where large companies can't push little companies around. you’re using for communication.

In the next post, we look at how a packet moves through the stacks from starting point to destination.