When the datasheet link in the device registry is dead

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, 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.

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.

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.

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.

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 that is still supportable in two years, and the same instinct we bring to an integration audit: measure the artefact in front of you, control the measurement, and report only what survives both.