スマートホーム自作｜ラズパイとESP32の始め方 - TsukuLab | ツクラボ

スマートホーム自作でラズパイとESP32をどう使い分けるか

3軸で理解する：OSの有無／消費電力／得意用途

得意用途まで含めて整理すると、ラズパイは「家の中の情報を受け止めて判断する側」、ESP32は「現場で測って動く側」です。
MQTTのPublish/Subscribeを使うと、この分担がとくに明快になります。
Brokerが中継し、PublisherとSubscriberがトピック単位で疎結合につながるので、ESP32側はセンサー送信に専念でき、ラズパイ側は受け取ったデータの蓄積やルール処理に集中できます。

構成のイメージは次のようになります。

［家庭LAN］—Raspberry Pi（Mosquitto/Node-RED）←→『ESP32』（温湿度/LED）

この矢印は片方向ではありません。
ESP32が温湿度をPublishし、ラズパイ側がそれを受け取って表示や判定を行う流れと、ラズパイ側からLED点灯などの命令を出し、ESP32がSubscribeして実行する流れが同時に走ります。
スマートホーム自作では、この双方向性が「見るだけの監視」から「状況に応じて動く制御」へ広がる分岐点になります。

GitHub - espressif/arduino-esp32: Arduino core for the ESP32

Arduino core for the ESP32. Contribute to espressif/arduino-esp32 development by creating an account on GitHub.

github.com

中央集約型の基本構成と考え方

自作スマートホームを安定して育てるなら、最初の設計は中央集約型に寄せるのが定石です。
家の中の通信ハブと自動化ロジックをRaspberry Piへ集め、部屋ごとのセンサーやアクチュエータを『ESP32』へ分散させます。
そうすると、変更点の大半は中央側のNode-REDで吸収でき、末端ノードは「測る」「光らせる」「スイッチを受ける」といった単純な役割を保てます。

具体的には、Raspberry Piの中にMosquittoを置いてMQTT Brokerを担当させ、Node-REDでトピックを受け取り、条件分岐やダッシュボード表示を組みます。
必要に応じて『Home Assistant』を加えれば、既製デバイスとの橋渡しや統合UIも持たせられます。
Linuxが動くラズパイはこうしたサービスの同居に向いていて、microSDへOSを書き込む初期セットアップやヘッドレス構成もRaspberry Pi Getting startedに沿って進められます。

末端の『ESP32』は、たとえば温湿度センサーを読んで home/bedroom/temperature のようなトピックへ送信し、別のトピックを購読してLEDやリレーを切り替える役目を持たせます。
ここで効くのがMQTTの疎結合です。
センサーの送信先や制御の送り元を個別のIP直結で組まなくてよいので、ノードを増やしても全体が崩れません。
1台のESP32を差し替えても、同じトピック設計を守れば中央側のロジックはそのまま流用できます。

筆者はこの構成を、インフラでいう「監視・制御のプレーンを中央に寄せる」考え方に近いものとして扱っています。
各ノードに判断ロジックを分散させると、あとから挙動を追いにくくなります。
反対に、ルールをNode-REDに集めておくと、「どの条件で照明がついたか」「どの時刻から温度が上がったか」を中央で追跡できます。
自宅で運用していても、部屋をまたいだ条件分岐を足すときはラズパイ側のフローを触るだけで済む場面が多く、全ノードのファームウェアを書き換える必要がほとんどありません。

NOTE

中央集約型は、最初の1部屋を作ったあとに2部屋目、3部屋目へ広げるときに差が出ます。
追加する側は『ESP32』の配線とトピック名をそろえるだけ、変更する側はRaspberry Pi上のフロー1か所という形に分かれるので、拡張時の見通しが保てます。

もちろん中央に寄せる以上、Raspberry Piは単なる実験機ではなく常時稼働サーバーとして扱う前提になります。
初期パスワードの変更、SSH設定、OS更新、必要に応じたFail2Banやファイアウォールの導入といった基本がここで効いてきます。
スマートホームは室内の小さな自作に見えても、家の中では通信の中心になるため、司令塔の作法はサーバー寄りで考えたほうが筋が通ります。

ESP32ファミリ比較（C3/S3/H2）と初台の選び方

『ESP32』と一口に言っても、実際に選ぶのは単体のチップではなく、どのファミリを子機の初台にするかです。
初心者が迷いやすいのはESP32-C3ESP32-S3ESP32-H2の違いなので、用途別に整理して判断するのが有効です。

まず全体像を表にすると、役割の差がつかみやすくなります。

項目	Raspberry Pi	ESP32-C3	ESP32-S3	ESP32-H2
位置づけ	Linuxが動くSBC	低価格IoT向けMCU	高機能汎用MCU	Thread/Zigbee向けMCU
OS	Raspberry Pi OSなど	なし（ファームウェア）	なし（ファームウェア）	なし（ファームウェア）
通信	Ethernet/Wi-Fi/Bluetooth（機種依存）	Wi-Fi + BLE	Wi-Fi + BLE系	Zigbee/Thread、Wi-Fiなし
得意用途	Mosquitto、Node-RED、サーバー、ダッシュボード	センサー端末、簡易制御	GUI/AI寄り拡張も視野	Matter/Thread系スマートホーム末端
消費電力傾向	ESP32より大きい	小さい	小さい	より低消費電力寄り
初心者の役割	家の司令塔	最初の子機候補	高機能子機候補	将来拡張向け

ESP32-C3は、温湿度取得、ボタン入力、LED制御のようなシンプルなIoTノードを数多く並べる用途と相性がよく、最初の1台として素直です。
価格面でもESP32系開発ボードは6〜12ドル帯が一つの目安で、日本国内ではESP32-DevKitCの価格例として秋月電子で1,480円があります。
コストを抑えながら数を増やす前提なら、C3系は候補に置きやすい存在です。

ESP32-S3は、同じWi-Fi系子機でも少し余力を持たせたいときに向きます。
スマートホームではセンサー読み取りだけで終わらず、表示機能を足したり、複数の周辺機器をつないだり、将来の機能追加を見込んだりする場面があります。
筆者は「最初は温湿度だけのつもりでも、そのうち表示や入力を載せたくなる」ケースを何度も見てきたので、最初から少し拡張余地を持たせるならS3を選ぶ考え方もありだと感じています。

一方のESP32-H2は立ち位置がはっきりしていて、Wi-FiではなくThreadやZigbee寄りのスマートホーム末端向けです。
今すぐRaspberry Pi上のMosquittoへWi-Fiでつなぐ基本構成を作るなら優先度は上がりませんが、将来MatterやThreadを軸に家全体を組み直す視点では注目株です。
Wi-Fi子機の延長として考えるとズレるので、初台より拡張計画の文脈で捉えるほうが判断しやすくなります。

初台としての結論は明快で、まず1台目はESP32-C3かESP32-S3です。
温湿度センサーとLEDをつないでMQTTのPublish/Subscribeを体験する段階では、この2つが扱いやすい守備範囲に収まります。
部屋に置く子機を数で増やすならC3、後から表示や周辺機能を足す前提ならS3、ThreadやZigbeeはその次の段階でH2を検討する、という順番にすると構成がぶれません。

まず揃える最小構成と部品リスト

最小構成：Pi + Mosquitto + Node-RED + ESP32 1台

