HOME Assistantに自作機器をつなぐ（構想編）

2026年5月11日

過去のブログ記事で3つの自作機器を紹介したが、それらをHOME Assistantから監視・制御できるように改良することを検討したので紹介する。改良方法の提案を、ChatGPT 5.5 ThinkingとClaude Opus 4.7に依頼し、それらの方法を相互評価させた。

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

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

HOME Assistantにつなぎたい自作機器

1. ソーラーパネル出力電力測定用のデータロガー

2. みちびき（準天頂衛星システム）の災害・危機管理通報サービスの受信装置

3. 洗濯物乾燥監視装置

ChatGPT 5.5 Thinkingの提案

自作機器をHOME Assistantに繋ぐ方法を提案してください。
自作機器は下記の3つです。
・ソーラーパネル出力電力測定（データロガー）
　https://roompine.com/solar_panel_watt_log2/
・みちびき（準天頂衛星システム）の災害・危機管理通報サービス
　https://roompine.com/gps_qzss1/
・洗濯物乾燥監視装置
　https://roompine.com/laundry-drying-monitor-2/

結論としては、3台とも「MQTTでHome Assistantへ送信」する方式を第一候補にするのがよいです。
ただし、3台の性格が違うので、次のように分けるのがおすすめです。

自作機器	おすすめ接続方式	理由
ソーラーパネル出力電力測定	Arduino MEGAはそのまま残し、ESP32等を追加してMQTT送信	既存のSDカードロガーを壊さず、Home Assistantには電圧・電流・電力だけ送れる
みちびき災危通報受信機	既存Web表示＋MQTTまたはREST API追加	L1S/DC Report/DCXの独自処理があるため、ESPHome化より既存ファーム活用が安全
洗濯物乾燥監視装置	M5Stack Core2のスケッチにMQTT送信を追加	重量・温湿度・進捗・乾燥判定をHome Assistantで表示・通知しやすい

Home Assistant公式では、ESPHomeはマイコンをHome Assistant用デバイス化し、ネイティブAPIで直接連携できる方式と説明されています。
一方で、既存スケッチを活かす場合はMQTTやRESTの方が改造量が少なくなります。(Home Assistant)

1. 全体方針：MQTT中心がよいです

3台とも「測定値や状態をHome Assistantへ送る」用途なので、基本構成は次の形が扱いやすいです。

自作機器
  ↓ MQTT JSON送信
Mosquitto MQTT Broker
  ↓
Home Assistant
  ↓
ダッシュボード表示・履歴グラフ・通知・自動化

MQTTを使うと、各機器は次のようなJSONを送るだけで済みます。

{
  "power_w": 18.6,
  "voltage_v": 12.4,
  "current_a": 1.50,
  "temperature_c": 28.1,
  "sd_status": "ok"
}

Home AssistantのMQTTセンサーは、state_topicのMQTTペイロードをセンサー値として扱え、JSONから値を取り出すvalue_templateも使えます。(Home Assistant)
また、MQTT Discoveryは初期状態で有効で、Home Assistantの起動通知をきっかけにデバイス側がDiscovery情報を再送する設計もできます。(Home Assistant)

2. ChatGPT 5.5 Thinking提案内容（ソーラーパネル出力電力測定データロガー）

Home Assistantに出す値

エンティティ	単位	用途
`sensor.solar_voltage`	V	パネル出力電圧
`sensor.solar_current`	A	出力電流
`sensor.solar_power`	W	瞬時電力
`sensor.solar_temperature`	℃	周辺温度
`sensor.solar_sd_status`	–	SD書き込み状態
`sensor.solar_today_energy`	kWh	積算発電量

特に重要なのは、電力 W をHome Assistantに送り、IntegralヘルパーでkWhに変換することです。
Home Assistantのエネルギー管理では、瞬時電力センサーがWまたはkWを返す場合、Riemann sum integralでkWhのエネルギー量に変換できると説明されています。(Home Assistant)

MQTT例

Arduino MEGA側は1〜10秒ごとにSerialへこう出します。

{"voltage_v":12.48,"current_a":1.21,"power_w":15.1,"temperature_c":27.8,"sd_status":"ok"}

ESP32側はそれを受け取り、MQTTへ送信します。

home/solar_logger/state

Home Assistant側の例です。

