ThinkLink の MQTT 連携：AS payload と解析済み計測値を選び、転送を検証する

両システムでデータの取り決めを共有する

MQTT 対応だけでは両者が自動的に理解し合えるわけではありません。識別情報、Topic、形式、単位、時刻の意味、異常処理を決めます。検証済みメッセージを一件用意し、受信側が必要とする項目を確認します。

受信側がプロトコル解析を担当するならアプリケーション payload を選びます。業務分析だけなら物モデルの計測値を使うと重複解析を減らせます。用途は異なりますが、データ層の選択ミスによる項目欠落をネットワーク障害と混同しません。

AS と ThinkLink メッセージを使い分ける

資料では AS と ThinkLink を別の内部 Broker 種別としています。AS は復号済み上りメッセージ、ThinkLink は物モデル処理後の計測値を提供します。購読 Topic は対象層と実際の組織に合わせ、他環境の組織パスをそのままコピーしません。

接続、購読、変換の順に設定する

現在の外部 MQTT 転送は Broker と転送器を使います。送信元と宛先を設定し、宛先の動作を確認してから規則を有効化し Topic を指定します。アドレス、認証情報、証明書は接続先の要件に従います。

最初は変換スクリプトなしで元のメッセージがテスト Topic へ届くことを確認します。その後、項目名変更、絞り込み、Topic 変換を追加します。入力例と期待出力を残すと、未受信、規則での破棄、形式変更を区別できます。

既存の ChirpStack や TTN を維持する

公式ブリッジ資料では ChirpStack v4、TTN v3 との双方向 MQTT 経路を説明しています。上りは転送層で AS 形式へ正規化してから物モデルで処理し、下りは外部 NS のインターフェースを使います。ThinkLink 側のデバイス登録とモデル関連付けは必要です。

既存ネットワークを維持しながらデータ機能を使いたい案件に適します。上り一件の受信だけでは下りキュー、対象機器、受信窓の動作や全履歴の同期は証明できません。上下方向を個別に受け入れ確認します。

切断と重複の処理責任を明確にする

自動再接続するからといって切断中の全メッセージが再送されるとは限りません。転送器資料は購読復旧を説明していますが、オフライン蓄積や再送の保証は追加していません。補完が必要なら履歴照会、永続化、業務再試行を設計し検証します。

受信側では重複、時刻の順序逆転、識別情報の対応も確認します。少数のメッセージを送信時刻、Topic、受信結果で追い、切断と復旧を試します。納入するのは接続済みの画面だけでなく、説明できる業務結果です。

1. 送信元で実メッセージを確認します。
2. Topic と規則の有効化を確認します。
3. 宛先で機器、項目、単位、時刻を照合します。
4. 切断復旧を試し、追加の補完処理の要否を記録します。