julian
a0e0fd9118
UHPPOTE controllers self-announce via UDP broadcast, but the frontend had no way to find them — the admin had to type the serial blind. Add a generic discovery capability and surface it in the setup wizard. packages/devices: - DiscoverableDriver capability + DiscoveredDevice type + isDiscoverable() guard on the registry (optional, so any driver can opt in). - uhppote driver implements discover() via uhppoted getDevices (UDP broadcast), mapping each controller's serial/IP/firmware into a DiscoveredDevice; extract shared buildCtx(). apps/server: - GET /api/setup/discover/:driverId (admin-only): runs discover() and health-checks each found device so reachability shows before assigning. - catalog now returns a `discoverable` driver-id list. apps/web: - SetupWizard "Scan for controllers" button for discoverable drivers; lists found devices with health badges; selecting one auto-fills serial + host. api client gains discoverDevices(). wiki: new device-discovery concept; cross-link from registry/setup/uhppote; note the broadcast-permission (EACCES) deployment caveat; index + log. Verified: catalog flags uhppote discoverable; discover runs and fails gracefully without hardware; non-discoverable driver -> 400; missing token -> 401.
47 lines
2.1 KiB
Markdown
47 lines
2.1 KiB
Markdown
---
|
|
type: concept
|
|
tags: [parking, architecture, devices, setup]
|
|
sources: [parking-system-architecture]
|
|
updated: 2026-06-15
|
|
---
|
|
|
|
# Device Discovery
|
|
|
|
An optional driver capability: **find devices on the LAN** so the admin doesn't have to type
|
|
connection details by hand during [[first-run-setup]]. Modeled generically so any driver can
|
|
opt in.
|
|
|
|
> Implementation-derived (from `@parking/devices` + setup API/UI), not the source doc.
|
|
|
|
## The capability
|
|
|
|
A driver may implement `DiscoverableDriver` — `discover() => DiscoveredDevice[]`. Each found
|
|
device carries an `id`, a `label`, a `config` blob to **auto-fill** the setup form, and `info`
|
|
(firmware, MAC, …). The [[device-registry]]'s `isDiscoverable()` guard lets the system treat it
|
|
as optional; the setup catalog returns a `discoverable` list of driver ids.
|
|
|
|
## UHPPOTE discovery
|
|
|
|
The [[uhppote-controller]] supports discovery natively: a **UDP broadcast** (`get-devices` on
|
|
`255.255.255.255:60000`) that **every controller on the LAN answers** with its serial, IP,
|
|
netmask, gateway, MAC, firmware version, and date. The official `uhppoted` lib exposes this as
|
|
`getDevices(ctx)`; the `uhppote` driver maps each result into a `DiscoveredDevice` (serial → id,
|
|
IP → host).
|
|
|
|
## Flow
|
|
|
|
1. The setup catalog flags `uhppote` as discoverable.
|
|
2. Admin clicks **Scan** → `GET /api/setup/discover/:driverId` (admin-only).
|
|
3. The server runs `discover()` and **health-checks each found device** so the admin sees
|
|
reachability before assigning.
|
|
4. Selecting a result **auto-fills serial + host**; the admin then assigns it to a lane.
|
|
|
|
## Deployment notes
|
|
|
|
- UHPPOTE discovery is a **broadcast** — the host socket needs broadcast permission (a raw
|
|
`send EACCES …:60000` means the OS blocked it). Works on the isolated device VLAN
|
|
([[network-isolation]]) where the controller and host share an L2 segment.
|
|
- Discovery shares the same unauthenticated UDP exposure as everything else UHPPOTE — another
|
|
reason the controllers live on an isolated VLAN ([[uhppote-udp-protocol]]).
|
|
- Cameras (Hikvision/Dahua via ONVIF/WS-Discovery) could implement the same interface later.
|