mqtt:
  sensor:
    - name: "Solar Power"
      state_topic: "home/solar_logger/state"
      value_template: "{{ value_json.power_w }}"
      unit_of_measurement: "W"
      device_class: power
      state_class: measurement
      expire_after: 120

    - name: "Solar Voltage"
      state_topic: "home/solar_logger/state"
      value_template: "{{ value_json.voltage_v }}"
      unit_of_measurement: "V"
      device_class: voltage
      state_class: measurement
      expire_after: 120

    - name: "Solar Current"
      state_topic: "home/solar_logger/state"
      value_template: "{{ value_json.current_a }}"
      unit_of_measurement: "A"
      device_class: current
      state_class: measurement
      expire_after: 120

その後、Home Assistantの「ヘルパー」から Integral を作り、入力に sensor.solar_power を指定します。単位は kWh になるよう、unit_prefix: k、unit_time: h 相当の設定にします。

判断

この機器は、ESPHome化は後回しでよいです。
理由は、SDカード記録・OLED・RTC・既存測定コードがすでに安定しているためです。Home Assistantは「表示・通知・集計」担当にし、SDカードは正式ログとして残すのがよいです。

3. ChatGPT 5.5 Thinking提案内容（みちびき災害・危機管理通報サービス受信機）

Home Assistantに出す値

エンティティ	例	用途
`binary_sensor.qzss_alert_active`	on/off	有効な災害情報があるか
`sensor.qzss_last_type`	津波情報、気象警報、Jアラート等	種別
`sensor.qzss_last_area`	対象地域	地域フィルター
`sensor.qzss_last_message`	要約文	ダッシュボード表示
`sensor.qzss_received_at`	受信時刻	最終更新確認
`sensor.qzss_satellite_status`	受信状態	診断用

特に重要な設計

この機器は、Home Assistantの通知に直結する前に、フィルターを入れるべきです。

理由は、記事中でも「情報は4秒ごとに更新され、広域の情報も配信されるので、履歴機能やフィルター機能が必要」とされています。
また、災危通報は補完的な災害情報として使うのが適切で、緊急地震速報の即時受信を完全に置き換えるものではない、という注意も示されています。

MQTT送信例

{
  "alert_active": true,
  "type": "津波情報",
  "area": "和歌山県",
  "headline": "津波注意報",
  "received_at": "2026-05-10T15:30:00+09:00",
  "source": "QZSS L1S"
}

MQTTトピック例です。

home/qzss_dc_report/state

Home Assistant側の例です。

mqtt:
  sensor:
    - name: "QZSS Last Type"
      state_topic: "home/qzss_dc_report/state"
      value_template: "{{ value_json.type }}"
      expire_after: 300

    - name: "QZSS Last Area"
      state_topic: "home/qzss_dc_report/state"
      value_template: "{{ value_json.area }}"
      expire_after: 300

    - name: "QZSS Last Message"
      state_topic: "home/qzss_dc_report/state"
      value_template: "{{ value_json.headline }}"
      expire_after: 300

  binary_sensor:
    - name: "QZSS Alert Active"
      state_topic: "home/qzss_dc_report/state"
      value_template: "{{ 'ON' if value_json.alert_active else 'OFF' }}"
      payload_on: "ON"
      payload_off: "OFF"
      device_class: safety
      expire_after: 300

APモードについての注意

災害時用にESPr Developer C6をアクセスポイント化している構成は、とても良いです。
ただし、APモード時はHome AssistantサーバーがそのAPに接続していない限り、Home Assistantからは取得できません。

そのため、おすすめは次の二重構成です。

モード	用途
通常時：自宅Wi-Fiに接続	Home Assistant連携、履歴、通知
災害時：APモード	スマホから直接確認する独立運用

つまり、Home Assistant連携は便利機能として追加し、災害時の単独表示機能は残すのがよいです。

4. ChatGPT 5.5 Thinking提案内容（洗濯物乾燥監視装置）

Home Assistantに出す値

エンティティ	単位	用途
`sensor.laundry_weight`	g	現在重量
`sensor.laundry_target_weight`	g	乾燥判定目標
`sensor.laundry_progress`	%	乾燥進捗
`sensor.laundry_temperature`	℃	温度
`sensor.laundry_humidity`	%	湿度
`sensor.laundry_elapsed`	分	経過時間
`binary_sensor.laundry_dry`	on/off	乾燥完了
`binary_sensor.laundry_measuring`	on/off	測定中

MQTT送信例

{
  "measuring": true,
  "weight_g": 182.4,
  "target_g": 158.7,
  "progress": 72.5,
  "temperature_c": 25.8,
  "humidity": 61.2,
  "elapsed_min": 83,
  "dry": false
}

