ESP32温湿度モニタリングの始め方｜可視化まで - TsukuLab | ツクラボ

ESP32で温湿度モニタリングを作ると何ができるか

用途シーンと完成イメージ

温湿度モニタリングは、温度と湿度を継続して測り、その値を記録し、必要ならしきい値を超えた変化を拾い、あとから見返せる形にする仕組みです。
単に今の室温を1回読むだけなら市販の温湿度計でも足りますが、朝から夜にかけてどう変わったか、不在中にどこまで湿度が上がったかまで追えるようになると、用途が一気に広がります。
人が気づいたときだけメモする運用と違って、取り忘れや見間違いが入り込みにくい点も実用面で効きます。

使い道は家庭内だけでも十分あります。
たとえば自宅や作業部屋なら、冷暖房の効き方や換気のクセが見えます。
3Dプリンター用フィラメントの保管箱では、乾燥状態が崩れていないかを数値で追えます。
サーバーラック周辺なら、排熱で局所的に温度が上がっていないかを確認できますし、植物育成棚では昼夜の変化が育成環境の調整材料になります。
押し入れや収納の湿気監視も相性がよく、カビが出る前に「この場所は湿度が高止まりする」と判断できるのは、スポット測定にはない強みです。

完成イメージとしては、まずArduino IDEで読み出した値をシリアルモニタに出し、温度と湿度が安定して読める状態を作ります。
その次に、同じ値をローカルのWeb画面で見られるようにすると、PCやスマホから現在値を確認できるようになります。
さらに記録先を用意すると、時系列グラフに展開できます。
筆者は自宅でMQTTNode-REDInfluxDBGrafanaにつないでいますが、常時表示のダッシュボードにすると「今どうか」だけでなく「昨日より湿度が高い」「毎日昼に温度が上がる」といった傾向まで自然に読めます。
ABEJAの技術ブログでもESP32と可視化基盤を組み合わせた例が紹介されていて、単発表示から時系列監視へ広げる流れは実践的です（『ESP32 x Prometheusで温湿度・気圧データを可視化』）。

筆者が実際に役立ったと感じたのは、設置場所の違いがグラフにそのまま出ることです。
日射の当たる窓辺にセンサーを置いたときは、昼だけ温度が鋭く跳ね上がり、湿度の線も引っ張られて見えました。
部屋全体の空気を見たいつもりでも、実際には「窓辺の日射」を測っていたわけです。
数値だけ眺めていると見落としがちですが、時系列グラフにすると不自然な山がひと目で分かります。
この経験から、温湿度モニタは用途と設置位置を切り離して考えないほうがうまくいきます。
作業部屋の快適性を見たいのか、収納内部の湿気を見たいのかで、置く場所も通風の考え方も変わります。

ESP32の強み

ESP32が温湿度モニタリングの土台として定番になっている理由は、センサーを読むだけで終わらず、記録や可視化まで1枚でつなげやすいからです。
EspressifのESP32はWi‑FiとBluetoothを内蔵したマイコンで、外付け通信モジュールなしでネットワーク連携まで持っていけます。
Espressif ESP32 公式概要Espressif ESP32 公式概要でも、その位置づけが明確です。
温湿度の取得自体は小さな仕事ですが、そこからローカルWeb表示、MQTT送信、ホームネットワークへの統合まで広げられる余地があるので、学んだ内容がそのまま次の段階につながります）。

普及している背景には、価格の軽さと情報量の多さもあります。
ESP32-DevKitC系ボードは参考価格で1,000円〜2,000円程度の例が多く、入門用として現実的な範囲に収まります。
しかもArduino系の実装例が豊富で、最初はArduino IDEから始められます。
温湿度センサー側もDHT11DHT22『BME280』AM2320のような定番がそろっていて、サンプルコードや配線例を見つけやすい構成です。
AM2320のようなI2Cセンサーなら3.1V〜5.5Vで動き、I2Cアドレスは0x5Cなので、ESP32側に複雑な通信回路を足さずに組めます。

ハードウェアとしての余力もあります。
ESP32は最大240 MHzで動作し、40 nmプロセスで製造されています。
このあたりの数値は、温湿度を読むだけなら持て余すほどですが、だからこそWebサーバーを立てながらセンサーを読み、さらにネットワーク送信までこなせます。
単機能の表示器ではなく、小さな監視ノードとして扱えるのが強みです。
BluetoothやWi‑Fiを内蔵したSoCがここまで広く流通しているので、家庭のIoTでは「まずESP32で1台組む」が自然な出発点になります。

ただ、機能が多いからといって最初から全部載せる必要はありません。
筆者はこの手の構成を作るとき、最初の目標を「数値が安定して読める」に固定します。
BME280でもAM2320でも、配線、電源、取得周期、設置位置が整っていない段階で可視化基盤まで進むと、どこで値がおかしいのか切り分けにくくなります。
数値の安定を確認してから、次にWeb表示、さらに時系列保存という順に積み上げるほうが、トラブルの位置が見えます。
Random Nerd TutorialsのESP32でDHT11/DHT22を使うチュートリアルも、まずは基本的な読み出しから始める流れで、入門段階の進め方として筋が通っています（ESP32でDHT11/DHT22を使うチュートリアル）。

ESP32 Wi-Fi & Bluetooth SoC

espressif.com

連続記録の意義

温湿度は、その瞬間の値だけでは判断しにくい場面が多いです。
たとえば収納の湿気は、朝に見たとき正常でも、夜間だけ上がっていることがあります。
作業部屋も、在室中は快適でも不在中に温度がこもっているかもしれません。
ここで効いてくるのが連続記録です。
値が積み上がると、平均的な傾向、急な変化、毎日同じ時間に起こるクセが見えてきます。
スポット測定では取りこぼす変化を拾えるので、監視としての意味が出ます。

人的ミスを減らせる点も見逃せません。
手で測る運用は、測る時間がずれたり、記録を忘れたり、異常が起きた瞬間を逃したりします。
連続記録なら、その穴が小さくなります。
筆者の感覚では、温湿度モニタの価値は「今の数値が取れた」ことより、「あとでグラフとして振り返れる」ことにあります。
グラフがあると、冷房設定を変えた日、換気を増やした日、除湿剤を入れ替えた日などの効果も比較しやすくなります。

NOTE

温湿度モニタを作るときは、現在値の表示を先に完成させ、その後で時系列グラフを追加すると、配線の問題と記録系の問題を分けて追えます。

連続記録を前提にすると、センサー選びの見方も少し変わります。
DHT11は入門用として動かしやすい一方で、実用寄りの監視ではDHT22や『BME280』のほうが扱いやすい場面が増えます。
特にグラフ化すると、測定値の粗さや安定性の差がそのまま見えてきます。
逆に言えば、最初の1台では高機能構成を急ぐより、素直に値が並ぶセンサーと、無理のない記録経路を選ぶほうが結果的に前へ進めます。
シリアル表示で土台を作り、ローカルWebで見せ方を整え、そこからGrafanaのような時系列可視化へ伸ばす流れは、学習順としても運用順としても無駄が少ない構成です。

GitHub - adafruit/Adafruit_BME280_Library: Arduino Library for BME280 sensors

Arduino Library for BME280 sensors. Contribute to adafruit/Adafruit_BME280_Library development by creating an account on

github.com

必要なもの｜ESP32と温湿度センサーの選び方

推奨ボードと周辺機材

最初にそろえる部品は、できるだけ「情報量が多い定番」に寄せると迷いが減ります。
ESP32側は ESP32-DevKitCまたはESP32-WROOM系の開発ボード が無難です。
国内記事や作例が豊富で、Arduino IDEでも扱いやすく、価格も参考価格で1,000円〜2,000円程度の範囲に収まることが多いからです。
EspressifのESP32はWi-FiとBluetoothを内蔵したSoCとして広く使われていて、公式概要でもIoT向けの定番であることがわかります（『Espressif ESP32 公式概要』）。

このセクションで必要になる部品を先に表でそろえると、買い漏れを防げます。

部品	数量	推奨例	役割	補足
ESP32開発ボード	1	ESP32-DevKitC、ESP32-WROOM系	センサー値の取得、Wi-Fi送信、表示制御	日本語情報が多く、最初の1枚に向きます
温湿度センサー	1	DHT11、DHT22、『BME280』、AM2320系	温度・湿度、または気圧の計測	用途に応じて選びます
USBケーブル	1	ボードの端子形状に合うもの	書き込みと給電	充電専用ではなくデータ通信対応品を使います
ブレッドボード	1	ハーフサイズ以上	はんだ付けなしで試作する土台	配線の差し替えが多い初期段階で便利です
ジャンパワイヤ	数本	オス-オス中心	ESP32とセンサーの接続	色を分けると配線ミスを減らせます
抵抗	必要に応じて	10kΩ	DHT系のプルアップ用	モジュールに内蔵されている場合は不要です
可視化先PC/サーバー	1	PC、ローカルサーバー、Docker環境	シリアル表示、Web表示、保存先	まずはPC、次にサーバーへ広げる流れが自然です

