ThinkLink で複数センサーを部屋へ集約する：仮想資産と欠測

部屋に必要な指標を決める

平均温度、最高温度、最後の読取りは異なる問いへの答えです。用途を決めてから対象、単位、計算法を定義します。吹出口と人のいる場所の二台を単純平均しても、快適性を適切に表すとは限りません。本稿は集約の設計方法であり、個別建物の制御しきい値は指定しません。対象範囲は確認済みの関係や一覧から決め、端末名に同じ部屋番号があるだけで追加しないでください。追加と除外の担当も定め、設置変更が知らないうちに統計の意味を変えないようにします。

元端末を資産へ関連付ける

ThinkLink は VIRTUAL 資産で複数端末の通知を受けます。from_eui から to_eui へ向け、必要な属性種別を通知対象にします。方向、対象型、物モデルの関連付けを照合し、通常端末へ接続しただけで集約が動くと期待しないでください。各メンバーから一つずつ有効値を送り、資産側で出典が正しいか確認します。通知対象は実行の契機を決めるため、無関係な設定変更まで集計させる全項目通知を安易に選びません。識別には EUI、読みやすい表示には名称を使います。

各端末の値と有効性を保持する

到着した一台と、他の保存済みメンバーをスクリプト内で区別します。公式の処理データ機構で値や必要時刻を保持できますが、その時刻が計測か受信かを明示し、欠けた計測時刻を作りません。新しいスクリプトでは中間状態を process_data に置き、最終指標をテレメトリとして返します。未受信、期限切れ、実測ゼロを同一に扱わないでください。期限切れをいつ再評価するかも決めます。イベントがなければ関係通知は再計算されず、時間比較を書くだけで独立したタイムアウト処理にはなりません。

欠測と重複を含めて試す

少数のメンバーで手計算の期待値と資産の出力を比較します。二台正常、一台だけ受信、重複、順序逆転、不適合単位、メンバー除外を試してください。重複で台数が増えず、古いサンプルが新しい有効値を無条件に置き換えないよう、案件のスクリプトで処理して検証します。結果には有効台数や欠測説明も添えると画面で判断できます。積算エネルギーと平均温度は同じ計算法ではなく、前者はリセットや交換を扱う必要があります。受信する積算値を毎回加算してはいけません。

1. メンバーと指標の意味を確認する。
2. 各端末から資産への通知を試す。
3. 欠測、重複、逆順、除外を検証する。
4. まず観察し、制御は別途検証する。

データ確認後に制御へ進む

資産の結果をまず画面で観察し、台数、更新時刻、欠測表示が現場と合うかを確認してから制御や通知への接続を検討します。制御先の識別、権限、物理的な応答は別に検証し、集約が正しいから下り通信も確実とは判断しません。対象一覧、計算式、単位、有効期間、再計算条件、試験サンプルを渡します。センサー交換や範囲変更では関係を見直し、古いメンバーの保存値も処理してください。撤去した端末の値が滑らかな集約結果に残り、判断を誤らせることを防ぎます。