⬇️ Scan the Sticker, Take the Record: Importing a Unit From a Live QR Code

There are three kinds of QR code the app can print, and only one of them is a pointer. A text code carries the specs as readable text and a JSON code carries them as data, both written onto the sticker itself, so the sticker is finished the moment it comes out of the printer. A live URL code carries neither. It carries an address, and that address only resolves because the app publishes a page for that record and keeps it up to date.

That difference is the whole feature. A sticker with the data printed into it tells you what was true the day it was printed. A sticker with an address on it tells you what is true now — including the service visit somebody logged last Tuesday, on a phone you have never seen.

What happens when the app scans one

The scanner reads the URL, pulls the record id out of the path, and then does two things at once: it looks for that unit in your own database, and it reads the published copy from the cloud.

It reads the cloud even when the unit is already yours. That sounds obvious and it was not: the lookup used to be skipped whenever a local match was found, which meant that every unit anybody had ever received was frozen at the moment it was sent. A unit pushed to a vendor in June, with two service logs added in July, still showed June for ever, and nothing on screen said why.

The id is taken from the sticker rather than from whatever the scan happens to resolve to, which matters more than it sounds. A unit received by push is re-created in your account under your own id, so your copy will match on its serial or its model number rather than on the id printed in the code — and if the id were only captured on the branch that matched by id, the published copy would never be fetched at all.

The two shapes a scan takes

If the unit is not on your device, you get "Found in Cloud", the name and the site, and a note saying that specs, parts, service history and the site address come across and that photos stay with the owner. One button imports it.

If the unit is on your device — under the same id, or as the twin of a unit somebody pushed you — you get the ordinary match dialog with one extra button on it. It reads "Import Updated Info" when the published copy holds something yours does not, and "Check For Updates" when it does not. The button is there either way on purpose: a button that only appears when the comparison found something makes every failure upstream of the comparison look identical to "nothing new".

That is also why the dialog now names which step it reached. "Checked the live code — nothing new to bring in" is a different sentence from "Nothing is published under this code", which is different again from "Could not read the live copy for this code. Check the signal and scan again." Three separate causes hid behind one silence for two days; each has its own line now.

What actually crosses over

The specs, from a fixed list both the first import and the later updates use: name, type, manufacturer, model and serial numbers, floor, unit, location inside the building, address, city, state, voltage, phase, BTU, refrigerant and charge, horsepower, FLA/MCA, MOP, filter size, belt size, capacitor size, install date, manufacture date, warranty expiry, asset tag, last service date and notes.

The parts, with their sizes and their resolved stock. The service history. The spare units. And the building record itself when your device does not have that site yet — because the first version of the import wrote one equipment row and nothing else, so the unit arrived filed under a location name with no address and no contact behind it. It never overwrites a site you already have: that is the record you maintain, and a scan is not the moment to rewrite it.

• ▸ Your building name is never taken. Every part, PM schedule and work order you own is keyed on it, so overwriting it would detach all of them.
• ▸ Photographs never cross over. That was an explicit ruling, and the import dialog says so out loud, because an import that brings everything else and silently skips the pictures reads as broken.
• ▸ Cost, labour hours, labour rate and materials cost are absent from the published copy entirely. The person scanning your sticker might be a competitor; publishing your margin to a smaller audience is the same mistake as publishing it to the world.
• ▸ A site contact and address are withheld if that building has its site information switched off. The toggle governs what leaves the account, so it has to govern this copy too — otherwise switching it off would hide the contact from a page and hand it to an importer.

What it refuses to do, and why that is the interesting part

You cannot import from yourself. Scanning your own sticker reaches a page your own device published, so the page can only ever be the same as your copy or older than it. Leaving that to the comparison would work most of the time and then offer to "update" a unit from its own reflection the moment a published field is derived rather than stored — a last-service date computed from the logs, an address folded in from the building. A teammate is the same account by design, so their scan of your sticker behaves the same way.

Things you deleted do not come back. Deleted parts are matched by id and deleted service logs by their content — the date, the description, the technician — recorded against the unit the delete happened on, because two rooftop units genuinely get the same quarterly PM on the same day from the same tech, and asking that question across the whole device suppressed the log on both. If either list cannot be read, nothing is added at all rather than everything you deleted being handed back; unknown means add nothing.

Nothing arrives twice. A part is recognised by its id, and a published part with no id is skipped rather than added, because nothing could tell it apart from one you already have and it would arrive again on every single scan. A service log with no date is skipped for the same reason: the import has to put something in the date column, so it would write today’s, the stored row would differ from the published one — and differ again tomorrow — and the same visit would be added for ever.

