Comparison
Loxone vs BACnet
Why Loxone and BACnet are not the same category, how BACnet devices connect to a Loxone-based platform, and where each belongs in a building control design.
A category mistake worth correcting
A comparison page usually puts two alternatives side by side. Loxone and BACnet do not fit that frame. BACnet defines how devices exchange objects and services over a network. Loxone defines a control platform: a controller, I/O, an engineering environment and an operating interface. One is a language; the other is a place where the language is spoken. You can run a building on BACnet without Loxone, and you can run Loxone without BACnet. The useful question is how they meet. Once that is clear, the commercial question becomes simpler: do you need a BACnet-native supervisor, a cross-system platform, or both? Calling them competitors leads to bad specifications, because it mixes a protocol requirement with a platform requirement. A specification can ask for BACnet devices and a Loxone-based operating layer without contradiction. The distinction also affects who you hire: a BACnet engineer and a platform integrator are not always the same person.
- BACnet: protocol, object model, services
- Loxone: controller platform, logic, operator interface
- They meet at a BACnet/IP interface or gateway
The BACnet object model, briefly
BACnet exposes plant as objects: analogue inputs and outputs, binary inputs and outputs, analogue values, multi-state values, schedules, trends and notification classes. Each object has an instance number and a set of properties. A controller reads a present value, writes a setpoint through a priority array, or subscribes to change-of-value notifications. The model is strong for plant because it is explicit and vendor-neutral. It is less expressive than a free-form programming environment: a BACnet object describes data, not the operating narrative around it. That is not a defect; it is a division of labour. The device owns its sequence, and the platform owns the coordination and the operator view. Services matter as much as objects: Who-Is and I-Am for discovery, ReadProperty and ReadPropertyMultiple for data, WriteProperty for commands, SubscribeCOV for events. Some devices implement only a subset, so the object list is a promise that must be tested. A device that exposes only present-value reads can be monitored but not controlled, which changes the operating model.
- Objects carry instance numbers and properties
- The priority array protects critical writes
- Change-of-value reduces polling traffic
- Services and object support vary by device
How Loxone works with BACnet
In a Loxone-based project, BACnet/IP is one of the field interfaces. The controller reads plant points, maps them into its own data model, and adds schedules, interlocks, alarms, trends and operator views. The BACnet device keeps its local control and safety functions; the platform supervises and coordinates. Where the plant speaks BACnet MS/TP, a gateway or router translates to IP. The mapping should be documented point by point: object name, instance, unit, scaling, read/write direction and update interval. The mapping document becomes the maintenance manual. Without it, every future change depends on the person who built the integration. Decide early whether the platform will poll or subscribe: COV reduces traffic but depends on device support and on how the device reports changes. For critical points, a heartbeat or maximum-age check prevents a frozen value from looking healthy. The plant controller should remain the authority for its own safeties. Where the gateway supports it, a diagnostic counter for failed reads is worth exposing to the operator.
- BACnet/IP as a native field interface
- MS/TP through a gateway or router
- Point-by-point mapping and naming
- Plant safety remains in the plant controller
Point mapping, naming and write ownership
Point mapping is where most integration defects are born. Put the BACnet object instance in the platform point name, for example B01-CH-01-CHWST-AI-1201, so that field support can trace a value back to the device without a separate lookup. Record the object type, instance, property, engineering unit, resolution, read/write rights, priority and the owner of each writable point. Scaling should be tested across the range, not at a single value. Alarms need the same discipline: decide which events come from the device and which are calculated by the platform, and who acknowledges them. A point name that means something to the operator is worth more than a perfect object tree that only the programmer can read. Avoid duplicating the same physical value under two names; duplicate points drift and confuse trend analysis. Treat the mapping register as a controlled document with a revision. A mapping reviewed by the mechanical contractor catches naming errors before they reach the graphics.
- Object instance visible in the point name
- Type, property, unit, scaling and rights
- Write priority, relinquish and owner
- One name per physical value
Where each one belongs
Use BACnet-native supervision when the plant specification already defines BACnet devices, when the consultant wants a conventional BMS architecture, or when the facility team is trained on a BACnet workstation. Use a Loxone-based layer when the building needs one logic model across BACnet plant, KNX lighting, Modbus meters, access events and guest rooms. In many projects both are present: BACnet for the plant, Loxone for integration and operator experience. The boundary should be written down, including who owns each point and who tests each write. The boundary is not a political compromise; it is the line between device safety and building coordination. A useful test is to ask what happens when the platform is offline: the plant must keep running on its own controls. If it does not, the design has put too much authority in the integration layer. That test should be part of the design review, not discovered at commissioning.
- BACnet-native: conventional plant BMS
- Loxone-based: cross-system integration
- Combined: plant on BACnet, logic on Loxone
- Plant must survive platform loss
Testing, limitations and handover
BACnet is not self-configuring. Device instance numbers, network numbers, BBMD settings and object names must be planned. Vendor-specific objects and proprietary properties may not be readable by a third party. Writes need priority and relinquish behaviour defined, or a setpoint can remain stuck. Testing should cover discovery, object reads, writable points, COV subscriptions, alarm delivery, network failure and recovery. A point that appears in a browse tree is not commissioned until it has been read, scaled, written and observed. The handover pack should include the device register, object export, point schedule, network diagram, test records and the names of the people who can change each device. Check performance as well as function: a device that answers in seconds under test may time out under full polling. Record firmware versions, because a vendor update can change object behaviour. Where a device cannot provide the required property, record the limitation and design around it.
- Plan device instances and network numbers
- Confirm vendor objects and read/write rights
- Test COV, priority writes and failover
- Record scaling, units and update intervals
- Hand over device register and access contacts
Loxone platform and BACnet compared
14 rows| Criterion | Loxone platform | BACnet |
|---|---|---|
| What it is | Controller platform with engineering and operator tools | Open building-automation protocol |
| Scope | Logic, integration, supervision, app | Device data exchange and plant objects |
| Data model | Platform objects and function blocks | Standard objects with instance numbers and properties |
| Services | Platform services and protocol adapters | Who-Is, ReadProperty, WriteProperty, SubscribeCOV |
| Logic location | In the controller programme | In BACnet devices or a BMS |
| Device ecosystem | Loxone devices plus open protocols | Multi-vendor BACnet devices |
| Typical role | Cross-system integration and operation | Plant, AHU, chiller and meter connectivity |
| Engineering tool | Loxone Config | Vendor BMS tool or BACnet engineering tool |
| Write handling | Platform logic with defined ownership | Priority array with relinquish behaviour |
| Reporting | Built into the platform | Depends on the BMS or supervisor |
| Strength | One logic layer across systems | Vendor-neutral plant integration |
| Limitation | Controller-centric configuration | Object model does not describe sequences |
| Handover evidence | Config backup, point list and test records | Device register, object export and test records |
| Typical fit | Integrated building operation | Plant-level control and BMS specification |
Project images
3 images
Frequently asked
01Is Loxone a BACnet system?
No. Loxone is a controller platform that supports BACnet/IP as one of its interfaces. A BACnet system is built from BACnet devices and a BACnet-capable supervisor.
02Can Loxone read BACnet devices?
Yes, through a BACnet/IP interface. The project confirms which object types, properties and services the devices expose, then maps them to platform points.
03Do we need a gateway for BACnet?
Not always. BACnet/IP devices can connect over the building network. A gateway is normally needed for BACnet MS/TP or for a network segment that cannot be routed directly.
04Can Loxone replace our BACnet BMS?
It can supervise BACnet plant and provide the operator layer, but plant safety and local sequences should stay with the plant controllers. Whether to remove the existing BMS is a separate lifecycle decision.
05Which is more open?
BACnet is an open protocol with a standard object model. Loxone is a proprietary platform with open interfaces. Openness should be judged by what you can read, write and replace later, not by the label alone.
06Can BACnet and Loxone share setpoints?
Yes, with a defined write path and priority. The project should decide which system owns the setpoint, what happens when communication fails, and how the last command is recorded.
07What should be tested before handover?
Device discovery, point reads, writable points, scaling, COV subscriptions, alarm routing, network loss and recovery. Test records should name the object and the observed value, not only the device.
08Is BACnet suitable for small buildings?
It can be, but it may be more structure than a small plant needs. The decision should follow the equipment interfaces and the operator model, not the protocol's popularity.
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.