USBケーブルは見落としがちな部品です。
ESP32ボードは手元に届いても、ケーブルが充電専用品だとArduino IDEから認識されず、最初の一歩で止まりやすいんですよね。
センサーやボード本体より地味ですが、データ通信対応のUSBケーブル を1本含めて考えると、作業が止まりません。

可視化先も、この時点でざっくり決めておくと後が楽です。
最小構成ならPCのシリアルモニタで十分ですし、1台で見られる形にしたければローカルWeb表示、長期保存まで含めるならローカルサーバーやDocker環境が候補になります。
筆者のようにDocker上でMQTTやGrafanaへ広げることもできますが、最初はPCに値が出るところまでで十分意味があります。

可視化方式まで含めた全体像は、次の表くらいの粒度で押さえておくと判断しやすくなります。

可視化方式	難易度	必要なもの	向いている場面
シリアル表示	低い	ESP32、センサー、PC	まず値が読めるか確かめたい段階
ローカルWeb表示	中	ESP32、Wi-Fi環境、ブラウザ付きPC/スマホ	PCをつなぎっぱなしにせず見たい段階
MQTT→DB→Grafana	中〜高	ESP32、MQTTブローカー、DB、Grafana、PC/サーバー	長期記録と時系列分析まで進めたい段階

温湿度センサーの比較と選び分け

温湿度センサーは、まず動かすのか、実用監視まで見据えるのか で選ぶと整理できます。
候補としてはDHT11DHT22『BME280』AM2320系の4つを押さえておけば十分です。

センサー	取得できる値	接続方式	特徴	向いている使い方
DHT11	温度・湿度	単線通信	安価で作例が多い一方、精度面は控えめ	配線と読み取りの流れを学ぶ入門用
DHT22	温度・湿度	単線通信	DHT11より一段実用寄り	室内の基本的な監視
『BME280』	温度・湿度・気圧	I2C / SPI	気圧まで取れて拡張性が高い	可視化や分析を広げたい用途
AM2320系	温度・湿度	I2C	I2Cで扱え、室内監視に向く	DHTより配線を整理したい用途

DHT11は安価で、検索すると作例が大量に見つかります。
配線も単純で、温湿度センサー入門の教材としては役立ちます。
ただ、精度面は期待しすぎないほうがよい センサーです。
数値を「読めた」という学習には向いていますが、部屋の変化を真面目に見たい段階になると、値の粗さが気になりやすいです。

DHT22はその中間です。
温湿度モニタを実用品として考えたとき、DHT11より一歩前に出られます。
ただしDHT系共通の注意として、読み取り間隔や配線の状態に気を使います。
筆者の経験でも、DHT系は配線が少し甘かったり、読み取りの間隔が詰まりすぎたりすると NaN を返しやすく、コード側の問題なのか配線なのか切り分けに時間を使いがちです。
入門センサーとして有名でも、最初の成功体験が必ずしも最短になるわけではありません。

その点で『BME280』は、温湿度に加えて気圧も取得できるのが強みです。
あとからGrafanaで時系列グラフにしたとき、温度と湿度だけでなく気圧も並べて見られるので、環境変化の読み解きが一段深くなります。
I2C接続なら配線本数も少なく、ESP32では一般的にSDAをGPIO21、SCLをGPIO22へつなぐ構成が取りやすいので、試作段階での混乱も抑えられます。
『Adafruit BME280 Library』のような定番ライブラリがあるのも助かるポイントです。

AM2320系もI2Cで扱える候補です。
動作電圧は3.1 V〜5.5 Vで、ESP32の3.3 V系とも組み合わせやすく、I2Cアドレスは0x5Cです。
温度・湿度だけを取りたいなら十分な構成ですが、AM2320はスリープからのウェイクアップ手順を意識する場面があり、単純にI2Cスキャンだけで進めると引っかかることがあります。
配線は整いますが、ライブラリや初期化の流れを少し理解してからのほうが進めやすい部品です。

センサー方式をざっくり比べると、こんな見方になります。

項目	DHT系	BME280 / AM2320系
配線本数	少ない	少ない
通信方式	単線通信	I2C
学習テーマ	タイミング制御も含めて学べる	I2C機器の基本を学べる
読み取りの安定感	配線品質と間隔の影響を受けやすい	比較的組みやすい構成を作りやすい
拡張の広げ方	温湿度の基本確認向け	複数センサーや可視化へ伸ばしやすい

最初の成功パス

最初の1台としておすすめしたい組み合わせは、ESP32 + 『BME280』 + I2C + PCのシリアル表示 です。
理由はシンプルで、配線が少なく、読み取りが安定しやすく、あとからWeb表示やMQTTへ伸ばしても構成をそのまま活かせるからです。

DHT系で始めると、センサー自体は有名でも、NaN が出たときに「配線」「読み取り間隔」「ライブラリ設定」のどこを疑うべきかで止まりやすいです。
筆者も最初の数台はそこに時間を取られました。
一方、『BME280』をI2Cでつなぐ構成だと、見るべきポイントが VCC、GND、SDA、SCLの4本 に絞られます。
配線チェックの範囲が狭いので、学習効率が上がります。

BME280を使うときは、I2Cアドレスが0x76か0x77のどちらかになるモジュールが多いので、スケッチで片方を試して反応がなければもう片方を見る、という切り分けが基本になります。
この「疑う場所が少ない」感覚が、最初の成功パスでは効きます。
値が出たあとも、そのまま気圧が見えるので、単なる温湿度計で終わらず、時系列可視化の題材として伸びしろがあります。

ソフト側の入口も整理しやすいです。
Arduino IDEにesp32 by Espressif Systemsを入れ、センサー側は『Adafruit BME280 Library』を追加する、という形で進められます。
EspressifのArduino向けドキュメントでも、ESP32はArduino IDEから扱える流れが整っています。
I2Cベースのセンサーはコードの構成も読みやすい部類です（『ESP32 Get Started』）。

この段階の可視化先はPCで十分です。
シリアルモニタに温度、湿度、気圧が並んで出れば、センサーの接続とライブラリ導入がひとまず通ったことになります。
そこからローカルWeb表示へ進めてもよいですし、サーバーを用意できるならMQTT経由で蓄積に進めます。
中級構成のイメージを先に見ておきたい場合は、ABEJAの技術ブログにあるESP32の環境データ可視化例が参考になります（『ESP32 x Prometheusで温湿度・気圧データを可視化』）。

TIP

最初の1台で迷ったら、センサー選びは「気圧も欲しいか」ではなく「切り分け箇所を減らせるか」で決めると失敗が少なくなります。
BME280のI2C構成は、この基準にうまくはまります。

こういう人におすすめ

まず動かしたい人には、ESP32-DevKitCまたはESP32-WROOM系 + 『BME280』 + シリアル表示 の組み合わせが合っています。
配線が4本中心で、PCに数値が出たかどうかで成否をすぐ判断できます。
電子工作が初めてでも、「どこを見るべきか」が散らばりません。

部品代を抑えつつ温湿度センサーの基本を学びたい人なら、DHT11も選択肢に入ります。
安価で、サンプルコードや配線例が多いので、センサー入力の流れを知る教材としては有効です。
ただし、実際の室内監視や記録まで考えると、次の段階でDHT22かBME280へ移りたくなることが多いはずです。

室内監視を実用品として作りたい人には、DHT22かAM2320系が候補になります。
温湿度だけを堅実に取りたいならこのあたりがちょうどよく、I2C配線で進めたいならAM2320系が収まりやすいです。
ローカルWeb表示との相性もよく、PCを常時接続しない構成へ移りやすいです。

温湿度の記録をグラフで見たい人、気圧まで含めて分析したい人、将来的にMQTTやGrafanaへ広げたい人には、『BME280』がもっとも噛み合います。
温湿度だけでなく気圧も加わることで、可視化したときの情報量が増えますし、I2C構成のままサーバー連携へ進めるので、最初の試作がそのまま次の段階の土台になります。
Dockerやローカルサーバーに慣れているなら、可視化先をPCからサーバーへ移す流れも自然です。

配線する｜まずはセンサー値を読める状態にする

I2C（BME280/AM2320）の配線

