赤外線受信部を備えたESPHomeデバイスの製作

下記の記事で、Home Assistant 2026.6のバージョンアップで、赤外線プラットフォームに受信用のイベントエンティティが追加され、受信した赤外線コマンドをHome Assistant内のイベントとして公開できるようになり、それをトリガーとしてオートメーションを設定できるようになったことを紹介した。
具体的には、ESPHomeが最初の対応送信機統合として挙げられているので、赤外線受信部を備えたESPHomeデバイスを制作すれば、家電の赤外線リモコンを、Home Assistantのオートメーションのトリガーとして使うことができる。例えば、高齢者が使うテレビリモコンの電源の赤外線信号を受信するESPHomeデバイスを用意すれば、高齢者の見守り用途に利用することができる。
その赤外線受信部を備えたESPHomeデバイスを制作したので紹介する。当初、Fable5に相談してすすめたが、トラブルが発生して行き詰まり、Codexに相談することとなった。

（注）本記事の内容は正確性を保証するものではない。

（2026年6月11日 追記）YouTube動画を追加しました。　https://youtu.be/HuBkn82nwHc

---

ESP32デバイス（ESP32-DevKitC-VE ESP32-WROVER-E開発ボード）と、赤外線受信モジュール PL-IRM1838Bを購入して、Claude Code Fable5に質問しながら製作を進めた。

赤外線受信部を備えたESPHomeデバイスの制作

ESP32-WROVER-E と PL-IRM1838B の組み合わせは、ESPHomeの赤外線レシーバーとして定番の構成です。
配線からHome Assistant連携まで順を追って説明します。

1. 配線

PL-IRM1838B は3ピンで、受光面(レンズ側)を手前に向けて足を下にしたとき、一般的に左から OUT / GND / VCC の並びです(念のためお手元のデータシートで確認してください)。

PL-IRM1838B	ESP32-DevKitC-VE
VCC	3V3
GND	GND
OUT	GPIO23

ポイント:

• 電源は必ず 3.3V から取ってください。5Vでも動作する素子ですが、OUTの信号レベルが5Vになり ESP32 のGPIOには危険です。
• GPIO16 / GPIO17 は使わないでください。 WROVER-E はこの2ピンが内蔵PSRAMに使われており、外部に使うと起動しなくなります。GPIO23のほか、19・21・22・25・26・27 あたりが無難です。
• そのままでも動きますが、データシート推奨どおり VCC–GND 間に パスコン(0.1µF〜47µF程度) を受光モジュールの近くに入れるとノイズ誤検知が減ります。

ESPHomeが登録されるまでのステップ

ESPHomeデバイスの新規作成から、Home Assistant(HA)にデバイスとして登録されるまでの操作のステップを説明する。

全体は3フェーズ:

(A) ESPHome側でデバイス定義を作る → (B) ESP32に書き込む → (C) HAに登録される

フェーズA: ESPHome Device Builderでデバイス定義を作る

ステップ1: Device Builderを開く

• 画面: HAのサイドバー → 「ESPHome Device Builder」(アプリのWeb UI)　補足：現在の名称「アプリ」に変更
• 操作: 右下の「+ NEW DEVICE」をクリック
• 「NOT CONNECTED」の「ESP Device」が表示されるので、「CONNECT」をクリック
• シリアルポートを聞かれるので選択する（下図では、選んだことがあるポートが「ペア設定済み」となっている）

ステップ2: デバイス名の入力

• 画面: 新規デバイス作成ダイアログ
• 入力: デバイス名(例: ir-receiver)
• Wi-Fi情報は secrets.yaml に保存済みのもの(!secret wifi_ssid / !secret wifi_password)が自動で使われる。初回のみSSID/パスワードの入力を求められることがある

ステップ3: 基本設定の自動生成

• 結果: デバイスカードが作られ、<デバイス名>.yaml が自動生成される
• この中に API暗号化キー(api: encryption: key:)とOTAパスワードが自動で入っている（図示省略）
• この暗号化キーがフェーズC(ステップ10)で必要になる

ステップ4: YAMLの編集

