Connected Devices

A run of bytes, usually a few dozen to about 1500, wrapped with the address it is going to and the address it came from. The network reads the wrapper and never the contents, the way a postal worker reads an envelope and not the letter.

Packets matter here because each one travels alone: one can be lost while its neighbours arrive, one can be delayed, and one can even be delivered twice. Every strange behaviour in this course comes from those three facts. Computer Networks builds packets properly; this course only needs the envelope picture.

A switch closes when a person moves it. A thermostat reads a sensor, compares the number with a target, decides, and moves the switch itself. Reading, comparing and deciding is a program running, and the thing running it is a computer.

The test is whether the behaviour can be changed without changing the parts. A thermostat can be given a new schedule, a new target, even a whole new program. A bare switch cannot. That flexibility is the whole reason to put a chip in, and it is also what a firmware update, much later in this course, is allowed to replace.

Because the battery decides. A chip doing many jobs has to stay awake to see what turns up, and staying awake is the one thing a small battery cannot pay for. A device with one job knows exactly when it has nothing to do, and sleeps.

One job also means one honest answer to the question is it working? A desk computer that is misbehaving has a person in front of it to notice, and a plant sensor has nobody. The fewer things it can be doing, the easier it is for the far end to notice that it is doing nothing. A lot of this course is about noticing exactly that.

A millisecond is a thousandth of a second, written ms, and a blink of an eye is about 150 of them. The numbers in the lab are how long each stage takes on a small wireless board of the kind you would put in a kitchen sensor. They are not evenly sized: the smallest is 2 ms and the largest is 1200.

They matter because a device on a battery pays for time. While any of this is happening the radio is switched on, and a radio that is on draws roughly fifteen thousand times as much current as one that is asleep. Step 11 turns these milliseconds into months of battery life.

The middle of it is, more or less. A browser also resolves a name, opens a connection and checks a certificate. The two ends are different. A browser starts on a machine that is already on a network, so the first three stages happened while you were making tea. And it wants an answer back at once, so a human can read it.

A sensor has to do the joining itself, every time it wakes up, with nobody there to type a password if it goes wrong. And it does not want an answer. It wants to say one short thing and go back to sleep for fifteen minutes. Those two differences produce nearly every design decision in this course.

Because the phone cannot be reached and neither can the device. Both of them sit behind a box that gives them an address usable only inside one building or one mobile network. Neither box lets a stranger start a conversation from outside. Step 4 lets you try it and watch it fail.

The way round it is that both sides dial out to a third machine that does have a reachable address, and that machine passes messages between them. That machine is called a broker, and Steps 5 to 7 are about what it does once it exists.

A number that identifies one machine on a network, written for humans as four smaller numbers with dots between them, such as 192.168.1.42. Anything sent to that number arrives at that machine and nowhere else. Computer Networks builds addresses properly, including why they have structure and how a router uses that structure to decide which way to send a packet.

What matters here is that a device does not own one. It borrows one, for a stated period called a lease, and it has to ask again before the lease runs out. A device that sleeps through the end of its lease wakes up with an address that may now belong to a laptop.

Because it is a conversation, not a message: the device scans the channels for the network it wants, which means listening on each in turn. It then exchanges several frames to prove it knows the password without ever sending the password, which takes four messages of arithmetic on both sides. Only then is it allowed to send anything of its own.

Some of that can be cached. A device that remembers which channel its network was on last time skips most of the scan. Real low-power products do exactly this, and it is the difference between 300 ms and about 90 ms.

It uses the answer it kept. Every answer from the name system arrives with a time to live: how many seconds it may be believed before it must be asked again. Inside that period the device does not ask anybody, so a name server that has fallen over is invisible.

The second lab lets you run exactly that case. It is worth knowing because it produces one of the nastiest field faults there is. A fleet keeps working perfectly for an hour after something important has broken, and then all of it fails at once when the last cached answer expires.

The older numbering scheme, called IPv4, has about four billion addresses in it. That sounded generous in 1981 and ran out around 2011. There are more connected devices than that. The newer scheme, IPv6, has enough for every grain of sand, and where it is deployed a device really can have an address of its own.

It has not fixed this, for two reasons. Deployment is patchy, so a product that relied on it would not work in a lot of houses. And having a reachable address is not the same as being reachable. The firewall in the router, the part whose job is refusing uninvited connections, still refuses them by default, and almost everybody wants it to. The broker is the answer under either scheme.

It can, and it does not help. The public address belongs to the house, not to the device, so the phone would still be knocking on a door with no row in the table behind it. And that address changes: many providers hand out a different one after a reboot or every few days.

