Protocols: support level by transport

The server's integration catalog collects one row per transport the platform knows: MQTT, Matter, Zigbee, Modbus, KNX · BACnet, ONVIF and REST/cloud. The row states the direction, the environment, the devices behind the transport and whether the required dependency is present. It is a real server record, not a marketing row — which is exactly why it also shows what is missing.

The levels we work with

• Ready — the path works and has been verified: the device changes state from the screen.
• Described and verifiable — the transport is in the catalog, the panel offers leads with an address and a port and makes a real TCP test request to the device. The device is not yet read or commanded.
• Pending — the missing element is named: a driver, a coordinator or a broker.

We never present a pending integration as available. Specific device models are confirmed during a site survey; we do not advertise compatibility we have not tested.

Transport by transport

• Matter — ready. The matter.js controller runs over IPv6 (UDP port 5540) with mDNS discovery and starts only when MATTER=1. Pairing is real: the steps "network kind → device → request → result" go through POST /api/pair with the config permission, pass the OnOff cluster and write matter-devices.json, from where the device enters the registry with origin "integration". Paired metering devices also report measured energy. Requirement: IPv6 in the LAN — without it the controller starts but never sees the node.
• MQTT — the contract is ready, the broker is pending. The home/v1 topics are defined once in code and the panel and the simulation both speak them (full topic list). Connection code for a real broker exists, but the mqtt package is not in the dependencies and has not been tested against a broker.
• Zigbee — through a gateway only. The platform has no radio layer of its own: 2.4 GHz devices (Zigbee 802.15.4, Bluetooth LE, Wi-Fi plugs) come in through a coordinator or a gateway that translates the radio traffic into MQTT. What is missing is the coordinator choice and the integration module that fills the home/v1 topics from a real gateway.
• Modbus — described and verifiable. Modbus TCP and RTU/RS485 are in the catalog; the panel gives leads and a real TCP request. Reading the registers is the job of the driver that is still pending — needed for inverters and energy meters.
• KNX · BACnet — described and verifiable. KNX is in the catalog as leads with group addresses plus a TCP check of the interface; the driver that reads and writes on the bus is pending. From the site we need the installation project.
• ONVIF and cameras — partial. The Security screen shows motion, the last frame and the time of the last change, and the log is kept on the server. The path (ONVIF discovery, RTSP ingest, NVR) is described in the catalog but still pending; no live view and no recording are promised. (HoumeOS and cameras)
• REST / cloud API — described and verifiable. For vendors with no reverse path there is a read-only mode: the device is shown, commands are not promised.

What you see on the panel is useful by itself: the list separates device state from transport liveness — a device can be online while the link is retrying, and the other way round.

Radio hygiene that solves more than code does

• Client isolation (AP isolation) on the router blocks kiosk → server and must be off.
• The server address is a static IP or an internal DNS name — there is no automatic device discovery in the LAN.
• Keep the Zigbee channel different from the access point channel (for example 15/20/25 against 1/6/11).
• Keep the coordinator antenna away from USB 3.0 ports and controllers that noise the 2.4 GHz band.

Links to the per-protocol pages

KNX · Modbus · Zigbee · MQTT · Solar inverters · Heat pumps · Cameras and ONVIF. Each one describes the support level, the limits and what we need from your installation.