Robo Mesh OS

RoboMeshOS System Architecture

Architecture first

How the complete system is connected

RoboMeshOS turns physical measurements into trusted history, alerts, dashboards, and automation. The architecture is offline-first: devices and gateways preserve data locally, while the cloud unifies identity, storage, APIs, analytics, firmware, and integrations.

Telemetry and samplesConfiguration and controlExternal integrationPersistence
RoboMeshOS complete system block diagramSensors run low-power firmware, send BLE data to an offline gateway, upload through TLS or REST to HiveServer, store history and expose it to applications and integrations. Configuration travels back to devices. 1. PHYSICALSensors and actuators2. DEVICE EDGEEmbedded firmware3. FIELD EDGEMobile / fixed gateway4. TRANSPORTAuthenticated ingress5. CLOUD COREHiveServer platform6. PRODUCTSPeople and systems GPIOBLETLSDATAREST Sensors / metersTemperature, humidityweight, CO2, audiocounters, dust, relayPHYSICAL SIGNAL Hardware boardsHeart, Scale, EnviroCounter, Gatewaycustom derivatives ActuatorsRelay outputslocal control actions Device firmwareSensor driverslow-power schedulercalibration + payloadBLE advertising / GATTLIVE SAMPLE Local flash historySequence cursorring buffer / replaypersistent settings Direct clientsREST v2 capable sensorLoRaWAN device Control endpointGATT configurationDFU / replay request Gateway runtimeBLE discoverydevice recognitionlive + delta replaybatch preparationCOLLECTOR SQLite outboxLocal sensor recordsupload queue + retryreplay cursor state Field serviceDiagnostics + QRfirmware / configuration TCP/TLS :32359LEB128 framesgateway authenticationsample + Commit HTTPS REST APIProject APISensor REST v2X-Auth-Token IoT integrationsChirpStack webhookLoRaWAN uplinkpartner requests Return channelREST responsesgateway configuration HiveServer ingress + APIIdentity resolution and authorizationframe / JSON validationsample normalizationcontroller and domain routingINGRESS94 API OPS PostgreSQLsamplesdomain entitiesconfigurationRedisshared statecoordinationruntime support Domain serviceshistory, analytics, thresholds, scriptsfirmware, configuration, notifications Outbound adaptersMQTT, exports, push, external links Web appdashboards, mapsoperationsMobile monitoralerts, trendsfield recordsDiagnosticsBLE serviceinstaller toolsPartner systemsERP, GIS, BMSbilling, MQTTcustom analyticsOperator actiondecision or automation DATA IS ACCEPTED ONLY AFTER IDENTITY, VALIDATION, PERSISTENCE, AND COMMIT BOUNDARIES SUCCEED

1. Sensors and hardware

Physical values are sampled by low-power firmware and preserved in local flash history.

driverscalibrationBLEreplay

2. Gateway and field edge

The gateway discovers devices, downloads replay data, stores it in SQLite, and builds an offline upload queue.

BLE scanSQLiteoutboxretry

3. Transport and identity

Data enters through compact TCP/TLS frames, REST v2, project APIs, or ChirpStack webhooks.

TLS :32359RESTX-Auth-TokenLoRaWAN

4. HiveServer cloud core

Ingress normalizes samples. PostgreSQL stores history and domain data; services run analytics, thresholds, firmware, scripts, and notifications.

PostgreSQLRedis94 API operationsMQTT

5. Products and actions

Web, mobile, diagnostics, and partner systems turn shared data into decisions. Configuration and commands travel back to the edge.

dashboardmobilediagnosticsautomation
Offline continuity

Device replay and the gateway SQLite outbox separate measurement capture from cloud connectivity. A temporary outage delays delivery but does not have to lose the sample.

Two authenticated paths

Gateways use compact TLS frames with commit semantics. Device-aware HTTP clients use REST v2 with a sensor API key in X-Auth-Token.

Closed control loop

Apps and integrations do more than read charts. They can update configuration, request samples, distribute firmware, run scripts, notify users, or trigger external automation.

Telemetry lifecycle

What happens to one measurement

A measurement is useful only when the system can preserve its origin, recover it after an outage, authenticate its sender, commit it safely, and turn it into an action.

Sample-to-insight pipeline

The primary gateway path shown below also explains where data can wait safely when the next layer is unavailable.

EdgeTransportCloud
01

Measure

Firmware samples a physical signal, validates it, timestamps it, and maps it into a typed payload.

sensor -> sample
02

Preserve

The current value is advertised over BLE and historical rows are retained in device flash for replay.

BLE + flash
03

Collect

The gateway identifies the device, reads live data, and requests the missing range after its last cursor.

scan + delta replay
04

Queue

Rows are written to SQLite before transmission and grouped into a durable outbox batch.

SQLite outbox
05

Upload

The gateway authenticates, sends LEB128 frames over TLS, then requests an explicit Commit response.

TCP/TLS :32359
06

Normalize

HiveServer resolves identity, validates frames, maps payload fields, and stores trusted domain data.

ingress -> PostgreSQL
07

Act

History, rules, notifications, APIs, dashboards, MQTT, and exports turn the sample into useful output.

insight -> action
Device not reachableFlash history remains available for the next replay connection.
Gateway offlineSQLite keeps collected rows in the local outbox.
Upload interruptedThe batch remains queued because Commit was not acknowledged.
Processing rejectedThe server closes or rejects the request before success is returned.

Closed control loop

How a decision returns to the physical world

RoboMeshOS is bidirectional. Users and integrations read shared state, make a decision, and send a controlled change back through authenticated services to gateways, firmware, or external actuators.

Operator-to-device path

The exact return mechanism depends on the capability: REST updates cloud state, gateways retrieve configuration, and BLE GATT or DFU applies the device-level change.

1. Decision source

  • Web or mobile operator
  • Threshold or analytics rule
  • Partner ERP, GIS, BMS, or MQTT client
  • Installer diagnostics workflow
->

2. Cloud authorization

  • Project or sensor identity check
  • Configuration and domain validation
  • Firmware, script, sample request, or relay command
  • Audit-friendly persistent state
->

3. Edge execution

  • Gateway receives desired configuration
  • BLE GATT writes device settings
  • DFU updates compatible firmware
  • Relay or external system performs the action
Physical result -> new measurement -> same trusted telemetry pipeline verifies the outcome