• 画面: デバイスカードの「EDIT」→ YAMLエディタ
• 操作: captive_portal: の後に remote_receiver: などを行頭(トップレベル)から追記 → SAVE
• 検証: カードの ︙ メニュー → Validate（検証） で「Configuration is valid!」を確認してから次へ
• 注意: トップレベル項目を字下げすると [xxx] is an invalid option for [captive_portal] エラーになる

esphome:
  name: ir-receiver
  friendly_name: IR Receiver

esp32:
  board: esp32dev
  framework:
    type: arduino

logger:

api:
  encryption:
    key: "（自動生成されたキー）"

ota:
  - platform: esphome
    password: "（自動生成されたパスワード）"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

remote_receiver:
  pin:
    number: GPIO23
    inverted: true        # 受光モジュールの出力はアクティブLowなので必須
    mode:
      input: true
      pullup: true
  dump: all               # 受信した信号をログに全部表示(コード解析用)
  tolerance: 55%
  filter: 250us
  idle: 25ms

---

フェーズB: ESP32への書き込み(初回はUSB)

ステップ5: INSTALLメニュー

• 画面: 「How do you want to install <デバイス名>.yaml on your device?」ダイアログ
• 選択肢:
  • Wirelessly(無線。2回目以降用)
  • Plug into this computer(初回はこれ)
  • Plug into the computer running ESPHome Device Builder(HAサーバー機にUSB接続している場合)
  • Manual download

ステップ6: HTTP環境のため迂回ルートへ

• 画面: 「Install ESPHome via the browser」ダイアログ(HTTPS要件未達の案内)
  • HAに http:// でアクセスしているとブラウザ直接書き込み(WebSerial)が使えないことが検知され、projectファイルをダウンロードして、そのファイルをESPHomeデバイスに書き込むという代替案を実行することとなった。
• 操作①: 「Download project」→ コンパイル完了を待つ → 形式は Factory format → .bin がダウンロードされる
• 操作②: 「Open ESPHome Web」→ web.esphome.app が開く(Chrome/Edge必須。Safari/Firefox不可)

ステップ7: ESPHome Webで書き込み

• 画面: web.esphome.app
• 操作:
  1. ESP32をUSB接続 → 「CONNECT」
  2. シリアルポート選択ダイアログで「CP2102N USB to UART Bridge Controller」を選択
     • Macでは cu.usbserial-210 と cu.SLAB_USBtoUART の2つが見えるが実体は同一(標準ドライバとSilicon Labsドライバの両方がポートを作るため)。どちらかで接続できればOK
  3. 「INSTALL」→ ダウンロードした .bin を指定 → 書き込み(1〜2分)

ステップ8: 起動とWi-Fi接続

• 結果: ESP32が自動再起動し、YAMLのWi-Fi情報でネットワークに接続(※ESP32は2.4GHz帯のみ対応)
• 確認: Device Builderのデバイスカードが「ONLINE」表示になる
• 以降の設定変更は INSTALL → Wirelessly でUSB不要

---

フェーズC: Home Assistantへの登録

ステップ9: 自動発見

• 仕組み: ESP32がmDNSでネットワーク上に自分を広告し、HAが自動検出する(数十秒〜数分)
• 画面: HAの 設定 → デバイスとサービス の上部に「発見」セクションが現れ、デバイスのカード(ESPHome)が表示される

ステップ10: 追加と暗号化キー入力

• 操作: カードの「追加」をクリック
• 入力: 暗号化キーを聞かれたら、ステップ3でYAMLに自動生成された api: encryption: key: の値を貼り付け
• 入力: エリアの選択(寝室など。後から変更可)

ステップ11: オプションダイアログ

• 画面: 「オプション」(チェックボックス2つ)
  • 「デバイスがHome Assistantアクションを実行できるようにします」
  • 「Subscribe to logs from the device」
• 操作: センサー受信だけならどちらもOFFのまま「送信」
  • 前者はESP32側からHAのアクションを呼び出す場合のみ必要
  • 後者はESP32のログをHAのログに流すデバッグ用

ステップ12: デバイスとエンティティの生成(完了)

