Blog

The 2026 IoT Bottleneck Isn’t the Radio — It’s the Clipboard

Posted on by Support

Every year the IoT press picks a hero technology. In 2026 it’s been Bluetooth 6.0 Channel Sounding, BLE 5.1 AoA locators getting genuinely cheap, UWB tags at ten-centimeter accuracy, and LoRaWAN quietly passing 125 million devices. All of that is real, and none of it is what sinks most projects.

What sinks projects is the part between the purchase order and the first useful dashboard. Someone has to walk a building with a tablet, name 600 tags, get the advertising intervals right, find the three gateways that won’t talk to the network, and then do it again six months later when somebody decides the battery life isn’t good enough.

That work has a name — commissioning — and in 2026 it’s the scarcest thing in the whole stack. If you sell or spec IoT hardware, this is the constraint you’re actually designing against.

The industry finally started counting the human hours

In October 2026, UK industry publication Talking IoT argued something that should make every hardware vendor uncomfortable: industrial IoT projects should be quoted in engineer-days per thousand tags, not in platform licences. Their own planning range is roughly 45 to 90 engineer-days per thousand tags, split across instrument survey, naming conventions, alarm rationalisation and network segmentation. On a 5,000-tag site, that’s 225 to 450 engineer-days before anybody sees a trend line.

The same piece points at the reason: the people who do this work are hard to hire. Uptime Institute’s 16th annual survey, published in July 2026, found more than half of its 800-plus respondents struggling to find qualified candidates. When the labour is scarce and the tag count is going up, every hour you shave off per device compounds.

And the tag counts really are going up. Morrisons committed to 10.8 million electronic shelf labels across 497 UK stores, with the rollout landing in early 2026 (Retail TouchPoints). Nobody installs ten million of anything with a clipboard and good intentions. At that scale, provisioning stops being an installation detail and becomes the product.

What commissioning actually means for beacons and gateways

It’s not plugging things in. It’s deciding, per device:

  • Identity. Which UUID, major and minor — or Eddystone namespace and instance — makes this tag belong to zone 4, aisle 12, shelf B? Get it wrong and your software sees a perfectly healthy tag in the wrong place.
  • Timing. Advertising interval and TX power. They determine battery life, scan reliability and, if you run AoA locators, the actual angle measurements. One value, three consequences.
  • Behaviour. Tamper sensitivity, temperature thresholds, when a sensor tag should shout versus stay quiet.
  • Network. Broker address, credentials, TLS, filter rules, which gateway covers which zone.

Every one of those is a decision someone makes late, after the hardware is already on site. That’s the trap. The hardware arrives configured with factory defaults, the site reality differs from the site plan, and suddenly you’re re-flashing devices by hand in a building with no mobile signal.

Where the hardware can actually carry its weight

This is the part I find interesting, because it’s the least glamorous spec sheet work and the most useful. KKM’s Bluetooth gateways — the KG01 for outdoor and the KG02 for indoor — were clearly designed by people who have been shouted at in a car park. A few examples:

Bulk parameter writes from your own cloud. The gateway can push multiple beacon parameters down in a single command: TX power, advertising interval, iBeacon UUID/major/minor, Eddystone namespace and instance, lock password. Not one message per field, and not a technician with a phone. You send it from your platform, the gateway handles it over the air.

Auto-rollback when a push goes wrong. This is the detail I’d put on the box. Change a gateway’s config remotely, it reboots, then it checks whether it can still reach your cloud. If the new settings don’t connect, it reverts to the last working configuration on its own and comes back up. The alternative is a site visit — and at forty gateways across six sites, that’s a schedule problem, not a support ticket.

Offline buffering. KG01 keeps data on board when the network drops and uploads it when the link returns. Commissioning failures and network failures look identical in a dashboard with holes in it. Buffering means a bad week doesn’t become a data gap you have to explain to an auditor.

Scan capacity as a provisioning feature. KG01 handles 300-plus beacons per second, KG02 around 200. That headroom is what lets you deploy at a realistic density instead of adding a gateway every time the tag count goes up. It also means the difference between “this zone is covered” and “this zone is covered twice, once badly.”

NFC on the LoRaWAN side. KKM’s LoRaWAN sensor node is configured over NFC, which sounds like a small thing until you’ve done it. Tap a phone or a handheld against the enclosure, write the config, move on. No opening the case, no pairing ritual, no laptop. The same device runs EU868 or US915, Class A, one or two external temperature probes, −30°C to +85°C, with OTA firmware updates so a fix doesn’t require a ladder.

