メインコンテンツまでスキップ

トラブルシューティング — フローで陥りやすい落とし穴

症状原因 / 対処
Deploy 後も変化がないノードの赤い点が残っている = 保存されていない。再度 Deploy する。または、キャッシュされた inject 結果を見ている — 新しい inject トリガーをクリック
タグ値の読み取りが常に nullタグ ID の誤記 / そのタグがゲートウェイに登録されていない / OPC 接続が切断。まず 자주 하는 작업 → 실시간 값 보기 で確認
inject が速すぎてゲートウェイに負荷1 秒未満のポーリングは非推奨。本当に高速な更新が必要な場合は Sparkplug または MQTT 直接購読 を検討
Fresh オプションを有効にしたまま多数のタグを同時ポーリングPLC の同時 read が急増。通常はキャッシュ(default)で十分。診断時のみ fresh を使用
Node-RED が突然停止する無限ループ(ノード出力 → 同じノードの入力)を疑う。Catch ノードを置くとデバッグが容易
外部インターネット呼び出しが失敗ゲートウェイのファイアウォール / DNS を点検。社内網環境なら プロキシ 設定が必要
「Maximum call stack size exceeded」function ノードの無限再帰。return msg が自分自身を再びトリガーする構造になっていないか点検
Deploy 後にフローが全て消えた/data1/pp-data/node-red/flows.json の破損。バックアップからの復元が必要。node/bin/start.sh は master conf と自動 sync するが、一度破損がディスクに固定されると 復旧が必要
MQTT メッセージが一度も来ないトピックのワイルドカード(#/+)の誤記。MQTT Explorer などの別ツールでトピックツリーを確認
OPC-UA BadIdentityTokenInvalidユーザー/パスワード、または証明書が未信頼。サーバーコンソールでクライアント証明書を Trust 処理
OPC-UA BadTypeMismatchOpcUa-Item の DataType が実際のノードの型と異なる

デバッグのヒント

  1. debug ノードを msg オブジェクト全体設定して、どのフィールドが流れているかを確認する。
  2. Catch ノードを片側に置いて全てのエラーを捕捉し debug に送る — どのノードで停止したかを即座に把握。
  3. Status ノードで mqtt/opcua ノードの 接続済み / 切断 の変化を捕捉すると、外部通信の問題を診断しやすい。
  4. inject の Inject once after deploy で「Deploy 時に一度実行」を作り、結果を debug で確認する。
  5. function 内の node.warn(...) または node.error(...) でサイドバーに自由に出力。

次のステップ