Home Assistant側の例です。

mqtt:
  sensor:
    - name: "Laundry Weight"
      state_topic: "home/laundry_monitor/state"
      value_template: "{{ value_json.weight_g }}"
      unit_of_measurement: "g"
      device_class: weight
      state_class: measurement
      expire_after: 120

    - name: "Laundry Progress"
      state_topic: "home/laundry_monitor/state"
      value_template: "{{ value_json.progress }}"
      unit_of_measurement: "%"
      state_class: measurement
      expire_after: 120

    - name: "Laundry Humidity"
      state_topic: "home/laundry_monitor/state"
      value_template: "{{ value_json.humidity }}"
      unit_of_measurement: "%"
      device_class: humidity
      state_class: measurement
      expire_after: 120

  binary_sensor:
    - name: "Laundry Dry"
      state_topic: "home/laundry_monitor/state"
      value_template: "{{ 'ON' if value_json.dry else 'OFF' }}"
      payload_on: "ON"
      payload_off: "OFF"

    - name: "Laundry Measuring"
      state_topic: "home/laundry_monitor/state"
      value_template: "{{ 'ON' if value_json.measuring else 'OFF' }}"
      payload_on: "ON"
      payload_off: "OFF"

自動化例

乾燥完了時にスマホ通知します。

alias: 洗濯物乾燥完了通知
trigger:
  - platform: state
    entity_id: binary_sensor.laundry_dry
    to: "on"
    for: "00:05:00"
action:
  - service: notify.mobile_app_iphone
    data:
      title: "洗濯物が乾いた可能性があります"
      message: "重量が目標値に達しました。確認してください。"

記事では、重量が目標重量以下になった時点で乾燥完了と判定し、その後30分間測定を継続する構成とされています。
Home Assistant側でも、すぐ通知せず、for: “00:05:00″のように数分待ってから通知すると誤判定が減ります。

5. RESTでつなぐ案

MQTTではなく、各機器がWebサーバーを持っている場合は、RESTでも接続できます。

Home Assistant
  ↓ 10秒ごとにHTTP GET
http://自作機器のIP/api/state
  ↓ JSON取得
Home Assistantセンサー化

Home AssistantのRESTful統合は、1つのHTTPエンドポイントから複数センサーを定義できるため、JSON APIを自作機器側に追加できるなら有効です。(Home Assistant)

例です。

rest:
  - resource: "http://192.168.○.○/api/state"
    scan_interval: 10
    sensor:
      - name: "Solar Power REST"
        value_template: "{{ value_json.power_w }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Solar Voltage REST"
        value_template: "{{ value_json.voltage_v }}"
        unit_of_measurement: "V"
        device_class: voltage
        state_class: measurement

ただし、RESTはHome Assistant側から定期的に取りに行く方式なので、災害情報のようなイベント通知型の情報はMQTTの方が向いています。

6. ScrapeでHTMLを読む案は最終手段

みちびき受信機のように、すでにHTML表示ページがある場合、Home AssistantのScrape統合でHTMLから値を抜き出す方法もあります。
Scrape統合ではCSSセレクタでHTML要素を選んでセンサー化できます。(Home Assistant)

ただし、これはおすすめ順位としては低いです。

方式	安定性	おすすめ度
MQTT JSON	高い	◎
REST JSON	高い	○
HTML Scrape	中〜低	△

HTMLは表示用なので、ページ構造を少し変えただけでHome Assistant側の取得が壊れます。
自作機器側を改造できるなら、HTMLとは別に /api/state のようなJSON APIを追加する方がよいです。

7. ESPHome化するならどれか

ESPHome化に向いている順番は、次の通りです。

機器	ESPHome化の向き不向き	判断
洗濯物乾燥監視装置	やや向いている	ただしM5Stack Core2のLCD・ボタン・SD・既存スケッチを活かすならMQTTが簡単
ソーラーロガー	部分的に向いている	新規ESP32版を作るなら可。既存Arduino MEGA版は残した方が安全
みちびき受信機	向いていない	独自GNSSデコード処理が中心なので既存ファーム＋MQTT/RESTがよい

ESPHomeは、単純なセンサー値をHome Assistantへ出すには非常に便利ですが、今回の3台はどれも「既存スケッチの役割」が大きいです。
したがって、まずはMQTT追加、将来の新規製作時にESPHome検討という順番が現実的です。

8. 実装順序の提案

