Files

T

julian a0e0fd9118 Add device discovery (UHPPOTE LAN scan) to setup

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.

2026-06-14 08:21:27 +02:00

2.5 KiB

Raw Blame History

type, tags, sources, updated

type

UHPPOTE Controller (current choice)

The starting access-control hardware: a UHPPOTE Wiegand 26/34 network controller (4-door) — a cheap reader-plus-relay frontend, acceptable provided you understand its limits. The plan is UHPPOTE now → ZKTeco later (see bom). (See parking-system-architecture §6.)

Implementation: integrated via the official uhppoted npm package (MIT, by the uhppoted org — github.com/uhppoted/uhppoted-lib-nodejs), added to @parking/devices as the uhppote access driver (device-registry). It exposes exactly the protocol commands this design needs: openDoor, getStatus, and the event-log set (getEvent, getEventIndex, setEventIndex, recordSpecialEvents) plus setListener/listen for auto-push — see event-log-ingestion. Transport defaults to UDP (broadcast …:60000), with optional per-call TCP on newer firmware. The driver also implements device-discovery (getDevices broadcast) so the setup wizard can scan for controllers. Note: the lib pulls one trivial extra dep (the npm os shim) and uses UDP broadcast, which needs socket broadcast permission on the host.

What it is

Combines reader input (wiegand) and door relays, with an onboard card list enabling autonomous offline decisions for Wiegand lanes.
Stores an indexed event log (see event-log-ingestion): get-events returns the stored range + current index; each record has event ID, timestamp, card number, door, access-granted flag, reason code. At the record level it's effectively append-only — no command edits/deletes an individual event.

The catch

It speaks the uhppote-udp-protocol: UDP port 60000, no auth, no encryption. Anyone on the LAN can open any door — and several unauthenticated commands can blind/reset/skew the log. So the device is tamper-evident, not tamper-proof, and only trustworthy behind network-isolation (mandatory). Firmware cannot be customized — the open-source uhppoted ecosystem is protocol reverse-engineering only; the controller accepts only the manufacturer's official firmware images.

Make the log trustworthy via event-log-ingestion (host-side index tracking) landing into the append-only-event-chain. For prevention-grade authentication, see the esp32-custom-controller. The choice between them is the trust-boundary decision.

2.5 KiB Raw Blame History

UHPPOTE Controller (current choice)

What it is

The catch

2.5 KiB

Raw Blame History