ThinkLink にデータが届かないとき：ゲートウェイ、NS、AS、計測値の順に確認

値を照合できるデバイスから始める

プロトコル資料が揃い、設定値が分かるデバイスを使います。温度を現場の基準計と比較するなど、独立して確認できる量を選ぶと、通信経路にデータがない問題と値の解釈ミスを区別できます。

型式、地域と周波数計画、参加方式、送信周期、ファームウェア、物モデルを記録します。鍵は管理された場所で照合し、公開記事やチケットの画像には載せません。識別しやすいテスト名を付けると、複数の画面で同じ送信を追跡できます。

四つの証拠が示すこと

ThinkLink はネットワークメッセージと業務データを分けて表示します。以下は標準 LoRaWAN ネットワークサービスへ直接接続する場合の確認順です。外部 NS の MQTT ブリッジ経由なら、送信元メッセージと AS 入力を先に確認します。外部データがすべてローカル NS に現れるとは限りません。

最後に成功した段階から原因を絞る

接続先が想定した基盤かを確認し、デバイスの上り送信を調べます。リセット直後や参加中は資料に従い DevEUI で参加要求を探し、参加後の通常フレームでは DevAddr と検索条件に注意します。識別子が違うと存在するデータも見えなくなります。

NS にフレームがあり AS に有効なメッセージがなければ、デバイス情報、参加状態、鍵の一致を確認します。AS に payload があるのに値がなければ、モデルの関連付け、ポート分岐、解析出力を確認します。Base64 はバイト表現なので、AS の payload が Base64 でも LoRaWAN の復号前とは限りません。

同じ送信の記録を突き合わせる

短い時間範囲を固定し、ゲートウェイ受信時刻、送信番号、AS のアプリケーションポートを記録します。その payload をモデルテストへ入れ、画面の時刻と項目値を比較します。昨日の payload と今日のモデルを混ぜると再現性を失います。

手動送信できる機器では既知の状態変化を起こして時刻を記録します。できない場合は送信周期を待ち、連続リセットで送信を急がせません。パラメーター変更を記録し、結果の変化を説明できるようにします。

一台の受け入れ後に設定を展開する

継続性、正確性、保守性を確認します。予定どおり送信するか、項目と単位が現場状態に合うか、通信断の調査方法とモデル版の識別方法が明確かを確かめます。

確認後に適用範囲の合うモデルと設定を再利用します。外観や型式が似ていても同じプロトコルとは限りません。ファームウェア、ポート定義、センサー構成が異なる場合は新しいサンプルで試験します。

1. 正常送信と期待値を保存します。
2. リアルタイム値と履歴を確認します。
3. 異常や欠測の表示を確認します。
4. 調査手順、モデル版、担当者を記録します。