Readings, devices, thresholds
The schema holds sensor registration, calibration, and threshold configuration. It holds timestamped readings and events. The Java service writes the readings. The agents read that record.
In production
Cold-chain monitoring fleet
906 wireless sensors report temperature on a food-service cold chain across school districts. The districts get a condition view they can act on, and we run the backend behind it.
In production
906 devices report temperature today.
The fleet runs on a food-service cold chain across school districts. Solutions Cay operates agentdbaas. We hold the cloud account. We manage this fleet end to end.
Wireless IoT temperature sensors sit on food-service storage. The job of the monitoring is food-safety compliance. Every reading counts toward a continuous record.
Each device carries a registration, a calibration, and a threshold. The backend keeps that configuration in one place. A reading arrives with a timestamp and lands on the record for its device.
We manage the fleet as a service. We stand up the backend, run it, and change it as the work changes. The districts do not run a console. They read the reports and the dashboards, and they get an alert when a reading crosses a threshold.
The work
Sensors on storage, one condition view.
The existing sensor hardware stayed in place. A middleware service talks to it, and a Java service takes the readings and writes them to the schema. The agents work on the record after it lands.
Food safety needs a continuous record and a threshold alert. District operations need one view of gateway and sensor health. The backend gives readings, device state, and battery level in one place.
The fleet reports real-time temperature and environmental readings. It reports gateway and sensor health too, and it reports battery level for each device. When a reading crosses a threshold, the record holds the event with a timestamp.
The middleware service moves the raw payloads to the Java service. The Java service writes each reading to the schema. From there the same record serves the agents, the reports, and the dashboards.
The backend
Four parts hold the fleet.
Payloads and reports
Buckets hold raw payloads and the weekly fleet condition report. Each report stays on file for later reference.
Every agent run
The Agent Flight Recorder keeps the tape for every agent run. You can see what each agent read and what it produced.
Exceptions and trends
Dashboards show exceptions and trends. Gateway and sensor health sit next to the temperature record.
The agents
Three jobs, run on the record.
The agents produce the weekly fleet condition report. They flag readings that cross a temperature threshold. They watch gateway or battery health and surface failures.
That is the full set. The agents read the record and act on it. The Java service does the ingest, so the agents stay on the work that people see.
The Flight Recorder holds a tape for each run. When an agent flags a reading or surfaces a failure, the tape shows the record it read. So we can answer why an alert fired and point to the record behind it.
What people see
A view people can act on.
Weekly fleet condition reports go out on a set cadence. Each one covers the fleet as a whole. A threshold alert fires when a reading crosses the limit.
The report is a condition view: the temperature record, the health of the gateways, and the state of the sensors in one place. People can act on what it shows. We keep the whole backend running behind it, and the record stays continuous, so food-safety compliance has the trail it needs.
906
Devices reporting
Weekly
Fleet condition reports