Digital Interoperability Protocol

Purpose

This protocol defines how Orbita's electronics subsystem communicates — between sensors, actuators, the monitoring software, and third-party devices. Following this spec allows any compatible device to integrate with an Orbita unit.

Communication Protocol

MQTT is the primary messaging protocol. It is lightweight, well-suited for constrained IoT devices, and supports pub/sub patterns for real-time sensor data.

• Broker: each Orbita unit runs a local MQTT broker
• QoS: level 1 (at least once) for sensor readings; level 2 (exactly once) for actuator commands
• TLS: required for any non-local connections

Topic Structure

orbita/{unit_id}/sensors/{sensor_type}
orbita/{unit_id}/actuators/{actuator_type}
orbita/{unit_id}/status

Examples:

• orbita/unit-001/sensors/temperature
• orbita/unit-001/sensors/humidity
• orbita/unit-001/actuators/ventilation
• orbita/unit-001/status

Payload Format

All messages use JSON. Example sensor payload:

{
  "timestamp": "2026-03-09T12:00:00Z",
  "value": 22.5,
  "unit": "celsius",
  "sensor_id": "temp-01"
}

Example actuator command:

{
  "command": "set",
  "value": true,
  "actuator_id": "vent-01"
}

Sensors

Placeholder — the electronics subsystem is in early planning.

Planned sensor types:

• Temperature (indoor/outdoor)
• Humidity
• Energy production (solar panel output)
• Energy consumption
• Water level (rainwater tank)
• Air quality (CO2, VOC)

REST API

Placeholder — to be defined alongside the monitoring software.

The Orbita monitoring application will expose a REST API for:

• Querying historical sensor data
• Sending actuator commands
• Retrieving unit status and configuration

Third-Party Integration

Devices can integrate with an Orbita unit by:

1. Connecting to the unit's MQTT broker
2. Publishing/subscribing to the topic structure above
3. Using the JSON payload format specified in this document

Authentication, device registration, and discovery mechanisms will be defined in future versions.