スマートリモコン自作｜ESP32と赤外線で家電操作

ESP32と赤外線送受信を組み合わせると、スマホやWi‑Fi経由の命令をESP32が受け取り、照明やエアコンの赤外線リモコン信号を再送する自作スマートリモコンを作れます。
この記事は、電子工作の入門を一歩越えてみたい初心者から中級者に向けて、2〜3時間ほどで完成までたどれる現実的な手順を前提にまとめました。

ポイントは、配線して終わりではなく、赤外線コードを受信して再送し、家の自動化基盤につなぐところまで見通すことです。
筆者も自宅のHome AssistantでESP32デバイスを運用していますが、IR制御は照明の就寝シーンに組み込むと日常の動線に自然に乗り、手動操作より出番が増えます。

赤外線は見通し距離と設置位置に素直に結果が左右されるので、『IRremoteESP8266』のような定番ライブラリで信号を扱いつつ、光の届き方まで含めて設計するのが成功の近道です。
NECやAEHA、SONY形式の違いも押さえながら、まずは照明を確実に動かし、その先にエアコン連携へ広げていきます。

関連記事スマートホーム自作｜ラズパイとESP32の始め方ラズパイ=司令塔、ESP32=末端ノードの役割で最小構成を組む入門。必要部品、MQTT（Mosquitto）、Node-RED、必要に応じてHome Assistantまで一気通貫で解説。センサー送信とLED制御の初実装、容量要件とセキュリティの基本もカバー。

スマートリモコンの自作でできること

できることの例

自作スマートリモコンで狙う対象は、赤外線リモコンに対応した家電です。
代表例は照明、エアコン、テレビで、スマホや自宅ネットワークからの指示をESP32が受け取り、それを赤外線信号に変換して送信する流れになります。
市販のスマートリモコンがしていることを、自分で配線とソフトウェアを組んで再現するイメージです。

動作の中身は意外と素直で、スマホのボタン操作やHome Assistantからの自動化トリガーを起点に、ESP32が赤外線LEDを点滅させ、家電の受光部へリモコン信号を送ります。
家庭用リモコンでは38kHz前後の搬送波が広く使われ、通信形式としてはNECAEHASONYが定番です。
IRremoteESP8266 GitHubIRremoteESP8266 GitHubのような定番ライブラリは、こうした形式の受信・再送に対応しており、特にエアコン系のコードも扱える点が実用的です）。

できることを生活目線で見ると、照明なら就寝シーンに合わせて消灯、テレビならワンボタンで電源オン、エアコンなら帰宅前に冷房や暖房を入れる、といった用途が中心になります。
筆者の環境では、照明のオンオフをESP32経由に置き換えるだけでも、スマホ操作より自動化ルールとの相性のよさが目立ちました。
たとえば夜の決まった時間帯に照明を落とし、必要ならテレビもオフに寄せる、といった連携は赤外線対応家電だけでも十分組めます。

一方で、エアコンはテレビや照明の単純なボタン再送より少し複雑です。
多くの機種では「温度」「運転モード」「風量」などの状態をまとめて送る方式が使われるため、電源オンだけを短いコードで送る感覚とは異なります。
この点もIRremoteESP8266がエアコン向けの実装を豊富に持っているので、自作でも現実的なラインまで持っていけます。

GitHub - crankyoldgit/IRremoteESP8266: Infrared remote library for ESP8266/ESP32: send and receive infrared signals with multiple protocols. Based on: https://github.com/shirriff/Arduino-IRremote/

Infrared remote library for ESP8266/ESP32: send and receive infrared signals with multiple protocols. Based on: https://

github.com

届く距離と設置のコツ

赤外線は光なので、届く距離と置き方がそのまま成功率に直結します。
家庭向けの目安としては見通しで3〜10m程度を想定すると現実的で、比較記事では6〜7m前後の到達例も見られます。
製品紹介では30mをうたうものもありますが、送信側の出力、LEDの数、受光部の向き、部屋の明るさで結果が揺れるため、その数字を部屋の実力値として受け取るのは危険です。

ここで効くのは、回路より先に「光がどこへ飛ぶか」を考えることです。
赤外線の送信部をテレビ台の奥に隠したり、棚の側板に近づけたりすると、理屈どおりに飛んでいても家電の受光部に届きません。
筆者の環境でも、家具で遮られる位置に置くと応答が目に見えて落ちました。
そこで赤外線LEDの向きを家電の正面に寄せ、設置場所を棚の縁近くへ動かしたところ、反応が安定しました。
自作ではケースの自由度が高いぶん、配線より設置場所の微調整が効きます。

受信側でリモコン信号を学習するときも、同じく見通しを意識したほうが取りこぼしが減ります。
ESP32でIRremoteESP8266を使う方法ESP32でIRremoteESP8266を使う方法で紹介されているように、受信・送信の基本設定は比較的素直ですが、実際の安定性は机上の設定より配置に左右されます。
特にエアコンのように長めのコードを送る機器では、送信部の向きがずれるだけで成功率に差が出ます）。

ESP32で赤外線通信ができるライブラリ「IRremoteESP8266」の使い方 ｜ Wak-tech

ESP32で赤外線を送受信する「IRremoteESP8266」の使い方Wi-Fi, Bluetooth機能がある高性能マイコンのESP32で赤外線の送信・受信を試してみたので使い方を概説します！今回使用したライブラリはIRremoteES

wak-tech.com

市販品 vs 自作の使い分け要点

市販スマートリモコンと自作の違いは、ひとことで言えば手軽さと自由度の交換です。
Nature RemoやSwitchBot ハブのような市販品は、最初のセットアップが短く済み、アプリからすぐ家電登録まで進めます。
その代わり、内部でどう学習してどう再送しているかは見えにくく、細かな制御や独自の連携は製品側の仕様に乗ることになります。

自作は逆で、ESP32にどの信号を持たせるか、どのトリガーで送るか、MQTTやESPHomeOpenMQTTGatewayへどうつなぐかまで自分で決められます。
OpenMQTTGateway ESP32 Setup & Home Assistant GuideOpenMQTTGateway ESP32 Setup & Home Assistant Guideのような方向へ進むと、赤外線だけでなく他の無線方式とまとめて扱う拡張も見えてきます。
学ぶことは増えますが、ブラックボックスが減るので、動かなかったときに切り分けやすい点はDIYならではです）。

使い分けの目安も明確です。
すぐ使いたい、家電を数台まとめて手早くスマホ操作したいなら市販品が向いています。
赤外線コードを自分で理解したい、家の自動化基盤に深く組み込みたい、あとで構成を育てたいなら自作の価値が出ます。
筆者は最初の一歩としては市販品の完成度も認めつつ、学習コストを払ってでも仕組みを見える形で持てる点で、自作はスマートホーム全体の理解を一段引き上げてくれると感じています。

OpenMQTTGateway ESP32 Setup & Home Assistant Guide

OpenMQTTGateway is an open-source ESP32 MQTT gateway bridging BLE, RF, and IR for scalable IoT integration. Explore ente

zediot.com 関連記事ESP32 Arduino IDE入門｜初期設定と書き込み『ESP32』をArduino IDE 2で今日から動かしたい初心者の方向けに、定番のESP32 DevKitC系ボードを前提に、ボード定義の追加からボードとポートの選択、『WiFiScan』の書き込み、シリアルモニタを115200bpsに合わせて結果を読むところまで、最短ルートで通します。

スマートリモコンの仕組みを先に理解する

信号の流れを図で把握する

スマートリモコン自作の中心は、ネットワークの命令を赤外線に翻訳する役をESP32が担うことです。流れを一度まっすぐに整理すると、全体像が崩れません。

