Skip to content

Add pms_smartlock_tesa (TESA Smartair) and pass PIN in lock sync - #98

Merged
jesusVMayor merged 1 commit into
16.0from
feat/pms-smartlock-tesa
Jun 19, 2026
Merged

jesusVMayor merged 1 commit into
16.0from
feat/pms-smartlock-tesa

Conversation

@jesusVMayor

Copy link
Copy Markdown
Member

What

New vendor module pms_smartlock_tesa wiring TESA Smartair into the smartlock framework, mirroring the TTLock/Omnitec pattern:

  • vendor_type selection adds tesa ("TESA Smartair").
  • TESA has no cloud, so the on-prem connection params live on lock.vendor: host, port (8181), operator name/password, verify_ssl.
  • get_connector() returns the TesaSmartairProvider from the roomdoo_locks_tesa library.
  • _pin_confirm_key_defaults() entry + vendor form view.

Plus a change in pms_smartlock_base: _sync_modify/_sync_remove now pass the grant's PIN to modify_access/revoke_access. TESA needs it to re-resolve live state (a pre-assignment auto-activates into a check-in, the stored handle goes stale) and to recreate a grant when the start date changes. The PIN is read under sudo, stays in the group-restricted field, and is never written to vendor_grant_ref.

Dependency

Depends on the library PR commitsun/roomdoo-smartlocks#22 (the new roomdoo_locks_tesa package + the additive pin=None on modify_access/revoke_access). Merge that first — until it lands on the lib's main, the additive pin kwarg won't exist. requirements.txt/requirements-overrides.txt declare the new lib at @main.

Tests

Vendor module tests pass; the library behaviour (auto-activation re-resolution, start-change recreate) is covered in the lib PR and validated end-to-end against a real Smartair server.

New vendor module pms_smartlock_tesa wiring TESA Smartair into the
smartlock framework, mirroring the ttlock/omnitec pattern: vendor_type
"tesa", on-prem connection params on lock.vendor (host, port, operator
name/password, verify_ssl) since TESA has no cloud, and get_connector()
returning the TesaSmartairProvider from the roomdoo_locks_tesa library.

pms_smartlock_base now passes the grant's PIN to modify_access/
revoke_access (read under sudo, never exposed): TESA needs it to
re-resolve live state and confirm a stay is ours before acting, and to
recreate a grant when the start date changes. The PIN stays in the
group-restricted field and is never written to vendor_grant_ref.

Depends on the roomdoo_locks_tesa library and the additive pin contract
(roomdoo-smartlocks#22); requirements declare the new lib.
@jesusVMayor
jesusVMayor merged commit 9416329 into 16.0 Jun 19, 2026
1 check failed
@github-actions

Copy link
Copy Markdown

Diff Coverage

Diff: origin/16.0...HEAD, staged and unstaged changes

No lines with coverage information in this diff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant