Edge Ingestion
Field readings enter through a dedicated device-facing boundary.
← Case-study library
Telemetry Platform
ShedSense
Field telemetry routed into alerts and an operations dashboard.
- Rodent role
- Distributed Systems Engineering
- Project type
- Rodent Product Demonstration
- Scope
- Telemetry intake, rule checks, alerts, and an operator dashboard.
The context
Why this system exists.
ShedSense demonstrates the software path between distributed field equipment and an operator: readings enter through a telemetry boundary, pass through processing and rules, and become status, alerts and a reviewable incident history.
The problem
The operational or engineering gap.
Teams monitoring equipment in the field needed a clear way to turn incoming meter readings into information they could act on.
Key requirements
What the system needed to make possible.
- ✓ Telemetry ingestion
- ✓ MQTT message transport
- ✓ Ordered event processing
- ✓ Rule evaluation
- ✓ Operator alerts
- ✓ Operational dashboard
- ✓ Historical incident review
- ✓ Separation between device and interface layers
What Rodent built
A system, not a framework demonstration.
Rodent built a telemetry flow that receives readings through MQTT, checks them against rules, and sends alerts and status updates to an operations dashboard.
Capabilities delivered
The working parts of the product.
MQTT Telemetry
Messages move from equipment into the processing flow through an IoT-oriented protocol.
Rule Evaluation
Defined conditions convert readings into operational events.
Alert Routing
Relevant events are surfaced for operator attention.
Operational Dashboard
Operators can view equipment state and event context away from the device layer.
Incident History
Time-ordered events support review and reconstruction of what occurred.
System architecture
Responsibilities separated into understandable layers.
- 01Edge ingestion
- 02Stream processing
- 03Rule evaluation engine
- 04Operational dashboard
Data / process flow
How information moves through the system.
- 01Edge Meter → MQTT Broker
- 02Broker → Stream Processor
- 03Processor → Rule Engine
- 04Rule Engine → Dashboard
Engineering decisions
Choices explained in operational terms.
Decoupled Ingestion
Device messages enter a processing layer instead of being coupled directly to the operator dashboard.
Rule-Based Events
Explicit rules translate telemetry into operator-relevant status and alerts.
Reviewable Timeline
Ordered events preserve enough context to inspect what happened after an alert.
Engineering challenges
Constraints addressed without inflated claims.
Device and operator separation
Telemetry intake is isolated from the interface so either layer can evolve without becoming the other’s transport.
Ordered event history
Readings and derived events retain sequence so operators can reconstruct an incident rather than see only the latest state.
Connectivity variation
The architecture acknowledges that field messages and user interfaces do not always share a continuous connection.
Technology in context
Tools selected to support the system.
Technology supports the product’s interfaces, data and release path. It is part of the engineering explanation, not the outcome itself.
Operational interface
The system as operators see it.
Outcome
A demonstrable result, without invented metrics.
The system demonstrates field readings appearing as alerts and a time-ordered incident record for operators to review.
Connected field telemetry, rule evaluation, alerts, and an operator-facing incident view.Related services
Capabilities behind this project.
From Rodent Lab Insights
Engineering notes from this project.
Build something similar
Need a system with similar capabilities?
Tell Rodent about the operational problem, users and constraints—not just the technology you think you need.