There is a family of techniques that make direct connections work anyway. Both sides dial out to a helper at the same moment, so that two rows appear in two tables at once. Video calls use it. It is intricate, it fails on some networks, and it needs the helper anyway, which is why almost no sensor product does it.

It depends who owns the box, and the range is enormous. The standard asks for at least two hours and fourteen minutes for an established connection. Plenty of home routers honour that. Mobile networks, where one public address may be shared by thousands of subscribers, are far less generous, and five minutes is common.

The lab uses five minutes because that is the number a product has to survive. Step 11 shows what it costs: the device must send something, anything, more often than the shortest table timeout in the path, or the way back to it closes.

Asking means one side has to know how to reach the other, has to be awake at the moment the other one asks, and has to answer. Every one of those is a problem for a sensor on a battery behind a router. Publishing means the sensor says its piece when it wants to and goes back to sleep, and whoever cares finds out when they next look.

The technical name for the difference is coupling. Asking couples the two ends: they have to agree on an address, be awake together and stay compatible. Publishing couples both of them to a name instead, which is a much cheaper thing to keep stable.

General to specific, left to right, so that a wildcard part way along means something useful. home/kitchen/temperature lets somebody subscribe to one room. Writing it the other way round, temperature/kitchen/home, would let somebody subscribe to all temperatures everywhere, which nobody wants.

Two things to avoid. Do not put anything in a topic that changes when nothing has really changed, such as a firmware version, because every subscriber then has to be updated. And do not put a value in the topic, as in home/kitchen/temperature/21.4, because a subscriber would have to subscribe to every possible reading to see any of them.

Both messages go to every subscriber, in the order the broker received them, and nothing marks which came from where. The broker does not police topics. This is usually a mistake in the naming, fixed by putting the device's serial number into the topic and letting subscribers use a wildcard when they want the lot.

Occasionally it is deliberate, and useful: several door sensors publishing to one home/doors/opened topic gives a subscriber a single stream of door events without caring how many doors there are.

Because the device cannot tell the two failures apart. If it sends a reading and hears nothing, that could mean the reading never arrived, or that it arrived and the acknowledgement was the packet that got lost. From where the device sits, those look identical.

It has to choose, and the only safe choice is to send again, because losing a reading forever is worse than sending one twice. So it resends, the broker receives a message it has already handed on and has kept no record of, and hands it on again. The duplicate is not a bug in anything. It is the price of a promise made over a link that loses packets, and Reliable Data Transfer is the whole course about that promise.

By making the broker remember. When it receives a message at level 2 it writes down the message number before doing anything else, and answers with a received. If the same number turns up again it recognises it, answers again and does not hand the message on a second time. Only when the device says release does the broker forget the number.

That is four messages for one reading instead of two, and it means the broker has to store something for every message in flight from every device. Level 2 is not a better version of level 1: it is a different trade, and the lab counts both sides of it.

Level 0 for anything that will be replaced by a better version shortly. A temperature every fifteen minutes is the perfect case: losing one costs nothing, because another is coming, and the graph has a small gap in it.

Level 1 for anything where losing the message matters and a repeat can be recognised, which is most things. Level 2 for the small set where a repeat cannot be recognised and would do damage: a meter reading that gets added to a total, a command that spends money. In practice level 2 is rare, because designing the message so a repeat is harmless is usually cheaper than paying for level 2 on every message forever. Step 12 is that design.

By a timer, agreed when the device connects: the device promises to say something at least every so many seconds, and that period is the keepalive. If it has nothing to publish it sends a two-byte ping instead. The broker waits one and a half keepalives, and if nothing has arrived it treats the connection as dead.

So the will is not instant. With a sixty second keepalive the broker declares the device gone ninety seconds after its last word. That delay is a direct consequence of the number you chose, and Step 11 is where choosing it gets expensive.

A disconnect message. One byte of intent that says: I am finishing on purpose, throw the will away. A device that is going to sleep, or being switched off by its owner, sends it and no obituary is published.

Every other ending skips it. A flat battery, a snapped wire, a crash, a router reboot, a phone walking out of range. All of those leave the will in place, and that is precisely the set of events you want to be told about. The lab lets you end the device both ways and see the difference.

Yes, and together they make one of the few tidy patterns in this subject. Publish online to home/kitchen/status with retain set on connecting, and set the will to publish offline to the same topic, also retained. Now that topic always holds the truth, and any subscriber that appears at any time is told at once.