最初の1セットは、中央側にRaspberry Pi、末端側に『ESP32』を1台置く形がいちばん見通しよく進められます。
役割分担も明快で、ラズパイではMosquittoをMQTTブローカーとして動かし、Node-REDでフローを組み、ESP32はセンサー値の送信やLED制御の受信を担当します。
ここに有線LANまたはWi-Fiで同一LANを用意すれば、スマートホームの最小構成として成立します。

構成として必要になるのは、Raspberry Pi本体、microSDカード、Pi用電源、ネットワーク接続、有線または無線LAN、ESP32開発ボード、USBケーブル、ブレッドボード、ジャンパワイヤ、LEDと抵抗です。
部屋全体の自動化や複数ノード化はこの先で広げればよく、最初は「ESP32が1台」「LEDが1個」で十分です。
この段階でMQTTのPublishとSubscribeの両方を体験できるので、構成の意味が頭に入りやすくなります。

Raspberry PiはLinuxが動く小型コンピュータなので、ブローカーやフローエンジンを1台にまとめやすいのが利点です。
Raspberry Pi hardware overviewでも、SBC（シングルボードコンピュータ）としての位置づけが明確に説明されています。
一方の『ESP32』はWi-Fi内蔵のマイコンで、GPIO制御やセンサー接続を軽く任せるのに向いています。
Espressif ESP32 overviewでも、IoT向けSoCとしての役割が整理されています。

OS用のmicroSDは、Raspberry Pi Getting startedで案内されています。
通常版Raspberry Pi OSなら32GB以上、Lite版なら16GB以上が案内されています。
対応上限は2TB未満です。
筆者の感覚では、初回はRaspberry Pi OS Liteでも32GBを選んでおくと余裕があります。
MosquittoのログやNode-REDのフロー、あとから追加したパッケージが積み上がっても窮屈になりにくく、再構築のタイミングを後ろへずらせます。
16GBでも始められますが、学習中は試行錯誤の跡が残りやすいので、32GBのほうが落ち着いて運用できます。

ラズパイ本体の候補としては、Raspberry Pi 5 1GBモデルが公式発表で$45です。
国内流通の参考例では、Raspberry Pi 4 4GBがAmazonで約15,999円という価格帯があります。
価格は時期と販売店で動く前提ですが、最小構成の司令塔としてはPi 4かPi 5のどちらでも組めます。
Node-REDとMosquittoを同居させるだけなら、初心者の最初の構築で困る場面は多くありません。

ESP32側は、前のセクションで触れた通りESP32-C3やESP32-S3が入口として扱いやすい選択肢です。
定番のESP32-DevKitCは秋月電子で1,480円の例があり、海外相場ではESP32開発ボード全体で$6〜$12がひとつの目安になります。
最初の1台は、USBで書き込みできる開発ボード形状を選ぶと、電源供給とファーム書き込みを1本でまとめられます。

LEDの確認回路もこの最小構成に含めておくと、トラブル切り分けが進めやすくなります。
3.3V系でLEDに330Ωを直列に入れると、目視確認には十分な明るさになりやすく、ESP32のGPIOテストに向いています。
ブレッドボードで組むと、センサーをまだ載せていない段階でも「MQTTで点灯命令が届いているか」を1秒で見分けられるのが便利なんですよね。

部品リスト

最初の買い物では、部品単体の性能だけでなく「この1回で配線まで進められるか」を基準に揃えると迷いません。
下の表は、MQTTブローカーとNode-REDをラズパイ上に置き、ESP32 1台でLED制御まで進めるための最小構成です。

部品名	数量	仕様・型番	参考価格
Raspberry Pi本体	1	Raspberry Pi 4 4GB または Raspberry Pi 5 1GB	AmazonのRaspberry Pi 4 4GB例で約15,999円、公式発表のRaspberry Pi 5 1GBは$45
microSDカード	1	32GB以上推奨、2TB未満対応	1,000〜2,000円台
Pi用電源	1	対応機種に合う純正級電源	1,500〜3,000円台
LAN接続	1	Ethernet または Wi-Fi	手持ち流用可
『ESP32』開発ボード	1	ESP32-DevKitC、またはESP32-C3ESP32-S3系開発ボード	秋月電子のESP32-DevKitC例で1,480円、開発ボード相場は$6〜$12
USBケーブル	1	開発ボードの端子に合うもの	500〜1,000円台
ブレッドボード	1	400ポイント級ハーフサイズ以上	数百円〜1,000円台
ジャンパワイヤ	1式	オス-オス中心、必要に応じてオス-メス	数百円〜1,000円台
LED	1	3mmまたは5mmの一般的な赤色LED	数十円〜数百円
抵抗	1本以上	330Ω、1/4W級	Amazonの100本パック例で59円〜

部品選びでつまずきやすいのが、実はUSBケーブルです。
見た目が同じでも、充電専用でデータ線が入っていないケーブルだと、ESP32がPCに認識されません。
開発ボードの書き込みで止まると、ボード不良と勘違いしがちですが、原因がケーブルだったという場面は珍しくありません。
最初から「データ通信用」を前提に揃えておくと、切り分けが一段楽になります。

電源も型番ではなく規格で見ておくと判断しやすくなります。
Raspberry Piは機種ごとに求める電源が違うので、Pi本体に合った純正級の電源を組み合わせるのが素直です。
ラズパイはサーバー役として常時動作の時間が長くなりやすく、電圧不足が起きると不安定さの原因が電源なのかソフトなのか見分けづらくなります。
最初の構成ほど、ここは素直な組み合わせのほうが進行が止まりません。

ブレッドボードは400ポイント級のハーフサイズで十分始められます。
LED、抵抗、ESP32、数本のジャンパワイヤなら収まりがよく、机の上でも扱いやすい大きさです。
逆に小さすぎるものを選ぶと、ESP32を挿しただけで電源レールや配線スペースが足りなくなります。
筆者は最初の1枚に400ポイント級、その次に拡張用として大きめを追加する流れが収まりよかったです。

ジャンパワイヤはオス-オスが中心になります。
ESP32開発ボードをブレッドボードに挿し、LEDと抵抗を並べるだけなら、まずここから入れます。
センサーモジュールを増やす段階でオス-メスが欲しくなるので、はじめから混合セットを持っていると配線の自由度が上がります。
配線本数に余裕がないと、1本外して付け替える作業が増え、つなぎ間違いも起こりやすくなります。

あると便利な工具・消耗品

最小構成だけでも動きますが、作業の止まりどころを減らす道具がいくつかあります。
代表的なのはUSBシリアルケーブル、テスター、予備のmicroSD、抵抗アソートです。
どれも派手な部品ではありませんが、組み始めてから効いてきます。

USBシリアルケーブル（USB-TTLアダプタ）は、ESP32開発ボードによっては不要ですが、シリアルログの確認や別系統の書き込みで役立つ場面があります。
価格帯は300〜1,500円程度です。
ただしこの手のモジュールは電圧まわりの癖がある個体もあり、3.3V表記でも信用し切らずにテスターで見る運用のほうが安全です。
ESP32は3.3Vロジックなので、ここを曖昧にすると一気に面倒になります。

テスターは、初心者ほど早い段階で恩恵が出ます。
電源が来ているか、GNDがつながっているか、USBシリアルの3.3Vが想定通りか、そこだけでも見えるようになると、ソフトの問題と配線の問題を分けられます。
ブレッドボード配線は見た目が合っていても、1列ずれているだけで動きません。
筆者も最初の頃はコードより先にテスターを当てる場面が多く、結果的に復旧が早くなりました。

