【ITニュース解説】Adding Tuya Smart Switches to Home Assistant: Three Paths and What Breaks

スマートホームデバイスの普及に伴い、様々なメーカーの製品が市場に出回っている。その中でも「Tuya」というロゴを目にすることは多いが、これは単一の製品や技術を指すものではない。Tuyaは、スマートデバイスを動かすためのクラウドプラットフォームであり、Wi-Fiデバイス向けのファームウェアスタックであり、さらにはZigBeeデバイスにおける特定の通信プロファイルを示すこともある。どのTuya技術がデバイスに採用されているかによって、そのデバイスを「Home Assistant」と呼ばれるオープンソースのスマートホーム管理ソフトウェアでどのように扱うべきか、またどのような困難に直面するかが決まる。Home Assistantは、様々なスマートデバイスを一元的に制御し、自動化を実現するための強力なハブとして機能する。

Tuya製スマートスイッチをHome Assistantに接続する方法は主に三つある。

一つ目の方法は「公式クラウド連携」である。これはHome AssistantがTuyaのクラウドサーバーと通信し、そのサーバーを介してスマートスイッチを操作する形式だ。スマートスイッチはTuyaのサーバーに自身の状態を報告し、Home Assistantからのコマンドも同じ経路をたどってデバイスに届く。この方法の最大の利点は、事実上すべてのTuyaデバイスに対応していることである。デバイスのファームウェアが更新されても影響を受けにくく、自宅から離れた場所からでも操作できる。しかし、欠点も存在する。この連携は「ポーリング」という方式を採用しており、Home Assistantが定期的にTuyaサーバーにデバイスの状態を問い合わせるため、実際のスイッチの状態変化がHome Assistantの画面に反映されるまでに数秒から数分かかる場合がある。特にHome Assistantからスイッチの状態を変更した場合にこの遅延が顕著だ。また、インターネット接続が途切れると、たとえスイッチが近くにあっても自動化機能が停止してしまう。地域やアカウントによっては、無料の開発者ティアで利用できるデバイス数に制限がある場合もある。

二つ目の方法は「Local Tuya」である。これは公式の連携ではなく、コミュニティによって開発されたカスタムコンポーネントであり、Home AssistantがWi-Fi経由でデバイスと直接通信する。具体的には、ローカルネットワーク上のTCPポート6668を介して、スマートフォンのアプリがデバイスと通信するのと同じプロトコルを利用する。この方法の利点は、遅延が数十ミリ秒と非常に短く、インターネット接続がなくても動作することである。セットアップにはデバイスごとに三つの情報が必要となる。それはデバイスID、ローカルIPアドレス、そしてローカルキーだ。このうちローカルキーの取得が最も手間がかかる。Tuya IoT開発者コンソールで自身のアプリアカウントをクラウドプロジェクトにリンクさせるか、Androidアプリのバックアップから抽出するといった手順が必要になる。このキーはデバイスごとに異なり、デバイスを再ペアリングすると変更されるため注意が必要だ。しかし、このLocal Tuyaにも限界がある。新しいファームウェア（特にプロトコル3.5以降）では、ローカル接続が拒否されるケースが増えており、そもそもポート6668に応答しないデバイスも存在する。また、一度動作したデバイスでもファームウェアの更新によって突然機能しなくなる可能性がある。そのため、Local Tuyaは個々のデバイスで試行錯誤が必要な実験的な方法と考えるべきだ。安定したローカル制御を望むならば、ペアリング後にルーターの設定でデバイスのインターネット接続を遮断しておくことが推奨される。これにより、意図しないファームウェア更新による機能停止を防げる。