スマホやHome Assistant、あるいは外部のネットサービスから「テレビの電源を入れる」「照明を消す」といった命令が送られます。
その命令はまずWi‑Fi経由でESP32に届きます。
ESP32はWi‑FiとBLEを内蔵したマイコンなので、ネットワーク側の受け口と、GPIOからの信号出力の両方を1枚で担当できます。
ここで受け取った命令を、そのまま家電に送るわけではありません。
家電が理解できるのは赤外線リモコンの信号なので、ESP32が「この命令ならこの赤外線コードを出す」と変換し、赤外線LEDから送信します。
家電側は、手元の純正リモコンから届いたのと同じ種類の信号として受け取って動作します。

文字だけだと見えにくいので、頭の中では次の並びで捉えると整理できます。

スマホ / ネットの命令 → Wi‑Fi → ESP32 → 赤外線送信 → 家電

この図で見ると、ESP32はWi‑Fi家電そのものを作っているのではなく、既存の赤外線家電に対する通訳機です。
ここが、最初に押さえておきたいポイントです。
照明やテレビがネットにつながるわけではなく、ネットワーク側の命令をESP32が受け、赤外線リモコンの操作に置き換えています。

実際に組むと、ネットワーク部分と赤外線部分は別の層として考えたほうが切り分けやすくなります。
たとえば「スマホから命令は送れているのに家電が反応しない」なら、Wi‑Fiではなく赤外線の向きや送信コードを疑うべきです。
逆に、赤外線LED単体では送れているのにスマホ操作だけ失敗するなら、HTTPやMQTTなどの受け口側を見直す段階だとわかります。
初心者が混乱しやすいのは、この2つの問題を一緒に考えてしまう場面なんですよね。

ネットワーク経由の制御は、筆者はクラウド越しよりLAN内で完結するローカル制御を基本にしています。
そのほうが応答が安定しやすく、ボタンを押してから赤外線が出るまでの間も短くまとまります。
特に照明の消灯やテレビの音量のような単発操作では、この差が体感に出ます。

一方で、スマート家電は考え方が異なります。
Wi‑FiやBLE、Zigbeeなどを家電本体が内蔵していて、家電自身がネットワークの相手になります。
つまり、スマート家電は「スマホ → ネットワーク → 家電」という経路で直接つながりますが、赤外線家電は「スマホ → ネットワーク → ESP32 → 赤外線 → 家電」という1段追加の構成です。
この違いがあるので、赤外線家電では送信位置や向きの影響を避けられません。

赤外線の基礎

赤外線リモコンは、見えない光を点滅させて情報を送っています。
家庭用のリモコンでは、38kHzの搬送波を使う方式が広く使われています。
これは1秒間に38,000回のペースで赤外線LEDを点滅させ、その点滅のまとまり方で「0」「1」やコマンドの区切りを表す仕組みです。
SparkFun系の解説や各種受信モジュールの説明でも、この38kHz帯が標準的な前提として扱われています。

使われる光の波長は、リモコン用途では940nm帯が一般的です。
人の目には見えませんが、受信モジュールはこの帯域を前提に作られていることが多く、送信側もその組み合わせで考えると筋が通ります。
受信側が38kHz付近を選択して拾うことで、部屋の照明や太陽光のノイズをある程度切り分けています。

赤外線通信には、リモコンごとの話し方の違いもあります。
代表的なのはNECAEHASONY形式で、elm-chanの『赤外線リモコンの通信フォーマット』を見ると、同じ赤外線でもビット長や符号化の考え方が違うことがわかります。
NECは32bit、SONYは12 / 15 / 20bit、AEHAは48bit以上を8bit単位で扱う実装例が知られています。
自作で受信と再送をやる面白さは、この「メーカーごとに話し方が違う」部分が見えるところにあります。

ここで混同しやすいのが、「赤外線なら全部同じように送れるはず」という感覚です。
実際には、テレビや照明の単純なボタン信号と、エアコンの状態をまとめて送るコードでは重みが違います。
エアコンは温度、運転モード、風量などを含んだ長めのコードを送ることがあり、単純なトグルボタンの感覚で扱うと引っかかります。
IRremoteESP8266 GitHubIRremoteESP8266 GitHubでも、テレビだけでなくエアコン系の実装が重視されているのはそのためです）。

赤外線は光なので、届く条件も無線LANとは別物です。
見通しが取れていれば反応しますが、家具や扉で遮られると止まります。
標準的な受信モジュールを相手にした家庭環境では、見通し状態なら数m単位で届く構成が現実的で、筆者もこの感覚で配置を詰めています。
机上では動くのに、テレビ台の奥へ押し込んだら急に失敗が増えることがありますが、これはソフトではなく光路の問題です。
赤外線工作では、コードより先に置き場所が勝負を決める場面が本当にあります。

赤外線リモコンの通信フォーマット

elm-chan.org

方式の選び方

スマートリモコンを作る方法はいくつかありますが、違いは「どこまで自分で持つか」に出ます。
最初の比較軸としては、市販スマートリモコン、ESP32+IRremoteESP8266、ESPHomeやOpenMQTTGatewayを使う構成の3つで考えると見通しが立ちます。

市販スマートリモコンは、たとえばNature RemoやSwitchBot Hub Miniのように、Wi‑Fi接続と赤外線学習の仕組みが最初からまとまっています。
導入の手間が少なく、アプリ中心で進められるので、赤外線制御をすぐ生活に入れたい場合には向いています。
ただし、内部で何をどう送っているかは見えにくく、赤外線コードを自分で細かく扱いたい場面では物足りなさが残ります。

ESP32にIRremoteESP8266を組み合わせる方法は、自作の定番です。
受信してデコードし、そのコードを保存して再送する、という流れがそのまま見えます。
どのGPIOで送るか、どのコマンドをどう管理するかまで自分で決められるので、仕組みを理解しながら組みたい人にはこの方式が合っています。
筆者の感覚でも、この構成は「ブラックボックスが減る」ことの価値が大きいです。
ネットワーク処理と赤外線送信が1枚のマイコンの中でつながるので、ソフトウェア側の知識をそのまま電子工作に持ち込みやすいんですよね。

ESPHomeやOpenMQTTGatewayは、その先の発展形です。
Home Assistantとの連携まで含めて設計するなら、この系統は強力です。
特にOpenMQTTGatewayはESP32をBLE / RF / IR / MQTTのブリッジとして扱えるので、赤外線専用機というより家全体の中継ノードとして位置づけられます。
設定の層は増えますが、そのぶん自動化システム全体に組み込みやすくなります。

選び方を言葉で整理すると、こうなります。
すぐ使いたいなら市販品、赤外線の中身まで追いたいならESP32+IRremoteESP8266、Home AssistantやMQTTまで含めて統一したいならESPHomeやOpenMQTTGatewayです。
初心者にとっては、市販品が一番近道に見える一方で、Wi‑Fi→マイコン→赤外線の変換を理解する教材としてはESP32自作機のほうが得るものは多くなります。

このあと実際に受信と送信を扱う段階では、どの方式でも赤外線の物理条件そのものは共通です。
市販品でも自作でも、障害物に弱いという性質は変わりません。
違いが出るのは、そこから先をどれだけ自分で調整できるかです。
自作構成は、置き場所を変える、送信コードを差し替える、MQTT経由で呼び出す、といった改善を積み重ねられるので、仕組みを知るほど運用の精度も上がっていきます。

必要な部品と選定理由

送信用パーツの選び方

送信側の中心になるのは、ESP32開発ボードと赤外線LEDです。
開発ボードはESP32-DevKitCやDevKit v1系を前提にすると、作例が多く、ブレッドボード上でも配線の見通しが立てやすくなります。
USB経由で給電しながら書き込みとシリアル確認を同時に進められるので、赤外線コードの送信テストまで一気につなげやすい構成です。
USBシリアル変換ICは版によってCP210x系とCH340系がありますが、この段階で意識しておきたいのは、手元のUSBケーブルが給電専用ではなくデータ通信対応であることです。
ここを外すと、ボード自体は光っていても書き込みで止まります。