第1段階：Home Assistant側を準備

Mosquitto brokerを導入
MQTT統合を追加
MQTT Explorerなどで受信確認
configuration.yamlまたはMQTT Discoveryでセンサー作成

第2段階：洗濯物乾燥監視装置から始める

最初に試すなら、洗濯物乾燥監視装置が一番よいです。

理由は、M5Stack Core2がWi-Fi対応で、測定間隔も5秒程度なので、MQTT送信の確認がしやすいからです。
乾燥完了通知というHome Assistantらしい効果もすぐ確認できます。

第3段階：ソーラーロガー

Arduino MEGAにJSONのSerial出力を追加し、ESP32でMQTT送信します。
Home Assistant側では、まず瞬時電力グラフを作り、その後IntegralヘルパーでkWh化します。

第4段階：みちびき受信機

最後に、災危通報受信機にMQTTまたはREST JSONを追加します。
この機器は通知設計が重要なので、単に受信したら即通知ではなく、地域・種別・重要度で絞るのがよいです。

最終的なおすすめ

一番バランスがよい構成は、次の形です。

ソーラーロガー
  Arduino MEGA + ESP32 MQTTブリッジ

みちびき受信機
  ESPr Developer C6の既存Web表示 + MQTT/REST JSON追加

洗濯物乾燥監視装置
  M5Stack Core2スケッチにMQTT送信追加

Home Assistant
  MQTTで3台を受信
  ダッシュボードで表示
  必要なものだけ通知
  電力はIntegralヘルパーでkWh化

この方針なら、既存機器の良いところを壊さず、Home Assistantには「表示・履歴・通知・自動化」の役割を持たせられます。

Claude Opus 4.7の提案

3つの記事を確認しました。
それぞれ装置の構成が違うので、Home Assistant（HA）への繋ぎ方も装置ごとに最適解が変わります。
まず全体の構成イメージを図にした上で、デバイス別の具体策をまとめます。

（補足）SVG図はClaude Opus 4.7が作成したもので、他の図はClaudeの提案内容をChatGPT 5.5 Thinkingが図解した。

全体構成のおすすめ：MQTTを中心に据える

3つの装置をHome Assistant（HA）に繋ぐ場合、最も汎用的で運用が楽なのは MQTT を中継役に置く構成です。
HA本体に Mosquitto MQTT ブローカー をアドオンとして導入し、各装置からトピックを発行してもらう形にすると、装置側のコードはどれも数十行追加するだけで済みます。

デバイス別の接続方法

1. ソーラーパネル出力電力測定（Arduino MEGA）

3台の中で唯一WiFiを持たないため、ここが一番手間です。記事を読む限りA案がおすすめです。

A案：M5Stack系またはESP32 DevKitに置換（推奨）
洗濯乾燥監視装置と同じ M5Stack Core2 か、安価なESP32 DevKitに換装。理由は3つあります。

WiFi標準搭載でMQTT発行が簡単（PubSubClient ライブラリ）
メモリが大幅増（ESP32は SRAM 320KB、Flash 4MB）でArduino MEGAより余裕
HAが履歴を持つので、microSDの寿命問題（記事中で約257日と試算）も心配しなくて済む

OLED・I2C温度センサ・電流電圧センサのスケッチは、ピン定義の変更とライブラリ差し替えで概ね移植できます。

B案：MEGAは残してESP32をブリッジに（既存資産を活かす場合） MEGA → Serial (UART) → ESP32 → WiFi → MQTT という構成。
記事中でMEGAのUARTが4本あると確認されているので、そのうち1本（Serial1など）でJSON文字列を吐かせ、ESP32側で受けて MQTT publish するだけ。
Arduino側のスケッチはほぼそのままで、追加するのは Serial1.println(json) くらい。

publishするトピック例：

solar/voltage    → 電圧 (V)
solar/current    → 電流 (A)
solar/power      → 電力 (W)
solar/temp       → 室温 (℃)

2. みちびき災害・危機管理通報（ESPr Developer C6）

ここが一番ラクです。すでにWiFi搭載で、ローカルWebサーバー（192.168.○.○）も動いています。選択肢は2つ。

方法1：MQTT publish を追加（推奨） DC ReportやDCXメッセージを受信したタイミングで qzss/dc_report qzss/dcx qzss/jalert などのトピックにJSONで発行。
記事中で4秒毎に更新とあるので、内容に変化があった時だけ送る差分発行にするとブローカーが軽くなります。