予備のmicroSDが1枚あると、OSの書き換えや構成の切り替えが軽くなります。
Node-REDの試験構成と、安定運用の構成を分けたいときにも便利です。
ラズパイはmicroSD交換で環境を丸ごと切り替えられるので、サーバー用途を触り始めると予備メディアのありがたみが見えてきます。

抵抗アソートも地味ですが、配線の自由度を一段上げてくれます。
最初はLED用の330Ωが1本あれば進められるものの、センサー追加やプルアップ抵抗の試行に入ると値の違う抵抗が欲しくなります。
抵抗は単品で不足すると作業が止まりやすいので、アソートを1セット持っているとブレッドボード実験のテンポが落ちません。

NOTE

初回の買い物では、主役のRaspberry Piや『ESP32』よりも、USBケーブルとブレッドボードまわりの取りこぼしで手が止まりがちです。
ボード単体ではなく、「電源投入してLEDを点けるところまで」を1セットとして眺めると、必要な物が抜けにくくなります。

通信の基本：MQTTでラズパイとESP32をつなぐ

MQTTは、ラズパイとESP32の役割分担をそのまま通信に落とし込めるのが強みです。
ラズパイ側にMosquittoを置いて家の中の通信ハブにし、各部屋の『ESP32』が必要な情報だけを送り、必要な指示だけを受け取る形にすると、配線よりも構成そのものがすっきり見えてきます。
ここで先に押さえたいのは、MQTTは「1台が全部と直接つながる」発想ではなく、「Brokerを中心にメッセージを受け渡す」発想だという点です。

Broker／Publisher／Subscriberの正しい理解

MQTTの登場人物は3つです。Brokerは中継役、Publisherは送信側、Subscriberは受信側です。
スマートホームの最小構成では、ラズパイ上で常駐するMosquittoがBrokerになります。
Mosquittoは、届いたメッセージを自分で使うのではなく、「どのトピックに誰が興味を持っているか」を見て、適切な受信側へ配る役目です。

ESP32は、場面によってPublisherにもSubscriberにもなれます。
たとえば温湿度センサーを付けたESP32は、測定値を送るときはPublisherです。
一方で、LED点灯やリレー制御の命令を受けるときはSubscriberになります。
ラズパイ側のNode-REDも同じで、センサー値を受け取るときはSubscriber、ESP32へ制御命令を出すときはPublisherです。

この整理が曖昧だと、「ラズパイがサーバーで、ESP32がクライアント」という理解だけで止まりがちです。
もちろん接続の向きとしてはそう見えますが、MQTTでは役割が固定ではありません。
1台のESP32がセンサー値をPublishしながら、同時に制御用トピックをSubscribeするのが普通です。
ラズパイも、可視化画面の裏では受信と送信の両方を担います。

筆者は最初、ここをHTTPの感覚で考えて少し遠回りしました。
HTTPだと「どの端末がどの端末へ直接リクエストするか」を意識しますが、MQTTではBrokerに預ける前提で考えたほうが構成が素直になります。
送る相手のIPを毎回意識するのではなく、「このデータはこのトピックに流す」と決めるだけでよくなります。

スマートホームにおけるPublish/Subscribeの実例

自宅のスマートホームで最初に組みやすいのは、ESP32からラズパイへデータを送る流れです。
たとえばリビングのESP32が温度や湿度を測り、その値をMQTTでPublishします。
ラズパイ上のMosquittoがそれを受け取り、Node-REDが該当トピックをSubscribeしてダッシュボード表示やログ保存を行います。
センサー側は「どこに表示されるか」を知らなくてよく、Node-RED側は「どのESP32から来たか」をトピック名で判別できます。

逆方向の制御も同じ考え方で動きます。
Node-REDのダッシュボードでスイッチを押すと、ラズパイ側が制御メッセージをPublishし、ESP32がそのトピックをSubscribeしてLEDやリレーを切り替えます。
つまり、ESP32からRaspberry Piへの送信だけでなく、Raspberry PiからESP32への指示も、同じBrokerを経由して対称的に扱えます。
この双方向性が見えてくると、スマートホームの自動化フローを組み立てやすくなります。

たとえば、リビングの温度をESP32が送信し、その値をNode-REDで受けて「室温が一定値を超えたら通知する」「人感センサーの反応がある時間帯だけ照明コマンドを送る」といった処理につなげられます。
MQTTの利点は、センサー、可視化、制御を疎結合に保てることです。
温度センサーの送信先をあとから『Home Assistant』へ増やしたくなっても、既存のESP32のコードを大きく書き換えずに済みます。

Node-RED Home Automation collectionの作例でも、ラズパイ上のNode-REDとMosquittoを軸に、各ノードがPublish/Subscribeでつながる構成がよく使われています。
Node-RED側のフローを差し替えるだけで見せ方や処理内容を変えられるので、ESP32側は「送る」「受ける」に集中できます。

筆者宅では、まず平文のMQTTでESP32とMosquittoの疎通だけを通し、そのあとNode-REDで見える形にしてから、認証とTLSを段階的に足していく流れがいちばん安定しました。
最初から暗号化や証明書まで一気に入れると、つながらない原因がネットワークなのか認証なのか証明書なのか見分けづらくなります。
平文でメッセージが往復する状態を先に作ると、問題の切り分けが一段ずつ進みます。

TIP

家庭内LANで最初に試すなら、MQTTの標準ポートとして使われる1883番で平文接続し、動作が固まってから8883番のTLS接続へ移る流れが扱いやすい構成です。
mqtt.org FAQでも1883番は非TLS、8883番はMQTT over TLSとして整理されています。

トピック設計の基本と命名ルール

MQTTで後から困りにくい構成にするには、トピック名を最初に整えておくのが近道です。
トピックはメッセージの「分類ラベル」で、Brokerはその文字列を見て配送先を決めます。
ここが曖昧だと、ESP32を2台、3台と増やした時点で「この値はどの部屋の何のデータか」が見えなくなります。

スマートホームでは、場所と役割を含めた階層構造にすると整理しやすくなります。
たとえばセンサー値なら home/living/temperature、LED制御なら cmd/living/led のように分けると、データと命令が混ざりません。
前者はESP32がPublishしてNode-REDがSubscribeする経路、後者はNode-REDがPublishしてESP32がSubscribeする経路です。
役割をトピック名に埋め込むことで、双方向通信でも読み違えが起きにくくなります。

命名では、単数形のルールを決めてぶらさないことが効きます。livingroom と living を混在させたり、temp と temperature を混ぜたりすると、Node-REDのフローが増えたときに検索しづらくなります。
筆者は、1階層目を用途、2階層目を部屋、3階層目を項目という形にそろえることが多いです。
たとえば home/bedroom/humidity、home/entrance/motion、cmd/bedroom/fan のように並べると、目で追っただけで意味が取れます。

ここでMosquittoの位置づけも改めてはっきりします。
Mosquittoは home/living/temperature の中身を解釈して温度グラフを描くわけではありません。
あくまで、そのトピックを購読している相手へメッセージを渡すだけです。
表示や保存はNode-RED、現物の制御は『ESP32』という分担になります。
この分離があるので、あとから購読先を増やしても全体を壊さず拡張できます。

