WindowsでSONOFF Zigbeeドングル使用時にZigbee2MQTTが起動しない原因と解決策（HOST_FATAL_ERROR対処）

Windows環境でSONOFFのZigbeeドングル（Dongle-LMG21 / -PMG24 / -Mなど）を使ってZigbee2MQTTを立ち上げようとすると、起動途中でリセットが繰り返され、最後に Failed to start EZSP layer with status=HOST_FATAL_ERROR で落ちることがあります。ログ上はシリアルポートが開けているのに、ASHアダプタのリセットが何度も発生して失敗するのが特徴です。
本記事では、この現象が起きる技術的な理由と、現実的に動かすための回避策（コード修正を含む）を、手順としてまとめます。

• WindowsでSONOFF Zigbeeドングル使用時にZigbee2MQTTが起動しない原因と解決策（HOST_FATAL_ERROR対処）
  • 症状：起動直後から「ASH Adapter reset」がループして落ちる
  • 原因：WindowsのSerialPort挙動がDTRを操作し、ドングルが再起動ループに入る
  • 解決策：zigbee-herdsman側で hupcl: false を明示する（暫定だが効きやすい）
    • 手順1：前提（Node.jsとpnpm）
    • 手順2：Zigbee2MQTTのソースを取得
    • 手順3：依存関係をインストール
    • 手順4：問題のファイルに hupcl: false を追加
    • 手順5：ビルドして起動
  • うまくいかない場合の追加チェック（再現率が高い落とし穴）
    • COMポートを他プロセスが掴んでいないか
    • USBポート・ハブを変える
    • 「暫定パッチ」である点を理解して運用する
  • まとめ：ASHリセットループは「設定ミス」ではなく「Windows側のDTR挙動」が原因になりやすい

症状：起動直後から「ASH Adapter reset」がループして落ちる

典型的には、Zigbee2MQTT起動後に以下の流れになります。

• Zigbee2MQTT / zigbee-herdsman が起動

• ember / ezsp 初期化開始

• Serial port opened の直後から
  ASH Adapter reset → ASH starting が数回繰り返される

• 最終的に zigbee-herdsman が起動できず終了
  Failed to start EZSP layer with status=HOST_FATAL_ERROR

このパターンは「ポート設定やCOM番号が間違っている」ケースとは違い、通信は開始できているのに、ドングル側が再起動を繰り返して握手が成立しないときに起きやすい挙動です。

原因：WindowsのSerialPort挙動がDTRを操作し、ドングルが再起動ループに入る

Zigbee2MQTTは、SONOFFドングルとの通信にSerialPortライブラリを使います。ここで問題になるのが、WindowsのSerialPort実装における既定挙動です。

• Windows側のSerialPortが、ポートオープン時にDTRピンを意図せず引き下げる（制御する）

• その結果、SONOFFドングルがリセット扱いになり、起動処理の途中で再起動

• Zigbee2MQTT側は初期化を続けようとするが、ドングルが落ち続けるのでEZSP層が開始できずエラー

この挙動を制御する代表的なオプションが hupcl です。
ただし厄介なのは、Zigbee2MQTT（および内部のember系処理）がこの hupcl を設定として公開していない点です。つまり設定ファイルだけでは回避できず、現状では「ソース側に手を入れる」形が取りやすい対処になります。

解決策：zigbee-herdsman側で hupcl: false を明示する（暫定だが効きやすい）

最もストレートな回避策は、Zigbee2MQTTが内部で使う zigbee-herdsman のEmber UART設定（serialOpts）に hupcl: false を追加することです。
これにより、Windows側でのDTR絡みのリセット誘発を避けやすくなり、再起動ループが止まる可能性が上がります。

手順1：前提（Node.jsとpnpm）

• Node.js 24 をインストール

• 次に、pnpmを使えるようにするためコマンドを実行
  corepack enable

ここでpnpmを使うのは、Zigbee2MQTTのビルドや依存関係の整合性を取りやすいからです。

手順2：Zigbee2MQTTのソースを取得

任意の作業フォルダで以下を実行します。

手順3：依存関係をインストール

手順4：問題のファイルに hupcl: false を追加

対象は zigbee-herdsman の Ember UART ASH 実装です。
概念としては、serialOptsのオブジェクトに hupcl: false を足すだけです。

• 対象ファイル例：
  zigbee-herdsman/src/adapter/ember/uart/ash.ts

• 追加位置の目安：
  serialOpts を組み立てている箇所（質問文では「line 457付近」「xoff: false の後ろあたり」）

変更イメージ（例）：

ポイントは次の2つです。

• hupcl: false が serialOptsの中に入っていること

• 余計な場所に足してTypeScriptの型エラーを起こさないこと（オブジェクトのカンマ位置も注意）

手順5：ビルドして起動

起動ログで ASH Adapter reset が延々と繰り返されず、初期化が先に進むようなら改善傾向です。
ここで改善しない場合、次の切り分けも併用すると効果が出やすいです。

うまくいかない場合の追加チェック（再現率が高い落とし穴）

COMポートを他プロセスが掴んでいないか

• シリアルモニタ

• フラッシャーツール

• デバイス管理系ユーティリティ

これらがポートを開きっぱなしだと、Zigbee2MQTT側の動作が不安定になります。一度すべて閉じるのが基本です。

USBポート・ハブを変える

USBハブ経由や電力が弱いポートだと、通信開始直後の負荷で不安定になりやすいです。
可能なら以下を試します。

• PC直結のUSBポートに挿す

• 別ポートへ移動（特に背面ポート）

• 可能なら延長ケーブルでノイズ源から離す

「暫定パッチ」である点を理解して運用する

この方法は根本解決というより、WindowsのSerialPort挙動に対して「落ちない設定を強制する」回避策です。将来的にZigbee2MQTT側で設定が公開されたり、依存ライブラリ側で改善される可能性もあります。

運用面では、

• アップデートのたびにパッチが消える可能性がある

• ビルドを伴うため、導入にひと手間かかる

というデメリットがあります。
一方で、**「今すぐWindows上でSONOFFドングルを安定稼働させたい」**という目的には、効果が出やすい現実的な解です。

まとめ：ASHリセットループは「設定ミス」ではなく「Windows側のDTR挙動」が原因になりやすい

今回のエラーは、単なるCOM指定ミスや権限不足というより、WindowsのSerialPort既定動作がDTRを触ってドングルを再起動させることが引き金になりがちです。
Zigbee2MQTT側が hupcl を設定として公開していない状況では、hupcl: false をserialOptsへ追加するパッチが有効な回避策になります。

「ログではポートが開いているのに、ASH resetが何度も出て落ちる」場合は、まずこの対処を最優先で試す価値があります。