• 結果: 「設定済み」一覧にESPHome統合が登録され、その配下にデバイスと、YAMLで定義したエンティティ(例: binary_sensor.〜terehi_dian_yuan_hotan)が自動生成される
• 確認: 開発者ツール → 状態 でエンティティIDを検索できれば登録完了。このIDをオートメーションで使う
  • 日本語のエンティティ名はローマ字化された読みにくいIDになるため、必ずここで正確なIDをコピーして使う

---

リモコンコードの収集

• ESPHome Device Builder の LOGS を開いた状態でリモコンを受光部に向けてボタンを押す
• 1回の押下で JVC / LG / NEC / Pioneer / Pronto など複数行が出るのは正常(dump: all が各プロトコル解釈を全部表示するため)。NECの行の address と command を使う
  • 例: Received NEC: address=0xBF40, command=0xED12(テレビ電源ボタン)
• リモコンの電源ボタンはトグル動作だが、送信されるコードは毎回同じ。binary_sensorは「テレビの電源状態」ではなく「ボタンが押された瞬間」を検知する(トリガーは to: "on" でよい)

受信できないリモコン

• FireTV / Apple TVのリモコンはBluetooth通信のため受信不可(故障ではない)
• 例外: FireTVリモコンの音量ボタンはテレビ操作用に赤外線を出す設定の場合があり、実際に受信できた。
  Apple TV(Siri Remote)はHDMI-CEC経由のため赤外線は出ていなかった。
• FireTV/Apple TVをHAで扱うなら、IRではなくネットワーク統合(Apple TV統合 / Android Debug Bridge)を使う

通知オートメーションの設定

HOME Assistantのオートメーションとして、「テレビリモコンの電源ボタンが押されたらiPhone17に通知がいく」という設定を行った。下記は「yamlで編集」を選択した場合の編集画面である。

alias: テレビ電源ボタンで通知テスト
triggers:
  - trigger: state
    entity_id: binary_sensor.qin_shi_ir_receiver_terehi_dian_yuan_hotan
    to: "on"
actions:
  - action: notify.mobile_app_iphone17   # テスト中はiPhone宛て
    data:
      title: "赤外線リスナー"
      message: "テレビの電源ボタンが押されました"
mode: single

• エンティティIDは 開発者ツール → 状態 で正確なものを確認して使う(日本語名はローマ字化されて読みにくいIDになる)
• 通知単体のテストは 開発者ツール → アクション から notify.… を直接実行できる
• オートメーション編集画面の ︙ → アクションの実行 でアクション部分だけ即時テストできる(トリガーと切り分けられる)

オートメーションは、「トリガー」が発生したら、「アクション」を実行するように構成するが、「アクションの実行」により、アクションだけの動作確認を行うことができる。この機能により、「電源ボタン操作検知テスト」というオートメーションのアクションは正常に実行され、iPhone17に通知が届くことが確認できた。

（補足）Mac miniへの通知も試した。iPhone17にはすぐに通知が届いたが、Mac miniにはかなり遅れて通知が届くという現象がみられた。Mac miniの「設定」の「通知」や「集中モード」で、HOME Assistanの通知をまとめて通知したりせず、「即時通知」するように設定することにより、ある程度、改善がみられた。

トラブルシューティング記録

オートメーションのアクションのみの動作は確認できていたが、ESPHomeデバイスである赤外線受信モジュールにテレビリモコンの電源ボタンの赤外線信号を当てても、オートメーションが動作しないというトラブルが発生した。

ESPHomeデバイスにリモコンの赤外線信号を当てると、ESPHomeデバイスのLOGS画面に赤外線信号の情報が表示されることも確認済みだったので、原因は、ESPHomeデバイスからの情報がHOME Assistantに伝わっていないものと思われた。

オートメーションが動作しない原因と対策を、Fable5に相談し、色々と確認作業も行ったが解決しなかった。
この段階で、Favle5には、これまでのトラブルをまとめてもらった。