セキュリティ面では、家庭内LANの最初の段階なら1883番の平文で構成を固め、その後に認証やTLSを追加する進め方が現実的です。
TLSを使う場合の標準ポートは8883番で、証明書の管理も入ってきます。
ラズパイ側はLinuxが動くのでMosquittoのTLS設定を受け持てますし、ESP32側でも『PubSubClient』とTLS対応のクライアントを組み合わせる構成が取れます。
ただ、実装の入口ではまずトピック設計と役割分担を先に固めたほうが、通信の問題と暗号化の問題を混同せずに進められます。

MQTTのモデルをこの段階で頭の中に置いておくと、このあとMosquittoの導入やNode-REDのフロー作成に入ったときも、「誰が送って、誰が受けて、Brokerはどこか」がぶれません。
ラズパイとESP32をつなぐというより、家の中のデータの通り道を設計している、と捉えると全体像がつかみやすくなります。

Raspberry Pi側の構築：Mosquitto・Node-RED・必要ならHome Assistant

Raspberry Pi OS準備

ラズパイ側は、まずRaspberry Pi OSを安定して起動できる状態に整えます。
Raspberry Pi Getting startedでは、通常版なら32GB以上、Liteなら16GB以上のストレージが案内されています。
今回のようにMosquittoとNode-REDを同居させる前提なら、GUIを使わないならLite、最初は画面付きで触りたいなら通常版という分け方で十分です。
microSDは2TB未満まで対応なので、家庭内の小規模なMQTTハブ用途なら32GB級から入る構成で収まりやすいです。

ヘッドレスで始めるなら、Raspberry Pi Imagerの初期設定でホスト名、Wi-Fi、SSH、有線を使わない場合の無線設定を先に入れておくと、起動直後からLAN内で扱えます。
筆者はサーバー用途のラズパイでは、最初にディスプレイをつながずSSH前提で作ることが多いです。
あとから置き場所を変えても運用がぶれませんし、スマートホームの司令塔は棚の奥や情報分電盤まわりに置くことも多いからです。

初回ログイン後は、パッケージ更新とパスワード変更を先に済ませます。最低限の初期整備としては次の流れです。

sudo apt update
sudo apt full-upgrade -y
passwd
sudo reboot

apt update はパッケージ一覧の更新、full-upgrade は依存関係を含めて更新を通すためです。passwd はログインユーザーのパスワード変更です。
ここを後回しにすると、あとでMosquittoやNode-REDを入れた段階で「何から守るべきか」が曖昧になります。
サーバーの土台を先に締めておくと、その後の設定に迷いが出ません。

Raspberry Pi 5を使う場合は、将来のTLS化も見据えやすい土台です。
Raspberry Pi公式の紹介では、暗号処理のベンチマークでPi 5はPi 4比45倍という話が出ており、MQTTをまず平文で始めて、あとから8883番のTLS接続へ広げる構成でも余力を持たせやすい背景があります。
家庭内の小規模構成ではすぐに限界が来る場面は多くありませんが、証明書や暗号化を段階的に足したい人には心強い差です。

Mosquittoインストールと基本設定

Broker役のMosquittoは、Debian系の標準パッケージで入れるのが最短です。まずはインストールして、自動起動と稼働状態を確認します。

sudo apt install -y mosquitto mosquitto-clients
sudo systemctl enable mosquitto
sudo systemctl start mosquitto
sudo systemctl status mosquitto

mosquitto-clients を一緒に入れるのは、その場でPublishとSubscribeの疎通確認まで進めるためです。
GUIを開かなくても、ラズパイ単体で通信経路を検証できます。

最初の段階では、家庭内LANだけに閉じた状態で匿名接続のまま試し、ESP32側の送受信が通ることを先に確認すると切り分けが速くなります。
ここでいきなりユーザー認証まで入れると、失敗時に「ネットワークが悪いのか、Broker設定が悪いのか、資格情報が違うのか」が混ざります。
前のセクションでも触れた通り、まず平文で流れる状態を作るほうが構築の歩幅が揃います。

動作確認は、同じラズパイ上でSubscribe側の端末とPublish側の端末を分けて試すのが確実です。1つ目のターミナルで次を実行します。

mosquitto_sub -h localhost -t test/topic

2つ目のターミナルで次を実行します。

mosquitto_pub -h localhost -t test/topic -m "hello mqtt"

これでSubscribe側に hello mqtt が表示されれば、Broker自体は動いています。
次にESP32から送る予定のトピック名、たとえば home/living/temperature に変えて試せば、あとでNode-REDにつなぐ時も同じ命名をそのまま流用できます。

匿名接続で通ることを確認したら、次はユーザー名とパスワードを付けます。
Mosquittoではパスワードファイルを作り、設定ファイルで匿名接続を止める流れが基本です。

sudo mosquitto_passwd -c /etc/mosquitto/passwd mqttuser

続いて、たとえば /etc/mosquitto/conf.d/local.conf のような追加設定ファイルに次の内容を入れます。

listener 1883
allow_anonymous false
password_file /etc/mosquitto/passwd

保存後に再起動します。

sudo systemctl restart mosquitto

以後のCLI確認は、ユーザー名とパスワード付きに変わります。

mosquitto_pub -h localhost -t test/topic -m "auth ok" -u mqttuser -P '設定したパスワード'

この順番にしておくと、ESP32側の『PubSubClient』設定でも、最初はBrokerアドレスとトピックだけ、次に認証情報、さらにその先でTLSという具合に一段ずつ足していけます。

GitHub - knolleary/pubsubclient: A client library for the Arduino Ethernet Shield that provides support for MQTT.

A client library for the Arduino Ethernet Shield that provides support for MQTT. - knolleary/pubsubclient

github.com

Node-REDでの受信確認と簡易ダッシュボード

Node-REDは、MQTTの中身を「見える化」する役として入れておくと進行が一気に楽になります。
導入は公式インストールスクリプトを使う方法が広く使われています。
インストール後にサービス化して起動すれば、ブラウザから >:1880 で編集画面へ入れます。
ラズパイのIPが 192.168.1.30 なら、` です。

フローの最初は凝った画面を作らず、MQTT inノード → debugノード の一直線で十分です。
MQTT inノードにBrokerとしてラズパイ自身のMosquittoを設定し、トピックに home/# のようなワイルドカードを入れると、配下のメッセージをまとめて受信できます。
そこにdebugノードをつなげてデプロイすると、ESP32から飛んできたpayloadが右側のデバッグ欄にそのまま出ます。

筆者は初期段階でこのデバッグノードをほぼ常設しています。
温湿度の値そのものを見るためというより、「ESP32が今も送っているか」「JSONの形が崩れていないか」「トピック名を打ち間違えていないか」を短時間で回すためです。
シリアルモニタだけで追っていた時より、ラズパイ側で受信の事実が見えるだけで切り分けの速度が上がりました。
ESP32のコードを書き換えて再書き込みし、Node-REDのdebug欄に戻って確認する流れが一定になると、配線ミスなのかWi-FiなのかMQTT設定なのかが見えやすくなります。

簡易ダッシュボードを置くなら、受け取ったpayloadをテキスト表示やグラフ表示に流すだけでも十分に価値があります。
たとえば温度なら、MQTT inノードの後ろにjsonノードを挟み、msg.payload.temperature を取り出して表示する形です。
最初から家全体のUIを作ろうとすると止まりやすいので、1トピックだけ見える状態を作るほうが前へ進めます。

TIP

Node-REDの受信確認は、まずdebugノードで生データを見てから整形ノードを足す順番が安定します。
表示が崩れた時に、MQTTの受信失敗なのか、JSON変換の失敗なのかを一目で分けられるからです。

ブラウザで開ける管理画面があるのも、Node-REDを最初の相棒に据えやすい理由です。
SSH先でログだけを見る構成より、家のLAN内から >:1880 に入って配線図のように処理を追えるので、スマートホーム全体の見通しが保ちやすくなります。

Home Assistantを後から足す拡張構成

スマートホームを続けていくと、時刻条件の自動化、スマホ通知、既製デバイス連携まで欲しくなることがあります。
その段階で『Home Assistant』を足せる構成にしておくと、最初に作ったMosquittoとNode-REDが無駄になりません。
MQTT中心の設計にしておけば、ESP32は同じトピックへ送り続け、『Home Assistant』を新しい購読先として追加できます。

拡張パスは大きく2つあります。
1つは同じラズパイに『Home Assistant』を同居させる形、もう1つは別ホストに分ける形です。
前者は台数が増えず、家庭内の配線と電源がすっきりします。
後者は役割分離が明快で、スマートホーム基盤を育てていく時に見通しが立ちます。
『Home Assistant』公式では、Raspberry Pi向けに『Home Assistant OS』をRaspberry Pi Imagerで書き込む導線が用意されていて、Web UIは通常 または>:8123` で開きます。

