はじめに ―「画像って、どう扱えば正解なんだ？」から始まった一日

前回の記事では、MQTT や HiveMQ を中心にリモート通信の仕組みづくりをまとめました。
(👉 前回: https://qiita.com/GGT1629/items/f744dae9276a84fd80d0)

今回は、画像が実際に流れ始めたその後のストーリーです。

Raspberry Pi → Gyazo API → Node-RED → フロントエンド。

この一連の流れの中で、
「あれ？画像バッファってどうやって扱う？」
「URLはどこで取得すべき？」
「最新画像とログ画像、どう両立する？」
といった技術的なハードルが次々と登場しました。

この記事では、議事録をもとに実際に起きた混乱・気づき・改善をストーリー形式でまとめます。

問題点 ― バッファ沼にハマる。JSON地獄に落ちる。そして気づく。

つまり、画像処理の問題は「コード」ではなく「設定」がボトルネックでした。

Gyazo の良いところは…

Gyazo から返ってきた URL は MQTT で通知、
Node-RED が HTTP GET して保存する構成に決定しました。

議論の結果、画像保存はシンプルに 2系統 にまとめられました。

保存方式	役割
LATEST_JPEG	フロントエンドが常に参照する“最新画像”
timestamped_YYYYMMDD-HHMMSS.jpeg	ログとして履歴管理する“証跡”

「最新」と「履歴」の矛盾を完全に解消したバランスの良い設計です。

今回の構成はかなりスマートです。

MQTTは軽量通知、HTTPはデータ取得。
役割分担が完璧です。

議論の中で強く共有された結論はこれ：

Node-REDはJSONインポートを使わないと沼る。

目視でフローを再現すると100%事故が起きる。
プロパティ名1文字違うだけでバッファが壊れる。
（これは多くの人が通る道…！）

今回の議論と実装の結果、システムの土台が一気に強化されました。

これにより、
リアルタイム性 × ログ保存 × 実装の簡易さ
をすべて両立した、“美しい構成” が生まれました。

など、幅広い用途で同じ設計が活躍します。