Baseline: docker stack, provisioning tools, test-data, gateway-as-files (pre-PrimeBAT build)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

test-data/README.md

@@ -0,0 +1,69 @@
+# Test Data — Simulated Alarm Activity
+
+Generates realistic alarm journal data for building/testing the alarm analysis dashboard.
+Everything here uses native Ignition features only (memory tags + tag alarms + Jython).
+
+## Files
+
+- `simulation_tags.json` — Ignition 8.3 tag export: a `BuildathonSim` folder with 49
+  Boolean memory tags across 5 plant areas (`Intake`, `BoilerHouse`, `Packaging`,
+  `Utilities`, `TankFarm`). Every tag has one Equality alarm (active when the tag is
+  `true`) with priorities spread across Low / High / Critical.
+- `alarm_simulator.py` — Jython script that drives those tags. Full usage instructions
+  are in the header comment.
+
+## Setup (after the gateway + journal are configured per the main README)
+
+### 1. Import the tags
+
+Already done if you ran `python3 tools/provision.py provision` (it imports this file
+through the REST API; re-run `python3 tools/provision.py import-tags` after editing it).
+Manual alternative: Designer → Tag Browser → select the `default` tag provider root →
+right-click → **Import Tags** → choose `simulation_tags.json`. Either way you should see
+`BuildathonSim/<Area>/<Tag>` folders appear.
+
+### 2. Install the simulator (gateway timer script — recommended)
+
+1. Designer → **Project Library** → new script named `alarmsim` → paste the contents of
+   `alarm_simulator.py`.
+2. **Project → Gateway Events → Timer** → add a script:
+   - Delay: `5000` ms, Fixed Delay, Dedicated thread
+   - Body: `alarmsim.tick()`
+3. Save the project. Alarm events start flowing into the journal immediately and keep
+   running as long as the gateway is up (no Designer needed).
+
+Alternative: paste the whole file into the Designer **Script Console** and call
+`run_console(minutes=30)` — simpler, but it blocks the console and stops when you close it.
+
+### 3. Let it run
+
+Give it 30-60 minutes for meaningful analytics. Roughly every 30-60 minutes one area gets
+a flood burst; to force one for a demo, call `alarmsim.force_flood()` (e.g. temporarily
+from the timer script, or from the console if using console mode). `alarmsim.reset()`
+clears all sim tags and state.
+
+## Patterns generated (what your analytics should detect)
+
+| Pattern    | Tags                | Behavior                                                    |
+| ---------- | ------------------- | ----------------------------------------------------------- |
+| Baseline   | 40 tags, all areas  | Random activations, active 30 s–5 min, ~3-4/min plant-wide  |
+| Chattering | `*_Chatter` (3)     | Re-trigger every 30–60 s, active 5–15 s each cycle          |
+| Standing   | `*_Standing` (2)    | Active from first tick, never clear                         |
+| Fleeting   | `*_Fleeting` (4)    | Active < 10 s (2–8 s), ~1/min                               |
+| Flood      | one random area     | 15+ activations within 10 min in a single area              |
+
+## Querying the journal
+
+Events land in MariaDB tables `PrimeControls_alarm_events` / `PrimeControls_alarm_event_data`
+(created automatically on first event). The **plant area is the folder in the alarm's
+source path** — e.g. `prov:default:/tag:BuildathonSim/TankFarm/T101_LevelHigh:/alm:...` —
+so area analytics can group on the path segment after `BuildathonSim/`. Priority is stored
+on the event; `eventtype` 0/1/2 = active/clear/ack.
+
+Quick sanity check from your SQL client (localhost:3306, user `ignition`/`ignition`):
+
+```sql
+SELECT source, displaypath, priority, eventtype, eventtime
+FROM PrimeControls_alarm_events
+ORDER BY eventtime DESC LIMIT 20;
+```