DEVELOPERS / Integration guide

Protocol integration

Understand KNX bindings, cloud-connected devices and the distinction between commands and observations.

Concept artwork · Explicit adapters bridge different interfaces.

SYSTEMS / IN DETAIL

One capability contract. Several transport realities.

A common entity model allows vendor adapters to contribute capabilities without making every consumer understand every protocol. Transport-specific decoding still belongs at the boundary.

ENGINEERING / FOLLOW THE FLOW

CONCEPTUAL MECHANISM 01 / 04

Boundary	Responsibility	Engineering consideration
Adapter boundary	Common entity and capability contract	Preserve vendor-specific transport handling behind the shared interface.
Regression boundary	Existing supported implementations	A new inverter path must not silently break another vendor’s established behaviour.
Measurement boundary	Scaling, registers and timestamps	Do not confuse energy data normalisation with a control command adapter.

What does compatibility actually mean?

A shared architecture does not imply that every product from a vendor is supported. Integration scope depends on the model, exposed interface, firmware and project requirements. Validate command behaviour and independent readback for the specific device family.

02 / PROTOCOL INTEGRATION

Bindings carry engineering meaning.

Boundary	Representation	Engineering concern
KNX	Control GA · Status GA · DPT	A command address and an observed status are distinct. Data type determines interpretation.
Cloud-connected devices	Vendor identity · capability · owning chart	Room and tenancy must reconcile with the authored project rather than the operator’s credentials.
Generated configuration	KNX YAML · host configuration · consumer views	Cloud-only dwellings remain valid when no KNX configuration is required.
Energy telemetry	Meter channels · generation · storage flows	Preserve measured channels before deriving load attribution or planning dispatch.