The Simulator launches a synthetic flock — GPS sentinels, BLE ear tags, optional scripted cast-ewe incident — that publishes the real MQTT contract. The ingest treats it exactly like live hardware, so everything downstream (map, alerts, analytics, drone response) behaves as it would on the hill.
The Simulator page: service status card and the flock simulation variables

​
Service status

The status card shows the simulator service: running (with live epoch progress and message count), idle, error, or offline if its container isn’t up. Admins get Launch simulation and Stop buttons; changes reach the service within seconds — no restarts.

​
Flock simulation variables

Everything about the synthetic mob is configurable and stored in the database:
  • Farm & topic — which farm slug the simulator publishes under, and the MQTT topic root (must match the ingest’s).
  • Flock shape — number of GPS sentinels and BLE ear tags, epochs to run (each epoch is 5 simulated minutes), and the wall-clock tick per epoch.
  • Where — an origin point, or pin the mob inside the farm boundary or a specific field, plus the BLE relay range.
  • The incident — the Cast-ewe incident switch casts a ewe at a chosen epoch; her emergency beacon fires about two epochs later and travels the whole alert pipeline: dashboard, Alerts page, webhooks, drone response.
  • Tags send behaviour labels — off means the server-side classifier does the work, exactly as with unlabelled hardware.

​
Drone flights tab

The second tab tunes the simulated aircraft: time speed-up, telemetry tick, battery drain and failure thresholds, climb rate. Re-read before every flight, so tweaks apply to the next mission immediately.
A good demo run: keep the defaults (2 sentinels, 15 tags, cast at epoch 25), launch, and watch the dashboard populate. When the cast beacon fires, resolve it as Ewe righted and check Welfare Events — that’s the full Sentinel loop in ten minutes.