The lock in this WG is a Homematic IP door lock (keypad + alarm), not
Nuki/Tuya as originally specced — confirmed with the user. Homematic IP
has no official self-service partner API for Access-Point-only setups
(no local CCU), so this uses the actively-maintained open-source
`homematicip` Python library (implements the same reverse-engineered
cloud protocol used by the official app) via two scripts rather than
reimplementing the HTTP/HMAC handshake from scratch — lower risk of
subtly wrong protocol details.
- scripts/hmip_register.py: non-interactive pairing (connection
request -> wait for the physical blue-button press on the Access
Point -> auth token). Writes progress to a status file so the API
can poll it instead of blocking a request for up to ~6 minutes.
- scripts/hmip_control.py: list-devices / lock / unlock via
HMIP_ACCESS_POINT + HMIP_AUTH_TOKEN env vars (not CLI args, so they
don't leak into process listings).
- routes/smartLock.ts: POST /smartlock/pairing/start + GET .../status
(LANDLORD/ADMIN, one-time setup), GET /smartlock/devices
(LANDLORD/ADMIN), POST /smartlock/devices/:id/:lock|unlock (any
authenticated user — this is the tenant-facing "keyless door" use
case from the spec). All lock/unlock routes 409 until pairing has
produced HMIP_ACCESS_POINT/HMIP_AUTH_TOKEN.
Does NOT cover temporary guest PIN codes on the keypad itself — that's
handled through Homematic IP's own "eSchlüssel" app feature, which
isn't exposed by this API; guest codes remain DB-only as before.
