Documentation

Appearance

SiloSentry #

SiloSentry shows how an equipment maker can give customers a useful silo operation while running the installed fleet behind it. Customer operators see levels, thresholds, connectivity, and cameras for their yard; the OEM sees software versions, fleet health, logs, rollout controls, and remote support.

Customer silo workplace showing every silo and its current level at one yard
The finished silo workplace lets an operator compare every silo and spot the one that needs attention.

SiloSentry is a fictional grain-bin sensor OEM used as one coherent worked example. It is not a real customer or a separate product.

The full screenshot tour lives at silosentry.com.

Why does it exist? #

Feature pages and API reference describe what Dataplicity can do. They do not always answer the question most OEM readers actually have:

How would it look if my connected-product company used Dataplicity to manage devices after they leave the factory?

SiloSentry answers that with one invented company and one spine of work: device inventory, ops walls, incidents, Device Class Pulse, fleet jobs, Wormhole, and terminal - all attached to the same device records.

Without a setting like this, it is easy to picture Dataplicity as “remote shell plus a few tools.” SiloSentry is there so the product reads as the operations layer for a company that ships Linux devices.

The finished product #

SiloSentry sells Linux-connected grain silo monitors. A customer operator does not buy “streams” or “remote access.” They buy a way to answer:

  • Which silo am I looking at?
  • How full is it, and is that reading trustworthy?
  • Is it approaching a high or low operating threshold?
  • Is the monitor connected?
  • Can I inspect the hatch camera?
  • What should I do next?

The OEM team needs a different view of the same installed product: software version, fleet health, peer drift, logs, diagnostics, rollout controls, and remote support.

Model the product #

Create one Silo Monitor Device Class. Treat it as a production contract:

Product conceptClass definition
Fill sensorsilo_height_m stream
Derived product valueSilo level input with height, capacity, and strapping artefact
Customer warningsilo_below_low and silo_above_high boolean streams
Customer operationRun sensor test trigger action
Customer preferenceReporting interval numeric setting with safe bounds
Visual inspectioncamera-0 video source
Product contextSerial, class, site, firmware, warranty, and approved inventory facts
SiloSentry Monitor I/O section with separate Streams, Actions, and Settings sections
The class separates published values, one-off actions, and lasting settings. The screenshot shows the current section structure while its records are loading.

Design the customer's silo page #

Arrange the page in decision order:

  1. silo name, site, serial, and connection state
  2. current fill level with unit and data freshness
  3. high/low state beside the level, not in a remote section
  4. useful history for filling and dispatch decisions
  5. hatch camera and recent event context
  6. bounded test or reporting controls
  7. a visible route to SiloSentry support
SiloSentry Monitor UI Designer showing the customer camera tile within the product class layout
UI Designer turns the class contract into the page shared by every Silo Monitor. Engineering tools remain outside the customer layout.

Do not display derived volume when calibration is incomplete. Show height or raw measurement with a clear “calibration required” state until the strapping table is approved.

Hand a monitor to the first customer #

  1. Create the downstream customer organisation.
  2. Add its real-world farm or terminal sites.
  3. Create the current portal placement boundary for each site.
  4. Invite one customer administrator and one read-only test operator.
  5. Allocate or claim a staging monitor.
  6. Open Devices. Confirm the online unassigned monitor is Ready, then assign it to the correct portal network so it becomes Enabled and app-active.
  7. Sign in through the branded Customer Portal.
  8. Open the farm from Networks, then verify the monitor's vendor page on device Controls as the read-only operator.
  9. Verify that another customer's sites and products are absent.
  10. Repeat with an offline monitor and a stale level reading.
Branded customer portal network detail for a silo yard
The network is the customer's operating place and entry point to the combined silo workplace.

Operate it after shipment #

  • Release product software to staging hardware before a bounded rollout.
  • Use Device Class Pulse to find monitors that differ from healthy peers.
  • Monitor connectivity and customer-impacting level signals.
  • Keep diagnostics, logs, Fleet Jobs, Wormhole, and Remote Shell in the OEM workspace.
  • Verify recovery from the product signal or monitor, not merely from a successful command.
  • Rehearse replacement, reassignment, return, and decommissioning before the first field failure.

Dataplicity remains the real platform. SiloSentry is only the example product.

When to open it #

  • You sell (or plan to sell) a Linux-connected product and want a concrete OEM picture
  • Docs stories name demonstration fleets and you want a longer, screenshot-led version of that idea
  • You are evaluating Dataplicity beyond remote access alone

If you want shorter vertical stories instead of a full OEM tour, start with illustrative customers.