SiloSentryWatch the installed equipment.
Choose the class, site or tag cohort, preview its members and set the offline condition. Sam can check how far a problem extends before treating one report as a fleet outage.
← Meet the SiloSentry product
The next version needs building.
The next version needs building.
The last one needs supporting.
SiloSentry makes grain-level monitors. The same small team develops the product, gets it working at customer sites and picks up the phone when a reading looks wrong.
Follow one monitor through their work. See where Dataplicity helps the team carry more of the job.
Follow the first installation
01
“We know the sensor. We need to get the interface right.”
Alex is preparing the monitor for Ashton Mill. A new sensor revision has changed the interface, and the installation date is approaching.
Work through the unfamiliar part.
Alex brings the exact board revision, sensor datasheet and interface drawing to Equidna, Dataplicity’s AI hardware and firmware specialist. The discussion can work through the Linux interface, permissions and a test plan.
Alex records the revision B interface decision and bench-check plan in the shared North Silo folder. Sam has the baseline before the site visit; the team conversation explains which version to use and what still needs testing.
Sam can prepare the installation without asking Alex to reconstruct the decision.
Illustrative engineering brief
North Silo · interface review
“Here is the sensor datasheet and revision B drawing. Help us check the interface to our Linux controller, decide how to detect a failed reading, and plan the bench tests.”
Sensor datasheet.pdfInterface review — rev B.mdBench-check plan
Before this leaves the bench
- Confirm the physical interface and electrical limits.
- Test real readings and a disconnected sensor.
- Record what the software reports when a reading is unavailable.
Implementation notes and engineering guide
Alex uses the current Applications workspace: Data for the Silo and strapping-table business objects, Customer app for reusable pages, Automations for alerts and actions, and Test & publish for the version customers run. The application converts measured height in millimetres into the mill’s calibrated volume in m³.
SiloSentry owns the sensor choice, calibration, signal conversion, firmware and local safeguards. AI guidance supports the engineering work. The team explicitly supplies conversation context; storing a file or linking a board does not automatically give a specialist access to it. Shared specialist advice is read-only. Plan and usage limits apply.
Check the assistance workflow
02
“It’s working here. Will someone else be able to support it?”
Sam installs SS-AM-01 at North Silo. The mill’s network is different from the workshop’s, and Alex is back at the bench.
Leave a supportable installation.
Sam connects the supported Linux monitor using the Dataplicity agent, checks its identity and assigns it to Ashton Mill. The team verifies a sensor reading through to the customer view.
In the customer portal, Sam opens Edit to bind SS-AM-01 and set its thresholds. The saved settings stay readable on the page. Manage calibration opens the saved curve and points in a modal. Sam can upload a CSV, drop a file or paste spreadsheet rows, then review the complete replacement before saving the table together. Cancel leaves the saved values unchanged.
Sam adds the calibration table and commissioning context to the same North Silo folder as Alex’s interface review. The support record keeps completed software checks separate from the physical checks still required on site.
The next person has the unit, the site information and a clear record of what was checked.
Illustrative installation record
Ashton Mill / North Silo
- Monitor
- SS-AM-01
- Installer
- Sam
- Interface baseline
- Interface revision B
- Shared folder
- Ashton Mill / North Silo – SS-AM-01
- Device identity checked
- Reading compared with the site reference
- Customer access tested
- Calibration and handover record saved
Handover note
Use SS-AM-01 when calling support. The shared folder carries the revision B baseline, calibration and investigation. Add physical inspection results when they are available.
Installation requirements and worked guide
The agent needs supported Linux and outbound connectivity. Sam uses the existing installation route to put it on the device and tests the actual site network. Product readings need a sensor/application integration and validated calculations. Files and planning boards support the team’s handover; they do not perform physical commissioning.
Build and connect a level monitor
03
“Can the customer get the answer without calling us?”
Jo prepares Ashton Mill’s customer application. The mill needs to plan grain movements and spot readings that need attention.
The customer’s equipment. Their daily view.
SiloSentry configures its product readings, permitted settings and branded Customer Portal. Jo assigns the mill’s equipment and tests that its users can see only the sites and actions intended for them.
The operator can check the volume history and low-level condition directly. They can see when a reading is out of date and have a specific monitor to name when they need help.
Routine questions have a useful first stop, and engineering access stays with SiloSentry’s team.
SiloSentryAshton Mill
Your grain store
North Silo
Wheat · Monitor SS-AM-01
Current volume
68.2 m³
120 m³ capacitySample reading · 09:42
Volume historyLast 24 hours
Illustrative customer view. These controls change sample data on this page only.
Product integration and customer access
The team integrates the level stream, validates silo geometry and calibration, and configures the customer interface and roles. The readings shown here are illustrative volumes. The example does not forecast deliveries or place replenishment orders. Customer Portal availability and branding follow plan limits; granting customer access does not grant a terminal or unrestricted engineering controls.
SiloSentry product contract and handover guide
04
“The reading hasn’t changed. Is the silo empty or is something wrong?”
The mill calls about North Silo. In this worked scenario, the monitor is online, but its last sensor reading is ten minutes old.
See the problem in the context of the fleet.
Sam needs to know whether this is one sensor, one site or a wider problem. Fleet monitors watch a selected group of devices for connectivity loss. The product’s freshness alert answers the separate question: are new readings arriving? Here, SS-AM-01 is connected and South Silo is reporting, so the investigation starts with North Silo’s sensor data.
Give the response an owner.
When the problem needs a managed response, open an incident. Sam acknowledges it, records the checks and keeps ownership through recovery. Configured on-call paths can escalate work that nobody has acknowledged.
Keep customers informed.
Jo reviews the customer-facing wording and selects the status page. Customers can follow the impact, current action and recovery update while the team keeps working.
This worked incident is opened manually. Fleet connectivity monitors create alerts; service, heartbeat and user-impact monitoring can feed configured incident automation. The example does not imply that every sensor alert automatically pages someone or publishes a status update.
Check what is known.
Sam checks SS-AM-01 and the reading timestamp. The gateway is connected. Its last 68.2 m³ is a stale observation, not evidence that the silo is empty. The second silo is still reporting.
Choose the next step.
In a field installation, Sam would follow the sensor runbook, inspect the available logs and use authorised remote access where appropriate. In this reference run, the simulator resumes reporting so the team can exercise the recovery path.
Check the customer’s result.
A fresh 68.2 m³ reading appears and the stale-reading alert clears. The monitor is connected and the customer view is live again. Physical sensor checks still belong to commissioning and the equipment maker’s support procedure.
A useful handover when Alex gets involved.
Sam opens the SS-AM-01 team conversation with the symptom and checks already completed, linking the shared installation folder. Alex picks up from the revision B review, calibration table and commissioning record. Jo can follow the investigation and give the mill a precise update.
The next person can pick up the job without starting the investigation again.
Illustrative support handover
SS-AM-01 · North Silo
“SS-AM-01 stayed connected while its sensor report aged. Reproduced the stale-reading state, resumed the simulated reports and checked the fresh reading and alert recovery. A real installation would still need the sensor and service investigation recorded here.”
The customer’s update
“Fresh readings are visible again and the software recovery checks passed. Alex owns the startup investigation; Sam owns the commissioning follow-up.”
Support the product without assembling another software stack.
Monitoring, incident response, status pages, files and team discussion are parts of the same job. Handle them in Dataplicity, with fewer separate services to buy, connect and keep in step.
Configure the scopes, response policy and customer communication for your product. Availability and limits follow your Dataplicity plan.
Evidence, connectivity and support permissions
Logs must have been collected before they can be reviewed. Live terminal and device-service access require an online device and authorised access. An offline device can still need a local visit. AI access depends on the conversation and its permissions; a specialist invited to team chat does not automatically have device authority.
Check the full support workflow
05
“If we change this one, what about the others?”
Alex finds that the sensor service needs to wait for its interface to become ready at startup. The fix needs testing while Sam keeps the existing installations supported.
Make the next installation better.
Alex adds readiness handling to SiloSentry’s sensor software, then tests a normal boot, a delayed interface and a missing sensor on bench hardware. The team releases to a limited set of suitable monitors and reviews their individual outcomes before expanding.
Sam updates the installation checks with the startup test. Jo can explain the change to Ashton Mill, and the board carries the remaining rollout work.
A field problem can lead to a reviewed product improvement and a better handover next time.
-
Bench
Prove the behaviour.
Check real signals, missing data and restart behaviour on representative hardware.
-
Pilot
Inspect a limited change.
Choose suitable devices and review their individual outcomes.
-
Expand
Carry the learning forward.
Expand deliberately and update the notes the next installer will use.
Software delivery and operating requirements
Software delivery requires a supported, prepared runtime and a tested release process. RAUC image updates additionally require qualified images, signing, boot and recovery behaviour. An agent installation alone does not provide those. Fleet jobs and application releases serve different jobs; a successful command alone does not establish product recovery.
Choose an adoption path for existing equipmentSomeone else needs to pick up the job.
The installation record and the conversation belong with the team, so the next answer does not depend on Alex being available.
One folder follows the installation.
In Files, Ashton Mill → North Silo – SS-AM-01 holds the revision B interface review, the calibration table and Sam’s commissioning and support record. The same record carries the symptom, completed checks, recovery result and next owners.
Alex keeps the engineering baseline here. Sam adds the site and support context. Jo can read what was verified before speaking to the customer.
Read the example handover record
One conversation carries the handover.
Sam names SS-AM-01, links the folder and records what is known. Alex takes the startup-readiness investigation. Sam keeps the commissioning follow-up. Jo has the result and the remaining work, without chasing three separate accounts of the problem.
Files hold the reference material. Chat holds the discussion, decisions and handover between the people doing the work.
The team can invite an AI specialist with selected context when useful. This example conversation is between Alex, Sam and Jo; it does not imply automatic file access or device authority.
These are internal SiloSentry team records. The mill’s customer portal remains focused on its equipment; portal access does not grant access to this folder or conversation. The records and messages are authored demonstration content in an isolated local organisation. The recovery uses simulated equipment.
The example running in Dataplicity.
One application, the same Ashton Mill silos, and the current engineering and customer screens. Open a capture to inspect it.
Captured from a running local Dataplicity reference application on 27–28 October 2026, using simulated equipment, sensor observations and heartbeats. These screens exercise application configuration, calibration, history, alerts and recovery. They do not establish physical sensor accuracy, a field deployment or a remotely repaired machine. The interactive customer illustration above is a simplified explanation of the same states.
A fictional business. A concrete way to explore your own.
SiloSentry, Alex, Sam, Jo and Ashton Mill are invented. The customer view, engineering brief, installation record and support exchange are authored examples. The Files and Messaging captures show those records in the actual product. The field fault and recovery are a worked scenario, not a captured customer incident. The walkthrough uses documented Dataplicity capabilities.
Dataplicity supplies equipment access, fleet tools, customer-application capabilities and team tools. The equipment maker brings the sensing system, product engineering, configuration and physical installation.
The linked guides explain implementation, plan limits and what your team must prepare. The example makes no claim about a real customer’s savings or results.
Build, deliver and support more equipment with the team you have.
Start with a useful job for your team: work through an engineering question, connect a device, or plan the application your customers need.