Docs / Using Rotorloop

Safety model

Every rule a change passes before it reaches a controller.

Rotorloop is built on the assumption that a mistake in an app should never become a problem in a building. Every change, from any person, passes all of these checks at the site, in the Connector, before anything reaches a controller. The same checks run whether the request came from the phone app, the desktop or an automated schedule.

The rules

1. Read-only by defaultEvery point starts read-only. An admin must allow changes on each point. Readings, like a room temperature, can never be changed.
2. LimitsEach changeable number has a lowest and highest allowed value. On/off and mode points have a list of allowed values.
3. Not too oftenA minimum time between changes to the same point stops rapid back-and-forth.
4. Equipment protectionStart/stop points can have a minimum on-time and off-time, to protect compressors and motors from short cycling.
5. Life safety is off limitsFire, smoke control and emergency points are never written, whatever any setting says.
6. Polite priorityOn BACnet, changes are written at priority 8 by default. Admins can choose 3–16. Priorities 1 and 2, reserved for life safety, are never used.
7. Every hold endsEach change is a hold with an end time: 2 hours by default, 12 hours at most. When it ends, control goes back to the building's own logic.
8. Ending is always allowedReleasing a hold that Rotorloop made is always allowed, even if the point has since become read-only. Making a point read-only releases its active holds at once.

When the internet drops

Your building runs on its own controllers, so it keeps running. The Connector keeps the hold timers on its own disk, so holds still end on time with no internet, and after a restart. While a site is offline the app shows that clearly, with the time of the last reading, and accepts no changes.

What gets recorded

Every attempt is recorded: who asked, what, the value, and whether it was applied or blocked and why. Blocked attempts are recorded too, because they're often the most useful. See Activity log.

What Rotorloop does not do

• It doesn't change controller programs, schedules or configuration. It only writes values to points an admin allowed.
• It doesn't take over priorities 1–2 or touch life-safety systems.
• It doesn't keep anything held forever. There is no "permanent" option.

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