SpeeDBeeSynapse を便利にする：wait_timer と gvar_pvar_collector を作ってみた
はじめに
SpeeDBeeSynapse を日々使っていると、「フロー上で表現したいのに、コンポーネントとしては用意されていない小さな処理」が出てきます。
今回は、自分の運用でよく発生していた2つの困りごとを解決するために、便利系のカスタムコンポーネントを2つ作ってみたので紹介します。
-
wait_timercollector：イベント後に一定時間待ってから次処理へ進めたい -
gvar_pvar_collector：Synapse 上で GVAR/PVAR の値を“時系列”として追いたい（Grafana確認の手間を減らしたい）
作ったもの一覧
-
collectors/wait_timer（イベント入力→指定ms待機→trigger=true出力） -
collectors/gvar_pvar_collector（定期実行→DBクエリで GVAR/PVAR を取得→列として記録）
1. wait_timer collector（リトライ間隔をフローで制御）
何のために作った？
BLE デバイスの操作などで、接続がうまくいかないケースがあります。
このとき「失敗時は待機せずスキップ」していると、すぐ次の処理に進んでしまい、再試行までの間隔を取りづらいです。
もちろんシェルスクリプト側で sleep 60; のように待ちを入れる方法もありますが、
- “待ち処理”がフロー上から見えない
- 再利用しづらい
- シェルごとに同じ制御を繰り返しがち
という理由で、待機を collector 化してフローで扱えるようにしました。
できること
in_port1 から入力が来るたびに、指定時間待ってから out_port1 の trigger に True を挿入します。
パラメータ
wait_timer は wait_ms のみです。
{
"wait_ms": 60000
}
-
wait_ms: 待機時間（ms）。デフォルトは1000
2. gvar_pvar_collector（GVAR/PVAR を Synapse 上で“時系列”にする）
何のために作った？
Synapse では GVAR/PVAR を使って、イベント条件を複合条件にしたり、カウント変数っぽいものを作ったりできます。
ただ、Grafana 側で確認する場合は例えば次のようなクエリを投げます。
SELECT $GVAR0 FROM SPDB WHERE _TS BETWEEN $__from AND $__to
この方法だと、
- 基本的に「最新値」中心になりやすい
- 確認のたびに Grafana を開く必要がある
- “今の状態”と“どう変化してきたか”を Synapse 上の状態と一緒に見づらい
という悩みがありました。
そこで「GVAR/PVAR を一定周期で取得して、Synapse 上で参照しやすい形にする」collector を作りました。
できること（概要）
-
interval_secごとに DB へクエリ - 指定した
$GVARn/$PVARnを取得 -
variables[].columnで指定した列としてSTRINGで挿入
これにより、Synapse 上で値の変化を追いやすくなります。
パラメータ
gvar_pvar_collector の例です。
{
"interval_sec": 1,
"dbquery_url": "http://127.0.0.1:8081/dbquery",
"api_key": "",
"query_timeout_sec": 30,
"variables": [
{
"db_ref": "$GVAR0",
"column": "gvar0_value",
"label_ja": "GVAR0 値",
"description": "SQL では $GVAR0 として参照"
}
]
}
-
interval_sec: サンプリング周期（秒） -
dbquery_url: DB クエリ POST エンドポイント（例：http://host:8081/dbquery） -
api_key: DB クエリ用アクセストークン（ヘッダX-hive-api-key。認証必須環境では設定） -
query_timeout_sec: クエリタイムアウト（秒） -
variables: 監視したい GVAR/PVAR と、出力カラム名
variables[].db_ref は $GVAR0 / $PVAR29 のように指定します（$ なしでも受け付けます）。
内部で叩く SQL（概略）
定期実行のたびに、_TS の範囲で GVAR/PVAR を取得します。
SELECT <指定した $GVARn / $PVARn の一覧>
FROM SPDB
WHERE _TS BETWEEN <from_ns> AND <to_ns>
ORDER BY _TS DESC
LIMIT 1
ここでの <from_ns> / <to_ns> は、コンポーネントが内部で回しているサンプリング周期に基づく nanosecond のタイムスタンプです。
Grafanaと比べたメリット
- 参照の導線が Synapse に寄る（状態確認が統一される）
- 時系列の変化を追う運用が作りやすい
- 確認のたびに Grafana を開く手間を減らせる
注意点
-
gvar_pvar_collectorは DB クエリを HTTP で投げるため、interval_secを小さくしすぎると DB 負荷に影響します。 - 認証必須環境では
api_keyを設定し、ヘッダX-hive-api-keyに必要なトークンを入れてください（401 が出た場合は設定見直しが早いです）。 - 取得できない/失敗した場合は、出力列には空文字
""が挿入される挙動です。
まとめ
今回作った2つは、いずれも派手さはないものの、運用の手間を確実に減らす系です。
-
wait_timer：リトライの“間隔制御”をフロー上で明示できる -
gvar_pvar_collector：GVAR/PVAR の値を Synapse 上で扱いやすくし、時系列で追いやすくなる
SpeeDBeeSynapse を使い倒していると「こんな小部品欲しい」がどんどん増えてくるので、今後も便利な collector を増やしていきたいです。