Loxone integration
Loxone Integration — KNX, BACnet, Modbus and Third-Party Systems
How a Loxone controller integrates KNX, BACnet, Modbus, DALI and third-party systems, and which engineering details decide whether the interface survives.
Quick answer
Integration means mapping third-party systems into the controller's point model so they behave like native points. KNX usually arrives through a gateway, BACnet over IP, Modbus over serial or TCP, and DALI through a lighting controller. The engineering work is the point list, read and write rights, scaling, naming and fault behaviour, not the cable alone.
What integration actually changes
A gateway alone does not create integration. Integration happens when a third-party value becomes a named point with a unit, a quality flag, a write permission and a defined behaviour when communication fails. That mapping is the deliverable. It should state whether the point is read-only, commandable or both, how it is scaled, how often it updates and what the controller does with the last known value. Without that layer, the project has a connection but not a system. A useful test is to ask what the operator will see when the third-party device is powered down; if the answer is a blank value with no quality flag and no timestamp, the mapping is incomplete.
- One name, unit, direction and failure state per point
- A gateway is not an integration on its own
- Define read and write rights explicitly
KNX, BACnet and Modbus in practice
KNX is strong at room-level lighting, shading and presence. It usually enters through a KNX interface or gateway, and the engineering work is group-address mapping and ETS ownership. BACnet is strong at plant and BMS level. BACnet/IP devices can be read directly or through a gateway; object types, COV subscriptions and write priorities matter. Modbus is common on meters, inverters and simpler plant. It is a register protocol with no shared semantics, so the register map, scaling and word order must be confirmed in writing. Each protocol solves a different layer of the building. The protocol names matter less than the point-level agreement between the two engineering teams, written before either side configures a controller.
- KNX for rooms, BACnet for plant, Modbus for meters
- Confirm register maps in writing
- Check object support before design
DALI, dry contacts and the long tail
DALI brings individual luminaire addressing, dimming and fault feedback. It normally connects through a DALI controller rather than directly to the automation bus. Dry contacts remain the universal fallback for fire signals, legacy plant and simple status. The long tail of building systems often includes HTTP APIs, SNMP, pulse meters and vendor-specific serial protocols. Each one needs an owner, a test method and a failure state. The test is not whether data appears once; it is whether the point recovers correctly after a device reboot, a network interruption and a power cycle. Log the last successful communication time for every interface, so a silent failure is visible before an operator notices a cold room or a dark floor.
- DALI needs a lighting controller
- Dry contacts remain the universal fallback
- Test recovery after reboot and power loss
Architecture rules that prevent rework
Keep gateways close to the systems they serve, on a documented network segment. Avoid cascading gateways: every translation adds latency and a place for the data model to drift. Give each point one owner and one direction. Decide where schedules live: in the third-party system, in the controller or in the supervision layer, but not in two places. Record the firmware and configuration of every gateway, because a replacement unit with default settings can silently change behaviour. Integration is maintainable when the drawing, the point list and the running system agree. A drawing that shows the gateway but not its point direction is only a cable diagram, not an integration design, and it will not help the next engineer.
- Keep gateways close to their devices
- Avoid cascading translations
- Record gateway firmware and configuration
Loxone Modbus integration
Loxone Modbus integration usually runs over Modbus RTU on a serial extension or Modbus TCP over the building network. The engineering work is the register map: address, function code, data type, scaling, unit, polling rate and write protection. Keep a single register schedule and test each point in both directions. Do not poll fast-changing data at a rate the device cannot sustain; group reads and cache values where the platform allows. For billing or tenant data, record the raw register and the scaled value so a future engineer can audit the conversion.
Integration interfaces
7 rows| System | Typical interface | Direction | Watch-out |
|---|---|---|---|
| Lighting and shading | KNX gateway or interface | Read and write | Group-address ownership and ETS access |
| Plant and AHU | BACnet/IP | Read and write | Object support, COV and write priority |
| Meters and inverters | Modbus RTU or TCP | Mostly read | Register map, scaling and word order |
| Luminaires | DALI controller | Read and write | Addressing, groups and fault reporting |
| Fire alarm | Dry contact or monitored interface | Read | Fail-safe state and cause-and-effect matrix |
| Legacy plant | Dry contact, RS485 or API | Read and write | Protocol documentation and spare parts |
| Energy dashboard | API, Modbus or pulse | Read | Interval, time sync and data ownership |
Project images
3 images
Frequently asked
01Can the controller integrate KNX, BACnet and Modbus at once?
Yes, through native interfaces and gateways. The constraint is engineering capacity and point ownership, not the number of protocol names on a brochure.
02Do we need to replace the existing BMS?
Usually not. The existing BMS can remain in place for plant control and be supervised through BACnet, Modbus or dry contacts. Replacement is a separate commercial decision.
03Who supplies the gateway?
That should be written into the interface matrix. The party that owns the protocol usually supplies and configures the gateway, and the integrator verifies the points.
04Is wireless integration acceptable?
It can be, for sensors and retrofit devices. For critical sequences, prefer a wired path or confirm that the wireless link has a defined failure state.
05How do we prove integration works?
With a signed point list and a witnessed test: read, write, fault, recover. A screenshot of a dashboard is not evidence.
Next step
Bring us the building.
Tell us the building type, systems in scope and the outcome you need. We will map the shortest path to a working system.