qzss/dc_report   → 災危通報本文 (JSON)
qzss/jalert      → Jアラート受信フラグ
qzss/lalert      → Lアラート本文
qzss/sat_count   → 受信衛星数

災害情報なのでイベントドリブンが本質的に向いていて、HA側で「受信したら即スマホ通知」という自動化が非常に書きやすくなります。

方法2：HAのRESTfulセンサー（コード変更ゼロ） 既存のWebサーバーをHA側からポーリングする方法。configuration.yaml に以下のような定義を追加するだけ。

sensor:
  - platform: rest
    name: みちびき災危通報
    resource: http://192.168.x.x/dcreport
    scan_interval: 30
    value_template: "{{ value_json.message }}"

ただし災害情報の即応性を考えると方法1が本命です。
スマホでの確認用に既存のWeb画面は残しておくのが良いと思います（停電時のオフラインAP動作という重要機能のため）。

3. 洗濯物乾燥監視装置（M5Stack Core2）

ESP32ベースなのでMQTTがそのまま使えます。
記事で5秒毎にmicroSDに記録しているのを、同じタイミングで MQTT publish するのが素直です。

publishするトピック例：

laundry/weight        → 現在の重量 (g)
laundry/target        → 目標重量 (g)
laundry/temperature   → 温度 (℃)
laundry/humidity      → 湿度 (%)
laundry/progress      → 進捗度 (%)
laundry/state         → idle / measuring / dried / finished

state を dried に変える瞬間にHA側で「乾きました」とスマホ通知させると、ボタンCで開始してから2時間後の通知運用が自動化できます。
記事で「洗濯後の残留物で目標重量に到達しないことがある」という課題が挙げられていましたが、HA側で「進捗度が95%以上で30分推移したら強制終了」という元記事の課題対応を入れる手も使えます。

Home Assistant側の設定

Mosquitto アドオンのインストール

Settings → Add-ons → Add-on Store → Mosquitto broker をインストール。
HA上にユーザー（例：mqtt_user）を作って、各デバイスはそのユーザー名/パスワードで接続します。

MQTT センサーの定義例（YAML）

mqtt:
  sensor:
    - name: "ソーラー電力"
      state_topic: "solar/power"
      unit_of_measurement: "W"
      device_class: power
    - name: "洗濯物 進捗"
      state_topic: "laundry/progress"
      unit_of_measurement: "%"
    - name: "洗濯物 重量"
      state_topic: "laundry/weight"
      unit_of_measurement: "g"
  binary_sensor:
    - name: "Jアラート受信"
      state_topic: "qzss/jalert"
      payload_on: "true"
      payload_off: "false"

自動化の例

災危通報受信 → スマホ通知：qzss/dc_report の値が変わったら HA Companion Appにプッシュ通知
洗濯完了通知：laundry/state が dried に遷移したらスマホ通知（家族全員のデバイスに送信可）
発電量の異常検知：晴天時にソーラー発電量が閾値を下回ったらパネルの汚れ・遮蔽を疑う通知
長期データ収集：HAの組み込みRecorderが自動で履歴をSQLiteに蓄積するので、Grafanaアドオンを入れるとグラフ化が楽になります（既存のCSV解析記事の延長として面白そうです）

段階的な進め方の提案

一気に3台を移行すると詰まりやすいので、洗濯乾燥監視装置から始めるのがおすすめです。
理由は、ハードがすでにESP32（M5Stack Core2）で完成形に近く、トピック設計とHA側の自動化の練習台として最適だからです。
そこでMQTT＋HA運用の感覚を掴んでから、ESP32-C6のみちびき機（コード追加だけ）→ ソーラーロガー（ハード換装が必要）の順に進めると、難易度が階段状になって作業が楽です。

2つのAIの提案内容の比較・評価（評価者：ChatGPT 5.5 Thinking）

以下、ChatGPT 5.5 Thinkingとの会話。

各自作機器について、ChatGPTが提案した方法と、Claudeが提案した方法を比較・評価し表にまとめてください

以下のように見ると、Claude案は全体的にMQTT中心で統一、ChatGPT案は既存装置をなるべく壊さず、REST・MQTT・ESPHomeを使い分ける方向です。
Claudeの回答では、全体方針としてMosquitto/MQTTを中心に据え、各装置からトピックを発行する構成を推奨しています。