このあたりからは導入形態ごとの差が増えるので、細かなインストール分岐やアドオン構成まで本稿で追い込むより、『Home Assistant』公式ドキュメントの手順に乗るほうが迷いません。
ここで押さえておきたいのは、最初の1台ではMosquittoとNode-REDで通信を固め、運用が見えてきたら『Home Assistant』を追加しても構成がつながる という点です。

筆者宅でも、先にMosquittoとNode-REDで温湿度と照明制御の流れを形にし、そのあと『Home Assistant』を足してUIや自動化を広げました。
MQTTのトピックを最初に整理していたおかげで、追加作業は「新しい購読先を増やす」感覚で進み、ESP32側のコードを大きく触らずに済みました。
スマートホームは最初から全部入りにするより、司令塔を小さく立ち上げてから周辺を伸ばすほうが、途中で詰まりにくい構成になります。

Raspberry Pi

Install Home Assistant on a Raspberry Pi

home-assistant.io

ESP32側の実装：最初のセンサー送信とLED制御

Arduino IDEの準備とボード設定

ESP32の最初の1台は、Arduino IDEで動かすのがいちばん入り口に立ちやすい構成です。
書き込み、シリアルモニタ、ライブラリ導入が1つの画面にまとまっているので、Wi-Fiにつながらないのか、MQTTにつながらないのか、そもそもファームが起動していないのかを順番に切り分けられます。
Espressifの開発環境全体像はESP32 Get StartedEspressifの開発環境全体像はESP32 Get Startedでも確認できますが、最初の送受信だけならArduino IDEで十分です）。

準備は3段階です。
まずArduino IDEの「ファイル > 環境設定」を開き、「追加のボードマネージャーのURL」にESP32用のパッケージURLを追加します。
実務では https://espressif.github.io/arduino-esp32/package_esp32_index.json がよく使われます。
次に「ツール > ボード > ボードマネージャ」から esp32 を検索し、esp32 by Espressif Systemsをインストールします。
そこまで終わったら、開発ボードをUSBでつなぎ、「ツール > ボード」で使っているESP32系ボードを選び、「ツール > ポート」で認識されたシリアルポートを選択します。

ここでつまずいたときは、「ファイル > 環境設定」の「追加のボードマネージャーのURL」に以下のいずれかの package_esp32_index.json を追加してください（実務でよく使われる検証済みURLの例）:

ライブラリは『PubSubClient』を入れます。
「スケッチ > ライブラリをインクルード > ライブラリを管理」から PubSubClient を検索して導入すれば、MQTTのPublishとSubscribeを同じ流れで扱えます。
『PubSubClient』はデフォルトでMQTT v3.1.1を使うので、家庭内のMosquittoと組み合わせる最初の実験では定番です。

配線はまずシンプルで十分です。
LED制御まで試すなら、ESP32のGPIOから330Ω抵抗を直列に入れてLEDへつなぎ、LEDの反対側をGNDへ落とします。
3.3V系で一般的な赤色LEDを想定すると、330Ω直列で流れる電流は約4mAほどになり、ブレッドボード上で点灯確認するにはちょうどよい明るさです。
まぶしさより「確実に見える」ことを優先したい初回検証には、このくらいの穏やかな電流が扱いやすい感覚でした。

Get Started - ESP32 - — ESP-IDF Programming Guide v5.5.3 documentation

docs.espressif.com

MQTT Publish：センサー値を送る

まずはESP32からラズパイ上のBrokerへ、一定間隔で値を送ります。
センサー実機がまだ手元になくても、ダミー値で通信経路は確認できます。
ここでは home/livingroom/temperature に数値をPublishする例を使います。
Wi-Fi接続、MQTT接続、定期送信までを1本にまとめると、最初の疎通確認が進めやすくなります。

#include <WiFi.h>
#include <PubSubClient.h>
// 最初はBrokerのIPアドレスを直接指定すると切り分けが速いです
const char* ssid = "YOUR_WIFI_SSID";
const char* password = "YOUR_WIFI_PASSWORD";

// 最初はホスト名ではなくBrokerのIPアドレスを直書きすると切り分けが速いです
const char* mqtt_server = "192.168.1.30";
const int mqtt_port = 1883;

WiFiClient espClient;
PubSubClient client(espClient);

unsigned long lastMsg = 0;

void connectWiFi() {
  WiFi.begin(ssid, password);
  Serial.print("WiFi connecting");
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  Serial.println();
  Serial.print("WiFi connected. IP: ");
  Serial.println(WiFi.localIP());
}

