Arcturus Intelligent Energy Control System
Integration overview for IT teams
No direct access to your building network required
Our system connects through the cloud services your BMS already uses.
Integration architecture
Your building
Vendor cloud
Arcturus
No direct traffic between your building and our platform
* Connection method varies per vendor:
- • BMS: typically over the building network (Ethernet/technical network).
- • Air-quality sensors: often on a dedicated mobile link (LTE/4G), independent of your building network.
- • Niagara N4 (MQTT): your MQTT broker must be reachable from our cluster, which means a firewall opening on your side. The "no inbound connections" and "no firewall changes" items above apply to cloud-connected BMSes only.
Secure API communication (cloud ↔ Arcturus)
- • TLS encryption: all traffic is encrypted in transit.
- • API tokens: per-integration unique keys for authentication.
- • Vendor-native authentication: each integration uses the vendor's own auth (OAuth 2.0, signed tokens, or service-account keys, depending on the BMS).
- • EU-hosted: Arcturus runs in a European data centre.
Parameter access requires manual approval
Your side
The BMS API must be configured to expose specific parameters. You decide which data points are available.
Our side
Only parameters that have been explicitly configured in the system can be accessed. All mappings are defined up front.
Arcturus cannot expand parameter access on its own
Arcturus cannot expand its own access. Every parameter is pre-defined and approved by people on both sides of the interface.
What we do NOT need
What we need
Security boundaries
| You control | You and your BMS handle | We control |
|---|---|---|
| Your building systems and network | API authentication | Arcturus optimisation |
| Decisions about granting access | Secure data transport | Platform security |
| User approval | Rate limiting and logging | Dashboard and access management |
Failsafe: if Arcturus becomes unreachable
The BMS always retains local control authority. Our system only delivers optimised setpoints and can be turned off at any time. If we become unreachable, the building keeps running on its local default settings.
Data handling: what we read and write
What we read (from BMS and sensors)
- Temperatures (indoor/outdoor/supply/exhaust)
- CO₂ levels
- Humidity
- Fan speeds / airflow
- Operating status (on/off/alarm)
- Energy consumption (when available)
What we write (setpoints)
- Temperature setpoints
- Airflow setpoints
- Schedules (when activated)
Note: we only write setpoints — the actual regulation is always performed locally by the BMS.
Data retention: historical telemetry is kept for analysis and reporting. The operational data we collect from the building (temperatures, CO₂, fan speeds, setpoints, statuses) contains no personal data. Administrator accounts for the platform itself are managed separately through standard sign-in.