The pattern has a limit worth knowing. It reports whether the broker is hearing from the device, which is not quite the same as whether the device is working. A device whose sensor has failed but whose radio is fine will happily report itself online forever.

A long run of random bits that the device knows and the broker knows, and that nobody else can guess. It might be presented as a password, or as a private key with a certificate around it. What matters here is not the format but the count: how many devices does one of these let you pretend to be.

Random is doing real work in that sentence. A key derived from something predictable, such as a serial number run through a fixed calculation, is one key wearing ten thousand hats. Reading one device tells you the recipe for all of them.

On a lot of hardware, yes. Many chips leave the debug port enabled by default, and the tool to talk to it costs a few pounds. Where the debug port is locked, the flash is often a separate eight-legged chip on the board, and a clip that grips those legs is also a few pounds.

Parts with encrypted flash and a permanently disabled debug port exist and are worth using, but they change the cost of the attack rather than removing it. The rule that survives is the one the lab is about: never let the compromise of one device be the compromise of the fleet.

Because it is worth almost nothing, and only once. It is not a key but a token that says: the unit holding me has not yet been claimed. On first power-up the device presents it, receives a real key of its own, and the token is marked as spent. From then on it opens nothing.

The exposure it leaves is real and it is small. Somebody who reads a code out of a boxed unit before the customer switches it on could claim that one unit. Nobody can claim the fleet, nothing is exposed after first use, and cancelling one code costs a line in a database.

A signature is a number worked out from the document and from a secret that only the signer has. Anybody can check it against a public number, and nobody can produce it without the secret. Change one character of the document and the check fails.

So a certificate says: this name belongs to whoever holds this key, and here is my signature to prove I looked into it. The device carries a short list of signers it was built trusting, called root certificates. The chain from the certificate it was handed has to reach one of them.

Because two of the checks are about dates. A certificate is valid between two moments, and the device compares them with what it thinks the time is. A small board with no battery-backed clock wakes up believing it is the first of January 1970. That is before every certificate on earth was issued, so every one of them looks not yet valid.

The order of operations therefore matters. The device has to learn the time before it can check a certificate. The usual way to learn the time is over the network, which it has not been allowed onto yet. The standard answers are a cheap clock chip with its own coin cell, or an unauthenticated time taken from the network. The second is purely a starting point, never trusted for anything else.

Authorities do not sign server certificates with their root key, because that key is kept offline in a safe. They sign an intermediate certificate with it, and the intermediate signs the servers. So a device has to follow a chain of two or three links to reach something it trusts.

The server is supposed to send the intermediate along with its own certificate. Some are misconfigured and send only their own. Browsers hide this by fetching the missing link themselves or by having seen it before. A small device does neither, so it fails against a server that appears to work perfectly in every browser anybody tries, which makes it a memorable afternoon.

It encrypts the hop between the device and the access point, and only that hop. It is real protection against somebody in the road with no password, and it stops at the router. Everything beyond, across the provider's network and the wider internet, is carried in whatever the application chose.

It also does less than it looks like inside the house. On the older shared-password schemes, anybody who knows the wifi password, which is everybody who has ever been given the wifi password, can decrypt their neighbours' traffic on that network. A guest at a party is inside the fence.

Who you are talking to, and when, and roughly how much. The broker's address and port are on the outside of every packet, because the network needs them to deliver it. The name the device asked for is sent in the clear at the start of the handshake so that a server holding many names knows which certificate to present. And every message's size and timing is visible.

That last one sounds harmless. The second lab shows that it is not, and that the fix costs almost nothing, which is why it is worth doing.

The temperature, no. The pattern, yes. A house's readings say when somebody cooks, when the heating comes on, and when nobody has been home for four days. Researchers have identified which programme people are watching from the traffic of a smart television, and which appliance was switched on from the shape of a power meter's traffic.

The general rule is that data about a home is data about the people in it, and it is worth more to somebody unpleasant than the readings themselves ever are. That is the argument for padding, and for not sending anything you did not need to send.

A measure of how much electrical charge a battery holds, in a form built for this exact sum. A cell of 180 milliamp-hours can supply 1 milliamp for 180 hours, or 180 milliamps for one hour, or 0.03 milliamps for 6000 hours. Divide the capacity by the average current and you get the time.

Average is doing the work. A device is not drawing a steady current: it is asleep at 0.005 milliamps almost all the time and awake at 75 for a fraction of a second. Spread those bursts out over the whole period and you get an average you can divide with, which is what the lab does.

