# 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;
```