三つ目の方法は「ファームウェアのリフラッシュ」、つまりデバイスの内部ソフトウェアを書き換えることである。一部のプラグや安価なデバイスはESP8266やESP32といったマイクロコントローラーを搭載しており、これらはESPHomeやTasmotaといったオープンソースのファームウェアに書き換え可能だ。これにより、MQTTという軽量なメッセージングプロトコルを介した完全なローカル制御が可能となり、クラウドサービスに一切依存しなくなる。しかし、この方法は重大な注意点を伴う。主電源が通る壁スイッチのようなデバイスに対しては絶対に行うべきではない。これらのデバイスは内部に高電圧が流れており、繰り返し開閉するようには設計されていない。ファームウェアを書き換えることで、本来取得していた製品認証（安全性や電波法に関するもの）も失われ、日本の法律に適合しなくなる可能性がある。また、無線通信のキャリブレーション（調整）は素人が簡単に行えるものではない。ローカル制御可能な主電源スイッチを求める場合は、最初からその目的のために設計された認証済みの製品を購入すべきである。なお、Tuya製のZigBeeデバイスはESPベースではないため、この方法でファームウェアを書き換えることはできない。

Tuya製のZigBeeデバイスを独自のZigBeeコーディネーターで利用するという選択肢もある。TuyaのZigBeeスイッチは、Zigbee2MQTT (Z2M) やZHAといった一般的なZigBeeコーディネーターにペアリングできることが多い。リレー機能は標準的なOn/Offクラスタとして認識されるため、ライトの点滅といった基本的な操作は問題なく行える。マルチギャングスイッチ（複数のスイッチが一体になったもの）も、それぞれのスイッチが別々のエンドポイントとして認識される。しかし、すべての機能が期待通りに動作するわけではない。Tuya独自の製造元固有のクラスタには、シーンイベント、ボタン押下、バックライト設定、そして電力監視といった情報が含まれているが、これらはZHAやZ2Mでそのままではきれいにマッピングされないことが多い。そのため、信頼性の高い基本的なスイッチング機能は得られるものの、それ以外の機能は部分的なサポートとなる。それらの機能を活用したい場合は、生のクラスタコマンドを直接指定する形で自動化を記述する必要がある。この方法は、「インターネットがなくても照明が機能する」という点を最優先するならば非常に良い選択肢だが、最初から洗練された完全なエンティティリストを期待するならば、がっかりする可能性がある。

Tuyaデバイスの設計には「データポイント（DPs）」という概念がある。これは、一つの物理的なデバイスが単一の「スイッチ」としてではなく、複数の機能や設定の集合体としてモデル化されていることを意味する。例えば、三連スイッチは「スイッチ1」「スイッチ2」「スイッチ3」という機能に加え、バックライト設定やカウントダウンタイマー、さらには電力監視機能を持つこともある。これが、一つの物理デバイスがHome Assistant上で四つや五つのエンティティとして表示される理由であり、ファームウェアの更新によってエンティティの数が増減する可能性もある。自動化を構築する際には、デバイス全体ではなく、個々のスイッチエンティティを対象とすべきである。そうすることで、将来のファームウェア変更によって自動化が予期せず動作しなくなる事態を防げる。

筆者の推奨するアプローチは、主電源スイッチングデバイスは、可能な限りZigBeeとローカルコーディネーターで運用することだ。クラウドサーバーへの往復通信を必要とするライトは、結局のところユーザーを苛立たせる可能性が高い。クラウド連携は、ローカル接続が難しいデバイスや、外出先からのリモートアクセスのための補助的な手段として利用するのが賢明である。ファームウェア更新後にデバイスの動作が不安定になった場合は、無理に問題を解決しようとせず、再ペアリングを試すことが推奨される。多くの「到達不能」とされるZigBeeデバイスの問題は、ファームウェアの問題ではなく、ペアリングの問題であることが多いからだ。筆者はこの分野の製造側で働いているため、「目の前のデバイスを何とか適合させる」よりも「自分のトポロジーに合ったデバイスを購入する」という考え方に偏りがあることを正直に述べているが、このトポロジーに関するアドバイスは、どのブランドの製品を使うかにかかわらず共通して当てはまるものだ。