赤外線LEDは、一般的な家電リモコンとの相性を考えて940nm品を選ぶのが基本です。
赤外線リモコンの搬送波は38kHz前後が広く使われていて、受信モジュール側もこの組み合わせを前提にした製品が多く流通しています。
SparkFunの赤外線解説でも、一般的なIR通信は38,000回/秒の点滅で情報を載せる方式として説明されていますし、elm-chanの赤外線フォーマット解説でも家庭用リモコンの前提をつかめます。
自作では「赤外線LEDなら何でもよい」と見えて、ここで波長を外すと受信側は動いているのに届かない、という切り分けしづらい状態になります。

抵抗値は「目安」で、必ず使用する IR LED の順方向電圧 Vf と狙いたいパルス/連続電流 I に基づいてオームの法則で算出してください（設計例）: R = (Vcc − Vf) / I 例: Vcc=3.3V、Vf=1.2V、I=0.02A → R=(3.3−1.2)/0.02=105Ω → 安全マージンで 150〜220Ω を選ぶ、という考え方です。
ESP32 の GPIO は連続出力で流せる電流に制限があるため（ピン当たり数十mAが目安）、高パルス電流を使う場合や長時間駆動する設計では GPIO 直結を避け、トランジスタやドライバ経由で駆動してください。

部品	仕様の目安	数量	参考価格（目安・執筆時点）
ESP32-DevKitCまたはDevKit v1系	USB給電対応のESP32開発ボード	1	目安: 1,000〜2,500円（執筆時点、販売ページを要確認）
赤外線LED	940nm品	1〜2	目安: 約30〜80円（執筆時点）
直列抵抗	150〜220Ω（目安、VfとIで計算）	1〜2	目安: 約5〜20円
NPNトランジスタ	2N2222または2SC1815（例）	1	目安: 約20〜50円
ベース抵抗	1kΩ前後（目安）	1	目安: 約5〜20円
ジャンパワイヤ	オス-オス中心	数本	目安: 約100〜300円/セット

受信用パーツの選び方

受信側は、まず購入前にメーカーのデータシートで VCC（動作電圧範囲）と OUT の出力仕様（出力電圧レベルやプルアップの有無）を必ず確認してください。
TSOP38238 系や VS1838B 系は 38kHz 対応の定番として流通していますが、型番・製造ロット・互換モジュールによっては推奨 VCC が異なったり、OUT が 5V レベル出力になっている例があります。
購入時はメーカー／販売ページのデータシート（Vcc 範囲、OUT 出力レベル、ピン配列）を確認し、OUT が 5V 出力の場合はレベルシフタや抵抗分圧等の対策を入れてから ESP32 に接続してください。
記事の手順は「3.3V 系で動作するモジュール」を想定した例であり、実際の製品仕様に従って調整してください。

|---|---:|---:|---:| | 赤外線受信モジュール | 38kHz対応、940nm帯想定、3.3V駆動可（モデル依存） | 1 | 目安: 約200〜400円 | | 候補型番 | TSOP38238 系（メーカー・ロットで仕様確認） | 1 | 目安: 約200〜400円 |

部品	仕様の目安	数量	参考価格（目安・執筆時点）
赤外線受信モジュール	38kHz対応、940nm帯想定（モデル依存）	1	目安: 約50〜400円（型番・販売元により幅があります）
候補型番	TSOP38238 系（メーカー・ロットで仕様確認）	1	目安: 約200〜400円（執筆時点の目安）
候補型番	VS1838B 系（安価な互換モジュールが多い）	1	目安: 約50〜150円

{{product:8}}

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

必須部品に加えて、作業の詰まりを減らす道具もそろえておくと進行が安定します。
まず必要なのはブレッドボードとジャンパワイヤです。
はんだ付け前の仮組みで送受信を切り分けられるので、ESP32本体、受信モジュール、IR LEDを順に差し替えて確認できます。
筆者はスマートホーム系の小物を組むとき、いきなりユニバーサル基板へ載せず、ブレッドボード上で「受信だけ」「送信だけ」「Wi‑Fi込み」の3段階に分けます。
この順で進めると、ネットワーク設定と電子回路の不具合が重なって見えなくなる場面を避けやすくなります。

USBケーブルも見落としやすい部品です。
ESP32の書き込みでは、給電できるだけでなくデータ通信できるケーブルが必要になります。
手元にあるケーブルを流用すると、スマホ充電用の結線しか入っていないものが混ざることがあります。
ボードが起動しているのにポートが出ない、という症状の原因がケーブルだった、というのは自作では珍しくありません。

消耗品では、抵抗アソートがあると便利です。
送信用の100〜220Ω、トランジスタ追加時の1kΩ前後だけでなく、表示LEDやプルアップ調整で別の値が欲しくなることがあるからです。
赤外線工作は部品点数が少ないぶん、1本の抵抗値を変えた結果がそのまま挙動に出ます。
固定の数値だけを買うより、複数値をまとめて持っておくと試行が止まりません。

ケースまで見据えるなら、3Dプリントやレーザーカット向けの素材も候補に入ります。
送信LEDの向き、USBケーブルの取り回し、受信窓の開口を最初から考えた箱にしておくと、机上では動いたのに設置後に通らない、という落差を減らせます。
スマートリモコンは基板むき出しでも機能しますが、赤外線は光路がすべてなので、外装も回路の一部として扱ったほうが完成度は上がります。

このセクションで触れた部品をひとまとめにすると、最小構成はESP32-DevKitC系、ブレッドボード、ジャンパワイヤ、USBケーブル、940nmの赤外線LED、38kHz対応の受信モジュール、抵抗類です。
そこにトランジスタを足すと、机上確認の先へ進める送信回路になります。
部品選定の段階で38kHzと940nmを揃えておくと、受信・送信・再送の流れが一本につながります。

回路を組む

配線表

ここでは例として GPIO23（受信）・GPIO17（送信）を使う手順で説明しますが、ESP32 のピンにはボード固有の配線やブートストラップに関する制約がある点に注意してください。
使用する DevKit の回路図（schematic）やピンリファレンスを確認し、該当ピンがブート時に特殊な機能や制約を持たないことを確認してから配線してください。
もし該当ピンに制約がある場合は、ボードのドキュメントに従って別の GPIO を選んでください（必ず回路図を参照することを推奨します）。
送信側はまず直結テストから始めると、ライブラリ設定とLEDの向きだけを確認できます。
なお GPIO の選定については注意が必要で、使用する DevKit の回路図やピンリファレンスで該当ピンがブート時に特殊な制約（ブートストラップ抵抗やモード選択に影響するピン）を持たないか必ず確認してください。
もしブート時の制約があるピンを使っている場合は、別の GPIO を選ぶか回路設計を見直してください。
GPIO17 から抵抗を挟み、その先に IR LED をつないで GND へ落とす形で直結テストを行います。
赤外線LEDには向きがあり、長い足側のアノードを GPIO17 側、短い足側のカソードを GND 側に接続してください。

回路	部品の端子	接続先
受信	受信モジュール VCC	ESP32 3.3V
受信	受信モジュール GND	ESP32 GND
受信	受信モジュール OUT	ESP32 GPIO23
送信（直結）	ESP32 GPIO17	150〜220Ω 抵抗
送信（直結）	抵抗の反対側	IR LED アノード
送信（直結）	IR LED カソード	ESP32 GND
送信（トランジスタ）	ESP32 GPIO17	1kΩ 抵抗
送信（トランジスタ）	1kΩ 抵抗の反対側	NPNトランジスタ ベース
送信（トランジスタ）	NPNトランジスタ エミッタ	ESP32 GND
送信（トランジスタ）	NPNトランジスタ コレクタ	IR LED カソード
送信（トランジスタ）	IR LED アノード	100Ω 抵抗
送信（トランジスタ）	100Ω 抵抗の反対側	ESP32 3.3V