症状	原因/状況	対処
Validate/InstallでFailed config	remote_receiver: のインデント誤り	トップレベル(行頭)に修正
ブラウザからUSB書き込み不可	HTTPアクセスのためWebSerial不可	代替案である「Download project + ESPHome Web で書き込み」の方法で書き込みを行った
ダッシュボードでセンサーが反応してしているように見えない	ON時間が0.1秒以下のmomentary動作	履歴の「オフになりました」が押下の証拠であり、正常に動作しているように思われるが、目視でも確認できるように、delayed_off: 500ms を追加する。 （補足）実際にはこの変更を行っていない。
Mac mini通知が遅延	通知経路・Mac側設定・宛先の複合(切り分け中にセンサー側の問題が発覚)	チェック項目を確認
センサーが更新されない (未解決→対応中)	ESP32側は正常(LOGSでNEC受信と binary_sensor >> OFF の発行を確認)。 HA側エンティティが更新されず。 エンティティ重複なし。 HAログにesphome関連エラーなし。統合の再読み込みでは復旧せず(再読み込み時に一度接続して状態取得はできている)	下記「次の手順」

次の手順(未解決問題の対応)

各ステップの後にリモコンを押し、開発者ツール → 状態 の「最近の更新」が動くか確認する。

1. ESP32の電源入れ直し(USB抜き差し、起動後30秒待つ)
2. Home Assistant再起動(設定 → システム → 電源アイコン)
3. ESPHome統合エントリの削除→再追加(暗号化キー再入力。エンティティIDは引き継がれる)
4. それでも直らなければ、デバイスページ(設定 → デバイス → ir-receiver)のエンティティ一覧で無効化された重複エンティティがないか確認

この「次の手順」を実行しても、動作しなかったので、Codexに相談した。

Codexへのトラブル相談

CodexとHOME AssistantはMCPで連携しているので、まず、ESPHomeのデバイスの状態を確認することから始めた。

確認できました。Home Assistant には ESPHome デバイスとして ir-receiver が登録されています。

項目	状態
デバイス名	ir-receiver
エリア	寝室
機種	esp32dev
メーカー	Espressif
ESPHome / firmware	2026.5.3 (2026-06-12 21:39:15 +0900)
MAC	8c:94:df:9c:79:cc
Home Assistant 接続	OK

登録されている主なエンティティはこれです。

エンティティ	名前	現在値
binary_sensor.qin_shi_ir_receiver_terehi_dian_yuan_hotan	テレビ 電源ボタン	off
update.ir_receiver_firmware	ファームウェア	無効化中

テレビ 電源ボタン は有効で、現在は off です。
つまり「登録はできていて、今は赤外線信号を受信していない/ボタン検出中ではない」状態に見えます。
最後に状態が変わった時刻は 2026-06-13 01:04:53 JST です。

再確認しました。2026-06-13 01:19:04 JST 時点では、赤外線受信機の検出エンティティはまだ off です。

エンティティ	現在値	最終更新
binary_sensor.qin_shi_ir_receiver_terehi_dian_yuan_hotan	off	2026-06-13 01:04:53 JST

つまり、Home Assistant 上では「赤外線を受信した」という状態変化は記録されていません。
少なくともこのエンティティは、赤外線を当てた後も更新されていないようです。

考えられるのは、当てた赤外線がこの テレビ 電源ボタン 用のコードと一致していない、受信GPIO/設定が違う、または ESPHome 側では受信しているが Home Assistant に公開する binary sensor 条件に届いていない、あたりです。
次は「私が30秒ほど監視するので、その間にリモコンを押す」形で見ると、瞬間的な変化も捕まえやすいです。

確認しました。2026-06-13 01:20:53 JST 時点でも、テレビ 電源ボタン は off のままです。

直近10分の履歴も見ましたが、on になった記録はありませんでした。
現在の Home Assistant 上では、さっき押した赤外線はこのエンティティには反応していない状態です。

次にやるなら、ESPHome のログで remote_receiver が生の赤外線信号を拾っているかを見るのが一番早いです。
Home Assistant のエンティティに出ていないだけなのか、ESP32自体が受信できていないのかを切り分けられます。

ESPHome のログを確認したが、ESPHome関連のエラーなどは発生していないことが確認できた。

---

はい、スクリーンショットを見る限り ESPHome 側では赤外線の受信はできています。

重要なのは最後の行です。

[S][binary_sensor]: 'テレビ 電源ボタン' >> OFF

