# `haniwers monitor` 構想と設計方針まとめ

## 🎯 目的

- `haniwers daq` や `haniwers scan` 実行中に、**別プロセスでリアルタイムに測定データをモニター表示**したい。
- **DAQ本体の動作に影響を与えず**に、安全に可視化・確認を行いたい。
- 表示対象は `RawEvent` / `ProcessedEvent` の両方。
- しきい値のリアルタイム確認は、ハードウェア的に難しいため、**データ側の傾向のみ**を見る形とする。

## 📦 ディレクトリ構成の方針

```text
haniwers/
├── monitors/                  # ← 新設モジュール（独立プロセス・可視化・分析）
│   ├── watcher.py             # watchdog による CSV 変更監視
│   ├── parser.py              # CSV → RawEvent / ProcessedEvent
│   ├── state.py               # 最新イベントの共有・統計情報キャッシュ
│   ├── dashboard.py           # Panel（または Streamlit）によるUI表示
│   └── utils.py               # 補助関数（時刻整形など）
```

## 🧩 各モジュールの責務

| ファイル名       | 役割                                                 |
|------------------|------------------------------------------------------|
| watcher.py       | `watchdog` を使ってCSVファイルの追記を監視           |
| parser.py        | `parse_raw_event()` / `process_event()` を提供       |
| state.py         | 最新イベントリストや統計情報を格納・更新             |
| dashboard.py     | `hvplot` + `panel` によるインタラクティブな可視化UI |
| utils.py         | その他ユーティリティ（時間変換、ログ整形など）       |

## 💡 使用ライブラリ

- `watchdog`: ファイルシステム監視（`tail -f` 相当の動作）
- `hvplot`: データ可視化（宣言的・直感的）
- `panel`: UI構築・再描画トリガーの管理に最適（`hvplot`との親和性◎）
- `pandas`: イベント系列データの集計・統計計算

## ✅ `daq/watcher.py` を作らない理由

- `monitor` 機能は **DAQプロセスとは独立して動作**し、別プロセス／別モジュールにするのが設計として自然。
- `daq/` の責務は **「取得」** に集中させ、**「観測・分析」** は切り離すことで責務分離（SRP）が明確に。

## 🚀 次のステップ案

1. `monitors/watcher.py`：`watch_csv_file()` を実装（`watchdog` ベース）
2. `monitors/parser.py`：CSV1行から `RawEvent` / `ProcessedEvent` を生成
3. `monitors/state.py`：共有状態（`deque` で最新イベント保持）
4. `monitors/dashboard.py`：`panel` を用いたリアルタイムダッシュボード

---
