Cloud & API Documentation

Backend architecture

Where devices, gateways, apps, and partner systems meet

The backend already contains more than raw sample storage. It includes ingress, authenticated sensor endpoints, firmware delivery, configuration, notifications, analytics, and operational entities such as hives, apiaries, inspections, tasks, and exports. That makes it a reusable cloud product core for multiple vertical solutions.

Sensor devices

Publish measurements through BLE or gateway-upload flows.

API keyBLE payloads

Gateway clients

Use the compact framed upload protocol for low-overhead synchronized delivery.

TCP/TLSCommit frames

Ingress and services

Resolve identity, accept uploads, process scripts, and route data into repositories.

IngressRepositories

Application API

Expose hives, sensors, history, maps, notifications, firmware, and onboarding flows.

REST APIDomain controllers

Apps and integrations

Web app, mobile clients, MQTT targets, reporting tools, and external partner systems.

WebMobileMQTT
Measurements + metadata
Authenticated upload
Storage + analytics
Operational use

Main cloud interfaces already present

Compact gateway protocol

Low-overhead framed TCP/TLS transport for uploads from gateways or field collectors. Suitable when power, data use, or intermittent connectivity matters.

Port 32359LEB128 framesCommit semantics

Sensor-facing REST v2

HTTP interface authenticated by X-Auth-Token for sensor-aware clients that can safely store a device API key.

GET /api/v2/sensors/currentGET /api/v2/scripts/currentPOST /api/v2/scripts/{id}/result

Product and admin endpoints

Existing controllers already expose hives, apiaries, enviro data, heatmaps, firmware versions, gateway settings, MQTT targets, notifications, and onboarding actions.

HistoryFirmwareMQTT targets

API example: sensor context lookup

HTTP request

Use REST v2 when the device or integration client already has a valid API key and needs current cloud context.

GET /api/v2/sensors/current HTTP/1.1
Host: api.robomeshos.com
X-Auth-Token: 0123456789abcdef0123456789abcdef
Accept: application/json

Response example

This lets a client discover its active hive and project context before further communication.

{
  "id": 123,
  "lastTime": 4567890123,
  "hiveId": 45,
  "name": "Hive 45",
  "projectID": 7,
  "projectName": "Demo project"
}

Gateway upload logic in pseudocode

Use the compact framed transport when optimizing field collection and low-overhead upload.

connect tls://cloud:32359
send AuthenticateGateway(apiKey)
send Hello(timeRef, preciseTimeRef, gatewayId)
for each bufferedSample:
  send SampleData(sample)
send Commit()
wait Success()

Who benefits from this layer

User perspective

The user sees shared history, alerts, maps, and operational records that remain available across mobile and web surfaces.

Result: clearer decisions, easier collaboration, and less manual reporting.

Integrator perspective

The integrator gets a ready backend core with identity, storage, domain entities, notifications, and extensible APIs.

Result: faster deployment of customer-specific portals and workflows.

Programmer perspective

The programmer gets controllers, repositories, tests, migrations, and protocol docs that can be extended instead of replaced.

Result: concrete extension points for APIs, analytics, exports, and automation.

Vertical solution examples

Smart farming and smart metering

Use gateways and compact uploads for remote sites, periodic reading, offline storage, threshold alerts, and historical review. Add farm-specific device profiles or meter-specific payloads on top of the same ingestion model.

Smart home, city, and school

Use REST APIs, web dashboards, and mobile alerts for distributed indoor or urban monitoring. Extend the domain model with rooms, zones, buildings, utility groups, classrooms, or city assets while preserving the same identity and history backbone.

Cloud control plane

From ingress to a customer action

The backend is organized as a processing pipeline. Each stage has one responsibility, a clear failure boundary, and an output that can be observed or extended.

Cloud service topology

Device traffic and product traffic enter through different interfaces but converge on the same trusted domain model.

IngestProcessServe
1

Authenticate

Resolve sensor, gateway, user, project, and API scope before accepting data.

2

Normalize

Decode frames or JSON, validate timestamps, and convert payloads into domain samples.

3

Orchestrate

Persist history, evaluate scripts, thresholds, analytics, firmware, and notifications.

4

Deliver

Serve web and mobile views, exports, MQTT targets, and partner integrations.

ID

Identity boundary

Untrusted traffic never writes directly to repositories. Controllers first establish sensor or user context.

DB

Persistence boundary

Current state, time-series history, configuration, firmware, and operations have separate lifecycles.

EV

Extension boundary

Rules, scripts, notifications, MQTT, and exports are the safe places for vertical behavior.

Illustrative processing profile

Responsibility distribution for a typical telemetry request, not a production benchmark.

IdentityPayloadHistoryLogicOutput

Developer extension points

Add value without replacing ingress or storage.

ingress -> identity context
-> normalized sample
-> repository commit
-> analytics / script
-> threshold decision
-> notification / MQTT / export