OMO Systems: Sub-300ms Device Control for Smart Buildings on AWS IoT

About project

Challenges

Two seconds means very different things depending on which device is at the other end. On a thermostat it is an annoyance a user forgives. On a lock at a door it is a guest in a corridor pressing the button again because nothing happened. On a valve under a detected leak it is water still running while the platform decides. The legacy platform applied the same delay uniformly to all of them.

The customer came into the engagement with a specific and well founded objection: that cloud hosted MQTT would be too slow for door locks. The second question followed immediately, and it was the better one. What happens if the internet drops in the middle of a command? The legacy platform had no good answer. Every control path, including the safety critical ones, depended on a round trip to a central service, so anything that degraded the network degraded the building, and a dropped link left the operator unable to tell whether a command had been applied.

To rebuild the platform, the engagement had to deliver:

• Sub-second device command latency end to end, with predictable behaviour under packet loss
• Safety automations that execute with no internet connection at all
• Secure identity for every device, so that one device cannot act for another
• Over-the-air updates across thousands of devices in buildings nobody visits
• A per-device cost that lets the operator grow the estate without growing the operations team

Our Approach

Device identity and cloud control plane

Device identity and state live in AWS IoT Core. Every lock, valve, thermostat, sensor and camera is a registered device with its own device shadow, and the AWS IoT rules engine routes messages into the rest of the platform. Devices connect using MQTT over TLS, each with its own X.509 certificate, and policies are scoped so a device can publish and subscribe only on its own topics. One device cannot speak on behalf of another.

Local autonomy at the building edge

The decisive part of the design is at the edge. AWS IoT Greengrass v2 runs on the OMO Hub installed in each building and handles local execution, buffering, secrets and edge inference. The principle we designed to is that the building keeps working when the internet does not.

• Safety automations such as “leak detected, close the valve” execute locally on the hub with no cloud round trip, so a safety action does not wait on the wide area link.
• Access windows are cached in a device shadow, so a credential that is valid right now still opens the door while the building is offline.
• Telemetry is buffered to disk in a capped ring buffer and replayed in order once the link returns, so an outage costs the operator visibility during the outage and nothing after it. The cap is deliberate: a hub that stays offline for a long period degrades predictably instead of filling its own storage.

Camera video is handled by Amazon Kinesis Video Streams. Everything else, from the operator and resident APIs to the data the platform holds about buildings, units and devices, runs on a serverless backend of Amazon API Gateway, AWS Lambda, Amazon DynamoDB and Amazon S3.

Fleet operations at scale

More than 3,000 devices are in service, spread across buildings nobody visits to run a software update. AWS IoT Device Management carries that load. Fleet provisioning issues each device its own certificate and registers it as it comes online, and fleet indexing makes the estate queryable, so a question such as which devices are on an older firmware version, or which have not reported recently, is answered directly rather than reconstructed from logs.

Firmware and component updates go out through AWS IoT Jobs in staged waves, a canary wave first and then progressively larger ones. Each device runs pre-flight checks before applying an update, and firmware is written to A/B partitions, so a device that fails its health check afterwards rolls back automatically to the version that was working. Rollouts are governed at fleet level too: if the failure rate inside a wave crosses its threshold, the rollout halts on its own rather than waiting for someone to notice. Shipping firmware to a physical fleet becomes a routine operation instead of a scheduled risk.

Outcome

Key achievements, all figures from the customer’s 2025 case study of this platform:

• Command latency down from more than 2 seconds to a median under 300 milliseconds
• 99.98 per cent uptime for device control and alerting
• Operating expenditure down approximately 58 per cent
• Cost per device down from approximately USD 150 to approximately USD 45
• Return on investment achieved in under 10 months
• Approximately USD 1.6 million net saving over five years
• Firmware update overhead down 60 per cent
• Development cycle time down 40 per cent
• More than 3,000 devices in service across the estate

Two further figures come from network impairment drills rather than from a production measurement window, and are reported here as drill results:

• Under 20 per cent injected packet loss, 95th percentile command latency was 1.2 to 1.5 seconds
• After a simulated wide area outage, shadow convergence recovered inside 1.5 seconds at the 95th percentile for locks and valves

Why It Matters

For a building operator, the difference between a two second command and a sub-300 millisecond one is the difference between a system staff work around and a system they trust. The difference between a cloud dependent platform and an edge resilient one is whether a connectivity problem is an IT incident or a safety incident.

OMO Systems can now answer the question its own customers ask first, what happens when the internet goes down, by describing exactly what still works: locks open for valid credentials, leak automations close valves, and telemetry is replayed rather than lost. Fleet wide updates that once carried real operational risk are now a staged, self halting routine, so the software in a building keeps improving without anyone going to the building.