Docs
Concepts

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
  1. An integration writes a new state for its entity.
  2. The hub compares old and new and, for every smart-app subscription whose filter matches, runs the registered handler with an EntityChangeEvent.
  3. 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

WhatWhereSurvives
Entity state and attributeshub state machinereboot (restored from the last known values)
Smart-app subscriptions, schedules, timershub, per instancereboot and code updates
Smart-app statehub SQLite, per instancereboot, code updates, settings changes
Smart-app settingshub and cloudeverything until the instance is uninstalled

On this page