# When the datasheet link in the device registry is dead

> Every product and datasheet link in the public LoRaWAN device registry, requested: 213 of 1,568 are gone, and a wall is not a break.

Source: https://plantroomlabs.com/notes/when-the-datasheet-link-is-dead/  
Published: 2026-10-16 (16 October 2026) · Plantroom Labs  
Topics: LoRaWAN, Measurement, Commissioning

The registry entry for a sensor carries two links: the product page and the datasheet. Across 1,568 of them, 13.6% answer 404 — and the person who finds out is holding the device.

## The link is part of the device definition

A LoRaWAN device arrives on a project as a line in somebody else's repository. The public device registry keeps one folder per vendor and one file per model, and each file names two URLs: `productURL` and `dataSheetURL`. The decoder in that file [is the integration](https://plantroomlabs.com/notes/reading-a-lorawan-payload-decoder/), and those two links are how anyone checks what the decoder is supposed to mean — which byte is the battery, what the invalid marker is, whether the temperature is signed.

So they are not background reading. On a commissioning morning they are the route to what a frame means, and a dead one is found at the panel by the person holding the sensor. This note is a measurement of how often that happens, and of how to tell a link that is gone from a host that simply will not talk to a script.

## What was requested, and what was not

All of it. 2,043 link values across 1,121 device files in 137 vendor folders — 1,117 `productURL` and 926 `dataSheetURL` — pointing at 1,568 distinct URLs on 183 hosts. The gap between those two counts is the first thing worth knowing: device files share links, so one dead URL takes several models down with it.

Each URL got a HEAD first. Anything that did not answer 200 straight away got a GET under a browser user agent and then a GET again, so the 316 URLs that failed once were each asked three times before anything was written down. Nothing was logged into, no `robots` directive was overridden, and no host was asked faster than one request at a time.

> **A dead link is a defect. A refused request is not.** 50 URLs on 12 hosts came back as an anti-automation wall — 403, 429, 451, 503. Those hosts serve their documents to people perfectly well; what they decline is a script, which is their right. They are counted and named as walls and they appear in none of the figures below. A link checker that scores a wall as a break reports a defect to somebody who does not have one, and is the reason most link reports get ignored.

## 213 of 1,568

**213 URLs — 13.6% — answer 404 or 410 three times from a host that is up.** Because files share links, that is 264 broken references in 202 device files, spread across 55 of the 137 vendors. 138 of the references are `productURL` and 126 are `dataSheetURL`; 93 of the dead URLs end in `.pdf`.

62 files have *both* of their links dead at once, in 19 vendors. For those models the registry offers no product page and no datasheet: an engineer who finds the device there has been handed a decoder and nothing to check it against. The heaviest single vendor folder carries 30 dead references on its own.

Three groups are kept out of that number because they are not broken links. 44 URLs on 10 hosts have no host left to answer — DNS or connection failure — which is a vendor that has gone rather than a link that has broken. 4 answered with something that is neither 200 nor 404: a redirect loop, a 500, a 520. 5 are left deliberately unjudged, and the next-but-one section says why. 1,252 URLs answer 200.

## Why a 404 on its own is not a finding

Any script can collect 404s. What makes one reportable is knowing that the host would have answered if the document were there, and that takes two controls per host, requested in the same pass as the link itself:

- **The host's own root.** If that is down or walled, every 404 under it is about us, not about them.
- **An invented path on the same host** — a path nothing should ever serve. It has to come back 404. A host with a catch-all that answers 200 for everything will make a dead datasheet look alive, and a host that answers 404 for *everything* including its own live pages will make live ones look dead.
Then there is a third, stronger control that only exists because the subject is a registry: other URLs *from the same registry files*, on the same host, answering 200. That proves the host serves this kind of path, to us, today. For 21 of the 55 vendors no such URL exists — the host holding the dead link serves nothing else the registry names — so those were left in the counts and nothing was reported to those vendors. A finding you cannot control is a guess with a number on it.

## Six shapes a dead link comes in

- **A 404 beside a live sibling on the identical path.** 36 of the dead URLs sit in a directory, on 12 hosts, that serves other registry URLs at 200 — same folder, same naming convention, one file present and the one next to it absent. This is the cleanest thing in the whole measurement to report, because nothing about the path, the host or the crawler can explain it.
- **A 200 that lands on the front page.** 14 URLs on 5 hosts answer 200 after redirecting to the host's root. A checker counting status codes calls them fine; a reader gets a home page and no datasheet. More broadly, 306 of the 200s land on a URL other than the one asked for. Most are a trailing slash or an http-to-https hop, and the few that land on a different model's page are the ones worth the time.
- **An expired download token.** Some datasheets are not files but calls to a document API, with a token in the query string. The document is still there; the token is not valid any more. From outside, that is indistinguishable from a deletion, which is why the 5 URLs of that shape here carry no verdict at all.
- **A URI that is legal and is not a URL.** 1 value in the whole registry is not an http address: it is a browser-extension URI with a real https URL stuck on the end — what a PDF viewer extension shows in the address bar, copied and pasted. It is a well-formed URI, which is what schema validation checks, and it resolves for nobody. The https URL inside it is dead too.
- **A deliberate 410.** 3 URLs answer 410 Gone rather than 404 — a host saying the document was withdrawn on purpose. Rarer than it should be, and far more useful to the reader than a 404.
- **A link that resolves and should still be fixed.** 366 of the registry's URLs — 23.3% — are written as plain `http`. Most of those hosts redirect to https, so a browser ends up in the right place, but the value in the file is still the insecure form: the first request goes out in clear, and anything that fetches these links without following redirects gets a plaintext answer or none.

## Doing this to the device list on your own project

The registry is one artefact. The same check pays on a bill of materials, a supplier folder or an O&M manual's appendix, and the order below is the order it pays in:

- **Treat the datasheet as a deliverable, not a link.** At selection time take the file, record its byte count and the date, and hand that over with the job. A link is somebody else's hosting decision; a PDF in the handover folder is yours.
- **Compare the landing URL with the one you asked for.** Status codes alone miss 14 of these and a redirect to the root is the commonest quiet failure.
- **Request the two controls before you report anything.** The root and an invented path, in the same run, from the same machine. One line of code each, and they are the difference between a report that gets acted on and one that gets argued with.
- **Obey the wall.** A refusal is an answer about your crawler, not about their documents. Record it as such and move on.
- **Re-run it on a clock.** 13.6% is one morning's answer. Vendors reorganise their sites far more often than they update other people's files, which is exactly why this number exists.
No vendor is named above, and that is deliberate. Where a dead link is a defect we can stand behind — file, field, both controls, a live replacement where one could be found — it goes to that vendor first, which is still working its way through the 55. A reader gets nothing out of the names, and the vendor gets a fair chance to fix the file. What is published is the record: the pseudonymous row-per-link measurement lives in this site's repository, every figure above is re-derived from it when the site is built, and a figure that stops matching fails the build rather than ageing quietly on the page.

This is the kind of groundwork behind [a LoRaWAN integration](https://plantroomlabs.com/services/lorawan-integration/) that is still supportable in two years, and the same instinct we bring to [an integration audit](https://plantroomlabs.com/services/integration-audit/): measure the artefact in front of you, control the measurement, and report only what survives both.