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.
In short: The system is built from clear parts, so it can grow and change without one fix breaking something else.
- What you needWe start from the business goal and its limits.
- Clear building blocksThe system is split into parts, each with one job.
- How the parts talkAgreed connections, so one part can change without breaking others.
- Who owns which dataEvery piece of data has one home everyone trusts.
- Put liveIt runs on reliable servers, set up the same way every time.
- Kept healthyMonitoring spots problems before your users do.
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.
Prefer email? hello@nxtinno.com