Skip to content
nxtinno

Case study

Loxone entry management integration platform

Designed and built an integration platform that synchronizes reservation and room-occupancy data into a Loxone-powered entry system, using desired-state reconciliation, durable jobs, monitoring, and safe access revocation.

  • TypeScript
  • Express
  • Redis
  • BullMQ
  • Loxone

Context

An accommodation operation needed guest access state in Loxone to stay aligned with live reservation data without manual code creation, stale room access, or repeated blind writes to the building automation system.

Challenge

Reservations, occupancy, validity windows, PIN codes, room state, and Loxone user records had to converge safely. Because the system affects physical access, failed writes, stale jobs, missing data, and duplicate updates could not be treated as ordinary sync noise.

Constraints

  • access-control changes must be explicit, auditable, and reversible
  • missing or uncertain reservation data must not extend access
  • unchanged room state should not trigger duplicate Loxone writes
  • one problematic room must not block the whole synchronization run
  • operators need visibility into sync health, incidents, queues, and failed rooms

Approach

  • Separated remote data ingestion from mutating Loxone reconciliation so polling and access changes had a clear boundary.
  • Generated normalized desired room state with deterministic hashes, then queued room-level reconcile jobs only when state changed.
  • Stored desired state, applied state, room locks, and reconcile results in Redis so retries could converge from the latest known facts.
  • Built operational surfaces around health checks, metrics, alerts, incident tracking, manual sync, dry runs, and a management UI.

Architecture

A TypeScript service ingests reservation and room data, derives desired access state, stores state and locks in Redis, queues room-level BullMQ reconcile jobs, applies only the required Loxone user and virtual-input changes, and exposes health, monitoring, metrics, alerts, reports, and manual sync controls for operations.

From product intent to operable architectureProduct intentgoals · constraintsDomain boundariesservices · ownershipAPIs & eventscontractsData ownershipsources of truthDeploymentcloud · KubernetesOperationsobservability
Diagram summary: product intent is decomposed into domain boundaries; boundaries define APIs and events; data ownership follows the boundaries; deployment and operations complete the loop so the architecture stays grounded in delivery.

Key decisions

  • desired-state reconciliation instead of blind scheduled writes
  • applied state saved only after confirmed Loxone success
  • per-room locking and stale-job skipping to keep retries safe
  • sensitive access data kept out of logs, metrics, reports, and dashboards

Details are anonymised. Additional context is available under NDA.

Related expertise

Curious what AI could actually do for your business?

Bring your questions, including the ones that feel too basic. In 30 minutes we go through how you work today, pick the task with the most to gain, and sketch what testing it would involve. No pitch, no obligation.