まず最短で値を出したいなら、I2C接続の『BME280』かAM2320から入ると流れがつかみやすくなります。
ESP32のESP32-DevKitC系では、標準的な配線として VCCを3.3V、GNDをGND、SDAをGPIO21、SCLをGPIO22 に結びます。
読むべき線が4本に絞られるので、通信経路を頭の中で追いやすく、シリアルモニタに数値が出るまでの切り分けも素直です。

接続を表にすると、最初の確認がぶれません。

センサー側	ESP32-DevKitC系
VCC	3.3V
GND	GND
SDA	GPIO21
SCL	GPIO22

『BME280』はI2Cで温度・湿度・気圧をまとめて読めるので、最初の成功体験を作りつつ、その先の可視化にもつなげやすい構成です。
I2Cアドレスは 0x76 または 0x77 のどちらかで見えることが多く、スケッチの初期化で片方が見つからないときは、配線ミスと決めつける前にアドレス違いを疑うと切り分けが進みます。
筆者はこの段階でI2C Scannerを先に流し、何番地で応答しているかを見てから本命スケッチへ進めることが増えました。
通信そのものが生きているかを先に見るほうが、ライブラリ設定と配線を同時に疑わずに済むからです。

AM2320もI2Cでつなげられ、ESP32側の線は同じ発想で組めます。
VCCを3.3V、GNDをGND、SDAをGPIO21、SCLをGPIO22に置けば、まずは最小構成として成立します。
AM2320はI2Cアドレスが 0x5C なので、『BME280』のように0x76と0x77を探す流れとは少し違います。
その代わり、スリープからの復帰手順が絡むことがあり、単純なスキャンだけでは見え方に戸惑う場面があります。
ここで慌てず、まず電源とGND共通を見て、その次に通信の初期化手順を見る順番にすると迷子になりにくくなります。

I2Cでは GNDを共通にすること が前提です。
ESP32とセンサーがそれぞれ別の電源ラインにつながっていても、GNDが共有されていないと、SDAとSCLの電圧基準がそろわず通信が成立しません。
筆者は一度、ブレッドボードでSDAとSCLが隣の列にまたがって刺さっていたのに気づかず、ずっと通信失敗を追いかけたことがありました。
見た目では刺さっているように見えるのに、列が1本ずれているだけでI2Cは沈黙します。
それ以来、配線を変えるたびに「SDAは同じ列、SCLは同じ列、GNDは共通」と声に出して確認しています。
地味ですが、この確認だけで無駄なデバッグ時間が減ります。
I2Cでは必ず GND を共通にしてください。
ESP32とセンサーが別電源につながる場合でも、GNDが共有されていないとSDA/SCLの電位基準がそろわず通信は成立しません。
さらに、SDA/SCLはプルアップ前提の信号なので、ブレークアウト基板にプルアップ抵抗が実装されていない場合は外付けで（一般に4.7k〜10kΩの範囲で）追加してください。
モジュールによって実装の有無が異なるため、見た目が似ていてもここで動作が分かれることがあります。
配線の基本形は次の通りです。

センサー側	ESP32の接続例
VCC	3.3V
GND	GND
DATA	GPIO4

GPIOは任意の汎用ピンを使えますが、最初は作例の多い GPIO4 にそろえるとコード例との対応が取りやすくなります。
加えて、DATAと3.3Vの間に10kΩのプルアップ抵抗 を入れておくと、信号線のレベルが安定します。
DHTモジュール基板の中には抵抗を内蔵しているものもありますが、裸のセンサーや最小構成の基板では外付け前提で考えたほうが配線の意味を理解しやすくなります。

接続のイメージを文字で揃えると、VCCは3.3V、GNDはGND、DATAはGPIO4、そしてDATAから3.3Vへ10kΩを1本入れる形です。
DHT系で NaN が出るときは、ライブラリやサンプリング周期も候補に入りますが、実際にはこのプルアップ不足かGNDの取りこぼしで止まっていることが少なくありません。

読み取り間隔にも癖があります。
DHT22は 2秒以上の間隔 を空けて読む前提で扱うのが無難です。
連続で何度も読もうとすると、値が更新されない、あるいは読み取り失敗になることがあります。
単線通信は「1本だから簡単」と見えますが、実際はタイミングを守る前提で成立しています。
ここを押さえておくと、「配線は合っているのに値が変」という状態を減らせます。

電源はDHT系でも 3.3V動作を軸にする のが扱いやすいです。
ESP32のGPIOは3.3V系なので、センサー側や周辺モジュールに5V系が混ざると、信号レベルの整理が別途必要になります。
最初の一台では、ESP32もセンサーも3.3Vでそろえ、GNDを共通化したうえで、DATAだけを1本引く形にすると全体像が崩れません。

TIP

DHT系で値が出ないときは、コードより先に「VCCは3.3Vか」「GNDは共通か」「DATAにプルアップがあるか」「読み取り間隔が詰まりすぎていないか」の4点を見ると、切り分けが短く済みます。

ピン配置の落とし穴と確認ポイント

ESP32の配線でつまずきやすいのは、回路の難しさより ピン番号の見間違い です。
ESP32-DevKitC系ではI2CをGPIO21とGPIO22に置く例が定番ですが、その感覚のままESP32-S2ESP32-S3ESP32-C3に移ると、ボード上の印字やサンプルコードとの対応がずれて混乱しやすくなります。
EspressifのArduino向け資料でも、I2Cは固定専用ピンではなく設定で割り当てられる前提になっているので、コード側の Wire.begin() と実配線を同じ前提で見ておく必要があります。

この段階で効くのは、本文の接続表、手元の図、実際に刺したピン番号が一致しているかを1セットで照合すること です。
たとえば表ではSDAをGPIO21としているのに、図では別ピン、実機ではボードのシルク印刷を読み違えていた、という食い違いがあると、どれか1つだけ正しくても通信は通りません。
配線トラブルの多くは電子回路そのものより、情報の不一致から起きます。

確認ポイントは多く見えて、実際には絞れます。

センサーのVCCがESP32の3.3Vにつながっていることを確認してください。
センサーのGNDとESP32のGNDが共通になっていることを確認してください。
I2CならSDAとSCL、DHTならDATAが、コードで指定したGPIOに一致していることを確認してください。
プルアップ抵抗が必要な方式で、抵抗の有無が配線と合っていることを確認してください。
『BME280』では0x76か0x77、AM2320では0x5Cというアドレス前提と、実際の応答が食い違っていないことを確認してください。

『BME280』で反応がないときは、センサー不良より先にアドレスの不一致を疑うと筋が通ります。
Random Nerd TutorialsのESP32でDHT11/DHT22を使うチュートリアルでも、ESP32のGPIO割り当てや配線確認が最初の関門になっていますESP32のGPIO割り当てや配線確認が最初の関門になっています。
I2C系ではそこにアドレス確認が加わる、と考えると整理できます。

ブレッドボードを使う場合は、左右の電源レールが途中で分断されている個体もあり、上半分では3.3Vが来ているのに下半分では来ていない、ということも起こります。
線そのものより、どの列が電気的につながっているか を基準に見るほうが確実です。
見た目で「近いから大丈夫」と判断すると、SDAやSCLだけでなくGNDの断線も見逃します。
筆者は配線作業のたびに、電源、GND、信号線の3系統を分けて確認するようにしてから、最初の起動でそのまま値が出る割合が上がりました。
最小構成で一度読める状態まで持っていくには、この確認の順番が効きます。

プログラムを書く｜シリアルモニタで温度・湿度を確認する

Arduino IDE設定とライブラリ導入

ここではArduino IDEで最初の動作確認まで進めます。
使用環境は Arduino IDE 2.x、ESP32向けのボードパッケージは esp32 by Espressif Systems を想定します。
執筆時点の作業環境例としては「Arduino core for the ESP32 3.3.7」を用いて検証しましたが、ボードパッケージは頻繁に更新されます。
導入時は Boards Manager で最新版（または安定版）を確認してください（バージョン差異が原因で動かない場合は、ここを疑うと早く解決します）。

ボード定義は、手元の基板名がメニューにあるならその実ボード名を、迷う場合は ESP32 Dev Module を選ぶ形で十分です（なお本文で挙げているボードパッケージやコアバージョンは執筆時点の例であることに注意してください。
導入時はBoards Managerで最新版または安定版を確認してください）。

