Integrations and protocols

Integrations: MQTT, Matter, Zigbee, KNX, Modbus, ONVIF and REST

One device model, many ways into it.

A catalog, an editor and a guide step by step — with a clear line between what works today and what is still coming.

In short

Integration in a smart home means a device from another brand lives in one shared model instead of its own app. HoumeOS does it through a single contract, home/v1, and seven transports: MQTT, Matter, Zigbee, BLE, Modbus, KNX and ONVIF. The panel describes each of them, but we do not claim that all of them already read your devices.

Illustration of HoumeOS integrations: MQTT, Matter, Zigbee, KNX, Modbus, ONVIF and REST
Seven transports in one panel and one device model.

The integration panel today

The panel is a catalog of seven transports with an editor and a step-by-step guide for each pairing. The pairing request goes through the server, and the 11-digit device code is never stored — it is used once, for the pairing itself.

  • A catalog that states what is known about each transport today
  • Pairing steps that check whether the address answers at all
  • One and the same record for every device: name, room, rights, history

Matter: the pairing really works

HoumeOS behaves as a Matter controller: it discovers the device over mDNS, pairs it locally and makes it live in the shared model. Commands are local, with no cloud from the manufacturer, and for devices with metering the measured energy is taken as well.

  • Discovery over mDNS, without an account and without the brand app
  • Local commands and local status — the internet is not needed
  • Measured energy on devices that expose it

MQTT is the contract of the house

The home/v1 topics describe every device as state and command: light, climate, blind, valve, inverter. The contract and the panel are ready; the broker that will carry the real devices is the next step, and we say it without detours.

Zigbee, BLE and why there is no radio in the platform

The platform is not a gateway and does not hold a radio. Zigbee and BLE devices arrive through a coordinator or a gateway that translates them into MQTT — the radio stays with the device, the logic stays on the server.

  • The coordinator carries the radio, not the server
  • A translated device enters the same model as every other one
  • There is no point in storing the same history twice

Modbus, KNX and ONVIF: guides with a check

For these three the panel provides guides: address, port, a TCP probe whether anything answers, and a description of what would be read. The real driver that reads the registers or the RTSP stream is still to come — and we do not present it as ready.

An invitation to integrators

A driver is a small, clear part: it reads the device, writes its state into home/v1 and accepts commands back. There is a simulation mode without hardware and a tested core, so development does not need a site. If you integrate and document your own protocols — write to us.

Protocols: a page for each

Every transport has its own page: what works today, what is still to come, and what we need from your installation.

KNXHoumeOS and KNX: group addresses, no cloudWhat works today — the catalog entry and guides with a real TCP check — and what is still to come: the driver for the group addresses.OpenModbusHoumeOS and Modbus: Modbus TCP and RTUHow TCP and RTU/RS485 are described and what we need from the device documentation: reading the registers is the job of a driver that is still to come.OpenZigbeeHoumeOS and Zigbee: devices through a coordinator or a gatewayThe platform has no radio of its own — devices arrive through a gateway into MQTT. The choice of coordinator is still to be made.OpenMQTTHoumeOS and MQTT: the home/v1 contractThe contract for state, commands and events is real and documented; the broker carrying the actual devices is still to come.OpenSolar invertersHoumeOS and solar inverters: where the surplus goesThe flow production → battery → boiler → export with real thresholds works today; the driver that reads the actual inverter is still to come.OpenHeat pumpsHoumeOS and heat pumps: target temperatures on a scheduleModes, schedules and shading work today; the link to a specific model over Modbus or BACnet is still to come.OpenCameras and ONVIFHoumeOS and cameras: motion, last frame and ONVIFThe screen with the last motion and the journal work today; camera discovery and the RTSP stream are still to come.Open

What works today and what is coming

We do not present upcoming work as available. This list matches the roadmap.

Works today

  • Matter: real pairing over mDNS, local commands and energy metering
  • Integration panel: catalog of seven transports, editor and pairing steps
  • The home/v1 contract and the simulation layer behind it
  • Devices screen with an honest state: offline, online, unknown

Coming soon

  • MQTT: the contract and the panel are ready, the broker with real devices is next
  • Modbus, KNX and ONVIF: guides with a TCP probe, the real driver is still to come
  • Zigbee and BLE: through a coordinator or gateway that translates into MQTT

Later

  • A radio of our own in the platform and our own mesh topology
  • OCPP for external chargers and HTTPS remote access
  • Drivers for specific brands, written on request for a site

Frequently asked questions

How do you pair a Matter device?

You open the panel, choose Matter and follow the steps: the device advertises itself on the local network, you enter the pairing code, the server validates it once and adds the device to the shared model. After that it is controlled like everything else — with rights, journal and history. The code is not stored and the commands never pass through a cloud.

What works today for KNX?

The panel describes KNX as a transport and provides a guide: address, port, a check whether anything answers at all, and a step-by-step walkthrough. The driver that reads and writes the group addresses on the bus is still to come, so we do not present it as ready. For a specific installation we are ready to build it together with your KNX partner.

How is a Modbus device integrated?

We expect a register map: address, port, units, read period. The panel describes the transport and checks whether the address answers; reading the registers themselves is the driver's job and it is still to come. For solar inverters and meters we are ready to write the driver together with your installer if the documentation exists.

Is there a ready MQTT broker in HoumeOS?

It is not ready yet. The description is: the home/v1 topics, the shape of state and commands, and the panel that shows the contract. The broker that real devices would publish to is the next step. Today the same contract is used by the simulation, so the interface and the rules are already tested against it.

How is a new manufacturer added?

Through a driver that does three things: reads the device, writes its state into home/v1 and accepts commands from it. There is a simulation mode without hardware and a tested core, so development does not wait for a site. If you are an integrator and have documentation for the protocol, write to us at contact@houmeos.com.

We show the system on a live screen

The demo starts from your question: which devices, which protocols, which scenarios.

What is ready and what is coming