rotorloop
Docs contents

Docs / Start

Connecting systems

What to have ready for BACnet, Modbus and gateway-based systems.

Rotorloop connects to each system with a driver in the Connector. Many brands are reached through one of a few protocols, so the setup below covers most sites. For the status of each brand, see Integrations.

DriverStatusUse it for
SimulatorWorkingTraining and evaluation without real equipment.
BACnet/IPIn testingMost commercial building controllers, BACnet MS/TP behind a BACnet router, and VRF central controllers with a BACnet option.
Modbus TCPIn testingMeters, drives, generators, PLCs, and Modbus RTU devices behind a Modbus gateway.

Drivers marked In testing pass their tests against simulated BACnet and Modbus devices, but have not yet run on a live building. Their settings may still change. We set them up with you during early access.

BACnet/IP

What to have ready

  • The IP subnet the controllers are on, and whether the Connector's computer is on it.
  • If the controllers are on another subnet: the address of the BACnet router in front of them. Rotorloop can be pointed at those devices directly. Registering with a BBMD as a foreign device is planned.
  • Optional: the range of device instances to include, to skip devices you don't want shown.
  • A points list from your controls contractor helps. Rotorloop suggests what each point is (for example ZN-T is a room temperature), and a person confirms.

How the driver works

  • Discovery sends Who-Is and lists each device that answers, then reads each device's object list, names, units and present values.
  • Values are read in batches with ReadPropertyMultiple where the device supports it, and one property at a time where it doesn't.
  • Changes are written to the point's priority array at the point's priority (default 8, allowed 3–16, never 1–2). When a hold ends, Rotorloop writes null at the same priority. That hands control straight back to the controller's own logic.
  • Rotorloop never writes inputs or objects without a priority array, because control couldn't be handed back. Anything named like fire, smoke, sprinkler or emergency equipment is marked life-safety and never written.
  • Small controllers: large replies are split into smaller requests. Older controllers without ReadPropertyMultiple are read one property at a time.
  • Values are polled every few seconds. Change-of-value subscriptions are planned.

BACnet MS/TP

MS/TP devices on RS-485 trunks are reached through the site's BACnet router (often built into the supervisory controller). Discovery finds them like any other BACnet device. To list one by hand, give the router's IP address plus the MS/TP network number and the device's station address. Rotorloop asks MS/TP devices for less at a time, because those trunks are slow.

Modbus TCP

What to have ready

  • Each device's IP address and Modbus unit ID.
  • The device's register map from the manufacturer's manual: register numbers, data types (16-bit, 32-bit, float), scaling and units.
  • Which registers are safe to write. Modbus has no priorities and no "release", so see the note below.

Common gotchas

  • Off by one. Manuals list registers as 40001 or as 0-based offsets. If every value looks wrong or shifted, the numbering is the first thing to check.
  • Word order. 32-bit values and floats span two registers, and makers disagree about which comes first. A value that's nonsense but stable usually means the word order is swapped.
  • Scaling. Many devices send 215 to mean 21.5. The register map says what to divide by.

Holds on Modbus

Modbus devices have no priority array, so ending a hold means writing a value back. Each Modbus point that may ever be changed needs a release rule in its setup, and there are two kinds:

  • Restore: Rotorloop writes back the value that was there before its first change. That value is saved on the Connector's disk, so a restart in the middle of a hold still restores it.
  • Fixed value: Rotorloop writes a set "automatic" value, for example a mode register's Auto setting.

A point without a release rule stays read-only, and the app says why. Agree the release rule for each writable register with your controls contractor.

Reading

Registers close together are read in one request. A wrong register number faults only that point. If one device behind a gateway stops answering, it shows Offline and the rest keep working.

Systems behind a gateway

VRF systems (Mitsubishi Electric, Daikin, LG, Samsung and others), lighting (DALI, KNX) and older field buses (LonWorks, Modbus RTU) usually connect through a gateway or central controller that speaks BACnet/IP or Modbus TCP. Rotorloop then talks to the gateway. Check two things with your installer:

  • The BACnet or Modbus option is licensed and turned on in the central controller. On several VRF controllers it's a paid add-on.
  • Which points the gateway exposes. Some expose only on/off, mode and setpoint per indoor unit. That's enough for most rooms.

Not on the list?

Tell us on the early-access form. Requests from early-access sites decide which drivers come next.

Applies to Rotorloop 0.2 (development preview). Last reviewed November 2026.