つまり、赤外線信号自体は受信・解析されていますが、Home Assistant に出している テレビ 電源ボタン の binary sensor が ON ではなく OFF として発火している 状態です。
だから Home Assistant 側では off のままに見えています。

ログ上ではテレビ電源ボタンらしき信号はたとえばこれです。

Received NEC: address=0xBF40, command=0xED12

次は ESPHome YAML 側で、受信時に binary sensor を一瞬 ON にしてから OFF に戻す形にするとよさそうです。

例：

binary_sensor:
  - platform: template
    name: "テレビ 電源ボタン"
    id: tv_power_button

remote_receiver:
  pin:
    number: GPIOxx
    inverted: true
  dump: all
  on_nec:
    then:
      - if:
          condition:
            lambda: |-
              return x.address == 0xBF40 && x.command == 0xED12;
          then:
            - binary_sensor.template.publish:
                id: tv_power_button
                state: ON
            - delay: 300ms
            - binary_sensor.template.publish:
                id: tv_power_button
                state: OFF

要点は、今は「受信ログは出ているが、HAに見えるセンサーはONになっていない」ことです。
ESPHomeの設定で テレビ 電源ボタン をどう定義しているかを見れば、かなりピンポイントで直せます。

---

置き換えるのは 一番下の binary_sensor: ブロックです。
さらに、既存の remote_receiver: ブロックの末尾に on_nec: を追加します。

今のこれを削除：

binary_sensor:
  - platform: remote_receiver
    name: "テレビ 電源ボタン"
    nec:
      address: 0xBF40
      command: 0xED12

代わりに、下の形にしてください。

remote_receiver:
  pin:
    number: GPIO23
    inverted: true
    mode:
      input: true
      pullup: true
  dump: all
  tolerance: 55%
  filter: 250us
  idle: 25ms
  on_nec:
    then:
      - if:
          condition:
            lambda: |-
              return x.address == 0xBF40 && x.command == 0xED12;
          then:
            - binary_sensor.template.publish:
                id: tv_power_button
                state: ON
            - delay: 1s
            - binary_sensor.template.publish:
                id: tv_power_button
                state: OFF

binary_sensor:
  - platform: template
    name: "テレビ 電源ボタン"
    id: tv_power_button

つまり変更後は、remote_receiver が赤外線を受けたら、tv_power_button というテンプレートセンサーを 1秒だけ ON にして、その後 OFF に戻します。
これなら Home Assistant 側でも状態変化を拾いやすいです。

---

必要なのは ON だけです。
通知が2回来るのは、こちらの設定で意図的に

1. ON にする
2. 1秒後に OFF に戻す

という2回の状態変化を作っているためです。

Home Assistant の通知・オートメーションは、たぶん ON/OFFどちらの変化でも反応する 形になっているので、2回通知されています。

おすすめは、ESPHome 側は今のまま ON → OFF に戻す 形を残して、Home Assistant のオートメーション側で ONになった時だけ通知にすることです。

条件はこうです。

trigger:
  - platform: state
    entity_id: binary_sensor.qin_shi_ir_receiver_terehi_dian_yuan_hotan
    to: "on"

OFF に戻す処理自体は必要です。
これをしないと一度 ON になったままになり、次に同じボタンを押しても ON → ON で状態変化が起きず、Home Assistant 側が反応しにくくなります。

なので結論は：

ON は通知・操作のトリガー用に必要。
OFF は次回の押下を検出できるように戻すために必要。
通知は to: “on” のときだけ出す、が一番きれいです。

---

情報源は「このケース専用に、ON/OFF を入れると安定します」と書いた1本の資料ではなく、以下の公式仕様を組み合わせた判断です。

1つ目は ESPHome の Template Binary Sensor です。公式ドキュメントに、binary_sensor.template.publish でテンプレート binary sensor に ON / OFF の状態を明示的に publish できる、とあります。
ESPHome Template Binary Sensor

2つ目は ESPHome の Remote Receiver です。on_nec は NEC の赤外線コードをデコードしたときに automation を実行でき、x.address や x.command を lambda で使える、と説明されています。
ESPHome Remote Receiver

