Running the front door of a stone building where the wifi drops out

What happens at the door when the network disappears?

Nothing, if you prepared. Before opening, the device downloads a signed manifest for the session: every credential that should be admitted, in a form it can check locally. From then on each scan is validated against that file with no network call at all, which is why a cellar, a chapel or a thick-walled gatehouse is not a problem the way it is for a system that asks a server on every visitor.

When the device gets signal again it uploads its log. A log uploaded twice applies once — the duplicates are counted and discarded rather than admitting anybody twice — so an unreliable connection at the end of the day cannot inflate your attendance figures.

How do two entrances stay in agreement?

They do not, in real time, and the design is honest about that. Two devices out of contact cannot agree about who has already walked in, so bindro records rather than refuses: a visitor admitted at the main door and then scanned at the garden gate produces a second record, flagged as a conflict, that you read afterwards in the console.

That is the right trade for a museum. Refusing at the second door would mean turning away a real visitor because two devices had not spoken, and the failure mode of recording is a queue of things to look at rather than an argument at the gate. If the conflict list is long every day, the answer is usually one entrance scanning and the other checking names.

Is there a bindro scanner app to install?

No, and this is the thing to know before you buy hardware. The offline door is an API: a manifest endpoint, a replay endpoint and a conflicts endpoint, meant to be driven by a device somebody sets up for you. There is no app in a store, and no configuration screen that turns a tablet into a scanner.

What the console gives you without any of that is a searchable visitor list for the session with a tap-to-admit button, and a day-of page showing what has sold and who has arrived. On a normal Saturday with signal at the desk, that IS the door — the offline machinery matters when the signal is not there, or when a second entrance has none at all.

What about re-entry, and members with passes?

Re-entry is allowed here and the door performs it. A visitor coming back through the entrance that admitted them is scanned in again as a return, with the time they first arrived on the screen; the same code at a different entrance while they are already inside reads as already used, and names the one that used it. A scan at a later point on your route counts as progress along it rather than a return. If your rule is the opposite of ours, the front desk enforces it — but "back in until four with the same code" is what the scanner does on its own.

A season pass behaves properly offline, which is the part that matters for members: the pass holder appears on the manifest for every session its event covers, so a device with no signal admits them without having to ask anybody. Attendance stays per-session either way: a pass counts once at each date however many times it is scanned that day, so re-entry never inflates the figure the museum reports.

What should the front desk do when a code will not scan?

Search the list and admit by hand. Manual check-in is on every plan and is not a workaround: it is the same record, made by a person, and it counts identically in the attendance figures and the board report. A visitor with a flat phone, a garbled forward or a printout that will not read is admitted in a few seconds.

The thing not to do is wave people through uncounted. Attendance is what the quarterly funder report is built from, so an unscanned visitor is a missing number in a document somebody will read later — and, if they were a member, a missing piece of the evidence that the membership scheme is worth running.