ThinkLink の属性が MQTT に出ないとき：許可リストと保存先

項目の保存先を決める

計測結果は通常テレメトリ、プラットフォームの業務設定はサーバー属性、共有設定は定義された属性、中間計算は process_data に置きます。現行のアプリ設定には app_attrs という保存先もあります。各項目の書き手、読み手、履歴の必要性、外部利用者を整理し、何でも頻繁に転送される大きなオブジェクトへ入れないでください。処理データは中間状態でも自動失効するメモリーではありません。既存スクリプトの移行では初期値を確認し、新しい保存先の空値を積算のゼロ開始と誤認しないようにします。

許可リストの意味を確認する

サーバー属性と共有属性は既定では転送されず、保存された forward_fields に含まれる実在する最上位キーだけが対象です。未設定や空配列は全件送信の意味ではありません。選択しても他の属性は消えず、規則を変えるだけではメッセージも発生しません。後続の更新や適切な転送処理が必要です。入れ子オブジェクトは最上位キーで選択され、点で区切った文字列を指定して一部だけ公開できるとは限りません。外部に必要な情報を先に整理して項目構造と転送範囲を設計します。

保存形式とスクリプト差分を分ける

端末やテンプレートは項目名の配列を保存し、スクリプトの forward_fields は真偽値の差分で追加・除外を指定します。省略部分は維持されるため、二つの形式を混用しないでください。RPC の forward: true も許可リストを迂回しません。false は対応する動作の仕様に沿って解釈し、全プロトコルの同期停止へ拡張しません。処理データはモデル結果か RPC 動作で書き込み、読取専用入力を直接変更しても保存されません。独自 MQTT の内容は作成者が決めるため、標準処理の除外規則を全出口の保証と考えないことも必要です。

部分更新を受信側まで検証する

テスト対象へ二つの通常属性を設定し、一つだけ選択して適切な更新を起こします。端末の保存値と転送先のメッセージを比較し、非選択項目が保存されたままメッセージから除かれているか確認します。その後、選択項目を外した場合も試します。受信側は項目単位で結合し、一部だけのメッセージで属性群全体を置換してはいけません。規則変更、メッセージ生成、Broker 転送、受信処理を別々に記録します。保存成功や接続 RUNNING の表示だけでは、正しい項目の到達を証明できません。

1. 項目の保存先と利用者を確認する。
2. 必要な項目だけの許可リストを保存する。
3. 更新を起こして転送先で確認する。
4. 受信側の結合と雛形の影響を試す。

テンプレートと版を引き継ぐ

テンプレートのリセットは転送規則も置換します。古いテンプレートに規則がなければ転送しない既定値に戻る場合があるため、一括変更前に端末との差と外部利用者への影響を確認します。処理データは通常の永続化後なら再起動をまたいで保持されますが、書込み待ち中のキャッシュ読取りは保存完了の証拠ではありません。項目の保存先、許可リスト、結合方式、サンプル、適用版を渡します。共有設定を実端末に送るには対応する下り RPC が必要で、属性変更や外部 MQTT 到達だけでは端末の受信確認になりません。