3つ目は Home Assistant の State trigger です。State trigger はエンティティの状態変化に反応します。to: "on" と書くと、on になったときだけ実行されます。逆に from/to を指定しないと、すべての状態変化で発火します。
Home Assistant State trigger

なので、今回の理屈はこうです。

赤外線ボタンは「押された瞬間のイベント」に近いです。でも Home Assistant の binary_sensor は状態を持つので、一度 on になったまま戻さないと、次に同じボタンを押しても on → on になり、状態変化として扱われにくくなります。

そこで ESPHome 側で、

ON
delay
OFF

という短いパルスにしています。
これは「押された」という一瞬の出来事を、Home Assistant が扱いやすい状態変化に変換するための実装です。

つまり、公式にあるのは部品ごとの仕様で、
「ONにしてOFFへ戻すと安定する」は、赤外線ボタンを Home Assistant の state trigger で扱うための実用パターン、という位置づけです。

Codexから、いきなり、「ON → OFF に戻す」という提案が出てきたので、なぜ、どこから、こんな提案が出てくるのかと驚いた。

また、この回答をみて、Fable5との下記のやり取りを思い出した。「トラブルのまとめ」の表にあるように、「ダッシュボードでセンサーが反応しているように見えない」という項目に関するやり取りである。

実はちゃんと動いています。
動いている証拠がスクリーンショットに写っていますよ。

アクティビティ欄を見てください。
「オフになりました 21:52:58」「オフになりました 21:45:31」とありますね。
これはリモコンを押した時刻と一致していませんか?「オフになった」ということは、その直前に一瞬オンになっていたということです。

前回少し触れた通り、このbinary_sensorは「押された瞬間」を検知するmomentary(瞬間)動作です。
オンになっている時間は0.1秒以下なので、人間の目でダッシュボードを見ていても、表示が「オン」に切り替わる瞬間はまず捉えられません。
履歴のグラフが全部「オフ」に見えるのも、オン期間が短すぎてグラフ上で幅ゼロになっているためです。

つまり故障ではなく仕様なのですが、「目で見て確認できない」のは気持ち悪いですよね。
オン状態を0.5秒間保持するようにYAMLを少し変更しましょう:

binary_sensor:
  - platform: remote_receiver
    name: "テレビ 電源ボタン"
    nec:
      address: 0xBF40
      command: 0xED12
    filters:
      - delayed_off: 500ms

追加したのは最後の2行(filters: と - delayed_off: 500ms)です。
これで「オンになったら500ミリ秒間はオンを維持してからオフに戻る」動作になり、ダッシュボードでもアイコンが一瞬青く点灯するのが見えるようになります。
Validate → Install → Wirelessly で反映してください。

なお重要な点として、オートメーションのトリガーとしては変更前の状態でもすでに正常に機能します。
HAのオートメーションは表示の見た目ではなく状態変化イベントそのものに反応するので、一瞬のオンでも確実にトリガーされます。
delayed_off はあくまで「人間が目視確認しやすくするため」の調整です。

「オン状態を0.5秒間保持する」という変更は、実際には行わなかった。目視できないだけで、正常に動作するならこの変更は行わなくていいかと思っていた。その後、Codexが提案した解決方法と似たようなことをFable5が回答していたのを思い出し、この変更を行っていたら、正常に動作したかもしれないと思った。ただし、この「オン状態を0.5秒間保持する」という変更は、オートメーションを正常に動作させるという意図（目的）で提案されたものではないので、もし変更していたら、このトラブルに気づくことなく、トラブルに関する知見を得る機会を失っていたかもしれない。この知見により、この方法を実用パターンとして今後生かすことができる。

Fable5は、もしかすると、ユーザーが「オン状態を0.5秒間保持する」という変更を行っているという前提で対策を検討し、オン状態を保持するという対策はすでに実施されているので、それ以外の対策を提案しなければならないと考えたかもしれない。

本記事で紹介したESPHomeデバイスにより、テレビリモコンの電源ボタンの押下を検知することができ、出先でもiPhoneなどで通知を受けることができるようになったので、高齢者の見守り用途などに利用することができる。また、テレビだけでなく、エアコンの冷房ボタンの押下も検知するとかして、複数の赤外線信号の検出を組み合わせてオートメーションを構成することもできる。

---