自作機器	ChatGPTが提案した方向	Claudeが提案した方向	共通点	違い	評価・おすすめ
ソーラーパネル出力電力測定	既存のArduino MEGAを活かし、ESP32などを追加してHome Assistantへ送る案を重視。既存スケッチを残すなら、シリアル出力→ESP32→MQTT/RESTが現実的。	A案：M5Stack/ESP32へ置換を推奨。 B案：Arduino MEGAを残してESP32ブリッジ追加も提示。	Wi-Fiを持たないArduino MEGA単体ではHA接続が難しいため、ESP32系を使う点は一致。	Claudeは「ESP32/M5Stackへ置換」をやや強く推奨。 ChatGPT側は、まず既存MEGAを活かす現実案を重視。	短期はMEGA＋ESP32ブリッジが安全。動作実績を壊しにくい。長期的に作り直すならESP32/M5Stackへ置換が有利。
みちびき災害・危機管理通報	既存ESP32/ESPr側にJSON APIを追加し、HAのRESTセンサーで読む案を有力視。即時通知が必要ならMQTTも有力。 ESPHome用の別中継機を増やす案は優先度低め。	方法1：MQTT publish追加を推奨。方法2：RESTfulセンサーも提示。	RESTとMQTTの両方が候補になる点は一致。既存Web画面を残す考え方も一致。	ChatGPT側は「まずRESTでHA表示」が始めやすいという評価。 Claudeは災害情報の即応性から「MQTT push」を本命視。	最終形はMQTT通知が有利。ただし、最初の確認用にはRESTセンサーが簡単。おすすめは RESTで表示確認 → MQTTで即時通知追加。
洗濯物乾燥監視装置	既存のM5Stack Core2スケッチを活かし、MQTT publishを追加する案が有力。 ESPHome化も可能だが、既存ロジックや画面操作を作り直す必要があるため優先度は下がる。	M5Stack Core2はESP32ベースなので、既存の5秒ごとのmicroSD記録ループにMQTT publishを追加するのが自然、と提案。	ほぼ同じ方向。既存M5Stack Core2を活かし、MQTTでHAへ送る。	ClaudeはHA側の補助ロジック、たとえば「進捗度95%以上が30分続いたらfinished扱い」まで具体化。	3台の中で最初に取り組むならこれが最適。既存構成を壊さず、MQTT追加だけでHA連携を試しやすい。

総合評価

観点	ChatGPT案	Claude案	評価
既存装置を壊さない	強い	中〜強	ChatGPT案は「既存スケッチを活かす」方向がやや強いです。
Home Assistantとの相性	強い	強い	どちらもMQTT/RESTを使うためHA向きです。
即時通知	中〜強	強い	Claude案は、特にみちびき災害情報でMQTT pushを重視しており、即時通知向きです。
導入の簡単さ	REST案が強い	MQTT統一で強い	最初の動作確認はREST、長期運用はMQTTが扱いやすいです。
3台の統一感	中	強い	Claude案は3台をMQTT中心に整理しているため、全体設計として統一感があります。
作り直しリスク	低〜中	中	ソーラーでClaudeのA案を採ると、ESP32/M5Stackへの移植作業が増えます。

私の結論

優先順位	機器	採用したい方式
1	洗濯物乾燥監視装置	既存M5Stack Core2スケッチにMQTT publishを追加
2	みちびき災害・危機管理通報	まずRESTでHA表示確認、その後MQTT pushで即時通知
3	ソーラーパネル出力電力測定	まずArduino MEGA＋ESP32ブリッジ。将来、ESP32/M5Stackへ置換

特に現実的なのは、「洗濯物乾燥監視装置でMQTT連携を先に成功させる」→「みちびきでREST/MQTTを試す」→「ソーラーは既存MEGAを残してESP32ブリッジ」という順番です。
Claudeも、最初はM5Stack Core2の洗濯乾燥監視装置から始めるのがよいと整理しています。

2つのAIの提案内容の比較・評価（評価者：Claude Opus 4.7）

各自作機器について、ChatGPTが提案した方法と、Claudeが提案した方法を比較・評価し表にまとめてください

ChatGPTの回答と私（Claude）の回答を装置ごとに比較し、全体評価をまとめました。

1. ソーラーパネル出力電力測定（Arduino MEGA）