Then there are the tags themselves. The S8 anti-tamper beacon is 30 × 48 × 8 mm and 12 grams, IP65, three years on a replaceable CR2450, and it logs up to 60,000 tamper events locally. The K6 sensor beacon runs up to eight years on an ER14505 and broadcasts temperature to ±0.3°C. Both take their parameters from an app or the gateway — which matters, because it means the same field technician who mounts them can also re-point them.

The AoA and UWB angle nobody mentions in the demo

If you’re building on BLE 5.1 AoA this year, your advertising interval isn’t a battery setting anymore — it’s a positioning parameter. Change it after the locator array has been calibrated and your angles drift, your accuracy numbers stop matching the acceptance test, and the integrator has to redo the survey. That’s a month, not a firmware tweak.

Same story with UWB. The tags are the easy half. The anchors have to go in the right places, with line of sight, and the tag firmware has to be pinned to a known version before anyone signs off. The moment you have more than a couple of dozen devices, “we’ll set it up on site” becomes the most expensive sentence in the project.

Centralised, versioned configuration isn’t a nice-to-have at that point. It’s the only way to keep a deployment reproducible.

Where KKM stops, on purpose

Here’s the boundary, and it’s deliberate: KKM builds hardware. No platform, no dashboard, no cloud account you’re obliged to keep paying for.

The gateway is a pipe. It scans BLE traffic, then sends it over MQTT or HTTPS to your broker — on-prem, AWS, Azure, whatever you already run — with TLS 1.2, PoE or 5V DC, Wi-Fi, Ethernet or optional LTE, and GPS if you need it on the cellular variant. Your platform does the naming logic, the zone mapping, the alerts, the dashboards. KKM supplies API and SDK documentation, and for custom work, schematics so your team can write its own firmware.

That division is the reason the commissioning conversation works at all. Your tag dictionary and alarm philosophy stay yours. We just make sure the hardware takes orders from your system instead of from a vendor portal.

What it looks like on a real rollout

A composite of the kind of deployment integrators describe, with names changed: a pharma distributor fitting out six distribution sites, 1,400 sensor and anti-tamper tags in total with 40 gateways.

Phase one went in at the largest site — 220 tags, eight gateways — and hit exactly the problems you’d predict. Two zones had overlapping coverage and produced duplicate reads. A batch of tags went out at a one-second advertising interval because the factory default was never changed, and battery projections dropped by more than half. One gateway lost its cloud connection after a config change and sat offline over a weekend.

The fix wasn’t new hardware. It was moving the decisions into the client’s platform and letting the hardware execute them:

  • Zone naming moved into the distributor’s own asset system, then got pushed out through the gateway in bulk instead of being typed into an app on site.
  • The interval change — one second to three — went out fleet-wide as a single command, which pushed projected battery life back past the five-year mark without touching a device by hand.
  • Filter rules on the gateways killed the duplicate reads in the overlapping zones.
  • The offline gateway became a non-event after auto-rollback was enabled: bad config, reboot, revert, back online, nobody drove anywhere.

The number that moved most wasn’t installation time. It was rework — the second and third visits to the same rack. That’s the cost that never shows up in a project plan, and it’s the one commissioning labour shortages make unaffordable.

Five questions to ask before you buy hardware in 2026

  1. Can your cloud set multiple parameters in one command? If it’s one field per message, you’ve just built a manual process with extra steps.
  2. Does the gateway fail safe? Ask what happens when a remote config push doesn’t work. “Someone goes on site” is the answer you don’t want.
  3. Is NFC or OTA configuration real, or a line on a slide? Ask for the workflow, not the feature name.
  4. Does it talk to your broker or only to theirs? MQTT/HTTPS with TLS into your own infrastructure, or it’s not your data.
  5. Does the battery life survive your settings? Datasheet years assume a specific interval and TX power. Do the arithmetic with yours before you commit to a five-year replacement cycle.

The radio was never the hard part. In 2026 the differentiator is how little field work your hardware demands — because the people who’d do that work are the ones nobody can hire.

If you’re spec’ing a rollout this year, tell us what you’re building. KKM has been making beacons, gateways and LoRaWAN nodes since 2008, and we’re happy to talk about the boring parts.

Sources

Support