Building automation
AI for building automation, inside limits you declare.
Energy optimisers, fault detection and facility assistants all end up writing setpoints. xZane sits between the model and your BMS. Every write is checked against a schema you declare, and the frost, high-limit and interlock logic you already have stays in charge.
{
"device_id": "ahu.level2_east",
"intents": {
"ahu.supply_air.set_temperature": {
"celsius": { "min": 16, "max": 24 }
},
"ahu.fan.set_speed": {
"percent": { "min": 30, "max": 100 }
},
"ahu.mode.set": {
"mode": { "enum": ["occupied", "unoccupied"] }
},
"ahu.sensor.supply_temperature": {},
"ahu.stop": {}
},
"safety": {
"reflex": true,
"reset_intent": "ahu.safety.reset",
"stop_intent": "ahu.stop",
"shim_url": "http://127.0.0.1:8092",
"heartbeat_timeout_sec": 3.0,
"boot_grace_sec": 10.0
}
}The problem
AI projects in buildings run into the same three things.
A protocol per system
BACnet on the air handlers, Modbus on the plant, KNX on lighting. Each AI project reaches them its own way, and the glue code stays with that project.
No agreed limit
A client asks what the AI is allowed to change. The answer should be a file they can read, not a promise.
No trail
When a zone is too warm at 15:00, someone has to know which model asked for what, and whether the request was allowed.
The schema
A limit the client can read.
You declare each device once, in a file. For the air handler above, the model may set supply air between 16 and 24 °C, run the fan between 30 and 100 percent, and switch between occupied and unoccupied. It may read the supply temperature at any time. It may stop the unit. It may not ask for anything else.
A request outside those limits is rejected before it reaches the controller, and the rejection is logged with the model that asked. The same schema serves every model, so changing from one AI to another changes nothing in the building.
Safety
xZane puts the device’s built-in safety above the AI.
Frost protection, high-limit thermostats, fire and smoke damper interlocks and BMS alarm logic already exist, and they stay where they are. xZane does not replace them and is not a safety-rated device. It reads their state and obeys it.
The safety reports in
When a device's own safety trips, it tells xZane. xZane then refuses AI commands to that device until it clears.
xZane reports alive
xZane tells the safety it is running. If that signal stops, the device's safety trips on its own.
The AI can ask, not force
The AI may request a reset. The device's safety re-reads its inputs and decides. If the fault is still there, it latches again.
One unit at a time. A tripped air handler is refused while the other air handlers, the plant and the lighting keep working.
The command path
From a model's request to a controller.
In practice
What integrators put on top of it.
Energy optimisation
An agent proposes supply-air setpoints from forecasts and tariffs. The schema holds every proposal inside the comfort band you set.
Fault detection and diagnostics
A diagnostic agent gets the sensor reads you expose and no write intents, unless you add them.
Ventilation by occupancy
Fan speed follows occupancy, with a minimum airflow written into the schema.
A facility assistant
A facility manager types "make level 2 cooler". The model proposes a setpoint change. The schema decides whether it is allowed.
What you write and what you keep. In a pilot we write the adapter for one controller together with your engineers, for example BACnet/IP or Modbus. You own it and reuse it on the next building. Adapters for further protocols follow the same pattern.
Pilot
One controller, one use case.
A bounded sprint: one device, one use case, four to six weeks. At the end xZane is running live on your hardware and your engineers understand every part of it.
Standard pilot
€10,000
One controller · standard hardware · 4 weeks
- xZane running live on your device
- An adapter written with us and owned by your engineers
- A ledger of every command, rejection and safety stop
- SDK access, so you can write future adapters without us
- 2 to 3 hours a week of an engineer's time
Extended pilot
€25,000
Several systems or custom hardware · 6 weeks
- Everything in the standard pilot
- Multi-device integration, for example air handlers and plant together
- Adapter development for custom hardware
- Ground Control UI, so operators watch AI decisions in real time
Ongoing licence: €400 to €600 per device per year. A 10-device installation runs at €4,000 to €6,000 a year. xZane installs on a central hub, and devices connect through adapters.
Start a conversation
A described building system is enough to start.
Tell us which controller and which protocol, and what you want a pilot to prove. A 30-minute call is usually enough to scope it. No commitment required.
Or write to [email protected]
What we need from you
- One controller or test setup
- A use case: what you want it to do through xZane
- 2 to 3 hours a week of an engineer's time