観点	ChatGPT	Claude	比較・評価
推奨方式	MEGAを残しESP32追加（ブリッジ方式）を第一候補に明示	「A案：置換」と「B案：ブリッジ」の2案を併記、A案を推奨	アプローチが逆。 ChatGPTは「既存資産を壊さない」、Claudeは「メモリ余裕とSD寿命解消」を重視
YAML設定例	`mqtt: sensor:` 配下に3つ（電圧・電流・電力）の完全な定義例。`expire_after: 120`等の実用パラメータ込み	概要レベル、具体YAMLは別装置でまとめて提示	ChatGPTの方がコピペで動く具体性
エネルギー管理	HAのIntegralヘルパーで W → kWh 変換、エネルギーダッシュボード活用に言及	言及なし	ChatGPTが優位。発電装置という性質上kWh化は重要
microSD寿命問題	言及なし	A案で「HA側に履歴があるのでmicroSD寿命問題（記事中の約257日試算）を回避」と明示	Claudeが元記事の課題に直接対応
視覚化	テキスト構成図（ASCII）	SVG図解でA案/B案を並列表示	表現形式の違い

2. みちびき災害・危機管理通報

観点	ChatGPT	Claude	比較・評価
推奨方式	MQTTまたはREST追加を併記、優劣の明示は薄め	方法1（MQTT push、推奨）と方法2（REST pull）を併記、即応性で方法1を推奨	Claudeは即応性の理由を明確化
エンティティ設計	6エンティティ（binary_sensor.qzss_alert_active等を含む）、種別/地域/受信時刻を分離	4トピック（dc_report, jalert, lalert, sat_count）	ChatGPTの方が運用に近い設計。 HA側で扱いやすい粒度
フィルター	「地域・種別・重要度で絞る」必要性を強調	言及なし	ChatGPTが優位。元記事の「履歴・フィルター必要」に直接対応
APモード対応	「通常時：宅内Wi-Fi接続、災害時：APモード」の二重運用を明確に提案	「既存のオフラインAP動作を維持」と簡潔に言及	ChatGPTがより踏み込んだ運用設計
ESPHome適合性	「QZQSM.h/QZSSDCX.hの独自処理が中心のため不向き」と明示	言及なし	ChatGPTが選択肢を網羅
視覚化	テキスト構成図	SVG図解で方法1/方法2を並列表示	表現形式の違い

3. 洗濯物乾燥監視装置（M5Stack Core2）

観点	ChatGPT	Claude	比較・評価
推奨方式	M5Stack Core2にMQTT送信追加	同左（PubSubClient使用）	ほぼ一致
エンティティ/トピック設計	8エンティティ（sensor 6 + binary_sensor 2：dry, measuring）	6トピック（state を idle/measuring/dried/finished の文字列1個に集約）	アプローチが異なる。ChatGPTは平坦・HA向き、Claudeは状態遷移を意識した設計
自動化例	完全な自動化YAML、`for: "00:05:00"` で5分デバウンス、`notify.mobile_app_iphone` まで具体的	概要のみ、ただしHA側で「進捗95%×30分で強制終了」の補助ロジックを提案	ChatGPTは即運用、Claudeは元記事の「目標到達しない問題」に対する補強案を提示
元記事の課題対応	5分デバウンスで誤判定軽減	95%×30分の補助で「残留物で目標未到達」問題に対応	両者とも対応するが角度が違う。 ChatGPTは「早すぎる検知」、Claudeは「いつまでも終わらない」を解決
副次的効果	言及なし	HAのRecorderで季節別・天気別の傾向分析の可能性に言及	Claudeが将来拡張に言及
視覚化	テキスト構成図	SVG図解（センサー→M5Stack→HA→3つの出力）	表現形式の違い

全体評価まとめ

観点	ChatGPT	Claude
基本方針	MQTT中心（Mosquitto経由）	同左
取り上げた選択肢の幅	MQTT、REST、Scrape、ESPHomeを網羅的に検討	MQTTとRESTに絞り込み
YAML/コード具体性	各装置に動作可能な完全YAMLを提示	概要中心、要点のみ提示
HA固有機能の言及	Integralヘルパー、MQTT Discovery、Scrape、エネルギー管理など豊富	Mosquittoアドオン、自動化、Recorder、Lovelace
元記事の課題への対応	全体に元記事を踏まえつつ、注釈として引用	各装置の具体的な未解決問題（SD寿命・乾燥判定）に直接対応する補強案を提示
トレードオフの明示	文中に分散	比較表と図解で明示的
段階的実装計画	4段階（HA準備→洗濯→ソーラー→みちびき）	3段階（洗濯→みちびき→ソーラー）
視覚化	テキスト構成図	SVG図解を3点
強み	即実装可能な具体性、HA固有機能の網羅、エンティティ設計の運用適合度	選択肢の対比・トレードオフの可視化、元記事課題への直接的補強
弱み	視覚的な比較が弱い、装置ごとの選択肢提示が控えめ	YAML具体性が薄い、Integral/Discoveryなどのキー機能への言及が不足