void reconnectMQTT() {
  while (!client.connected()) {
    Serial.print("failed, rc=");
    Serial.print(client.state());
    Serial.println(" retry in 2 seconds");
    delay(2000);
  }

void loop() {
  if (WiFi.status() != WL_CONNECTED) {
    connectWiFi();
  }

  if (!client.connected()) {
    reconnectMQTT();
  }
  client.loop();
  }

  if (!client.connected()) {
    reconnectMQTT();
  }
  client.loop();

  unsigned long now = millis();
  if (now - lastMsg > 5000) {
    lastMsg = now;

    float dummyTemp = 24.5;
    char payload[16];
    dtostrf(dummyTemp, 1, 1, payload);

    client.publish("home/livingroom/temperature", payload);
    Serial.print("Published: ");
    Serial.println(payload);
  }

このコードで見ているポイントは3つです。
Wi-Fiにつながること、MQTT Brokerへ接続できること、5秒ごとに値がPublishされることです。
前のセクションで作ったNode-REDの MQTT in → debug で home/# を受けていれば、受信の有無がすぐ見えます。
Broker側に問題がなければ、シリアルモニタには Published: 24.5 のように出て、ラズパイ側には同じ値が流れます。

実センサーへ置き換えるときも、骨格は同じです。
たとえば温湿度センサーから取得した temperature や humidity を文字列化してPublishするだけです。
最初からJSONにしてもよいのですが、初回はプレーンな数値1個で通すほうが切り分けが速く進みます。
シリアルモニタ、Broker、Node-RED の3地点で同じ値が見えたら、そのあとでJSONへ広げれば十分です。

接続失敗でよく見るのは、SSIDとパスワードの入力ミス、Brokerアドレスの誤り、ポート番号の取り違えです。
1883は非TLSのMQTT、8883はTLS付きMQTTの標準ポートとして使われます。
ラズパイ側のMosquittoを平文設定で立てているのに、ESP32側だけ8883へ向けると接続できません。
逆にTLS前提のBrokerへ1883で投げても当然入りません。

現場でいちばん詰まりやすいのは、コードの文法よりネットワークの前提でした。
筆者がワークショップで最も多く見たのは、ESP32とBrokerが同じLANにいないケースと、Brokerのホスト名が解決できないケースです。
スマホのテザリングへESP32だけつながっていて、ラズパイは自宅Wi-Fiにいる、といった状態だとMQTT以前で届きません。
ホスト名解決も、raspberrypi.local のような名前で通る環境と通らない環境があります。
初回はBrokerのIPアドレスをベタ書きにして疎通を取り、通信が通ってから名前へ戻す流れのほうが安定しました。

TIP

シリアルモニタには WiFi connected、Attempting MQTT connection、Published の3種類を必ず出しておくと、止まっている場所がすぐ見えます。
Wi-Fiで止まるのか、MQTT接続で止まるのか、Publishまで行っているのかが1画面で分かれます。

MQTT Subscribe：LEDを制御する

送信だけだと「センサー端末」としては動いていても、双方向通信の手応えが薄いままです。
そこで次はSubscribeを追加し、ラズパイ側から ON と OFF を送ってESP32のLEDを点けたり消したりします。
スマートホームの最小単位としては、これで「状態を送る」「命令を受ける」の両方がそろいます。

配線は、GPIOピンから330Ω抵抗を通してLEDのアノード側へ接続し、カソード側をGNDへつなぎます。
GPIOをHIGHにすると点灯、LOWで消灯という形です。
ここでは例としてGPIO 2を使います。

#include <WiFi.h>
#include <PubSubClient.h>

const char* ssid = "YOUR_WIFI_SSID";
const char* password = "YOUR_WIFI_PASSWORD";
const char* mqtt_server = "192.168.1.30";
const int mqtt_port = 1883;

const int ledPin = 2;

WiFiClient espClient;
PubSubClient client(espClient);

void connectWiFi() {
  WiFi.begin(ssid, password);
  Serial.print("WiFi connecting");
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  Serial.println();
  Serial.println("WiFi connected");
}

void callback(char* topic, byte* payload, unsigned int length) {
  String message;
  for (unsigned int i = 0; i < length; i++) {
    message += (char)payload[i];
  }

  Serial.print("Message arrived [");
  Serial.print(topic);
  Serial.print("] ");
  Serial.println(message);

  if (message == "ON") {
    digitalWrite(ledPin, HIGH);
  } else if (message == "OFF") {
    digitalWrite(ledPin, LOW);
  }

void reconnectMQTT() {
  while (!client.connected()) {
    Serial.print("Attempting MQTT connection...");
    String clientId = "esp32-led-";
    clientId += String((uint32_t)ESP.getEfuseMac(), HEX);

    const char* id = clientId.c_str();
    if (client.connect(id)) {
void reconnectMQTT() {
  while (!client.connected()) {
    Serial.print("Attempting MQTT connection...");
    String clientId = "esp32-led-";
    clientId += String((uint32_t)ESP.getEfuseMac(), HEX);

    const char* id = clientId.c_str();
    if (client.connect(id)) {
      Serial.println("connected");
      client.subscribe("home/livingroom/led");
    } else {
      Serial.print("failed, rc=");
      Serial.print(client.state());
      Serial.println(" retry in 2 seconds");
      delay(2000);
    }
  client.setCallback(callback);
}
  client.loop();
}

この状態でNode-REDから home/livingroom/led に ON を送ればLEDが点灯し、OFF で消灯します。
Injectノードを2つ置いて、それぞれpayloadを文字列 ON と OFF にし、MQTT outノードへつなぐだけで試せます。
最初の1台では、この「Node-REDから押したら、机の上のLEDが反応する」体験が強いです。
Broker、ESP32、GPIO制御が一本につながった実感があり、次にリレーや赤外線送信へ広げるときの土台になります。

ここでも接続失敗の見方は同じです。
Subscribeできていないなら、ESP32のシリアルモニタに connected が出ているか、client.subscribe("home/livingroom/led") が接続直後に実行されているかを追います。
トピック名の打ち間違いは本当に多く、home/livingroom/LED と home/livingroom/led のような大文字小文字違いでも反応しません。
LEDが点かないときは、GPIO番号の指定ミス、LEDの向き、抵抗の入れ忘れまで含めて見たほうが早く進みます。

書き込みのたびに挙動が不安定に見える場合は、コードより先にボードの書き込み手順を見るほうが近道です。
ESP32系の一部ボードは、アップロード開始のタイミングでBOOTボタンを押さないと書き込みモードへ入りません。
シリアルモニタに前のコードのログが出続けているのに、新しいLED制御が効かない場面では、実は書き込み自体が通っていなかった、ということが珍しくありません。
こういうときは、アップロード完了後にリセットして、起動ログから見直すと状況が揃います。

セキュリティと運用の基本

初期設定と更新の基本チェックリスト

Raspberry Piを家の司令塔にするなら、最初に固めるべきなのは機能追加よりも基本設定です。
自宅LANだけで使うつもりでも、初期状態のまま運用を始めると、あとから「どこまで設定したか分からない」「認証が甘いままノードだけ増えた」という崩れ方をしがちです。
筆者はサーバー運用の癖もあって、まずログイン経路と更新手順を先に整えます。
この順番にしておくと、後でMosquittoやNode-REDの設定を触るときも切り分けが楽になります。

最初に手を入れたいのは、初期パスワードの変更です。
平文でメモに残すのではなく、管理方法を決めたうえで早い段階で切り替えておくと、再セットアップ時も迷いません。
あわせて、SSHを使う前提ならパスワードログインだけに頼らず、公開鍵認証へ寄せる構成が安定します。
公開鍵を配置し、/etc/ssh/sshd_config で鍵認証を有効にして、管理端末側から接続できることを確認してからパスワード認証を止める、という順番です。
いきなりパスワード認証を無効化すると、自分自身を締め出す原因になります。

家庭内用途ではSSHのポート変更を必須とは考えていませんが、「どの端末から管理するか」を絞るのは効きます。
固定の作業PCやノートPCからだけ触る形にすると、運用の見通しが立ちます。
Raspberry Piの初期セットアップやヘッドレス運用の流れはRaspberry Pi Getting started（https://www.raspberrypi.com/documentation/computers/getting-started.htmlでも整理されています。
最初の段階で詰まりやすいポイントを押さえやすいです）。

更新も同じくらい地味で、同じくらい効きます。
OS本体だけでなく、apt で入れたパッケージ群もまとめて見ていく運用にしておくと、後から原因不明の不具合に見える問題を減らせます。
『Home Assistant OS』のように更新導線がまとまっている構成でも、周辺に置いたLinuxホストやブローカー側は別に面倒を見る必要があります。
筆者は新しい機能を足す前に、OS更新と再起動の確認を一度挟むことが多いです。
これだけで「設定変更のせいで壊れた」のか「前から壊れていた」のかを切り分けやすくなります。

チェック項目を最小限に絞るなら、次の5つで十分です。以下を順に確認してください。

OSユーザーの初期パスワードを変更する
SSHを有効化し、公開鍵認証でログインできる状態にする
鍵ログイン確認後に、SSHのパスワード認証を止める
OSとパッケージを定期的に更新する
不要なサービスを起動しっぱなしにしない

TIP

自宅用の小さな構成ほど、「公開していないから後でいい」と先送りしがちです。
実際には、最初の1台で鍵認証と更新の流れを決めておくと、2台目3台目を増やしたときの管理負荷が一段下がります。

MQTT認証とTLS

MQTTは軽くて扱いやすい反面、初期の試作では認証なしで動かしてしまいがちです。
動作確認の段階ではそれでも前に進めますが、本番に近い形へ寄せるなら、少なくともブローカーにユーザー名とパスワードを設定し、ESP32側も認証付きで接続させる構成にしておくほうが安心です。
Mosquittoではユーザーごとの認証情報を持たせられるので、全部の端末で同じ資格情報を使い回すより、役割単位で分けたほうが管理しやすくなります。
たとえばセンサー送信用、制御用、管理用で分けておくと、どこで問題が起きたか追いやすくなります。

筆者の自宅では、外部公開を前提にしていない時期でも、ゲストWi-Fiを家庭内のIoT用ネットワークから分離し、そのうえでMQTT認証を入れたことで、接続トラブルの切り分けが明らかに楽になりました。
来客端末が同じネットワークに入らないだけでもノイズが減りますし、誤って別端末からブローカーへ接続される場面も減ります。
LAN内だから認証なしでもよい、という考え方より、ネットワーク分離とアプリ層の認証を二段で置くほうが現実的でした。

TLSは「必ず最初から入れるもの」というより、「どこを通る通信か」で判断すると整理しやすくなります。
家の中だけで閉じた有線LANや分離済みWi-Fi上で、まず構成を安定させる段階なら、認証付きの1883番ポートで始める選択は十分あります。
mqtt.orgのFAQでも、1883は非TLSのMQTT、8883はTLS付きMQTTの標準ポートとして整理されています。
外部ネットワークをまたぐ、VPN外から接続する、あるいは認証情報を平文で流したくない経路が入るなら、8883へ分けてTLSを有効にする価値が出ます。

TLSを入れるときは、暗号化そのものより証明書配布の運用が肝になります。
ESP32側にCA証明書を持たせるのか、自己署名証明書を配るのか、ドメイン名で運用するのかで準備が変わります。
インターネット越しの公開構成ではLet’s Encryptを使った証明書運用が候補になり、90日の有効期間を前提に自動更新まで含めて設計する流れが一般的です。
逆に、家庭内だけで名前解決も閉じているなら、TLS導入の前にまず認証付きMQTTとネットワーク分離を先に固めたほうが、全体の見通しは良くなります。

ESP32側のコードも、認証なし接続から一段だけ進めればよいので、心理的な壁はそこまで高くありません。
『PubSubClient』はデフォルトでMQTT v3.1.1を使い、ESP32ではWiFiClientSecureなどのTLS対応クライアントと組み合わせる形も取れます。
最初はユーザー名・パスワード付き接続に変え、TLS化はブローカー側のポート設計と証明書配布の整理が済んでから進めると、切り分けの順番が崩れません。

運用・監視とバックアップ

防御の仕組みとして名前が挙がりやすいのがFail2BanとUFW、そして細かく制御したい場合のiptablesです。
家庭内LANのRaspberry Piに企業向けの厳格なルールセットをそのまま持ち込む必要はありませんが、考え方はそのまま使えます。
まず、どのポートを誰に開けるのかを決め、その範囲以外は通さない。
これが基本です。
SSHを使うなら管理端末からだけ、MQTTを使うならIoTセグメントからだけ、Web UIを使うならLAN内からだけ、という整理です。

UFWはその整理をシンプルに保ちたいときに向いています。
背後ではiptables系の仕組みに流れますが、日常運用では許可ルールの一覧を見て把握しやすい形に保てます。
一方で、iptablesを直接触る構成は自由度が高いぶん、あとから見返したときに「なぜこの順番で入っているのか」が分かりにくくなりがちです。
趣味の自宅サーバーでは、まずUFWで必要最小限の穴だけ開ける構成のほうが扱いやすい場面が多いです。

Fail2Banは、SSHの総当たり対策として入れておくと効果が見えやすい部類です。
ログを監視し、一定回数の失敗を検知したIPをファイアウォールで一時的に遮断する仕組みなので、SSHを有効にしているなら導入対象として筋が通っています。
逆に、LAN内だけで完結し、接続元も限られている構成で、そもそもSSHを常用しないなら優先度は落ちます。
筆者は「外へ見せているか」だけでなく、「認証失敗ログが発生しうる入口があるか」で判断しています。
仕組みの見た目より、入口の数で優先順位を付けるほうが運用に合います。

監視は大げさなダッシュボードから始めなくても回ります。
まず見るべきなのは、ブローカーの接続ログ、再起動後のサービス起動状況、ESP32の再接続頻度です。
センサー値が止まったときも、アプリ側の不具合より先にMosquittoへ接続できているか、Wi-Fiが再接続を繰り返していないかを見るだけで、原因の半分くらいは絞れます。
自宅IoTは「壊れた」より「どこで止まったか分からない」が面倒なので、ログを眺める習慣があるだけで復旧時間が短くなります。

バックアップも見逃せないポイントです。
Raspberry PiはmicroSDで動かす構成が多く、カード自体はRaspberry Pi Getting startedで案内されています。
通常版のRaspberry Pi OSなら32GB以上、Raspberry Pi OS Liteなら16GB以上がひとつの目安です。
容量の話より運用で効くのは、安定して動いている時点のイメージを残しておくことです。
Mosquittoの設定、認証ファイル、Node-REDのフロー、必要なら『Home Assistant』のスナップショットや設定群を、microSD全体のイメージ化とセットで持っておくと、カード交換時の復旧が早くなります。

スマートホームの運用は「強い対策を一つ入れる」より、「小さい対策を途切れさせない」ほうが効きます。
初期パスワード変更、SSH鍵認証、更新、MQTT認証、必要な範囲だけのTLS、入口を絞るファイアウォール、認証失敗を見るFail2Ban、そしてmicroSDのバックアップ。
この並びを崩さずに回していくと、自宅LANでもトラブルの質が変わります。
壊れにくくなるというより、壊れても戻せる構成に近づきます。

この先に学ぶべきテーマと作例

IoT入門：クラウド連携の基本

この先を学ぶなら、まずは「家の中で取れたデータを、外でも見られる形にする」流れを一段深めるのが王道です。
『ESP32』で取得した温湿度や開閉状態をMQTTでRaspberry Piへ集め、そこからクラウドや可視化基盤へ渡す構成を理解すると、単なる工作から運用できるIoTへ進みます。
AWSのIoTとはが整理している通り、IoTはセンサー、通信、処理、活用までつながって初めて価値になります。
完成イメージは、外出先からでも「今の部屋の状態が見える」小さな監視基盤です。

筆者自身も、家全体を広げるときはいきなり照明制御には進みませんでした。
最初は温湿度監視を作って、データが安定して貯まる感覚をつかみ、その後に赤外線スマートリモコン、さらに照明自動化へと広げました。
この順番だと、通信が不安定なのか、制御ロジックが悪いのかを切り分けやすく、後から構成が増えても破綻しにくくなります。

MQTTを深く理解する

MQTTをもう一歩理解すると、スマートホーム全体の見通しが一気によくなります。
ここで学ぶテーマは、publishとsubscribeの役割、トピック設計、QoSの考え方、再接続時の振る舞いです。
『PubSubClient』はデフォルトでMQTT v3.1.1を使うので、まずはこの前提で『ESP32』とMosquittoの通信を読み解くと、ライブラリのサンプルコードも腹落ちしやすくなります。
完成イメージは、「センサー追加や機能追加をしても配線ではなくトピック設計で拡張できる」通信基盤です。

入門段階では、メッセージが届いたかどうかだけ見がちですが、実際に運用していると「どの名前で流すか」が後から効いてきます。
たとえば部屋名、デバイス名、役割を混ぜずに切るだけで、Node-REDや『Home Assistant』側の整理がぐっと楽になります。
筆者は最初の温湿度監視でこの設計を雑に始めてしまい、赤外線リモコンを追加した段階で名前空間を整理し直しました。
早い段階でここを学ぶ価値は大きいです。

Home Assistant導入

『Home Assistant』は、「点で動いていた自作デバイスを、家全体の仕組みにまとめる」段階で効いてきます。
Raspberry Pi向けには『Home Assistant』公式がRaspberry Pi Imagerを使った導入手順を案内しており、最初の構築ルートが明確です。
完成イメージは、温湿度、赤外線家電、照明、人感センサーが1つの画面に並び、自動化ルールも同じ場所で管理できる状態です。

Node-RED中心で始めた人でも、『Home Assistant』を後から足す流れは自然です。
筆者も最初はセンサー値を見て満足していましたが、部屋ごとの状態を一枚のUIで見たくなり、『Home Assistant』を入れてから「自作したものが家のインフラに変わった」という感覚が出ました。
単体の工作記事を追うより、全体の管理面まで視野に入るのがこのテーマの強みです。

スマートリモコン自作：赤外線制御

次の作例として手応えが出やすいのが、赤外線送受信を使ったスマートリモコンです。
ここで学べるのは、家電のリモコン信号を読み取り、『ESP32』から再送してMQTTや『Home Assistant』経由で操作する流れです。
完成イメージは、エアコンや照明をスマホ画面や自動化ルールから動かせる自作リモコンです。

筆者が温湿度監視の次に進めたのもこのテーマでした。
部屋の状態が見えるようになると、次は「その状態に合わせて何か動かしたい」と考えるようになります。
そこで赤外線制御を挟むと、リレー制御のように商用電源を直接触らずに済むため、制御の学習に集中できます。
スマートホームを広げる順番として、観測の次に赤外線制御を置く流れは扱いやすいと感じています。

温湿度モニタリング構築

入門の次に手を動かす題材として、温湿度モニタリングは今でも最優先候補です。
ここで学べるのは、センサー値の取得、一定間隔での送信、時系列での可視化、しきい値を超えたときの通知までの一連の流れです。
完成イメージは、「寝室が暑すぎる」「脱衣所の湿度が上がっている」といった状態変化を数字で追えるダッシュボードです。

筆者もここから始めましたが、家の中の空気感を数値で見るだけで、自動化の題材が一気に増えます。
エアコンをつける条件、換気のタイミング、除湿の必要性が感覚ではなくデータで見えるからです。
しかも温湿度監視は、失敗しても被害が小さく、通信・センサー・可視化の基本を一通り練習できます。
最小構成の記事から次へ進むなら、最も自然につながる作例です。

市販スマートホーム機器の比較

自作だけで家中を埋めるのではなく、市販機器と役割分担する視点も持っておくと構成が安定します。
このテーマで学べるのは、Nature RemoやSwitchBotのような市販スマートホーム機器と、自作したRaspberry Pi＋『ESP32』構成をどう住み分けるかです。
完成イメージは、「赤外線家電は市販品、部屋ごとの細かいセンシングは自作」といった、無理のないハイブリッド構成です。

筆者も全部を自作に寄せるより、既製品の得意分野は借りたほうが家全体の完成度が上がる場面を何度も見てきました。
とくに家族が触る操作系は、市販品のまとまりが効きます。
一方で、設置場所に合わせた細かいセンシングや独自ロジックは、自作側のほうが融通が利きます。
この比較テーマは、工作好きほど一度読んでおく価値があります。

Zigbee/Thread/BLE/Wi-Fiの選び方

通信規格の選定は、機器が増えてから効いてくるテーマです。
ここで学べるのは、Wi-Fiで始めるべき場面と、ZigbeeThreadBLEを選ぶべき場面の違いです。
『ESP32』の中でも、ESP32-H2はThreadやZigbee向けで、Wi-Fiは持たないという整理を理解すると、将来のMatter対応まで視野に入れやすくなります。
完成イメージは、電池駆動センサー、据え置きノード、ハブ機器を適切な無線で分担した構成です。

入門ではWi-Fiが分かりやすい一方、家のセンサーが増えると、常時接続の考え方だけでは窮屈になります。
筆者は最初の温湿度監視と赤外線リモコンまではWi-Fi中心で十分でしたが、照明や人感のように台数が増える領域を見ると、低消費電力の規格も視野に入れておく必要を感じました。
規格選びは最初から完璧に決めるものではなく、拡張時の悩みを減らすための地図として持っておくイメージです。

照明の自動化：人感＋リレー

制御系の作例として次に面白いのが、人感センサーとリレーを組み合わせた照明自動化です。
ここで学べるのは、人を検知して照明をオンにする条件分岐、一定時間後のオフ、誤作動を減らすためのルール設計、手動操作との両立です。
完成イメージは、廊下や収納、洗面所の照明が必要なときだけ点灯する仕組みです。

筆者が家全体の拡張で三段目に持ってきたのが、この照明自動化でした。
温湿度監視でデータ取得に慣れ、赤外線スマートリモコンで制御に慣れてから進むと、人感センサーの誤検知や点灯条件の調整にも落ち着いて向き合えます。
いきなりここから始めると「動いたけれど運用が落ち着かない」構成になりやすく、順番の意味が出やすいテーマです。
家のインフラとしてのスマートホームを感じやすいのは、この段階からです。

TIP

学習ルートに迷ったら、筆者は「見える化」「既存家電の遠隔操作」「電源を伴う自動制御」の順で進めます。
温湿度監視、赤外線スマートリモコン、照明自動化の並びにすると、通信、可視化、制御の理解が少しずつ積み上がります。

まとめと次のアクション

自作スマートホームの入口は、Raspberry Piを司令塔、『ESP32』を末端ノードに分け、MQTTのPub/Subでつなぐ最小構成です。
まずはRaspberry Piと『ESP32』を1台ずつ用意し、PiにOSを入れてMosquittoとNode-REDを載せ、ESP32からテストトピックへPublishして受信を確認してください。
そこまで通ったらNode-RED側でSubscribeし、LED制御までつながれば土台はできています。
筆者はいつも、最初に1部屋だけで疎通と最小ダッシュボードを固め、運用が落ち着いてから家全体へ横に広げます。
安定後に『Home Assistant』やTLSを足す順番にすると、切り分けで詰まりません。
価格と入手性は動くので、購入直前にAmazonや国内代理店・販売店の最新価格と在庫を見直してから揃えるのが確実です。