Arduino IDEでの準備は、まずボードマネージャに esp32 by Espressif Systems を入れるところから始まります。
追加のボードマネージャURLに を登録し、ボードマネージャでesp32` を検索してインストールします。
そのあと、ツールのボードから ESP32 Dev Module か実機のボード名を選びます。

ライブラリはセンサーごとに分かれます。
『BME280』をI2Cで使うなら、『Adafruit BME280 Library』 に加えて 『Adafruit Unified Sensor』 と 『Adafruit BusIO』 を入れます。
DHT22を使うなら、『DHT sensor library』 と 『Adafruit Unified Sensor』 を入れます。
『Adafruit BME280 Library』の導入ページやサンプル構成は、公式のGitHubでも確認できます（『Adafruit BME280 Library』）。

この段階では、まだHTTP送信やMQTT連携に広げなくて構いません。
まずはシリアルモニタに温度と湿度が一定間隔で出る状態を作るほうが、配線、ボード設定、ライブラリ導入のどこで止まっているかを切り分けやすくなります。

BME280（I2C）コード全文と解説

『BME280』の初回確認でつまずきやすいのは、配線ミスより I2Cアドレスの食い違い です。BME280 not found は珍しいエラーではなく、実際には 0x76 と 0x77 の違いで止まっていることが多いです。
筆者はこの切り分けを早くするために、初期化時に「どちらのアドレスを試したか」をシリアルに必ず出すようにしています。
見えているかどうかをログで可視化すると、センサー不良を疑う前に確認すべき点が絞れます。

以下は、そのまま貼り付けて試せる『BME280』用のコードです。
I2Cは SDA=21、SCL=22 を明示し、0x76 と 0x77 を順に試します。
読み取り間隔は 2秒にしてあります。

#include <Wire.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BME280.h>

#define SEALEVELPRESSURE_HPA (1013.25)

Adafruit_BME280 bme;
bool bmeFound = false;
uint8_t bmeAddress = 0x76;

const int I2C_SDA = 21;
const int I2C_SCL = 22;
const unsigned long READ_INTERVAL_MS = 2000;
unsigned long lastReadMs = 0;

bool tryBeginBME280(uint8_t addr) {
  Serial.print("Trying BME280 at I2C address 0x");
  Serial.println(addr, HEX);

  if (bme.begin(addr)) {
    bmeAddress = addr;
    Serial.print("BME280 found at 0x");
    Serial.println(bmeAddress, HEX);
    return true;
  }
  return false;
}

void setup() {
  Serial.begin(115200);
  delay(1000);

  Serial.println();
  Serial.println("ESP32 + BME280 test");

  Wire.begin(I2C_SDA, I2C_SCL);
  Serial.print("I2C started. SDA=");
  Serial.print(I2C_SDA);
  Serial.print(", SCL=");
  Serial.println(I2C_SCL);

  if (tryBeginBME280(0x76)) {
    bmeFound = true;
  } else if (tryBeginBME280(0x77)) {
    bmeFound = true;
  } else {
    Serial.println("BME280 not found. Check wiring and I2C address (0x76 / 0x77).");
    bmeFound = false;
  }
} // setup() を閉じる中括弧をここに配置しています

void loop() {
  if (millis() - lastReadMs < READ_INTERVAL_MS) {
    return;
  }
  lastReadMs = millis();
    return;
  }
  lastReadMs = millis();

  if (!bmeFound) {
    Serial.println("Skip reading because BME280 is not initialized.");
    return;
  }

  float temperature = bme.readTemperature();
  float humidity = bme.readHumidity();
  float pressure = bme.readPressure() / 100.0F;
  float altitude = bme.readAltitude(SEALEVELPRESSURE_HPA);

  bool anyNaN = isnan(temperature) || isnan(humidity) || isnan(pressure) || isnan(altitude);
  if (anyNaN) {
    Serial.println("Failed to read from BME280.");
    return;
  }

  Serial.print("Temperature: ");
  Serial.print(temperature);
  Serial.println(" °C");

  Serial.print("Humidity: ");
  Serial.print(humidity);
  Serial.println(" %");

  Serial.print("Pressure: ");
  Serial.print(pressure);
  Serial.println(" hPa");

  Serial.print("Approx. Altitude: ");
  Serial.print(altitude);
  Serial.println(" m");

  Serial.println("-------------------------");
}

見ておきたい点は3つです。
ひとつ目は Wire.begin(21, 22) でI2Cピンを明示していることです。
ボード定義によってはデフォルトに頼っても動きますが、最初の確認ではコードと配線を一致させておくほうが迷いません。
ふたつ目は 0x76 と 0x77 を順番に試していることです。
I2Cアドレスの違いはBME280では本当に頻出で、ここを自動で試すだけでも切り分けが一段進みます。
みっつ目は isnan() による読み取り失敗の判定です。
シリアルに数字が出ていても、ときどき NaN が混ざるなら通信の安定性や電源ラインを見直すサインになります。

シリアルモニタのボーレートは 115200 に合わせます。
起動直後に Trying BME280 at I2C address 0x76 のようなログが出て、そのあと温度・湿度・気圧が並べば、最初の動作確認は通過です。

DHT22コード全文

DHT22では、I2Cアドレスの代わりに DATAピンの指定 と NaN判定 が効いてきます。
ここでは前の配線例に合わせて、DATAを GPIO4 にしたコードを載せます。
『Adafruit』のDHTライブラリでそのまま動く構成です。

#include <Adafruit_Sensor.h>
#include <DHT.h>

#define DHTPIN 4
#define DHTTYPE DHT22

DHT dht(DHTPIN, DHTTYPE);

const unsigned long READ_INTERVAL_MS = 2000;
unsigned long lastReadMs = 0;

void setup() {
  Serial.begin(115200);
  delay(1000);

  Serial.println();
  Serial.println("ESP32 + DHT22 test");

  dht.begin();

  Serial.print("DHT pin: GPIO");
  Serial.println(DHTPIN);
}

void loop() {
  if (millis() - lastReadMs < READ_INTERVAL_MS) {
    return;
  }
  lastReadMs = millis();

  float humidity = dht.readHumidity();
  float temperature = dht.readTemperature();

  bool anyNaN = isnan(humidity) || isnan(temperature);
  if (anyNaN) {
    Serial.println("Failed to read from DHT22. Retrying on next cycle.");
    return;
  }

  Serial.print("Temperature: ");
  Serial.print(temperature);
  Serial.println(" °C");

  Serial.print("Humidity: ");
  Serial.print(humidity);
  Serial.println(" %");

  Serial.println("-------------------------");
}

このコードで見るべきポイントは、dht.readHumidity() と dht.readTemperature() の戻り値をそのまま使わず、必ず isnan() を通していることです。
DHT22は読めるときは素直ですが、配線、プルアップ、読み取りタイミングのどれかが崩れると、数値ではなく NaN を返します。
ここで判定を入れずに計算や送信へ進めると、「表示がおかしい」のではなく「そもそも取得できていない」状態を見落とします。

シリアルモニタには温度と湿度だけが出ます。
『BME280』と違って気圧は取れませんが、室内の温湿度確認だけならこの構成で十分です。
最初の一歩としては、値が安定して並ぶところまで持っていくほうが、次の可視化や保存へつなげやすくなります。

読み取り間隔とNaN対策

読み取り間隔は、どのセンサーでも短ければ良いわけではありません。
とくにDHT22は 2秒以上 の間隔で読む前提で扱うほうが安定します。
ここを詰めすぎると、配線が正しくても NaN が混ざります。
前のセクションで触れたプルアップと合わせて、DHT系は「電気的な接続」と「待ち時間」の両方がそろって初めて素直に動きます。

『BME280』でも、初回確認の段階では2秒おきくらいがちょうどよいです。
シリアルの流れを目で追えますし、起動ログやエラーメッセージも埋もれません。
温湿度の変化は秒単位で激しく動くものではないので、短い間隔で連打しても得られる情報は増えにくく、むしろ切り分けが難しくなります。

NaN が出たときの対処は、コード側で無理に補正値を入れるより、まず 失敗をログに残して次周期で再試行する 形が扱いやすいです。
今回のサンプルが Failed to read... を出してその場で return しているのはこのためです。
センサー読み取りは、失敗した瞬間の値を何かで埋めるより、「失敗した事実」を見える形にしたほうが後で原因を追えます。

WARNING

シリアルモニタで最初に見るべきは、温度や湿度の数値そのものより初期化ログと失敗ログです。初期化が通っていない状態で先へ進むと、後の切り分けが難しくなります。

この段階で安定して読めていれば、ESP32からセンサー値を取る土台はできています。
次はその値をPC以外でも見える形にする、あるいは蓄積できる形に広げていけます。

データを可視化する方法を選ぶ

値が取れるようになったら、次は「どこで、どの形で見るか」を決める段階です。
ここは正解がひとつではなく、いま欲しい体験で選ぶのが近道です。
PCにつないだまま数値を確認したいのか、ブラウザで手元から見たいのか、日単位・週単位で記録して傾向を追いたいのかで、構成は変わります。

筆者は自宅のセンサー工作で、最初からGrafanaまで一気に組んだこともありますが、設定項目が増えるぶん、センサー読み取りの不具合と可視化基盤の不具合が混ざりやすくなりました。
いったん方式Aで「温度が上がった」「湿度が下がった」が目で追えるところまで持っていくと、数値が出る楽しさを先に体験できます。
その感覚があると、あとから方式Cの設定やデバッグに入っても、何のために手間をかけているのかを見失いません。

方式A：シリアル/ローカルWeb

最初の可視化として相性が良いのは、シリアルモニタか、ESP32内蔵の簡易Webサーバです。
シリアルモニタなら、すでに前のセクションで使っている表示をそのまま延長できます。
追加のサーバーもデータベースも不要で、ESP32とPCだけで完結します。
数値が一定間隔で流れてくるだけでも、配線、読み取り周期、センサーの安定性をまとめて観察できます。

もう一歩だけ見栄えを整えたいなら、ESP32をWi-Fiにつないでローカルネットワーク内に小さなWebページを出す方法があります。
ブラウザで温度と湿度を表示し、更新のたびに数値を書き換えるだけでも、PCのシリアルモニタを開きっぱなしにしなくて済みます。
『ESP32 Get Started』でわかる通り、ESP32はWi-Fiを前提にした開発情報が豊富なので、この段階の資料には困りません。
簡易グラフも、直近の数件を配列に持ってHTMLに描くだけなら十分実装できます。

この方式が向いているのは、まず動くものを見たい人です。
DHT11やDHT22で温湿度を読む入門では、とくに相性が良いです。
表示が素朴なぶん、トラブルの切り分け先が少なく、読めていないのか、送れていないのか、描画が壊れているのかで迷いません。
学習対象をセンサー読み取りとESP32の基本に絞れるのが強みです。

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

docs.espressif.com

方式B：HTTP送信

既存のWeb基盤があるなら、ESP32からHTTPでサーバーへ送る構成が自然です。
ESP32側は温湿度をJSONやクエリ文字列にしてAPIへPOSTし、受け側で保存と表示を担います。
REST APIをすでに持っている環境なら、可視化の仕組みを新しく覚える量が少なく済みます。
社内ツールや自宅サーバーに慣れている読者にとっては、もっとも収まりのよい方法です。

この方式の利点は、可視化と保存をESP32から切り離せることです。
たとえばWebアプリ側で一覧表示、折れ線グラフ、異常値の抽出を追加していけば、ESP32のスケッチは送信部分だけに集中できます。
データモデルを自分で決められるので、温湿度だけでなく、『BME280』で取った気圧や、設置場所の識別子も同じAPIに載せられます。
すでにFlaskやFastAPI、あるいは既存CMSのバックエンドを運用しているなら、この構成は実務の延長線上にあります。

一方で、サーバー側の受け口を自作する必要があるため、まったくのゼロから始める人には少し遠回りです。
グラフ表示まで自分で組むと、フロントエンドの実装も視野に入ります。
センサー工作の延長というより、「IoTデータをWebアプリに取り込む」発想の人に向いた方式です。

方式C：MQTT→InfluxDB→Grafana

長期記録とダッシュボード構築まで見据えるなら、MQTTを入口にして、Node-REDで整形し、InfluxDBに保存し、Grafanaで可視化する構成が伸びます。
ESP32は温湿度データをMQTTブローカーへPublishし、Node-REDが受信して必要な形式に整え、時系列データベースへ流し込みます。
Grafanaでは時系列グラフ、最新値パネル、しきい値アラートの土台まで一気につながります。
可視化の完成度を重視するなら、この構成の満足度は高いです。

自宅サーバーやミニPCがあるなら、Dockerでまとめて立ち上げる形が扱いやすいです。
コンテナごとに役割が分かれるので、MQTTブローカー、フロー処理、DB、ダッシュボードを個別に見直せます。
ESP32 x Prometheusで温湿度・気圧データを可視化のように、ESP32のセンサーデータを時系列で見る流れは業務寄りの監視とも相性がよく、趣味の工作でも「記録して比較する」価値が一気に上がります。
『BME280』のように取得項目が増えるセンサーでは、この方式の恩恵がとくに出ます。

そのぶん、学ぶ対象は増えます。
MQTTのトピック設計、Node-REDのフロー、InfluxDBの保存形式、Grafanaのクエリとパネル設定まで関わるので、最初の一台目には少し重い構成です。
方式Aで値が出る喜びを一度味わってから方式Cに入ると、ログの意味やグラフ化の価値が腹落ちします。
最初から全部を理解しようとするより、センサー値の手応えを持って進んだほうが、設定画面の多さに振り回されません。

方式比較と読者タイプ別おすすめ

3方式を並べると、違いは整理できます。

方式	難易度	準備物	長期記録	拡張性	おすすめ読者
シリアル/ローカルWeb	低い	ESP32、センサー、PC、ローカルWebならWi-Fi環境	弱い	中	はじめてESP32でセンサー値を見たい人
HTTP送信	中	ESP32、センサー、APIを受けるサーバー	可能	高い	既存のWeb基盤やAPI運用に慣れている人
MQTT→InfluxDB→Grafana	中〜高	ESP32、MQTTブローカー、Node-RED、InfluxDB、Grafana、サーバー環境	非常に向く	高い	ダッシュボードや時系列分析まで進めたい人

選び方を読者タイプに寄せると、まず一番わかりやすいのは「ESP32とセンサー工作が初めて」のパターンです。
この場合は方式Aが合っています。
画面は簡素でも、温湿度が変化して数値に現れる体験が先にあると、次の発展先を選びやすくなります。

普段からWebアプリやAPIを触っている人なら、方式Bの収まりが良いはずです。
認証、保存形式、表示画面まで自分の流儀で組めるので、既存の運用とつながります。
IoTの可視化を単独の遊びではなく、既存システムの一部として扱いたい人向けです。

ログを貯めてグラフを眺めたい、複数部屋にセンサーを増やしたい、将来的にHome Assistantや通知にも広げたいという人には方式Cが向いています。
最初の一歩としては少し重めですが、AからCへ段階的に育てる流れだと無理がありません。
まずAで読める状態を固め、次にMQTTで投げ、保存と可視化を後付けする形にすると、どこで詰まったのかを切り分けやすく、学習の順番にも無駄が出にくくなります。

TIP

迷ったときは、「今日ほしいのは数値の確認か、記録の蓄積か」で分けると決めやすくなります。
数値確認なら方式A、既存Web連携なら方式B、時系列分析まで含めるなら方式Cという整理でほぼ迷いません。

Grafanaでグラフ表示する構成例

構成概要と前提

この構成では、ESP32が温湿度データをMQTTで送信し、Mosquittoがブローカーとして受け取り、Node-REDがメッセージを整形してInfluxDBへ保存し、Grafanaがグラフとして表示します。
役割を分けると、どこで値が止まっているのかを切り分けやすく、温度・湿度だけでなく『BME280』で取った気圧や設置場所の情報も同じ流れに載せられます。

前提としては、ローカルネットワーク内に常時起動できるPCやミニPCが1台あり、そこにDockerとDocker Composeを入れて動かす形が扱いやすいです。
コンテナ単位でサービスを分離できます。
ブローカーだけ再起動する、Node-REDのフローだけ直す、といった作業が素直にできます。
中級者向けの橋渡しとしてもちょうどよく、ESP32からGrafanaまでのMQTT可視化例のような構成と発想はほぼ同じです。

筆者はこの手の構成で詰まったとき、いきなりGrafanaの画面を眺めません。
Dockerに慣れていない段階では、どのコンテナのログを見るべきかで止まりやすいからです。
まずmosquitto_subでブローカーに値が届いているかを確かめて、その次にNode-REDのDebugノードで整形後のメッセージを見て、保存先のInfluxDB、表示側のGrafanaという順で上流から追います。
この順番にすると、問題の場所がだいたい1段ずつ絞れます。

Docker Compose最小例

まずは4サービスをまとめて起動する最小構成を置くと、全体像をつかみやすくなります。
細かな本番向け調整は後回しにして、ポート、永続化ボリューム、依存関係だけ押さえる形で十分です。

version: "3.8"

services:
  mosquitto:
    image: eclipse-mosquitto:2
    container_name: mosquitto
    ports:
      - "1883:1883"
    volumes:
      - ./mosquitto/config:
      - ./mosquitto/data:
      - ./mosquitto/log:

  nodered:
    image: nodered/node-red:latest
    container_name: nodered
    ports:
      - "1880:1880"
    volumes:
      - ./nodered/data:
    depends_on:
      - mosquitto
      - influxdb

  influxdb:
    image: influxdb:2
    container_name: influxdb
    ports:
      - "8086:8086"
    volumes:
      - ./influxdb/data:
      - ./influxdb/config:

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - ./grafana/data:
    depends_on:
      - influxdb

この例では、Mosquittoが1883番、Node-REDが1880番、InfluxDBが8086番、Grafanaが3000番を使います。
ボリュームを切っているのは、コンテナを作り直しても設定やデータを残すためです。
depends_onは起動順の補助で、アプリケーションが起動完了して内部サービスが応答可能になるまでを保証しないため、初回起動時は数十秒待ってから各UIを開くと流れが安定します。

最初の起動は docker compose up -d で十分です。
その後の確認は docker compose ps で状態を見て、必要に応じて docker compose logs -f mosquitto のようにサービスごとのログを追います。
全部のログを一気に読むより、1サービスずつ切るほうが頭の中で整理しやすく、原因の候補も絞れます。

MQTTブローカーとトピック設計

MQTTは軽量で、ESP32から小さなJSONを定期送信する用途と相性が良いです。
ブローカーにはMosquittoを置くのが定番で、ESP32側は計測値をPublish、Node-RED側はSubscribeして受信します。

トピックは、あとでセンサーを増やす前提で決めておくと管理が楽です。
たとえば sensors/room1/bme280 のように、用途、設置場所、センサー種別の順で切ると見通しがよくなります。sensors/room1/temperature と値ごとに分ける方法もありますが、温度・湿度・気圧を同時に扱うなら、1つのトピックにJSONでまとめる形のほうがNode-RED側のフローが増えません。

送信ペイロードは、たとえば次のような形です。

{
  "temperature": 24.8,
  "humidity": 51.2,
  "pressure": 1008.4,
  "sensor": "bme280",
  "location": "room1"
}

QoSは、家庭内の温湿度監視ならQoS 0または1で十分です。
欠測が少し出ても連続観測の傾向を見る用途ならQoS 0で軽く運べますし、取りこぼしを少しでも減らしたいならQoS 1が収まりどころです。
QoS 2まで上げると構成が重くなるわりに、室内の環境ログでは得るものが少ない場面が多いです。

認証も最初から有効にしておくほうが運用が崩れません。
Mosquittoではパスワードファイルを作り、匿名接続を切る設定が基本です。
たとえば設定ファイルでは、匿名接続を禁止してパスワードファイルを読む形にします。

listener 1883
allow_anonymous false
password_file /mosquitto/config/passwd

ユーザーを分けるなら、ESP32用の送信アカウントと、Node-RED用の受信アカウントを分ける設計も考えやすいです。
自宅LANだから何もしない、という運用にすると、あとから機器が増えたときに境界が曖昧になります。

Node-REDフロー作成

Node-REDでは、まずMQTT Inノードで sensors/# を購読し、受けたJSONをFunctionノードでInfluxDB向けの形に整え、InfluxDB Outノードで保存します。
ここでやるべきことは、値をそのまま流すだけでなく、時刻、タグ、measurementを明示することです。

たとえば、MQTT Inの後にJSONノードを置いて文字列をオブジェクトへ変換し、その次のFunctionノードでこう整えます。

const p = msg.payload;

msg.payload = {
  measurement: "environment",
  tags: {
    location: p.location || "room1",
    sensor: p.sensor || "bme280"
  },
  fields: {
    temperature: Number(p.temperature),
    humidity: Number(p.humidity),
    pressure: Number(p.pressure)
  },
  timestamp: new Date().toISOString()
};

return msg;

measurementを environment にまとめ、location と sensor をタグにし、温度・湿度・気圧をフィールドに入れる形です。
この分け方にしておくと、Grafanaで「room1だけ表示」「bme280だけ表示」といった絞り込みが素直に書けます。
時刻はESP32側で付けてもよいのですが、まずはサーバー受信時刻で揃えるほうが構成が単純です。

フロー作成時は、保存先につなぐ前にDebugノードを挟むのが定石です。
受信した元データ、整形後データ、InfluxDB送信直前の3点のうち、どこで形が崩れたかを見られるようにしておくと手戻りが減ります。
筆者も最初はここを飛ばして遠回りしましたが、Debugノードを1個置くだけで、JSONのキー名違い、数値が文字列のまま、タグが空、という定番のミスをすぐ拾えるようになりました。

NOTE

Node-REDのFunctionノードでは、温度や湿度を Number() で明示的に数値へ変換しておくと、後段での集計やグラフ化時の保存ミスを避けやすくなります。

InfluxDBの準備

InfluxDBは時系列DBなので、温湿度のように「時刻付きの値」を扱う用途にぴったりです。
初回セットアップでは、組織、バケット、APIトークンを作成し、Node-REDからそのバケットへ書き込める状態にします。
InfluxDB 2系を使うなら、従来の「データベース名」より「バケット」の考え方で捉えると混乱しません。

バケット名は sensors や home_env のように用途が伝わる名前にしておくと、あとで別系統のデータを追加したときに見分けやすくなります。
保持期間も最初に決めておくと、運用の輪郭が出ます。
たとえば検証用途なら短め、部屋ごとの傾向を長く見たいなら長め、という発想です。
温湿度のような軽いデータは蓄積しやすい一方で、無制限に増やすとバックアップや移行時の負担が増えるので、保存年限の意識は早めに持っておく価値があります。

measurement設計はNode-RED側とセットで考えます。
今回のように environment をmeasurementとして、場所やセンサー種別をタグに寄せると、クエリがすっきりします。
温度を temperature、湿度を humidity、気圧を pressure と別measurementに分けることもできますが、1回の観測で同時に取得した値をひとまとまりで扱いたいなら、measurementは1つにしてフィールドを分けるほうが自然です。

Node-REDから接続するときは、InfluxDBのURL、組織名、バケット名、トークンを設定します。
ここで失敗しやすいのは、トークンの権限不足と、送信先バケット名の打ち間違いです。
MQTTまでは届いているのにDBに入らない場合、Node-REDのデバッグ画面とInfluxDB側の書き込みエラーを見比べると切り分けが進みます。

Grafanaのダッシュボード作成

Grafanaでは、まずInfluxDBをデータソースとして追加します。
接続先URL、組織、バケット、トークンを設定できたら、ダッシュボードを作って温度、湿度、気圧のパネルを並べます。
中級者向けの入口としては、1画面に3つの時系列パネルと1つの最新値パネルがあるだけでも実用感が一気に出ます。

温度は折れ線、湿度も折れ線、気圧は単位付きの時系列グラフにすると見やすくなります。
室内監視では、値の変化幅がそれぞれ違うので、同じY軸に無理に重ねるより、個別パネルに分けたほうが読み違えを減らせます。
さらに、温度はしきい値を超えたら色が変わる設定、湿度は乾燥・高湿の目安で背景色を変える設定を入れると、数値を読まなくても状態が把握できます。

アラートも入門として試しやすいポイントです。
たとえば室温が一定値を超えたら通知、湿度が一定値を下回ったら通知という形にすると、単なる記録から監視へ一歩進みます。
『ESP32 x Prometheusで温湿度・気圧データを可視化』のように、IoTデータを監視の文脈で扱う発想は家庭内の環境ログでもそのまま活きます。

ダッシュボード名やパネル名は、あとから見返したときに迷わない命名にしておくと効きます。room1 temperature よりも リビング温度 のように、人が読む前提の名前に寄せたほうが、家族や将来の自分が開いたときに理解が早いです。
技術的には英語でも日本語でも成立しますが、表示画面は運用の顔になるので、読み手基準で整える価値があります。

ESP32 x Prometheusで温度・湿度・気圧データを蓄積・可視化する - ABEJA Tech Blog

はじめに作ったもの ESP32 x BME280 ハードウェア準備 ESP32を用いた回路設計部品実装（リフロー）センサー仮組み ESP32ソフトウェア準備 platformio.ini src/main.cpp データ処理部分受信

tech-blog.abeja.asia

セキュリティと運用の注意

この構成はローカルネットワーク内で完結させる前提が扱いやすく、公開ポートは最小限に絞るのが基本です。
GrafanaやNode-REDのUIは便利ですが、外から見える状態にすると管理対象が一気に増えます。
家庭内で使う段階では、ルーターのポート開放はせず、同一LANからだけアクセスできる形に留めるほうが構成の目的に合っています。

認証はMosquittoだけでなく、InfluxDBとGrafanaでも有効にして、初期設定のまま放置しないことが前提になります。
とくにNode-REDはブラウザからフロー編集ができるため、誰でも触れる状態だとデータの流れそのものを書き換えられてしまいます。
編集UIと閲覧UIを分けて考える感覚を持つと、趣味の構成でも崩れにくくなります。

運用面では、コンテナの再作成に備えてデータ永続化とバックアップの置き場を先に分けておくと落ち着きます。
MQTTの設定、Node-REDのフロー、InfluxDBの保存領域、Grafanaのダッシュボードは、それぞれ失うと復元コストが違います。
中でもNode-REDのフローとGrafanaのダッシュボードは、動いている間は軽く見えますが、作り直しになると地味に時間を使います。
だからこそ、Composeでボリュームを切る設計が効いてきます。

可視化基盤は、センサー工作の延長というより、小さな監視システムを自宅に持ち込む感覚に近いです。
ESP32 Get Startedのような『Espressif公式ドキュメント』が示す開発の土台に、メッセージング、保存、可視化を重ねていくと、単なる数値確認から「時間で眺める」段階へ進めます。
ここまでつながると、温湿度の上下を見るだけでなく、換気のタイミング、部屋ごとの差、天候変化の影響まで読み取れるようになります。

精度を上げるコツ｜設置位置・校正・長期運用

設置位置と環境影響

温湿度の計測は、センサーの型番選びよりも、どこに置いたかで結果が変わる場面が少なくありません。
室内であっても、直射日光が当たる窓際、エアコンの吹き出しが直接当たる位置、PCやACアダプターの近く、照明の真下では、測っているつもりの「部屋全体の空気」ではなく、その場所特有の空気を拾ってしまいます。
温度センサーは放熱源の影響を受け、湿度センサーは結露や風の当たり方で応答が乱れます。
まず意識したいのは、何を測りたいのかではなく、どの空気を測りたいのかです。

具体的には、直射日光を避け、ヒーター、PC本体、電源アダプター、冷蔵庫の側面のような放熱源から距離を取り、結露しやすい窓面や水回りのすぐ近くは外します。
通風も見落としやすい点で、空気がほとんど動かない棚の奥に置くと、部屋の代表値というより局所的なよどみを記録し続けます。
逆にサーキュレーターの風が常時当たる位置では、変化が鋭く出すぎます。
壁面ぴったりや天井付近も温度差が出やすく、同じ部屋でも床近くと天井近くでは別の値になる、と捉えたほうが実態に近いです。

筆者は試作段階で、ESP32とセンサーを同じ密閉ケースに入れて設置したことがあります。
このとき温度がどうも高めに張り付いて、部屋の体感と合いませんでした。
原因はケース内にこもる基板の自熱で、通気孔を設けるか、センサーだけケースの外に出す構成へ変えると値が落ち着きました。
ESP32はEspressifの公式概要でもWi‑FiとBluetoothを内蔵したSoCとして整理されている通り、通信と制御を1枚でこなせるのが強みですが、そのぶんセンサーのすぐ横に置くと測定対象そのものを温めます。
工作としては一体化したくなりますが、計測としては分離配置のほうが筋が通ります。

湿度の読み方にもひとつ癖があります。
湿度は温度に依存していて、表示される相対湿度は「その温度の空気がどれだけ水分を抱えられるか」に対する割合です。
つまり、空気中の水分量が大きく変わっていなくても、温度が短時間で上がると相対湿度は下がり、温度が下がると相対湿度は上がります。
朝に暖房を入れた直後や、窓を開けて冷たい空気が流れた直後に湿度がぶれるのは、センサーの誤動作ではなく、相対湿度という量の性質で説明できます。
温度グラフと湿度グラフを並べて見ると、逆向きに動く場面があるのはこのためです。

こうした性質を踏まえると、設置位置は「部屋の中央に近い高さ」だけで決めるより、測りたい空気の流れを基準に考えるほうが失敗が減ります。
人が過ごす空間の快適性を見たいなら着座高さ付近、換気の効き方を見たいなら吸気・排気の中間、収納のこもり具合を見たいなら扉の内側近く、という具合です。
スポット測定では見えなかった偏りも、連続記録にすると設置場所の癖としてはっきり出ます。

TIP

センサー値が不自然に高い、または変化が鈍いときは、配線より先に「その空気を本当に測っているか」を疑うと切り分けが早く進みます。
とくにケース内部、壁面ぎわ、窓際、天井付近は値の癖が出やすい場所です。

校正と点検の進め方

温湿度モニタは、表示される数値がもっともらしく見えるぶん、ずれに気づきにくい計測です。
DHT22や『BME280』のような定番センサーでも、工作として動いていることと、計測として信頼できることは同じではありません。
用途が「部屋の傾向を見る」なのか、「しきい値で換気や除湿を制御する」なのかで、求める精度の扱いは変わります。
DIYではそこを曖昧にせず、必要な精度に合わせて校正の重みを決めるのが現実的です。

校正というと大げさに聞こえますが、最初の一歩は基準器との突き合わせです。
信頼できる温湿度計や校正済み機器を近接配置してしばらく同じ空気にさらし、表示の差を確認するだけでも意味があります。
DIY用途では、目的に応じて「どの程度の絶対精度が必要か」を先に決め、その上で簡易な突き合わせや定期点検を行うのが現実的です。
湿度の点検では、温度を切り離して考えないことも欠かせません。
相対湿度は温度に依存するため、校正のつもりで2台を見比べても、片方だけ自熱の影響を受けていれば湿度まで巻き込んで差が出ます。
温度がわずかに高めに出るだけで、湿度は低めに見える方向へ動くので、温度差と湿度差を別々に眺めるより、まず設置条件を揃えるほうが先です。
筆者は比較時に、同じ棚の上に置いただけでは差が消えず、ケースを開けて通風を揃えたら値の関係が見えやすくなった経験があります。

連続記録を始めると、作る段階では気にならなかった要素が効いてきます。
短時間のシリアル表示なら問題がなくても、数週間から数か月の運用では、電源、通信、再起動後の復帰、筐体の汚れや湿気がじわじわ効いて、欠損や値の乱れとして表面化します。
長期モニタリングでは、センサー精度そのものより、止まらず、戻り、取りこぼさない設計のほうが運用品質を左右します。

電源はまず分けて考えると整理しやすくなります。
USB給電は安定しやすく、常設には向いています。
バッテリー運用は設置自由度が上がる反面、交換や充電の周期が運用タスクになります。
測定そのものより、Wi‑Fi通信が消費の中心になるので、送信頻度が高い構成ほど電源設計の粗さが出ます。
産業用の無線温湿度センサーでは、1分周期測定で電池寿命が約5年という例がありますが、これは省電力を前提に詰められた設計だから成立する数字です。
ESP32工作で同じ感覚を期待するのではなく、送信間隔を空ける、まとめて送る、不要な常時通信を減らす、といった方針を持つほうが実務的です。

Wi‑Fiの電波品質も、長期記録では無視できません。
通信がたまに切れる程度なら手元のテストでは見逃しますが、日単位のログでは欠損が帯になって見えます。
アンテナの向き、壁の数、金属ラックの近さ、ルーターからの距離で安定性は変わります。
産業用ロガーが通信距離や接続台数を明示しているのはそのためで、たとえばHOBOの約30.5 mや、Braveridgeルーターの最大8台という数字は、通信設計もスペックの一部だと示しています。
DIYでも、センサーの置き場所とアクセスポイントの位置関係をログ品質の一部として扱うと、原因不明の欠損が減ります。

障害時の自動復帰にも目を向けたいところです。
停電復帰後に自動起動するか、Wi‑Fi再接続に失敗したまま止まらないか、送信先が一時停止したときに再送できるか、といった挙動は運用で差になります。
ESP32は手軽な一方で、再起動後の状態復元をスケッチ側で面倒を見る場面があります。
少なくとも、電源再投入で計測と送信が再開する構成、通信失敗時に次回周期で復旧を試みる構成、起動直後にセンサー初期化が通らなくてもリトライする構成にしておくと、現場で触れない場所でも扱いやすくなります。

筐体まわりでは、防塵・防滴の考え方が効きます。
ただし、ここでも密閉しすぎると計測を壊します。
ほこりを避けたいからと気密性を高めすぎて換気がほとんどない状態にすると、内部の自熱と湿気がこもり、温湿度計としては別の空間を測ることになります。
実際には、基板側は保護しつつ、センサー部には通気を確保する構造が落としどころです。
結露が起きる環境では、湿度センサーの応答だけでなく長期安定性にも影響するので、結露しない条件を前提にした製品スペックをそのまま屋外や水回りへ持ち込まない、という線引きが必要になります。

DIYでの設計目安を持つうえでは、産業用ロガーの数字を「そのまま真似する対象」ではなく「抜け漏れを見つけるチェックポイント」として見るのが有効です。
記録間隔は1秒〜18時間のように幅を持って考えられているか、通信は到達距離だけでなく再接続を意識しているか、温度ドリフトは時間軸で眺めているか、動作環境には湿度と結露条件を含めているか。
この観点で自作機を見直すと、単に値が出るだけの試作品から、継続監視に耐える装置へ設計の重心が移ります。
工作の完成は配線が終わった時点ではなく、ログ欠損なしで日をまたげた時点から始まります。

動かないときのチェックリスト

ハードウェアの確認

まずはセンサーとESP32のあいだを物理的に疑いましょう。
多くの場合、見た目の接続が正しくても列のずれや差し込み不足で通信が成立しません。
I2CならSDA/SCLの入れ替わりが典型例。
配線不良を潰したうえでソフトの確認へ進むと手戻りが少なくなります。

I2CやDHT系ではプルアップ不足も不調の原因になります。
SDA/SCLやDATAラインは、モジュール側に抵抗が載っていないと不安定になり、たまに成功して大半が失敗するような挙動になります。
DHT系ならDATAラインに10kΩ前後、I2CならSDA/SCLに適切なプルアップが入っているかを確認すると、急に安定することがあります。
筆者の経験では、“たまに読める”症状はコードより接触不良のことが多く、センサー基板のピンを一度抜いて別のブレッドボード列に挿し直しただけで落ち着いたことが何度もありました。

GPIO番号の取り違いにも注意が必要です。
コードではGPIO4を指定しているのに、実配線は別のピンに刺さっている、というずれは初心者だけでなく慣れた人でも起こします。
I2CならESP32系でSDAがGPIO21、SCLがGPIO22の例が多い一方、開発ボードによっては別のピン配置を前提にしていることがあります。
EspressifのArduino-ESP32ドキュメントでもI/Oの再割り当てが前提になっているので、コードの Wire.begin() と現物の配線が一致しているかを一度並べて見ると、詰まりやすい部分がほぐれます。

ソフト・IDEの確認

配線に問題がなさそうなら、次は開発環境を見ます。
ここで多いのが、ライブラリ未導入と誤ライブラリの組み合わせです。
『BME280』なのに別の互換ライブラリを入れていたり、『Adafruit BME280 Library』だけ入れて依存する『Adafruit Unified Sensor』や『Adafruit BusIO』が不足していたりすると、コンパイルエラーや初期化失敗になります。
DHT11DHT22では『Adafruit』の『DHT sensor library』を使う構成が通しやすく、サンプルもその前提で書かれていることが多いです。

Arduino IDE側では、ボード選択とシリアルポート選択のミスが定番です。
ESP32 Dev Module相当のボードで書き込むつもりが、別のマイコンを選んだままになっていると、書き込み時点でつまずきます。
Espressifのボード定義はesp32 by Espressif Systemsとして追加する形なので、そもそもボードパッケージが入っていない状態だと話が進みません。
Espressifの公式ドキュメントとArduino-ESP32の配布ページでも、その導入手順が前提になっています。

書き込み時にBOOTボタンが必要なボードもあります。
アップロード開始後に自動でブートモードへ入れず、手動でBOOTを押している間だけ書き込める個体は珍しくありません。
毎回同じところで Connecting... のまま止まるなら、配線よりブートモード移行の問題であることが多いです。
ここはハード故障と見分けにくいのですが、BOOTを押した瞬間に進むなら原因は絞れます。

センサーごとの読み取り条件も、ソフト側で詰まりやすいところです。
DHT系は読み取り間隔を詰めすぎると失敗しやすく、『Adafruit』の『DHT sensor library』でもDHT22は2秒程度の間隔を前提にした例が使われています。
ループのたびに連続で読んでいるとNaNが返り、配線不良と見分けがつかなくなります。
配線長が長すぎる場合や、USB電源まわりのノイズが乗っている場合も同じような失敗が出ます。
『BME280』ではI2Cアドレス違いも典型で、コードが0x77前提なのに、実物は0x76で応答していると見つかりません。
このタイプはセンサーが壊れているのではなく、探している番地が違うだけです。

TIP

センサー初期化に失敗したとき、いきなりスケッチ全体を書き換えるより、まずそのセンサーの最小サンプルに戻すと原因が見えます。
余計なWi‑FiやMQTT処理を外すだけで、どこから壊れているのかが一段ずつ追えます。

ネットワーク・MQTTの確認

シリアルモニタでは温湿度が見えているのに、Web表示やGrafanaに届かないなら、原因は通信経路にあります。
最初に確認したいのはWi‑Fi接続そのものです。
SSIDやパスワードの打ち間違いはもちろん、2.4GHzと5GHzが同じ名前で混在している環境では、ESP32が掴めるのは2.4GHz側だけなので、見た目は正しいのに接続できないことがあります。
シリアルにIPアドレスが出ていないなら、センサーではなく無線LANで止まっています。

MQTTを使っている場合は、ESP32側だけでなくブローカー側まで含めて見る必要があります。
いちばん多いのは、MQTTブローカーが起動していないケースです。
MosquittoをDockerで立てている構成では、コンテナ停止や再起動失敗で受け口が消えていることがあります。
センサー値は読めているのにPublishだけ失敗するなら、ブローカー未起動の線が濃くなります。

次に多いのが認証不一致です。
ユーザー名やパスワードを設定したブローカーに対して、スケッチ側が匿名接続のままだと接続は通りません。
接続自体は成功しているように見えても、別トピックへ送っていたということもあります。
たとえば home/room1/temp に送っているつもりが、受信側は home/room1/temperature を見ていると、データは存在するのに画面に出ません。
MQTTはこのトピック名の一致が前提なので、送信側、ブローカー、DB取り込み側の3か所で同じ文字列になっているかを確認すると、空振りの原因が見つかります。

段階的な切り分け方法

問題が重なると、どこから崩れているのか見えなくなります。
そういうときは、上流から順番に確認すると迷いません。
筆者はセンサー、シリアル、WebまたはHTTP、MQTT、DB、Grafanaの順で区切って追います。
流れの前半で値が取れていないのに、後段のダッシュボード設定をいじっても前には進まないからです。

まずセンサー単体の最小コードで値が読めるかを見る段階です。DHT22なら温度と湿度がNaNでないか、『BME280』なら初期化が通るか、I2Cならアドレスが見えているかをチェックします。
次にシリアルモニタで、取得した値が安定して出ているかを観察します。もしこの段階で乱れるようなら、配線やGPIO、電源、読み取り間隔に問題がある可能性が高いです。
その後にWeb表示やHTTP送信を足します。ここで崩れたら、センサーではなくWi‑Fi接続や送信処理の実装に原因があると考えられます。
MQTTを使う場合は、Publishできているか、ブローカーに接続できているか、トピック名が一致しているかを順に確認してください。
DB保存がある構成では、ブローカーから先で取り込みが動いているかを確認する段階です。
Grafanaは最終表示なので、ここだけ空ならクエリやデータソース設定の問題に絞れるでしょう。

この順番で見ていくと、「全部動かない」という状態が「センサー値は取れているがMQTTで止まっている」のように分解されます。
最初からフル構成で通そうとすると、配線ミス、GPIO違い、ライブラリ違い、Wi‑Fi接続失敗、MQTTブローカー未起動が一度に重なって見えてしまいます。
初心者の段階では、機能を足すたびに一度止まって確認するほうが、結果として完成までの距離が短くなります。

まとめと次のアクション

迷ったら、まずは『BME280』をI2Cでつないでシリアルモニタに値を出し、そのあとローカルWeb表示、必要になった段階でMQTTとGrafanaへ進む流れで十分です。
温湿度モニタは最初から完成形を狙うより、1段ずつ確認しながら積み上げたほうが、結果として詰まりません。
筆者もGrafanaで日周変動が見えた瞬間に、置き場所や通気の見直し案が一気に増えました。
見える化は記録の終点ではなく、改善を回し始める起点になります。

次にやること

ESP32とセンサーを用意し、まずシリアルモニタで温度と湿度が安定して読めるところまで進めます。
可視化はローカルWeb表示かMQTT経由の構成か、どちらか1つに絞って選びます。
長く置く前提なら、設置場所と校正の進め方まで先に決めておくと、あとで測定値の意味がぶれません。

将来拡張

1台で流れをつかめたら、部屋ごとにセンサーを増やして集約したり、しきい値を超えたときに通知したりと、実用寄りの構成へ広げられます。
Home Assistantと連携すれば、監視だけでなく除湿機や換気の自動化にもつなげられます。
常設するなら、ケース設計や防滴化まで手を入れると、運用の安心感が一段上がります。