受信回路と送信回路の両方で、GNDを共通にすることも外せません。
ESP32、受信モジュール、送信用LED、トランジスタが同じGND基準を見ていないと、GPIO17の出力もGPIO23の入力も基準点がずれて不安定になります。
見た目ではつながっているように見えても、GNDレールを1本飛ばしていたせいで動かなかった、というのはブレッドボードでよく起きます。
筆者の手元でもジャンパの抜けは信号線から先に表面化するので、受信OUTや送信GPIOの引き回しは短くまとめるのが定番になっています。

直結テストの作り方

直結テストは、送信回路を最短距離で確認するための仮組みです。
GPIO17から150〜220Ωの抵抗を入れ、その先にIR LEDをつないでGNDへ戻します。
配線としては単純ですが、この段階で確認したいのは「ESP32の送信ピン設定が合っているか」「IR LEDの向きが合っているか」「ライブラリから38kHzの搬送波を出せているか」の3点です。
一般的な赤外線リモコンは38,000回/秒のキャリアで情報を載せて送るので、SparkFunの解説どおり、単にLEDを点灯させるだけでは家電は反応しません。

ブレッドボード上では、ESP32を中央付近に置き、GPIO17から抵抗、IR LEDまでを同じ列の近くで閉じると追いやすくなります。
ジャンパが長いと、抜けや接触不良が起きたときに配線を目で追う量が増えます。
筆者は受信OUTも送信GPIO17も、まず5cm前後の短いジャンパでまとめることが多いです。
信号線が短いだけで、差し間違いの発見が早くなります。

直結テストの役目は、遠くまで飛ばすことではありません。
机の上で受信モジュールに向けて再送し、すぐ近くで反応するかを見る段階です。
たとえば別の受信モジュールをGPIO23へつないだ状態で再送し、シリアルモニタに受信コードが出るなら、送信系はひとまず成立しています。
家電本体へ向ける場合も、まずは近距離で正面から当てて、反応の有無を見ます。
ここで反応しないときは、距離を詰める前にLEDの向きとGPIO番号を見直したほうが早く進みます。

この構成は確認用としては便利ですが、到達距離は伸びません。
ESP32のGPIOから直接LEDを駆動する形は、あくまで短距離の点検向けです。
家庭用リモコンの再送を安定させたいなら、次の段階で電流をトランジスタ側に持たせる構成へ移ります。

トランジスタ駆動への置き換え

直結テストで送信できたら、送信回路をNPNトランジスタ駆動へ置き換えます。
構成はGPIO17から1kΩを通してNPNトランジスタのベースへ入れ、エミッタをGND、コレクタをIR LEDのカソードにつなぎます。
IR LEDのアノード側は100Ωを通して3.3Vへ接続します。
GPIO17はベースをON/OFFする役目に専念し、LEDへ流す電流は3.3V側からトランジスタ経由で流す形になります。

この置き換えの狙いは、ESP32のGPIOに無理をさせず、赤外線LEDへ必要な電流を流しやすくすることです。
IRremoteESP8266 GitHubの実装例でもESP32を送信に使う流れは一般的ですが、LEDを直接強く光らせたい場面では、GPIO直結よりスイッチング段を1段入れたほうが扱いやすくなります。
筆者も机上確認では直結、設置を前提にした回路ではトランジスタ駆動、という順で組みます。
この切り替えを入れるだけで、コードのデバッグとハードの強化を分離できます。

トランジスタを入れるときは、部品の向きも整理しておきます。
2N2222や2SC1815はどちらもNPNとしてよく使われますが、ベース、コレクタ、エミッタの並びは部品の見た目だけでは判断しづらいことがあります。
ここでは「GPIO17から1kΩで入る端子がベース」「GNDへ落ちる端子がエミッタ」「IR LEDカソードへつながる端子がコレクタ」という回路上の役割で追うと混乱が減ります。

到達距離をもう一段伸ばしたいときは、考え方がいくつかあります。
ひとつは今のようにトランジスタ駆動へ切り替えて、LEDへ流す電流をGPIO直結より増やすことです。
もうひとつはIR LEDを並列に増やす方法ですが、その場合はLEDごとに抵抗を持たせ、電流の合計がどこへ流れるかを計算に入れます。
抵抗1本で複数LEDを乱暴にまとめると、片方だけ光り方が偏ります。
加えて、設置場所の高さと向きでも結果は変わります。
赤外線は光なので、家電の受光部へ正面から届く位置に置くほうが通りますし、壁や天井の反射を使ったほうが通る部屋もあります。
筆者の自宅では、テレビ台の中に横向きで置くより、受光部に対して少し上から振る配置のほうが反応が安定しました。

この段階まで組めると、受信はGPIO23、送信はGPIO17、送信強化はトランジスタで行う、という構成が一本につながります。
あとはこの配線を前提に、受信したコードを保存し、同じGPIO17から再送する流れへ乗せていけます。

赤外線信号を受信して学習する

環境準備

ここでは、既存リモコンの赤外線コードをまず受信して読める状態まで持っていきます。
送信回路まで組めていても、どのフォーマットで何bitのデータが来ているかを把握できないと再送の精度が上がりません。
筆者はこの工程で、いきなりエアコンの複雑なコードを追うより、照明のON/OFFのように反応が単純なボタンから始めます。
1回押して受信、表示を確認し、あとで同じコードを再送するという流れが頭に入りやすいからです。

開発環境は例として「Arduino IDE（2.x 系）＋ESP32 ボードパッケージ（2.x 系）＋IRremoteESP8266（2.x 系）」で動作確認した手順を示します。
ただし、IDE やライブラリはバージョンによってサンプル API やデフォルト値が変わることがあります。
この記事で使った具体的な版（執筆時点のリリースタグ／コミットID）を明示するか、読者は必ず IRremoteESP8266 の公式リポジトリ読者は必ず IRremoteESP8266 の公式リポジトリと Arduino IDE の最新版ドキュメントを確認して、サンプルの定数や関数名が一致しているかを確かめてください。
サンプルを開いたら、ピン番号や定数を次のような方針で合わせます。

1. 受信ピンを GPIO23 に変更する
2. 受信ピンを GPIO23 に変更する（例）
3. capture buffer size を 1024 にする（例）
4. timeout を 50 にする（例）
5. frequency を 38000 にする（例）
6. シリアル速度はサンプル既定に合わせ、シリアルモニタ側も同じ値にする
   読者は実際に使う Arduino IDE や IRremoteESP8266 のバージョン（リリースタグまたはコミット ID）と参照 URL を控え、記事で示す設定が手元の版と一致するか確認してください。

デコード結果の読み方

シリアルモニタで最初に見るべきなのは、どの方式として判定されたかです。
家庭用リモコンでは、NEC、AEHA、SONY が代表的で、IRremoteESP8266もこのあたりを識別して表示します。
判定が出たら、続いてビット長を確認します。
ここで見たい目安は、NEC なら 32bit、SONY なら 12bit / 15bit / 20bit、AEHA なら 48bit以上で8bit単位です。
表示がこの形に乗っていれば、再送側でもプロトコルを指定して扱いやすくなります。

たとえば NEC で 32bit と表示されたなら、比較的まっすぐ再送へつなげられます。
SONY で 12bit や 15bit が出た場合も同様です。
AEHA は家電で見かけることが多く、長めのデータ列になることがありますが、8bit 単位でまとまっているかを見ると整理しやすくなります。
エアコンのように状態をまとめて送る機器では、同じ「温度変更」でも毎回コード長が長めになりやすく、照明やテレビより読み取る情報量が増えます。