Because the bytes are not what you pay for. Two hundred bytes at the speed the air carries them takes about a quarter of a millisecond. Waking the radio up takes 22 milliseconds and waiting for a reply takes about 90, and both of those happen whether you are sending two bytes or two hundred.

This is worth internalising, because it inverts the instinct. Making messages smaller buys almost nothing. Making them less frequent buys everything. The lab has a slider for the payload, the content bytes of a message. Drag it from 20 to 500 and watch the answer stay the same to the nearest day.

Not on its own. A CR2032 has a fair amount of internal resistance, and pulling tens of milliamps out of one drops its voltage far enough to reset the chip. That is why a device on a coin cell can reboot in a loop while a meter says the cell is nearly full. The 180 milliamp-hours in the model is already the honest figure rather than the number on the packet, for that reason.

The standard fix is a large capacitor across the cell. The cell trickles charge into it slowly, the capacitor supplies the burst, and the cell never sees the peak. The sums in this lab hold once that capacitor is there; without it, a design that looks fine on paper resets every time it tries to transmit.

Everywhere something might be retried, which is everywhere. Pressing a lift button twice does not summon two lifts, because the button is idempotent. A cash machine that dispenses on a repeated request is not, which is why the retry logic in payments is written by people who are paid a lot.

The web has it built into the vocabulary: fetching a page can be repeated safely and submitting a form cannot, which is why a browser warns you before resending one. Same idea, same reason: somewhere underneath, something might send the message again.

Then put a number on it and have the device remember. Every command carries an identifier, and the device keeps a short list of the ones it has already carried out. A command whose identifier is on the list is acknowledged and ignored. That converts any command into a safe one.

It is not free. The list has to survive a reboot, or a device that restarts mid-conversation loses its memory and does the thing again. And it has to be bounded, or it grows forever. Both are solvable, and both are more work than sending a target instead of a nudge, which is why the first thing to try is always the message design.

Yes, on a separate topic, and the report should be the new state rather than a confirmation. Publishing target is now 21 with retain set means the phone's screen is correct whenever it looks, the command loop is closed and a duplicate report is as harmless as a duplicate command.

The pattern is worth naming because it is the one that scales. The phone publishes what it wants, the device publishes what is true, and both are values rather than instructions. Nobody has to keep count of anything, and every message in both directions can be repeated without consequence.

The memory that holds the program when the power is off. It differs from ordinary working memory in two ways that matter here. It keeps its contents without power, which is why the program is there when the device switches on. And it cannot be changed a byte at a time: a region is erased in a block, typically four kilobytes at once, before anything can be written into it.

The erase is the slow part, tens of milliseconds a block, and during it that block holds nothing at all. So there is a real window, repeated for every block, where the old contents have gone and the new ones have not arrived. That window is where an interrupted update does its damage.

Two checks, at two different moments. Before switching over, a checksum: a number worked out from every byte of the image and compared with the number the server said it should be. That catches a truncated or corrupted download. It does not catch a program that downloaded perfectly and crashes on start.

For that there is a second check after switching over. The bootloader starts the new program with a flag saying this is a trial, and the new program has to mark itself as working within its first minute. If it does not, the next start goes back to the old slot. The lab lets you build an update that passes the first check and fails the second.

A signature, the same idea as the certificate in Step 9. The image is signed with a key the manufacturer keeps, the device holds the matching public key, and the bootloader refuses to start anything whose signature does not check out. Without that, an update mechanism is a way for anybody who can reach the device to run their own code on it forever.

The awkward part is what happens to the signing key. It has to be available often enough to sign releases and protected well enough that it cannot be stolen, and if it is stolen, every device already built trusts it. Products that take this seriously keep the key in dedicated hardware and allow more than one key so that one can be retired.

The same simulator as every other lab. A device publishing readings over a link that drops packets at whatever rate you set. A broker applying the rules of whichever quality of service you chose, and a subscriber counting what arrived. The energy panel divides the capacity of the cell you picked by the average current your settings imply.

The reachability line compares your keepalive with the five minute table timeout from Step 4. The update panel runs the same two-slot arithmetic as Step 13 against the flash budget your program size implies.

Mains powered, so battery is not a constraint. Keepalive around 60 seconds, because it has to be reachable from a phone at any moment and the router's table must be kept open. Level 1 for readings and level 1 for commands, with the commands worded as targets so duplicates do not matter. Retain set on both the current temperature and the current target.

A battery-powered window sensor is the opposite in almost every respect. It sleeps, wakes only when the window moves, sends at level 1 and disconnects. It cannot be reached at all between events, and nobody needs to reach it, because there is nothing to command.