評価の総括

実装着手のしやすさは ChatGPT に分があります。
各装置のYAML設定例がそのままコピペで動く水準で、Integralヘルパーやexpire_after、MQTT Discoveryといったホームアシスタント運用上の重要ポイントを押さえています。
特にソーラーロガーで「kWh化」を提案している点は、エネルギー監視という用途を考えると本質的な指摘です。

選択肢の対比・元記事の課題対応は Claude（私）の方が踏み込んでいます。
ソーラーロガーで「置換 vs ブリッジ」、みちびきで「push vs pull」を図解で並べ、元記事中の具体的な未解決問題（microSDの257日寿命、洗濯物が目標重量に到達しない）への補強案を直接提示しています。

両者を組み合わせて使うのが最良です。
Claudeで方針と選択肢を整理してから、ChatGPTのYAML例を雛形として実装に入る、という流れが、それぞれの強みを活かす使い方になります。

本記事は構想段階の話だが、ChatGPTは、次の段階の話（YAML雛形、JSONデータ構成、エンティティ、送信データ構造など）が混じっているので、構想段階での肝心な話が薄まるような印象を受ける。

「元記事の課題対応」について、ChatGPTは、「5分デバウンスで誤判定軽減」を提言しているが、Claudeは、SDカード対策と、洗濯物が乾燥したかを判断する補助ロジックを提案しているので、Claudeの方が優位。

提案内容は、Claudeが、「HAのRecorderで季節別・天気別の傾向分析」を提案しているのに対し、ChatGPTは、「電力 W をkWhに変換すること」、「みちびき受信装置で、Home Assistantの通知に直結する前にフィルターを入れるべきこと」、「みちびき受信装置で、通常時：自宅Wi-Fiに接続、災害時：APモードの二重構成にすること」を提案しているので、ChatGPTがやや優位。

基本構造の考え方はClaudeの方が整理されているので、Claude案で基本構造を構築し、ChatGPT提案をソフトウェアで実装していく。

HOME Assistantに自作機器をつなぐ（構想編）

HOME Assistantにつなぎたい自作機器

1. ソーラーパネル出力電力測定用のデータロガー

2. みちびき（準天頂衛星システム）の災害・危機管理通報サービスの受信装置

3. 洗濯物乾燥監視装置

ChatGPT 5.5 Thinkingの提案

1. 全体方針：MQTT中心がよいです

2. ChatGPT 5.5 Thinking提案内容（ソーラーパネル出力電力測定データロガー）

おすすめ構成

Home Assistantに出す値

MQTT例

判断

3. ChatGPT 5.5 Thinking提案内容（みちびき災害・危機管理通報サービス受信機）

おすすめ構成

Home Assistantに出す値

特に重要な設計

MQTT送信例

APモードについての注意

4. ChatGPT 5.5 Thinking提案内容（洗濯物乾燥監視装置）

おすすめ構成

Home Assistantに出す値

MQTT送信例

自動化例

5. RESTでつなぐ案

6. ScrapeでHTMLを読む案は最終手段

7. ESPHome化するならどれか

8. 実装順序の提案

第1段階：Home Assistant側を準備

第2段階：洗濯物乾燥監視装置から始める

第3段階：ソーラーロガー

第4段階：みちびき受信機

最終的なおすすめ

Claude Opus 4.7の提案

全体構成のおすすめ：MQTTを中心に据える

デバイス別の接続方法

1. ソーラーパネル出力電力測定（Arduino MEGA）

2. みちびき災害・危機管理通報（ESPr Developer C6）

3. 洗濯物乾燥監視装置（M5Stack Core2）

Home Assistant側の設定

Mosquitto アドオンのインストール

MQTT センサーの定義例（YAML）

自動化の例

段階的な進め方の提案

2つのAIの提案内容の比較・評価（評価者：ChatGPT 5.5 Thinking）

総合評価

私の結論

2つのAIの提案内容の比較・評価（評価者：Claude Opus 4.7）

1. ソーラーパネル出力電力測定（Arduino MEGA）

2. みちびき災害・危機管理通報

3. 洗濯物乾燥監視装置（M5Stack Core2）

全体評価まとめ

評価の総括