一方で、unknown や raw と表示されることもあります。
ここで止まる必要はありません。
unknown は「使えないコード」ではなく、ライブラリが既知フォーマットとして名前を付けられなかった、という意味です。
この場合は、シリアルモニタに出た raw データ列を保存しておき、あとで raw 送信として再利用します。
プロトコル名で再送できないときも、mark と space の並びをそのまま返せば動く家電は少なくありません。

筆者は unknown が出たとき、まずボタンを3回ほど押して raw の並びが大きく変わらないかを見ます。
同じボタンで似た波形が繰り返し取れていれば、学習素材として十分です。
逆に毎回大きく違うなら、押し方よりも別ボタンの混入や受信漏れを疑ったほうが前へ進めます。
既知プロトコルにきれいに乗ると気持ちよく進みますが、実際の自作では raw を拾って再送できるようになる場面も多いです。

この工程で得たいのは、単にコードの数値を控えることではありません。自分のリモコンが NEC なのか、AEHA なのか、SONY なのか、それとも raw で扱うべきなのかを見極めることです。
そこが見えると、次の再送実装で「プロトコル指定で送る」か「raw 配列で送る」かの判断が自然につながります。

赤外線信号を再送して照明・エアコンを操作する

照明での再送

受信フェーズで控えたコードがあれば、ここからはIRremoteESP8266でそのまま再送できます。
まず押さえたいのは、受信時に見えた方式に合わせて send 関数を選ぶことです。
NEC なら sendNEC、SONY なら sendSony、AEHA 系なら sendAEHA、既知方式に乗らなかったものは sendRaw で返します。
家庭用リモコンの搬送波は 38kHz が定番で、『elm-chanの赤外線フォーマット解説』でも NEC・AEHA・SONY の考え方が整理されています。
IRremoteESP8266でも、この区別がそのまま実装の分かれ道になります。

照明は ON と OFF が独立ボタンになっていることもあれば、同じボタンでトグルになっていることもあります。
まずは挙動が見えやすいよう、ON 用コードと OFF 用コードを別々に学習して送る形にすると切り分けが進みます。
ここでは、受信結果が NEC 32bit だった想定で、コピーしてそのまま動かせる最小構成のスケッチを載せます。
送信ピンは前段の配線に合わせて GPIO17 にしています。

#include <Arduino.h>
#include <IRremoteESP8266.h>
#include <IRsend.h>

const uint16_t kIrLedPin = 17; // (1/3)
IRsend irsend(kIrLedPin);

// 受信して控えた値に置き換える
const uint32_t LIGHT_OFF_CODE = 0x20DFC03F;

void sendLightOn() {
  irsend.sendNEC(LIGHT_ON_CODE, 32);
}

void sendLightOff() {
  irsend.sendNEC(LIGHT_OFF_CODE, 32);
}

void setup() {
  Serial.begin(115200); // (1/3)
  irsend.begin();

  delay(1000);
  Serial.println("IR light control ready");
  Serial.println("Type 'on' or 'off' in Serial Monitor");
}