Several things, and it is worth knowing which. The link loses packets independently, while real radio loses them in bursts when a microwave oven runs. The broker never falls over and never runs out of storage. It never rejects a connection because ten thousand devices reconnected at once after a power cut, which is a real and vicious failure. Time is exact and a real device's clock drifts.

The energy model assumes the radio comes up in a fixed 22 milliseconds. A real one takes longer when the signal is poor, so a device in a bad spot uses more power for the same work. And there is one device here. A field of five hundred sharing one access point is a different subject. It is the one that decides whether a product works in a block of flats.

Measure a complete exchange, not just the payload. Include headers, handshakes, retransmissions, radio wake time, RAM used by the library and time spent connected. Then test the actual failures: lost replies, duplicate requests, a sleeping peer and a service restart. The protocol name alone does not give those numbers, and a protocol that looks free on the bench can double the radio's waking time in the field.

MQTT 5 is the current OASIS standard used here. CoAP is specified in IETF RFC 7252. Their standards define wire behaviour; a product still needs a policy for authentication, authorization and data retention.

Only if the design makes it one. End-to-end encryption can keep a forwarding gateway from reading application data. A translating gateway must usually read and rewrite messages, so compromise has more consequences. Record that boundary in the threat model, update the gateway, and decide what happens when it is unavailable. A gateway that stores readings during an outage is also where readings are lost when it fails, so its storage needs the same care as the device's own queue.

Define numerical range, precision, missing-value meaning, clock basis and a stable device identity. Give each event a sequence number if duplicates or gaps matter. Store example messages as contract tests. JSON is readable but not automatically well defined; a binary format is compact but not automatically compatible. The contract supplies the discipline. A field that changes meaning is worse than a field that disappears, because every old reader keeps accepting the record and quietly computes the wrong thing with it.

Yes, so use a log or ring buffer that spreads writes across pages. Batch metadata updates and test recovery after power loss during both append and erase. A queue that was never tested against a power cut in mid-write tends to fail on the first winter evening the lights flicker, with the oldest readings as the casualties. The crash-safe storage methods in Embedded Systems apply directly.

A time service estimates clock offset using timestamped exchanges. Variable network delay limits that estimate, so synchronization has an error bound rather than perfect truth. Systems that need tighter timing may add hardware timestamping or a local precision-time network. Always measure the bound under load and after a device has been disconnected. A device that has just woken from a long sleep is the worst case, because its clock has drifted the whole time and its first messages carry the stalest timestamps.

List assets, entry points, trust boundaries and plausible attackers. Then name a control and a test for each important threat. Unique keys limit fleet compromise, and an access control list (ACL) blocks cross-device topics. Rate limits bound broker work, signed updates block modified firmware, and rollback and recovery handle a bad but correctly signed release. The rate limit deserves the same attention as the topic rules, because a compromised device that may only publish its own telemetry can still bury the broker in it.

State the affected cohort, time window, measured symptom and runbook. “Connection success fell from 99.8% to 93.1% for hardware B after firmware 7.2” is actionable. “IoT errors increased” is not. Keep metric labels bounded; a separate label for every device can overload the monitoring system. The runbook line matters because the person woken at three in the morning is rarely the person who wrote the release, and the alert is their only briefing.

Commissioning moves a new device from factory identity into a particular home or fabric, gives it operational credentials and assigns access. Test first setup, adding a second administrator, removing an administrator, factory reset and transfer to a new owner. A successful radio join is only one part of that lifecycle. The ownership transfer is the test most products fail first, because the factory reset has to remove every credential the old household ever granted.

Read the current specifications and release notes at the Connectivity Standards Alliance and Thread Group.

Removing a name may not be enough. A stable device identifier, precise location or distinctive activity pattern can link records back to a person or place. Test likely combinations, rotate identifiers where continuity is unnecessary, and keep the re- identification key separate when a product needs one for a stated purpose. A backup is the copy most deletion schedules forget, and a person who asked to be erased is entitled to be erased from the copies as well.

Treat the agent as an untrusted client. Give it narrow tools with typed arguments and least-privilege credentials. Require confirmation for high-consequence actions, make repeated calls idempotent, cap rate and cost, and keep a deterministic safe state when the model is unavailable. The fallback deserves as much testing as the model, because the day the model is unavailable is usually the day something else is already going wrong. Text from a sensor, document or web page is data, not an instruction allowed to change those rules.

TinyML covers fitting and measuring small models. The release gate here adds system evidence: representative data, false-alarm cost, memory and energy budget, signed model update, canary monitoring, rollback and a non-ML fallback.