Architecture
Decisions in the right location.
Our architecture puts each piece of logic in the right place. Protocol translation, command arbitration and safety limits run on the device. High-level goals and telemetry surface via the cloud. Right code, right place.
Ask an engineerTopology and execution
Where the Edge sits is flexible. Where the decision logic runs is not.
The Edge can be designed directly into a device, or deployed in a hub serving several devices, and both approaches can coexist on the same premises. An external system can reach the Edge through WattStack's Public API, or communicate directly with the device over open standards with no third-party cloud in the path. Your choice.
Operating a device cloud-to-cloud through different manufacturers means inheriting multiple layers of logic you cannot inspect, at minimum the device firmware, and usually the manufacturer's cloud API in front of it too. All opaque, with per-device-model differences common, so you must design for whichever combination behaves worst. With WattStack, no matter where the Edge is situated, protocol translation, command arbitration and manufacturer's safety limits run locally, with per-model mappings abstracted on the device. What reaches integrations is consistent data, behaving the same way across every model.
Today, via manufacturer clouds
With WattStack, from the device
With WattStack, from the device
Where our logic lives
| Capability | At the Edge | From the Cloud |
|---|---|---|
| Device control | instantaneous commands and schedules | high-level goals and adaptive schedules |
| Telemetry | cached when offline | REST query and webhooks |
| Device state | mastered on the device | live event stream |
| Security | safety limits and the sandbox, on the device | access scoped per integration and per device |
| Protocol translation | on-device | not required |
| Arbitration & safety | deterministic, local | policy & config only |
| Command acknowledgement | acknowledged at the device | tracked with receipts |
| Per-manufacturer logic | runs in hardware sandbox | not required |
Arbitration and resilience
When requests collide, the device decides.
Several inputs can ask a device to act at once, often contradicting each other. A flex dispatch, a schedule the owner set, a resident override, and a direct API command. Most manufacturer systems simply apply the last command they received. With WattStack, configurable priority rules drive behaviour, and the Edge resolves them on the device, not in a round trip. Whatever takes priority is still clamped within the manufacturer's limits, so no source can command a device inappropriately.
Manufacturer safety limitsAlways enforced
- 1 Resident override at the device
- 2 Flex dispatch
- 3 Resident override in the app
- 4 Device optimisation
- 5 Owner schedule
- 6 Manufacturer and commissioning defaults
Default source priority.
Hardware-based resilience.
When a cloud link drops or becomes unstable, the Edge keeps running the schedule it has in memory, enforcing the same safety limits, and caching telemetry until the cloud is available again. Wall-clock aligned timestamps mean that you always know when readings were actually taken, even if the transmission gets delayed, and a battery-backed real-time clock on the Edge keeps time through a power cut. Resident overrides still work locally, because they never use the cloud.
Talk architecture with an engineer.
Ask a schematic or an API question and talk to the real engineers designing our platform.