はじめに ― 今日の敵は“ドルマーク”だった
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ノードとコピペは最強
最終的には全員で協力しながらスッキリ解決し、
「また何か起きたら助け合おう」という温かい締めくくりになりました。