はじめに ― 今日の敵は“ドルマーク”だった

IoT開発をやっていると、コードでもアルゴリズムでもない、
「なぜか設定画面でハマる」 という時があります。

今回の議論テーマもまさにそれ。

Node-RED が「ファイル名がありません！」と怒ってくる。

しかも原因が “ドルマーク（$）” の誤用という、
バグというより小ボケに近い案件 だったので、
最後はみんなで笑いながらデバッグする流れになりました。

今回は、そんな “設定ミス系トラブル” を軸に、
Python → Node-RED → Gyazo までのデータフロー理解が一気に深まった議事録を紹介します。

問題点 ― ファイル名エラーの沼に落ちる

● File-to-Buffer ノードが怒る

エラー内容はシンプル：

「ファイル名が設定されていません」

設定画面を開くと、
そこには 意味不明な環境変数っぽい記述 が。

$filename
$image_path
$env.HOGEHOGE

など、ドルマークだらけ。

しかし、議論するうちに見えてきた真実はこうでした：

そもそもその環境変数、存在してません！

● ドルマークの罠

Node-RED の環境変数は ${VAR} 形式。
でも今回必要だったのは環境変数ではなく、

msg.payload.imagePath をドット記法で読むだけ

という超シンプルな話でした。

データフローの整理 ― 誰が何を送ってるの？

今回あらためて整理したフローはこう：

カメラ or Python が認識した画像のパスを送る
Node-RED がそのパスを受信
ファイルを読み取って処理（Gyazo に送る等）

重要なのは、

MQTTで受信した画像ではなく、自分のデバイスで認識した画像を扱う

という点。
データの“出どころ”を誤解すると、ファイルパスの解釈がズレてしまうため、ここは大切な確認でした。

解決策 ― msg.payload.imagePath を正しく読むだけで全部解決した

✔ 正しいファイル名設定方法

設定欄にはこう書くだけでOK。

msg.payload.imagePath

括弧不要
ドルマーク不要
環境変数でもない
ただのプロパティ参照

ここに辿り着くまで 30 分議論していたことは内緒です。

✔ なぜファイル保存を残したのか

実際には 一時保存なしで直接送信も可能
でもデバッグ時に画像が手元にあった方が圧倒的に便利
→ 結果、固定ファイル名で保存する方針に。

これは良い判断でした。

Python 連携の気づき ― “保存”より“利用”が目的だった

議論の途中で明らかになったこと：

Python側は「ファイル保存」ではなく「ファイル利用」が目的

つまり…

保存する必要が常にあるわけではない
Node-RED の役割は「パスを正しく読み取って送る」こと

というシンプルな構造でした。

そのため、

msg.payload.imagePath

が正しく叩ければシステム全体の動きが保証される、
という理解にたどり着きました。

デバッグ → 実装完了まで ― “コピー＆ペーストが正義” の回

最終的に行ったデバッグはとても実務的でした：

Debug ノードで msg.payload.imagePath の中身をチェック
設定値は 100%一致するようにコピペ
値が取れたら File-to-Buffer ノードが正しく動作

Node-RED の開発では、
「似てるけど微妙に違う」設定ミスが最大の敵。

そのことを痛感した議論でした。

結論 ― 小さな設定1つで止まるのがNode-RED、しかし戻すのも簡単なのがNode-RED

今回の議論を通じて得た学びはシンプルです。

● Node-REDは“設定の1文字違い”で動かなくなる

● でも原因さえ分かれば一瞬で直る

● Debugノードとコピペは最強

最終的には全員で協力しながらスッキリ解決し、
「また何か起きたら助け合おう」という温かい締めくくりになりました。