Where the Pro gate actually is

Not on the button. The importable copy of a record is a separate document from the page a sticker resolves to, and the security rules open it only to a reader who is signed in and is themselves Pro. A free account, or a Pro account whose entitlement has not settled yet, is refused by the server; the public page answers instead, with less on it. A modified app gains nothing by skipping the check, because the check is not in the app.

There are two more refusals in front of it, in this order. A Viewer on somebody else’s workspace is stopped first and told why — no amount of entitlement makes a read-only role able to write, and offering them the paywall would be advice they cannot act on, since the subscription belongs to the workspace owner. Then the Pro gate itself, which has three answers rather than two: allow, refuse, and wait. Entitlement reads as false for the first moment of every cold start, and a plain check would eject a paying subscriber who scanned a code two seconds after opening the app.

One honest wrinkle: a technician working on somebody else’s Pro workspace inherits entitlement from the owner, so the app has already decided they are Pro and drawn the button without a padlock — but their own subscription document is not marked Pro, and the rules read that document. The read is refused and the scan falls back to the public page. Rather than quietly comparing against less data and reporting "nothing new", the dialog says so: "Only the public page could be read on this account."

What a free — or logged-out — scan gets

A great deal, and this is the half worth knowing if you are the one printing the stickers. The page a live code points at is world-readable by design. A tenant, a contractor or an inspector with no account and no app points a plain phone camera at the sticker and a browser opens the unit: what it is, where it is, its specs, its service history and its parts.

That page is not a static snapshot either. It renders the stored copy immediately so somebody standing in a plant room is not looking at a spinner, then asks the server to reassemble the record from the live data and folds the result in — and the merge is only ever allowed to improve the page. Nothing may disappear, nothing may be blanked, and a response for a different asset is discarded rather than partially applied.

What a free scan does not get is the import. Reading is free and always will be. Taking somebody else’s record into your own database is the paid part, and the refusal says exactly that: "Reading the page is free — scan it again to view the specs, service history and parts without importing."

When it will not offer you anything

Four cases, and the app names all four rather than shrugging. The code has no live link at all — a text or JSON sticker, or a barcode — so there is nothing to check against. Nothing is published under that code, which is what a retired or deleted unit looks like. The copy could not be read, which is usually signal. Or it was read and there is genuinely nothing new.

There is a fifth worth stating plainly: the importable copy only exists for units published since it shipped. An older sticker still resolves to its page and still imports from that, with less on it than a sticker published today. Re-publishing the unit — which any edit that touches it does — fills the gap.

Do I need Pro to import a unit from a scanned QR code?

Yes. The importable copy of a record can only be read by an account that is signed in and Pro — that is enforced by the database security rules, not by the app — and the import itself is gated again in the app. Reading the page a sticker points at is free and needs no account.

What comes across when I import a unit?

The specs from a fixed list of 28 fields, the parts with their sizes and stock, the service history, the spare units, and the building record if your device does not have that site yet. Photos, costs, labour hours, labour rates and materials costs do not.

Will scanning overwrite the copy I already have?

Only the details you accept, and never your building name — every part, PM schedule and work order you own is keyed on it. Service logs and parts you do not have are added; anything you deleted on purpose is not brought back.

Why does scanning my own sticker never offer an import?

By design. The page was published by your own device, so it can only ever be the same as your copy or older. A teammate shares the same account and gets the same answer.

What does a tenant or a contractor see if they scan the same code?

The unit’s public page in an ordinary browser: what it is, where it is, its specs, its parts and its service history. No app, no account, no login. They cannot import it.

I scanned a code and it said nothing was published under it. Why?

Either the unit was unpublished or deleted, or the sticker is a text or JSON code with no live link. The app distinguishes those from "nothing new to bring in" and from "could not read the live copy", because they are three different problems.

Does the import work offline?

No. It reads a published copy from the cloud, so it needs a connection. Everything the app does with records already on the device — reading them, editing them, logging maintenance, scanning a code to look one up locally — works with no signal.

Why did an older sticker import less than a new one?

The full importable copy is written when a record is published, and it only exists for units published since that shipped. An older sticker resolves to its public page and imports from that. Editing and re-saving the unit republishes it and fills the gap.

Jonathan Curtis

HVAC Technician & Founder · Equipment Tracker Pro

Jonathan Curtis is an HVAC technician and the founder of Equipment Tracker Pro. He built the app to solve real problems he encountered in the field, including the daily frustration of faded nameplates and administrative double-entry.