A command is not a confirmation
Requested state and observed state are separate. Consumers can distinguish an acknowledged write from an observation that matches the request.
API & INTEGRATION ENGINEERING
OpenLight Gateway
Different devices. One understandable system.
The problem
Lighting systems speak different protocols. An application needs more than a way to send commands: it needs to know what happened, which device responded, and what to do when one did not.
Built for developers integrating mixed lighting hardware and operators who need a common control interface.
What I built
I built a local lighting gateway that separates a common API from manufacturer adapters. Work is tracked as an operation with per-device results, so a partial failure remains visible instead of disappearing behind a single success response.
ApplicationOne request
Common lighting APIValidate → schedule → observe
Adapter ADevice protocol
Adapter BDevice protocol
Adapter CDevice protocol
Per-device resultsObserved stateVisible failures
THE WORKFLOW
From the first step to the result.
- 01
Request
An application submits the desired state for selected devices.
- 02
Schedule
The gateway validates capabilities and orders work per device.
- 03
Observe
Adapters communicate with devices and read back available state.
- 04
Report
Operation results distinguish success, partial completion, and failure.
ENGINEERING DECISIONS
The details
behind the work.
Give each device its own queue
Per-device scheduling and deadlines prevent a slow target from holding up unrelated device work.
Contain adapter failures
The local implementation includes timeout containment, quarantine, and reconnect scheduling. Failures become structured results that the calling application can handle.
CURRENT SCOPE
Where it stands.
The implementation includes a common lighting API, manufacturer adapters, persisted asynchronous operations, and observed-state handling. This case study describes the local implementation; the public repository may lag those changes. A current controlled hardware demonstration is still pending.
Supporting verification notes
Source review confirms the operation and adapter mechanisms described here. No fresh physical-device acceptance run is represented by this illustration. Supported behavior depends on the configured adapter and device; Matter and Hubspace are not included in this case study.
APPLYING THE APPROACH
Connect your systems.
The same engineering approach applies when business applications need to exchange data, coordinate asynchronous jobs, and explain failures to an operator.
Discuss a similar project Opens your email application.