void loop() {
  if (Serial.available()) {
    String cmd = Serial.readStringUntil('\n');
    cmd.trim();
    cmd.toLowerCase();

    if (cmd == "on") {
      sendLightOn();
      Serial.println("Light ON sent");
      if (cmd == "on") {
        sendLightOn();
        Serial.println("Light: ON command sent");
      } else if (cmd == "off") {
        sendLightOff();
        Serial.println("Light: OFF command sent");
      } else {
        Serial.println("Command not recognized");
      }
      sendLightOff();
      Serial.println("Light OFF sent");
    } else {
      Serial.println("Unknown command");
    }

シリアルモニタから on と off を送るだけで、再送の成否をその場で確認できます。
ここで反応が出れば、次は HTTP や MQTT に載せるだけです。
最初の通電確認として照明を使うと、受信したコードが正しいか、送信 LED が光っているか、向きが合っているかを一度に見分けられます。
筆者も新しい送信回路を組んだ日は、テレビより先に天井照明で通します。
ボタン一発で部屋が変化するので、デバッグが速く進みます。

受信結果が SONY なら irsend.sendSony(value, bits);、AEHA なら irsend.sendAEHA(data, length, 38); のように切り替えます。sendRaw は raw 配列と長さ、搬送周波数を渡す形です。
既知フォーマットではないが再送自体は通る、という場面で頼りになります。

エアコンでの再送

エアコンは照明より一段むずかしくなります。
理由は、単純な電源ボタンのコードだけを送る機種より、現在の状態をひとまとまりのフレームとして毎回送る機種が多いからです。
温度、風量、運転モード、風向きなどを含んだ長いコードを送っており、見た目は「電源ON」の操作でも、実際には「冷房 26度 風量自動でON」といった状態一式を送っています。

この違いを知らずに進めると、学習したはずのコードが安定して効かない場面に当たります。
筆者も最初は電源トグルだけを抜き出して送ろうとして詰まりました。
受信ログ上はそれらしく見えても、実機では反応しないことがあり、温度設定とモードを明示したコードを送る形に切り替えたところ、そこでようやく動作が揃いました。
エアコンで欲しいのは「ON/OFF の1ビット」ではなく、「この状態にしてほしい」という命令だと考えると整理できます。

実装の方向は大きく2つです。
ひとつはIRremoteESP8266 GitHubひとつはIRremoteESP8266 GitHubにある各メーカー向けの AC クラスを使い、ライブラリ側で状態フレームを組み立てる方法です。
もうひとつは、リモコンから取れた raw をそのまま再送する方法です。
前者は温度やモードをコード上で扱えます。
後者は解析せずに動作を再現できます）。

たとえば AC クラスが用意されている機種では、次のように「冷房」「設定温度」「風量」をコードとして持てます。
クラス名はメーカーごとに変わるため、使うエアコンに対応したものへ置き換えます。

#include <Arduino.h>
#include <IRremoteESP8266.h>
#include <IRsend.h>
#include <ir_Daikin.h>  // 例: ダイキン系。機種に合わせて変更

const uint16_t kIrLedPin = 17; // (2/3)
IRDaikinESP ac(kIrLedPin);

void setup() {
  Serial.begin(115200); // (2/3)
  ac.begin();

  ac.on();
  ac.setMode(kDaikinCool);
  ac.setTemp(26);
  ac.setFan(kDaikinFanAuto);
  ac.send();

  Serial.println("AC: state sent");
}

void loop() {
}

この形の利点は、送るたびに状態が明確なことです。
「冷房 26度 風量自動」に固定して送れるので、前回の運転状態に引きずられません。
家電連携ではこの再現性が効きます。
スイッチの押下を真似するのではなく、目的の状態を宣言して送るイメージです。

対応クラスが見当たらない場合は raw 再送でも進められます。たとえば受信時に取得した配列をそのまま sendRaw に渡します。

#include <Arduino.h>
#include <IRremoteESP8266.h>
#include <IRsend.h>

const uint16_t kIrLedPin = 17; // (3/3)
IRsend irsend(kIrLedPin);

// 受信時に取得した raw データ例。実際の値に置き換える
uint16_t acStateRaw[] = {
  3450, 1750, 450, 1300, 450, 420, 450, 420,
  450, 1300, 450, 420, 450, 420, 450, 1300
};

const uint16_t acStateRawLength = sizeof(acStateRaw) / sizeof(acStateRaw[0]);

void setup() {
  Serial.begin(115200); // (3/3)
  irsend.begin();

  delay(1000);
  irsend.sendRaw(acStateRaw, acStateRawLength, 38);
  Serial.println("AC raw state sent");
}

void loop() {
}

raw 再送は手早く結果を出せる一方で、「温度を1度上げる」といった柔軟な操作はそのままでは扱えません。
その代わり、「冷房26度」「暖房22度」「停止」のように状態ごとに学習して持つ構成なら、実用段階まで持っていけます。

距離不足時の改善策

送れているはずなのに機器が反応しないとき、コードの間違いより先に、赤外線 LED の飛ばし方を疑うと解決が早まります。
赤外線リモコンは 38kHz 付近のキャリアに載せて送るので、ソフトだけ合っていても、LED 側の光量が足りないと届きません。
SparkFun系の解説でも 38,000回/秒で点滅させて情報を載せる仕組みが説明されており、再送では「正しいタイミングで、十分な強さで、狙った方向へ出す」ことが揃って初めて動きます。

まず効くのは、ESP32 の GPIO 直結からトランジスタ駆動へ切り替えることです。
IR LED はパルスで電流を流したい場面があり、GPIO だけで賄おうとすると飛びが鈍くなります。
2N2222や2SC1815のような NPN トランジスタを間に入れると、ESP32 は制御だけ担当し、LED 側に必要な電流を流しやすくなります。
筆者の手元でも、机の上では通るのに設置場所へ移した途端に不安定になるケースがありましたが、トランジスタ駆動に替えると反応が揃いました。

LED の向きも見逃せません。
赤外線 LED は見た目以上に指向性があり、数十センチずれるだけで受光部に当たらないことがあります。
家電本体の受光窓を正面から狙える位置へ置き直すと、それだけで通ることがあります。
スマートリモコンは「部屋のどこに置いても同じ」ではなく、受光窓までの角度が浅く、遮る物がなく、LED が正面を向く場所で結果が変わります。

複数の機器へ飛ばしたい場合は、LED を1個増やして向きを分ける方法もあります。
照明へ向けた LED と、エアコンへ向けた LED を別角度に振ると、1台で受け持てる範囲が広がります。
配線は少し増えますが、設置自由度は上がります。

それでも不安定なら、ESP32 本体を棚の奥に押し込まず、前面に近い位置へ出すだけでも差が出ます。
自作スマートリモコンはソフトの完成度だけで決まらず、設置したあとに「家電の受光窓へきちんと光が届くか」で仕上がりが決まります。
照明は通るのにエアコンだけ外しやすいのは、受光部の位置が高く、角度が付きやすいからです。
ここを合わせ込むと、実用動作の安定感が一段上がります。

スマホやHome Assistantとつなげてスマートリモコン化する

ローカル vs クラウドの選び方

ESP32 の赤外線送信が単発で動いたら、次はそれを「いつ・どこから・何と連携して使うか」に広げる段階です。
ここで分かれ道になるのが、ローカル制御を中心に組むか、クラウド経由を前提にするかです。

ローカル制御は、家の中にあるHome Assistantや MQTT ブローカーに命令を集約し、同じネットワーク内で ESP32 へ届ける構成です。
通信経路が短いので反応が素直で、インターネット側の障害に引っ張られません。
加えて、家電の操作履歴や状態を家の外へ出さずに済むので、プライバシー面でも納得感があります。
筆者はこの構成を好んでいて、就寝時に照明を消したあと、少し遅れてエアコンを弱運転へ切り替えるシーンをHome Assistantで組んでいます。
クラウド API の応答待ちがないぶん、照明 OFF と空調切り替えの流れが安定して揃います。

一方のクラウド制御は、スマホから自宅外でも扱えることが強みです。
専用アプリからそのまま操作できる構成は導入直後の体験が軽く、スマートリモコン製品が広く普及した理由もここにあります。
ただし、命令が自宅の外を経由して戻ってくるので、操作感はローカル構成より一歩遅れます。
メーカーのサービス設計に従うぶん、初期設定は楽でも、細かな自動化や独自ルールはローカル構成ほど踏み込みにくくなります。

どちらを選ぶかは、「まずスマホで遠隔操作したい」のか、「家の中の自動化基盤にきれいに載せたい」のかで決まります。
ESP32 自作スマートリモコンは後者との相性が良く、赤外線信号の送受信を自分で持てるので、照明・エアコン・扇風機を同じルールで束ねられます。
たとえば人感センサー、温湿度センサー、就寝シーンをまとめて扱うなら、ローカル主体のほうが設計に一貫性が出ます。
市販品の「アプリで操作できる」を自作で再現するのではなく、家のオートメーションの一部として赤外線を組み込むと見通しが良くなります。

MQTT/ESPHome/OMG：3つの実装ルート

ESP32 をスマートリモコン化する方法は大きく 3 つあります。
自作スケッチで MQTT を受ける方法、ESPHomeで YAML ベースにまとめる方法、OpenMQTTGatewayを載せる方法です。
どれも到着点は似ていますが、途中の手触りが違います。

もっとも素直なのは、自作スケッチ + MQTT です。
ESP32 側で MQTT ブローカーを購読し、たとえば home/ir/send のようなトピックに届いた文字列や JSON を見て、対応する学習済みコードを送信します。ac/cool_26 を受けたらエアコンの状態コードを送る、light/on を受けたら照明の NEC コードを送る、という作りです。
この方式は設計の自由度が高く、送信前に条件分岐を挟んだり、受信した raw コードとプロトコルコードを同じテーブルで管理したりできます。
IRremoteESP8266の実装例はGitHubでも追いやすく、送受信のベースを理解するには向いています。
ライブラリの全体像はIRremoteESP8266 GitHubを見ると掴みやすく、受信・再送の考え方も整理できます。

ESPHomeは、コードを書くより構成を書く方向です。
IR 送信ピン、受信ピン、送るコード、公開するスイッチやサービスを YAML で定義すると、Home Assistant側へ自動登録できます。
デバイス追加、エンティティ公開、ログ確認の流れがそろっているので、ホームオートメーション全体に載せるときの摩擦が少ないのが魅力です。
赤外線を単独で完結させるのではなく、既存のセンサーやオートメーションと横につなげたいなら、このルートは強いです。
筆者も、温湿度センサーや照明制御をすでにHome Assistantへ寄せている環境では、ESPHomeのまとまりの良さを感じます。
IR のためだけに API や MQTT の配線を全部自前で持たなくて済むからです。

OpenMQTTGatewayは、ESP32 を IR/MQTT ブリッジに変える既成ソフトとして見るとわかりやすいです。
ファームウェアの思想が最初から MQTT 連携に寄っていて、赤外線だけでなく複数の無線プロトコルを橋渡しする道筋が用意されています。
自作スケッチほど細部を握り込まない代わりに、ゼロから設計しなくても MQTT ベースの連携へ入れます。
OpenMQTTGatewayの解説では、ESP32 を MQTT デバイスとして扱い、Home Assistantへつなぐ流れがまとまっています。
学習コストを抑えつつ、将来ほかの無線デバイスへ広げたいときに噛み合います。

3 つを並べると、方向性はこう整理できます。

実装ルート	向いている人	強み	向いている用途
自作スケッチ + MQTT	動作を細かく制御したい人	トピック設計、データ構造、送信条件を自分で決められる	独自ロジック、複雑な分岐、学習目的
ESPHome	Home Assistant中心で組みたい人	YAML で定義でき、自動登録まで一気通貫	センサー連携、シーン制御、保守性重視
OpenMQTTGateway	既成の土台に乗せたい人	ESP32 を MQTT ブリッジとして使える	早く形にしたい、将来の拡張も見たい

赤外線フォーマットの基礎はelm-chanの『赤外線リモコンの通信フォーマット』がわかりやすく、NEC、AEHA、SONY の違いを頭に入れておくと、どの実装ルートでも「なぜ照明は短いコードで済み、エアコンは状態まるごと送るのか」が見えます。
エアコン系は raw か専用クラスで状態送信、照明や単機能リモコンはプロトコル指定送信、という住み分けが自然です。

外出先から安全に操作するには

外出先から家電を動かしたくなる場面は多いですが、ここで考えるべきなのは「ESP32 に直接つなぐ方法」より、どの経路で自宅の制御基盤へ入るかです。
赤外線送信機をインターネットへそのまま晒す構成は避け、入口はHome Assistantやホームゲートウェイ側に寄せたほうが管理しやすくなります。

方法としては、VPN で自宅ネットワークへ入ってローカル UI を使う形、クラウド経由のリモート機能を使う形、ホームゲートウェイ連携で認証済みの入口を一本化する形が現実的です。
VPN はローカル制御の延長として扱えるので、家の中と同じ画面・同じ自動化を外でも使えます。
構成が把握しやすく、どの機器に公開面があるのかを追いかけやすいのも利点です。
クラウドリモートは設定の手間が軽い反面、入口の管理はサービス側の設計に従います。
ホームゲートウェイ連携は、赤外線送信機単体ではなく、家全体の操作窓口を一つにまとめたいときに噛み合います。

ここで意識したいのは、外出先操作を「手動で電源を入れる仕組み」だけで終わらせないことです。
たとえば帰宅前にエアコンを入れるなら、時刻、在宅状態、部屋の温湿度と組み合わせたほうが運用が安定します。
Home Assistantの自動化に寄せておけば、スマホからの操作とルールベースの動作を同じ場所で管理できます。
筆者の環境でも、手動操作とシーン実行の経路が分かれていると、あとから「なぜ動いたか」を追うのが面倒でした。
入口を一つに揃えるとログも見やすく、トラブル切り分けが楽になります。

外出先操作が必要でも、実際に公開するのはHome Assistantや VPN の入り口だけに留め、ESP32 は自宅 LAN 内の赤外線ノードとして置く構成が扱いやすいです。
そうしておくと、赤外線コードの管理、MQTT トピック、オートメーションの修正を家の中の仕組みとして閉じ込められます。
スマホから見えるのは「照明を消す」「エアコンを弱運転にする」という意図だけで、その裏でどの IR コードを送るかはローカル側で吸収できます。
これが、自作スマートリモコンを単なる送信装置ではなく、スマートホーム基盤の一部として育てるときのまとまりです。

関連記事Home Assistant 始め方｜導入先の選び方と初手順Home AssistantはAIスピーカーではなく「ローカル中心の統合基盤」。Raspberry Pi・専用機・Mini PCの3択で導入先を選び、初期セットアップと最初の自動化までを理解できます。Matter/Threadの整理やセキュリティ運用も網羅。

動かないときのチェックポイント

配線・極性・GPIOの再確認リスト

動かないときは、コードやライブラリを触る前に配線を紙の上で一度ほどく感覚で確認すると、詰まりどころが見えます。
筆者はこの手の切り分けをするとき、まずGND共通が取れているかから見ます。
送信側と受信側を別々に組んでいると、VCC と信号線だけ見て満足してしまいがちですが、GND がつながっていないだけで受信値が安定しなかったり、送信しているのに相手が反応しなかったりします。
ここがそろうと、次に見るべき場所が一気に絞れます。

受信側では、赤外線受信モジュールの VCC / GND / OUT の向き を先に疑うのが近道です。
TSOP38238系やVS1838B系は 3 ピンですが、見た目が似ていても並びの認識を逆にしやすい部品です。
本文の配線なら、受信モジュールは 3.3V を VCC、GND を GND、OUT を GPIO23 へ入れます。
電源は 3.3V 前提でそろえておくと、ESP32 側との信号レベルも自然につながります。
OUT を GPIO23 ではなく別のピンへ挿しているのに、スケッチだけ GPIO23 のままだと、シリアルモニタには何も出ません。

送信側では、赤外線 LED の向きが最初の山場です。
長い足がアノード、短い足がカソードという基本どおりでも、いったん足を切った後は見分けがつきにくくなります。
LED 本体の平らな面がある側を目印にしたり、組む前に向きをメモしておくと混乱しません。
本文の構成では GPIO17 から送信 するので、GPIO17 側から抵抗を通り、IR LED を正しい向きでつなぎます。
直列抵抗は 100〜220Ω を目安にしておくと、LED に無理をかけずに組めます。

赤外線 LED は、見えている LED と違って点灯しても肉眼ではわかりません。
そこで役に立つのがスマホカメラです。
送信テスト中にカメラを IR LED に向けると、機種によっては白っぽく点滅して見えます。
これで少なくとも発光しているかを切り分けられます。
コードが合っているのに家電が反応しないのか、そもそも LED が光っていないのかを分けられるので、初心者ほど試す価値があります。
前面カメラのほうが赤外線を拾いやすい端末もあります。

周波数・距離・設置の見直し

配線が合っていても動かないなら、次は赤外線らしい失敗を疑います。
代表例が 38kHz の食い違いです。
家庭用赤外線リモコンは 38,000 回/秒のキャリアを使うものが多く、SparkFunの解説でもその前提が整理されています。
受信モジュール側が 38kHz 想定なのに、送信ライブラリの設定やスケッチが別の周波数前提になっていると、見た目には発光していても受け取ってもらえません。
IRremoteESP8266のサンプル例でも frequency 38000 の設定が使われることが多く、ここがズレると「配線は合っているのに無反応」という状態になりがちです。

設置では、赤外線は無線というより光の通り道を作る作業と考えると納得しやすいです。
家具越し、扉の陰、テレビ台の奥まった位置、斜め方向への送信では信号が目に見えて弱くなります。
とくにエアコン受光部は小さく、正面付近を外すと反応が鈍ります。
筆者の家でも、机の脚に少しかかる位置へ送信機を置いただけで、同じコードなのに通るときと通らないときが分かれました。
こういうときはコードの良し悪しではなく、遮蔽物と角度が原因です。

受信でも同じで、学習用のリモコンを受信モジュールへ向ける角度がずれていると、押しているのにログが取りにくくなります。
一般的な赤外線リモコンの利用距離は数メートル級ですが、学習時は距離を詰めて正面から当てたほうが安定します。
リビング全体で届くかどうかの話と、最初にコードを確実に読む話は分けて考えたほうが混乱しません。

赤外線 LED 自体の向きも、ここで見直したい点です。
LED が正しく配線されていても、発光面が家電の受光部から外れていれば届きません。
ブレッドボード上で真上を向いているだけだと、実際の家電の位置関係と噛み合わないことがあります。
まずは送信機を家電の正面に近づけ、障害物のない状態で反応を見ると、コードの問題か置き方の問題かを分けられます。

シリアルログでのデバッグ

配線と設置を見直しても詰まるなら、シリアルログを唯一の事実源として扱うのが早道です。
ESP32 が何を受信し、何を送ろうとしているかを文字で見える状態にすると、勘で追わなくて済みます。
受信確認ではIRremoteESP8266のIRrecvDumpV2やIRrecvDumpV3系のサンプルが基準になります。
受信モジュールの OUT を GPIO23 に接続した本文の構成なら、スケッチ側も受信ピンを GPIO23 にそろえておかないとログは出ません。

コンパイルや書き込みの段階で見落としやすいのが、ボード選択とライブラリの組み合わせです。
Arduino IDE では ESP32 系ボードを選んだ状態でビルドする必要があります。
ここが別ボードのままだと、通っているように見えても挙動が噛み合いません。
IRremoteESP8266も版によってサンプル名や出力の見え方が変わるので、サンプルコードの説明と手元のライブラリの版がずれていると読みにくくなります。

シリアルモニタではボーレートの一致も基本です。
スケッチ側で指定した値とモニタ側の値が違うと、ログが文字化けして「何もわからない」状態になります。
受信ボタンを押したときに raw データや decode 結果が並ぶなら、受信モジュールの配線、GPIO23、電源周りは通っていると判断できます。
逆に、何も出ないなら受信配線か GPIO 設定を優先して見るべきです。

送信側のデバッグでは、ログに「送信したつもり」の情報を出しつつ、スマホカメラで IR LED の発光を見る組み合わせが効きます。
シリアルには送信開始が出ている、スマホカメラにも点滅が見える、それでも家電が反応しないなら、残る候補は周波数設定、コード内容、向きの 3 つまで絞れます。
ここまで絞れると、初心者でも「全部壊れている」感覚から抜けられます。
ログが出ない、LED も光らないなら GPIO17 の指定違い、LED の極性、抵抗の入り方を見直す順番になります。

応用アイデア

シーン・自動化の設計例

赤外線スマートリモコンを作ったあとに一番おもしろくなるのが、単発操作をシーン制御へ広げる段階です。
たとえばHome Assistantに照明、エアコン、サーキュレーターのような複数家電登録をしておくと、「電源を入れる」を個別に叩く構成から、「帰宅」という1つのシーンでまとめて動かす構成へ進めます。
筆者の定番は、玄関を開けたタイミングやスマホの在宅判定をトリガーにして、帰宅シーンで照明を点灯し、夏場はエアコンを冷房で起動する流れです。
赤外線の再送自体は単純でも、シーン名で抽象化すると毎回の操作がぐっと減ります。

このとき、家電ごとの赤外線コードをバラバラに管理するより、「照明ON」「エアコン冷房」「エアコン除湿」「テレビ消音」のように役割単位でエンティティ名をそろえると、あとで自動化ルールが読めます。
インフラの設定ファイルと同じで、最初に名前を整えておくと運用で効きます。
Home Assistant側でスクリプトやシーンにまとめておけば、ESP32 の赤外線送信は裏方に回り、操作面はスマホや音声アシスタント寄りの体験になります。

MQTT連携まで入れると、この設計はさらに伸びます。
ESP32 が受け持つのは「指定されたコードを送る」という責務に絞り、Home Assistantや別の自動化基盤からはMQTTのトピックへ命令を投げる形にすると、構成が整理されます。
筆者はこの分け方にしてから、赤外線送信機の置き換えや追加が楽になりました。
送信ノードを1台から複数台に増やしても、上位のオートメーションはMQTTの publish 先を切り替えるだけで済むからです。

38kHz 前後のキャリアで赤外線 LED を点滅させる家庭用リモコンの前提はSparkFunの解説でも整理されていますが、そこをESP32側で吸収できれば、上位のシーン設計は「どの家電に何をさせるか」に集中できます。
DIY のおもしろさは配線そのものより、こうして家電の粒度を生活動線の粒度に合わせ直せるところにあります。

センサー連動と安全運用のポイント

自動化の次の一歩として相性がいいのが、温湿度連動です。
室温や湿度を見てエアコンを自動制御するだけでも、スマートリモコンが単なる代替リモコンではなくなります。
たとえば温湿度センサーの値をESPHomeや独自ESP32ノードからMQTTへ流し、Home Assistantで条件判定して赤外線送信を呼ぶ構成なら、「室温が上がったら冷房ON」「湿度がこもったら除湿へ切り替え」のような制御が自然に組めます。
筆者の家でも、リビングの温湿度を見て冷房と送風を切り替えるだけで、手動操作の回数が目に見えて減りました。

ここで意識したいのは、家電の状態管理を赤外線だけに頼り切らないことです。
赤外線リモコンは双方向通信ではないので、「送った」ことと「その設定になった」ことは別です。
そこで筆者は、エアコンのように状態がぶれると困る家電では、「トグル電源」より「冷房開始」「暖房開始」のような状態を直接指定するコードを優先して登録しています。
NEC は 32bit、SONY は 12/15/20bit、AEHA は 48bit 以上の 8bit 倍数という実装条件が知られており、プロトコルごとに表現力が違うので、学習時点でどのボタンを覚えさせるかが後の安定性に効いてきます。

センサー連動では、オートメーションの条件も少し工夫すると暴れません。
室温のしきい値をまたいだ瞬間に毎回送るのではなく、在宅時だけ有効にしたり、一定時間ごとの再判定にしたり、送信後はしばらく抑制したりすると、赤外線の連打を避けられます。
これはHome AssistantでもMQTT中心の構成でも同じで、制御ロジックは上位、送信は下位と役割を分けると見通しが保てます。

筐体/設置の工夫

ブレッドボードのままでも動作確認はできますが、常設するならケース化で完成度が一段上がります。
ESP32 とトランジスタ、IR LED、必要なら受信モジュールまで入るサイズでまとめておくと、ケーブル抜けやホコリ混入が減り、見た目も生活空間になじみます。
3Dプリントなら LED の角度や通気スリットを自由に設計でき、レーザーカットなら平板から箱形を作りやすいので、どちらも相性のいい選択肢です。
試作はレーザーカット、量産前提の形状詰めは3Dプリント、という使い分けも現実的です。

赤外線の届き方は筐体設計で変わります。
IR LED を1個だけ正面に向けると、その方向には強いものの、家具配置によって死角が残ります。
そこで複数IR LEDを左右や斜めに振って配置したり、前面に指向性レンズを組み合わせたり、内部や周辺に反射板を使って散らしたりすると、1台でカバーできる範囲が広がります。
赤外線リモコンは 940nm 帯を前提にした構成が一般的なので、LED の向きと遮光部材の形がそのまま効きます。
単に LED を増やすより、どこへ向けるかを先に決めたほうが結果が安定します。

設置場所も仕上がりを左右します。
筆者は最初、テレビ台の近くに置いていましたが、部屋の奥の家電には角度が足りませんでした。
その後、壁の上方に移して天井反射を使う置き方にしたところ、部屋全体に赤外線が回り込みやすくなり、手前と奥で反応差が出にくくなりました。
赤外線は直射だけでなく反射も使えるので、壁掛け設置と相性がいい場面があります。
とくにワンルームや横長のリビングでは、家具の影を避ける意味でも上側配置が効きます。

ケース化するときは、メンテナンスのしやすさも残しておくと後で助かります。
USB ポートへのアクセス穴、リセットボタンを押せる位置、LED 増設用の逃がし穴、壁掛け用のネジ穴やキーホール形状を用意しておけば、設置後に配線を崩さず更新できます。
自作スマートリモコンは、学習して終わりではなく、家電の追加やシーン変更に合わせて育てていく道具なので、ケース化は見た目のためだけでなく、長く運用するための設計として効いてきます。

まとめと次のアクション

学習の振り返り

このテーマは、受信して、同じ信号を返し、上位の自動化へつなぐという3段階で捉えると迷いません。
最初は照明のON/OFFのような単純なコードで、受信から再送まで通る感覚をつかむのが近道です。
次にエアコンでは、単発ボタンではなく状態フレームとして扱い、IRremoteESP8266のACクラスやRAW送信を使い分けると再現性が上がります。
そこまで安定したら、赤外線送信機ではなくローカル制御の末端ノードとして運用する視点に切り替えると、構成全体が整理されます。

次に読むべき関連トピック

次の一歩としては、まずMQTTでESP32と上位システムの役割分担を理解すると、赤外線送信の位置づけが明確になります。
続いてESPHomeやOpenMQTTGatewayを触ると、自前実装と既製フレームワークの違いが見えてきます。
Home Assistantまで含めて組む段階では、家電操作を単発命令ではなく、在宅判定や温湿度連動を含むローカルオートメーションとして設計すると、この自作スマートリモコンが日常の中で生きた仕組みに育ちます。