TasmotaとESPHomeとの違い

ESP8266/ESP32用ファームウェアに関して，“Xiaomi Mi Flora Monitorを利用した自動化” , “ESP32デバイス向けESPHome” で触れてきたTasmotaとESPHomeとの違いをきちんと調べてみた（他にもJavaScriptをサポートするものがあるがこの記事の範囲外）。

まず，TasmotaのESP32のサポートは現時点ではベータ版ということで，現時点でESP32のちゃんとしたサポートが欲しければ，それだけでESPHomeが自動的に選択される。が，TasmotaがESP32を正式サポートするのは時間の問題。

Tasmotaは動的構成でESPHomeは静的構成

設計方針としてここが大きく違う。

Tasmotaでは，基本的にまずはファームウェアをインストールしてから，後でWeb UIで構成する。そのため事前に想定された使用シナリオごとのファームウェアが複数用意されており，それが使えればそれをフラッシュした後，ハードウェアの設定をする。そのためのテンプレートリポジトリがある。自動化のルール設定はコマンドの一部として実現されているため，ファームウェアをインストール後，Web UIから設定できる。

事前に用意されたファームウェアの中に自分の使用法があったのが見当たらない場合自分で（クロス）コンパイルする必要がある。ユーザが自力でコンパイルできる環境を用意したりソースファイルに手を入れる必要があるため，敷居が大幅に高くなる。

ESPHomeではYAML形式のファイルで構成（自動化ルールを含め）を事前に指定し，変更があるごと，基本いちいちコンパイルしてファームウェアを生成してそれを焼く。必要なライブラリもその段階で面倒見てもらえる。そういった，「コンパイルありき」の使い方が前提なので，ユーザがコンパイル環境を用意したり，コンパイルする手間は最小限に抑えるよう工夫されている。

誤解を恐れず言語処理で例えるなら，Tasmotaはインタプリタ型言語処理，ESPHomeはコンパイラ型言語処理，のようだといえる。Tasmotaのファームウェアはいわば言語のインタプリタであり，一旦それをフラッシュすれば再フラッシュの必要はない。自分の望むように動作させるには，Web UIなどを使って数値を入力したり簡単なスクリプトを実行して設定する。一方，ESPHomeは，ユーザが用意した「プログラム」＝設定ファイルを元に（クロス）コンパイルして，得られたファームウェアをフラッシュする。その後の設定は極めて限定した形でしかできない。「プログラム」を変更するたびに，コンパイルし，ファームウェアをフラッシュする，というプロセスが必要になる。

外部とのインターフェース

TasmotaはMQTT, Web API, Web UIに用意されたコンソール，シリアルの4種のアクセス方法を必ず提供している。これら4種に跨がって一貫した充実したコマンド体系を用意しているのは特筆すべき。例えば，スイッチが接続されている場合，どういうコマンドでこのスイッチのオン・オフを外部から操作するかも規定されている。

ESPHomeでは用意されているコンポーネントを使うことで同様のことが実現できなくはないが，どれもデフォルトでは使えるようになっていない。例えば，MQTTクライアントコンポーネントを使用すれば，既知センサー種の値を指定したMQTTブローカに投げるところまではやってくれるが，接続されたスイッチに対する外部からの操作を受け入れるためのトピックの指定やそこにpublishされた際どう対処するかは，全てユーザが指定しなくてはならない。一方，Webサーバ・コンポーネントを利用すればWeb（サーバ）APIが利用でき，そこでは外部から操作するためのURIが規定されている。

なおMQTTに関しては，MQTTサブスクライブ・センサー，MQTTサブスクライブ・テキスト・センサーで，MQTTを介してデータが取得できる外部のセンサーを，自らに接続されたセンサーと同じように扱えるようにする道具立てが用意されている。

自動化

Tasmotaではルールはコマンドの一部という位置づけであるため，4種のアクセス方法全てで動的に設定できる。ただしルールは3つのみ。独自シンタックスで多様な内容が記述できる。動的に設定できるということは，裏返すとファームウェア内にハードコードされてないということ。同じ動作をさせたい機器を複数用意したい場合にこれは望ましくない。

これを限定的に補うためにスクリプト機能が用意されてはいるが，ファームウェアでデフォルトではこの機能は有効ではない。この機能が有効化されていたとしても，自分の理解ではやはりWeb UIで手動でいちいちスクリプトファイルを読み込ませなくてはならないと思うので，同じ動作をさせたい機器を複数用意したい場合にはやはり不十分。

ESPHomeでの自動化機能は “Automations and Templates” にまとめられている。ESPHomeでは構成は事前に静的に決められるため，自動化ルールも設定ファイルにYAMLシンタックスに従って記述される。特筆すべきはlambdaというキーワードで導入されるブロックで，ここには任意のC++のコードが埋め込める。

それだけでなく，自前のセンサーコンポーネント，（センサーに限らない）一般的コンポーネントをC++で記述し，それを組み込むことも可能。

適性

Tasmotaは素人向き，ESPHomeは玄人向き。

Tasmotaは事前に用意されたファームウェアで目的が達成できる場合に適している。自分でコンパイルしなくてはならなくなるとその手間が大きく見合わない。対象機器の性格上，込み入ったカスタマイゼーションが必要なく，あってもちょっとした自動化をする程度の場合，など。Web UIが必ずあるのでとっつきやすく，自動化ルールも含めて，Web UIで操作できるのはよい。MQTTを含めたアクセス方法がデフォルトで用意されているので手間がかからない。

ESPHomeは込み入った構成や複雑な自動化を行いたい場合によい。必要なコンポーネントのみファームウェアに組み込まれるため，同じことを実現するのならTasmotaの場合より，ファームウェアは小さく収まることが期待できる。逆に言えば，同じフラッシュの容量なら，より多くの機能を詰め込める。一方，例えば通信相手のMQTTブローカを変える，といった小さい変更のためだけにファームウェアをいちいち再コンパイルしなくてはならないのは手間といえば手間。

参考資料

“The COMPLETE Guide to Tasmota 2019 – YouTube”

追記: “Tasmota vs ESPhome: Who wins? (DIY Sensors, ESP32, Deep-Sleep, etc.) – YouTube”