Platform model
Hub, entities, integrations, smart apps, Flows and the cloud, and how events move between them.
The pieces
Hub. A small computer in the home running the Novon edge runtime. It talks to devices over Z-Wave, Zigbee, Matter and the LAN, keeps the state of every device, and runs automations locally.
Entities. Everything the hub knows about is an entity with an id of the form
domain.object_id, for example light.kitchen or binary_sensor.front_door. The domain says
what kind of thing it is and therefore which states it can report and which services it accepts;
a device class refines it (binary_sensor with device class motion). An entity has one
state value and a bag of attributes (brightnessPercent, batteryLevel, …).
The capability reference lists every domain.
Integrations. Code that owns entities: it talks to the physical device or service and keeps the entity's state current. The hub ships many first-party integrations; you can add your own as a sandboxed community integration.
Services. Commands you send to an entity: light.kitchen accepts turnOn, turnOff,
toggle. The integration behind the entity performs the command and reports the new state.
Smart apps. Your automation code. A smart app subscribes to entity changes, schedules work, reads state and calls services. It cannot own entities; that is what integrations are for.
Flows. The no-code automation builder in the Novon app. Flows and smart apps live side by side and share the device catalog, but do not call each other. See Flows.
Cloud. Accounts, the mobile and web apps, remote access, and the notification channels (push, email, SMS). Automations never need the cloud to run.
How an event moves
sequenceDiagram
participant D as Device
participant I as Integration
participant S as Hub state
participant A as Smart app
D->>I: motion detected
I->>S: binary_sensor.hall → on
S-->>A: EntityChangeEvent (matches a subscription)
A->>S: light.hall.turnOn()
S->>I: service call
I->>D: switch on
I->>S: light.hall → on- An integration writes a new state for its entity.
- The hub compares old and new and, for every smart-app subscription whose filter matches, runs the
registered handler with an
EntityChangeEvent. - The handler calls services; the hub routes each call to the integration that owns the entity.
The event carries who caused the change (context.actorType: a person in the app, a smart app,
a physical press on the device, the system), which lets an app react differently to a wall switch
than to its own command.
Locations, modes and people
Every hub belongs to a location (a home). A location has a mode (DAY, EVENING,
NIGHT, AWAY, VACATION) exposed as the entity system.mode, people whose presence is
exposed as binary_sensor entities (on = home), and places with their own presence entities.
Smart apps read all of these like any other entity.
Where things persist
| What | Where | Survives |
|---|---|---|
| Entity state and attributes | hub state machine | reboot (restored from the last known values) |
| Smart-app subscriptions, schedules, timers | hub, per instance | reboot and code updates |
Smart-app state | hub SQLite, per instance | reboot, code updates, settings changes |
| Smart-app settings | hub and cloud | everything until the instance is uninstalled |