Key Concepts
This page introduces the foundational concepts required to understand Zipato documentation. It is not a complete glossary. Each concept is explained at the level needed to read the rest of the docs without confusion; deeper detail is available on the linked pages.
Platform Core
The Platform Core is the technical foundation of Zipato. It is responsible for connecting devices, normalising data, executing logic, managing device fleets and providing the infrastructure services that all applications and integrations depend on.
The Core is not simply a cloud backend. It can run locally, in the cloud or across both environments simultaneously, depending on the deployment. Applications and capabilities do not interact with devices directly — they rely on the abstractions and services the Core provides.
Learn more about the Core Platform
Device
A device is any physical or virtual entity connected to the platform. Devices can represent hardware directly attached to a local runtime, hardware reached through a hub, or virtual entities that represent external systems.
Examples include smart locks, thermostats, sensors, cameras, energy meters, hubs and virtual devices that proxy a third-party API.
Learn more about Devices and Resources
Resource and Capability Model
Devices from different manufacturers using different protocols are represented through a normalised model of resources and capabilities. A resource is a specific measurable or controllable aspect of a device — for example, temperature, motionDetected or batteryLevel. A capability is a logical grouping of related resources — for example, a TemperatureSensor capability that includes current value, unit and threshold resources.
This means that a Z-Wave temperature sensor, a Zigbee temperature sensor and a Matter temperature sensor can all be handled through the same model. Applications and rules interact with the normalised model rather than with protocol-specific data.
This is one of the most important architectural concepts in Zipato. It is the reason the platform can support heterogeneous device ecosystems without requiring every application to handle protocol-level differences.
Learn more about Device Normalization
Protocol Adapter
A protocol adapter is a software component that connects a specific communication protocol or external system to the normalised Zipato device model. It translates protocol-specific messages into platform events and translates platform commands back into protocol-specific instructions.
Examples include adapters for Z-Wave, Zigbee, KNX, Modbus, BLE, MQTT, Matter and third-party APIs.
Learn more about Protocols and Connectivity
System
A System is the primary logical entity used to group connected devices and runtime instances within the platform.
Each System can contain one or more Edge Runtime instances. These runtimes may connect different groups of devices, operate on different network segments or serve different physical locations. Regardless of how devices are connected, they are managed as part of the same logical System.
A System may use a single runtime instance or a multi-node runtime configuration.
Edge Runtime
The Edge Runtime is the software layer responsible for connecting devices to the Platform Core.
It hosts protocol adapters, processes device communication, normalises device data and dispatches commands. Depending on the runtime model, it may also execute local messaging, automation rules and application capabilities such as security or environmental-control logic.
The term edge describes the runtime's architectural role: it is the layer closest to connected devices. It does not necessarily mean that the software is physically installed at the customer site.
An Edge Runtime can operate as:
- a Local Edge Runtime;
- a Virtual Edge Runtime;
- part of a Multi-Node Edge Runtime configuration.
Local Edge Runtime
A Local Edge Runtime is a full server application installed at the customer site.
It can run protocol adapters, messaging, device normalisation, automation rules and application capabilities locally. This allows the connected system to continue operating even when a permanent connection to the Platform Core is unavailable.
A Local Edge Runtime is suited to deployments requiring low latency, offline resilience, local processing or integration with devices available only within the local network.
Learn more about Local Edge Runtime
Virtual Edge Runtime
A Virtual Edge Runtime provides the same logical device-connectivity layer as a Local Edge Runtime but runs within the Platform Core infrastructure.
It can connect supported IP devices directly and can also receive device communication forwarded by Lightweight Protocol Hubs.
Because it runs as part of the Platform Core, a Virtual Edge Runtime is not tied to a specific infrastructure model. It can operate in a public-cloud, private-cloud or hosted deployment of the platform.
Learn more about Virtual Edge Runtime
Lightweight Protocol Hub
A Lightweight Protocol Hub is a compact hardware device that connects local devices and forwards protocol communication to a Virtual Edge Runtime.
For example, an ESP32-based hub may connect Z-Wave, Matter or BLE devices and securely forward their communication to the Platform Core.
A Lightweight Protocol Hub is not a runtime environment. It is a local connectivity bridge used by a Virtual Edge Runtime to reach devices that cannot connect directly over IP.
Learn more about Protocols and Connectivity
Multi-Node Edge Runtime
A System can contain multiple Edge Runtime instances. For example, a single System may contain several Local Edge Runtime instances connecting devices in different buildings, floors or network segments, or a combination of Local and Virtual Edge Runtime instances.
All connected devices remain part of the same logical System and can be managed through a unified platform view.
This model supports larger, distributed and more complex deployments.
Learn more about Multi-Node Edge Runtime
Edge Runtime Model
An Edge Runtime Model defines how devices are connected to the Platform Core and where device-related processing is executed. It is a per-installation decision.
Typical models include:
- Local Edge Runtime — full server application installed on-site;
- Virtual Edge Runtime with direct IP devices — cloud-hosted runtime connecting IP devices directly;
- Virtual Edge Runtime with Lightweight Protocol Hubs — cloud-hosted runtime reached via local protocol bridges;
- Multi-Node Edge Runtime — multiple runtime instances within a single System.
The Edge Runtime Model is independent of the Platform Deployment Model.
Learn more about Edge Runtime Models
Platform Deployment Model
A Platform Deployment Model defines where the complete Platform Core infrastructure is installed and operated. This is a separate decision from how local devices are connected.
Typical models include:
- Public Cloud — the customer's realm is hosted within Zipato's shared cloud infrastructure;
- Private Cloud — a dedicated platform instance is deployed in the customer's own cloud environment;
- Hosted or On-Premise Deployment — the platform runs on infrastructure chosen by the customer.
A Platform Deployment Model should not be confused with an Edge Runtime Model. For example, an on-premise installation of the Platform Core may still use a Virtual Edge Runtime to connect supported IP devices and Lightweight Protocol Hubs.
Learn more about Deployment Models
Realm
A realm is a logically isolated environment within the platform. It is the container for a specific customer, partner or organisation and holds all of their data, devices, users, configurations and access rights independently from other realms.
A realm may contain users, devices, locations, configurations, application settings and access control rules. Realm boundaries enforce data isolation — one realm cannot access the data of another.
Realm hierarchy, sub-realms and multi-level tenancy are described in detail in the Core Platform section.
Application Capability
An Application Capability is a ready-made domain logic module built on top of the Core Platform. It provides a complete set of models, logic, workflows and integration points for a specific functional domain.
A Capability is not just an API and not just a UI component. For example, the Security and Alarm Capability includes partition and zone models, alarm state logic, arming and disarming workflows, notification routing and integration with detection devices — all as a reusable module that different applications can consume.
Examples include Security and Alarm, Thermostat and Environmental Control, Video Management, Access Control, Notifications and Monitoring.
Explore Application Capabilities
Application
An application is a user-facing or administrative interface built on top of the Core Platform and Application Capabilities. Applications consume platform APIs and capabilities to deliver a complete experience for a specific user role or industry.
Examples include the mobile app for end users, the web administration interface, the rule and workflow editor, the AI copilot and vertical applications built for specific industries such as hospitality or senior care.
What Is Not Covered Here
Several related concepts — including Locations and Space Hierarchy, Automation Rules, Events, Message Queue, Digital Artifacts, AI Agents, MCP Servers, Fleet and Tenant Roles — are not described on this page. They will be introduced on the pages where they become relevant, and collected in full in the Glossary.