An AI edge computer that lives on a property closet shelf has no keyboard, no monitor, no SSH. Here is what replaces them.

Page one is a hardware catalog. NVIDIA Jetson Orin, Advantech MIC and UNO, Dell NativeEdge, Seeed reTerminal, Lenovo ThinkEdge, BrainChip Akida, and Supermicro edge nodes. Every result lists TOPS, thermal envelope in watts, memory, storage, PoE support, and a chart of I/O ports. That is correct but incomplete for a commercial property install. The catalog assumes the buyer is an OEM, a systems integrator, or a robotics team with a dev laptop and SSH keys. It does not describe the install UX on the device itself. A property maintenance tech with a ladder, a phone, and 2 minutes is not the persona those pages were written for.

Three things that the Jetson module datasheet cannot answer. The box sits on a dusty shelf above an already-running DVR. There is no keyboard or monitor plugged in and there never will be. And the human who installs it is a property manager, a leasing agent, or a maintenance tech, not a developer. Everything the installer needs has to surface on the device itself, through its own power LED, its own chassis, and a QR code the tech scans with their phone. SSH is not in the install path. A serial cable is not in the install path. A screen is not in the install path.

A single ASCII word in the file /run/cyrano/boot_phase. The file is rewritten by init scripts as the unit passes through six states: halt, power, link, model_load, detector_warm, active. halt means the unit is off. power means the SoC came up, kernel booted, rootfs mounted. link means DHCP got a lease and the captive portal is listening on mDNS. model_load means the on-device weights under /var/lib/cyrano/models/ finished loading into memory. detector_warm means a first forward pass completed without error. active means the HDMI capture loop is producing frames at the configured cadence. The file is one line, no quotes, no JSON, so even a tech on a phone shell can read it.

Four visible codes on a single multicolor LED, driven by /etc/cyrano/led.rules. L0 is solid red, shown while boot_phase is halt or the unit just lost power. L1 is slow amber pulse, shown during power and link, while DHCP and mDNS are coming up. L2 is fast amber pulse, shown during model_load, when the weights file at /var/lib/cyrano/models/detector.onnx is mmap-ing into memory and the classifier is deserializing. L3 is blue pulse, shown during detector_warm, after the first forward pass lands. L4 is blue solid, shown during active, the steady-state running condition. A fifth code, L5 blue double-pulse, appears only while a drain worker is flushing the outbox after a WAN outage; a tech on the phone can describe it without knowing what the outbox is.

The sticker is printed at the factory and shipped with the unit. It contains three things. The device_id (for example cy-8F3A21), a one-time binding token (a short string scoped to the unit's serial), and a mDNS URL of the form http://cy-8F3A21.local/setup. Scanning the sticker with any phone camera opens the captive portal hosted by the unit itself on the local network. The portal takes the account owner's email, a WiFi SSID and password if the unit is on wireless, and the physical address of the property. Submit writes the binding to /var/lib/cyrano/provisioning/status.json on the unit and POSTs a bind event to the cloud once the uplink is available. No app, no installer account, no SSH.

The unit falls back to a self-hosted WiFi AP named cy-setup-<serial> with a default password printed on the same sticker. The tech joins that AP with their phone, the phone's auto-captive-portal detection opens http://cy-<serial>.local/setup against the unit's local address, and the flow is identical. Once the tech enters real WiFi credentials, the unit writes them to /var/lib/cyrano/provisioning/wifi.conf, drops the setup AP, joins the real network, and continues the boot_phase sequence from link. The whole fallback adds roughly 90 seconds to the install.

Measured on a production 16-camera property with a cold boot: boot_phase=power reached in roughly 12 seconds (SoC + kernel + rootfs). link in roughly 20 seconds (DHCP lease, captive portal listener up, mDNS advertised). model_load in roughly 45 seconds (detector and layout-classifier weights mmap). detector_warm in roughly 60 seconds (first forward pass on the current HDMI frame). active around 75 seconds. Under 2 minutes from a cold plug. The QR binding runs in parallel with model_load on the tech's phone, so the end-to-end install including the portal form is commonly under 3 minutes.

Because /run is tmpfs. The boot_phase file is deliberately ephemeral; it reflects the current runtime, not the last known state. On a power cut it vanishes with the rest of /run and is rewritten by init on the next boot, beginning from halt. The persistent provisioning state, the account binding, the WiFi credentials, and the outbox all live under /var/lib/cyrano/ on real disk. Keeping the boot indicator in tmpfs eliminates an entire class of stale-state bug, for example a tech pulling power during model_load and the unit remembering a phase it is no longer in.

Yes. The codes are intentionally short and named L0 through L5 so the manager does not have to describe a color pulse. Support asks 'what is the LED doing' and the manager answers 'L2', 'L3', or 'blue solid'. The support rep looks at /etc/cyrano/led.rules (it ships the same on every unit) and knows which phase the unit is in without plugging anything into it. On calls where the manager has never touched the box, the entire diagnosis conversation is often four sentences long because the LED plus the QR sticker plus the captive portal leave no ambiguity about what state the box is in.

A single multicolor LED on the chassis, a small QR sticker printed at the factory, and a ~40 KB mDNS responder plus a captive-portal page bundled into the firmware image. The LED plus sticker add cents per unit. The software bundle adds roughly 40 KB of code against the main image. What they save is the entire serial-cable, keyboard, monitor, SSH-key path that most industrial edge computers assume on first boot, which is the actual gate between a 2-minute install and a half-day truck roll.