Embedded architecture
A reusable firmware model for low-power sensing, diagnostics, and replay history
The current repositories show more than one isolated firmware branch. They reveal a reusable device architecture: sensor acquisition, compact advertising, configuration channels, replay history, diagnostic streaming, storage, and board-specific power behavior. That is why RoboMeshOS can act as an embedded framework and not only a collection of old device projects.
Sensing and capture
Temperature, humidity, pressure, audio, scale, counter, dust, CO2, and board-specific peripherals.
Runtime scheduling
Timers, wakeups, and power-aware control decide when sensing, advertising, logging, and replay should happen.
Local data model
Current sample, persistent settings, and historical ring-buffer or flash-backed records.
BLE application layer
Advertisements, configuration characteristics, stream notifications, replay, and diagnostics.
Gateway and service tools
Gateways and mobile apps read the device state, request backlog data, change configuration, and diagnose behavior.
Device-side interfaces already visible
Advertisement payloads
The latest compact sample is broadcast in BLE manufacturer data so nearby tools can detect status without always opening a connection.
Configuration characteristics
API key and configuration values are exposed through device-specific characteristics, allowing setup and service actions from mobile tools.
Replay characteristics
Historical samples can be streamed on demand, which is why gateways can recover missed readings rather than only showing the current state.
Diagnostics streams
Higher-rate live data, audio-related streams, or counter-focused diagnostics help technicians validate real behavior in the field.
Storage and migration
Several families treat history and settings persistence as part of normal operation, including migration or continuity behavior after restart.
OTA and boot path
Bootloader-related targets and update behavior are already part of the embedded story, which matters for product lifecycle and maintainability.
Example BLE interaction blocks
Passive read path
Best when the client wants fast, low-touch state awareness from sleeping or battery-sensitive devices.
Device samples sensor values
-> packs latest sample into advertisement payload
-> gateway or mobile app scans nearby advertisements
-> UI shows current value, battery, and device identityReplay recovery path
Best when a collector needs to catch up on historical rows missed since the last successful upload.
Gateway discovers supported device
-> opens GATT connection
-> enables replay notifications
-> writes replay request with cursor/time limit
-> receives historical samples until end marker
-> stores rows locally and updates cursorDevice families and hardware surface
Hive Heart and richer sensing
Environmental values plus audio-derived fields show how the framework supports denser device payloads and diagnostics.
Scale and measurement hardware
Weight-focused logic and board caveats demonstrate that calibration and hardware quirks are handled as first-class engineering concerns.
Counter and event devices
The counter line proves that the platform is not limited to slow analog sampling and can support event-style sensing and inspection.
Hardware exports for derivative boards
Heart, scale, enviro, external, gateway, counter, relay, dust, temperature-map, and other board assets already exist with source and manufacturing exports.
User view
Reliable measurements, long battery life, simple onboarding, and serviceability are what the user experiences from good firmware design.
Integrator view
Existing boards and protocols reduce hardware and embedded project scope, making custom deployment planning much safer.
Programmer view
Protocol docs, setup guides, shared libraries, and platform ports create a realistic foundation for custom sensors or board migrations.
Industry fit
Smart farming, smart metering, smart home, smart city, and smart school deployments all benefit from the same low-power + replay-capable device pattern.
Why developers want to build on this
It behaves like a framework
Common patterns repeat across the repos: advertisement-first telemetry, config characteristics, replay history, diagnostics, and board-specific power care.
It already spans multiple platforms
Silicon Labs-based code and Nordic Zephyr ports show a clear path for keeping product behavior while evolving hardware choices.
It is practical for vertical customization
Most custom projects can keep transport and lifecycle behavior intact while changing only payloads, boards, sensors, business logic, and UI.
Embedded framework anatomy
Reusable firmware around a stable device core
A new sensor family should replace drivers and payload mapping, not reimplement scheduling, persistence, BLE services, diagnostics, and replay from zero.
Firmware responsibility ring
The center is the domain sample. The ring contains the reusable runtime capabilities that protect and transport it.
device
sample
Sensor adapter
Initialization, calibration, acquisition, validation, and units.
Power scheduler
Wakeup, sampling cadence, advertising window, and sleep policy.
Persistent history
Flash records, ring buffer, sequence cursor, and replay continuity.
BLE contract
Advertisement, configuration, stream, replay, DFU, and diagnostics.
Illustrative energy budget
A design tool for discussing where firmware optimization matters.
Porting checklist
1. Map board pins and buses
2. Implement sensor adapter
3. Define payload version
4. Configure storage capacity
5. Verify BLE and replay contract
6. Measure sleep and peak current
7. Validate DFU and diagnostics