家庭内の機器の状況を表示・操作するダッシュボードをM5Paperで作りました。コントロールハブとしてHome Assistantを用いており、Matter等様々な規格に対応します。
ESPHomeのコードはGitHubで公開しています。
https://github.com/timit3-github/m5paper_esphome
それ以外のセンサ類はストーリーの中で紹介しています。
要約：Matterデバイス作ったのにスマートスピーカー側が対応してないよ。
お、Home Assistant の Matter アドオンならいけるじゃない！
せっかくなので普段使うものを一通りHome Assistantに対応させたいな。
え、ESPHomeって表示やタッチ入力も使えるの？よしM5Paperでダッシュボード作ろう。
私はリモコン操作にNature Remo Lapis (通称りもいし) を使っています。でもスマホアプリの操作は手数が多くて面倒です。あと個人的に音声操作はあまり使いたくない。
Remo nano Dash ボタンを作ろう！で紹介されているRemo nano DashボタンはMatterデバイスをワンアクションで操作できて、しかも反応性が良くて快適なんですが、一つの機能のためにマイコン一つを使うのは効率が悪いです。
もっと多くの機器をワンアクションで管理したい、なるべくローカル通信を使って応答性もよくしたい。というのが出発点です。
今回対応したかった機器の一つに二酸化炭素濃度センサがあります。Matter対応の二酸化炭素濃度センサは市販されていないものの規格書のデバイスタイプには存在するので、デバイスを自作すれば対応できるだろうと軽く考えていましたが大間違いでした。
市販されているMatterコントローラーが対応しているデバイスタイプはとても少ないです。
Matterのリファレンスデザインであるconnectedhomeipのall-clusters-appをM5Stackで動かしてAmazon EchoやApple HomePodにコミッショニングしたことがある方は、照明が2つ登録されるだけなのにどこがall-clusters-appなんだ？と疑問に思ったことでしょう。しかしchip-toolをビルドしてコミッショニングしてみると、照明以外のエンドポイントも大量に存在していることがわかります。
つまりall-clusters-appはその名の通りのMatterデバイスとして動作しているのに、市販のMatterコントローラー側が対応してないから照明２つしか登録されないわけです。
AmazonとAppleのデバイスは二酸化炭素濃度センサどころか気圧センサにすら対応してないことがわかって膝から崩れ落ちました。
Home Assistantは海外のスマートホーム界隈では広く使われているようなのですが、日本での知名度は低いと思います。日本語での記事を書いてくださっている方もいますが、Matter対応の話や、Home Assistantと連携できるESPHomeで Home Assistant と双方向の情報のやりとりや表示ができるということに触れている記事はなかったと思います。
ベータ版という扱いですがHome AssistantにはMatterコントローラー・デバイスとして動作する公式アドオンがあります。注意点としてはDockerで導入したHome Assistantでは利用できません(アドオンを追加できない)。Raspberry Pi Imagerを使ってRaspberry Pi 4にHome Assistant OSを導入するのが間違いないです(RPI3だとスペック不足で最近のバージョンのHome Assistant OSはまともに動かなかった)。
Home AssistantにMatterアドオンを入れてall-clusters-appをコミッショニングしてみると、なんと照明以外のデバイスも片っ端から認識してくれました。
これはとてもよいものです。Matter遊びをしていてラズパイが余っている人は全員導入した方がいいと思います。デバイスタイプとしては対応していてもエンドポイントに複数のデバイスタイプがあると最初しか認識しないとかもあるし、市販のMatterコントローラーは融通が利かなすぎます。
Matterの規格は日本の家電の仕様とは相性が悪い部分があります。特にスマートリモコンではデバイスの状態を取得できないことが原因で仕様に準拠させることができないため、純正アプリならできるけれどもMatter経由ではできない操作がたくさんあります。
こんなときにはMatter以外の通信方法も使えるのがHome Assistantの良いところです。
今回はMatter以外に以下のようなIntegrationを使用しました。
登録されたデバイスは抽象化されるので、Home AssistantのAPIからはどのIntegrationを使ったのかを気にせずに同じように扱えます。
ESPHomeはYAMLファイルを引数にしてコマンドを一つ実行するだけで、ファームウェアをビルドしてくれるとても便利な仕組みです。OTAにも対応しているので、初回以外はPCにつなぐ必要がなくIoT機器向きです。
一方でWiFi周り以外のすべての処理が1スレッドで行われるため、電子ペーパーの画面更新中はタッチ入力を拾えなくなるといった残念なところもあります。
またArduinoのライブラリの豊富さに比べるとESPHomeが対応する対応デバイスは少ないです。それを補うものとしてcustom compornentという形で独自のコードを使用することができます。ESPHomeはM5Paperの電子ペーパーには非対応ですが、GitHubでM5Paperの電子ペーパーに対応するコードを公開されている方がいたので利用させてもらいました。
ただし画面更新が異様に遅いです。ESPHome側で無駄に全画素分レジスタアクセスしてそうな感じ。
M5Paperの標準の画面更新方法では画面全体に反転が起こりますが、他にも画面更新方法がいくつかあって若干の残像が残ることと階調数が減ることを犠牲にして、反転なしでの画面更新が可能な方法もあります。
いいとこ取りをするために基本的には反転なし表示を行い、一時間に一回だけ反転ありの表示更新を行うようにしました。
Override で設定する画面更新メソッド以外に独自の画面更新メソッドを追加することで対応しています。
Home AssistantのMatterアドオンはボーダールーターを用意すればThreadにも対応します。
cinimlさんがM5NanoC6向けに公開されているボーダールーターとThreadデバイスもHome Assistantで使うことができました。
しかしながらボーダールーターを直接Home Assistantに登録するやり方はどうもうまくいかなかったので、Amazon Echoを介してWiFiでコミッショニングする方法を取りました。
具体的には以下の手順をとります。
WiFiでのコミッショニングに成功したら、以降はボーダールーターを介してHome Assistantが直接Threadデバイスと通信できるようになります。直接通信するので、Echoの電源が切れてようが、Echoからデバイスの登録を削除してしまおうが問題ありません。Matterの仕組みはよくできていますね。
cinimlさんのリポジトリに書かれているように、sdkconfigに特定のフラグを立てるとM5NanoC6一台でot_rcpとot_brを兼ねることができます。しかしながらこの方法を使うと、NanoC6の電源を入れ直すたびにシリアルからコマンド入力でWiFiに繋いでボーダールーターを有効しなければならないという落とし穴があります。
ot_brには自動起動の設定があるのですが、NanoC6一台でot_rcpとot_brを兼ねるオプションと併用するとブートループに陥ります。どうやらot_rcpとot_brの初期化処理が適切な順番で行われないようです。
一方ot_rcpとot_brを別々のデバイスで実行した場合にはot_brの自動起動設定が正しく動作し，電源を入れ直したときに何もしなくてもボーダールーターとして動作するようになります。ot_rcpはThread通信が可能なデバイスが必要ですが、ot_brはWiFiに対応したESP32デバイスなら何でも使えるので、余っていたM5StampPicoを使いました。GroveケーブルでM5NanoC6と通信しつつ電源を受けられるので、電源につなぐのはM5NanoC6だけで大丈夫です。
cinimlさんのリポジトリにはThreadで通信するコンタクトセンサーとライトのデバイスも含まれています。
ESP32のライトスリープを使って低消費電力状態で待機し、GPIO入力に反応してスリープから復帰して状態を更新するという動作をします。
スリープ復帰用のGPIOにM5Stackのメカニカルキーユニットをつなぎました。スイッチから手を離すと状態が戻ってしまうのでは使いづらいので、コードを変更してスイッチを押すと状態をON/OFFのトグルするように変更しました。
スリープに入る処理中はGPIOの変化を検知できないためボタンの連続操作ができなかったり、スリープから復帰してデータが更新されるまでにやや時間がかかりますが、500ms程度長押しすれば状態が変化するので十分実用的です。なんといっても消費電力が少なくて全くデバイスが熱くなりません。
部屋の入り口付近において照明用のボタンとして便利に使っています。
M5 Atom LiteとCO2 Unitの旧版(SCD40)を使いました。ESP32用のソフトはSCD41向けのMatterデバイスのコードを公開している方がいたので使わせてもらいました。基本的な機能だけを使うのであれば、SCD40でも一切コードの変更無しで利用できました。
多分この手の統合コントローラーを使うときの定番と思われますが、操作する側のデバイスの入力を直接操作には紐づけるのではなく、単なる入力センサとして登録するのがおすすめです。
物理スイッチだけでなく、タッチ操作もエリアごとに異なる入力として登録します。
そしてHome Assistantのオートメーション機能を使って、各入力に対して操作を紐づけます。
こうすると後から操作に紐づける動作を変更したくなったときでも操作用デバイス側の変更が不要になりますし、状況に応じて同じ操作に対する動作を変更する条件判定や、複数の動作の実行も可能になります。
私が行った例として、M5Paperからの音楽制御では電源が入っているかどうかやスピーカーの入力ソースに応じて判断して対象機器がApple TVとfoobar 2000 のどちらなのかを判別するようにしています。
再生機器によらずM5Paperで行う動作は一緒でよいので利便性が上がります。
という手順を踏む必要があります。
エアコンの設定温度を1度上げるスクリプトの例は次のようになります。
service: climate.set_temperature
metadata: {}
data_template:
entity_id: climate.eakon_remo_lapis
temperature: |
{% if not is_state('climate.eakon_remo_lapis', 'off') %}
{% set n = states.climate.eakon_remo_lapis.attributes.temperature | float %}
{{ n + 1.00 | round(2) }}
{% endif %}
enabled: true
対象のデバイスの電源が入っていたら現在の設定温度を読み出して、+1度した値をset_temperatureメソッドのdataとして設定します。
Sony SongpalのIntegrationで登録したHT-A9というAVアンプ＋ワイヤレススピーカーがあるのですが、エンティティに対するアクションで音量を一段階上げると、なぜか音量が10上がって9下がるという挙動が起こりました。結果的には音量が1上がるものの一瞬大きな音がなるのでよろしくありません。
こんなときにも先と同様のスクリプトを書けば解決できます。
service: media_player.volume_set
metadata: {}
data_template:
entity_id: media_player.ht_a9_3
volume_level: |
{% if is_state('media_player.ht_a9_3', 'on') %}
{% set n = states.media_player.ht_a9_3.attributes.volume_level | float %}
{% if n <= 0.50 %}
{{ n + 0.01 | round(2) }}
{% endif %}
{% endif %}
手違いで音量が上がりすぎる事故を防ぐために一定値以上には上げない処理が増えていますが、やっていることはほとんど同じです。
ブラウザやスマホアプリを使ってHome Assistantにアクセスすると、メディアプレーヤーで再生中の曲名やジャケットの表示や、カラフルでわかりやすいグラフ表示など、GUIでのエアコン操作などグラフィカルな制御も可能です。
私のHT-A9のHDMI入力にはApple TVが接続されていて、foobar 2000はUPnPデバイスとしてネットワーク経由で再生しています。
電子ペーパーの必要以上に主張しない慎ましさもよいですが、情報量豊富で即時性の高い表示も悪くないです。
またスマホアプリを使うとiOSのショートカットやガジェットに、Home Assistantの任意のアクションを割り当てられます。もちろんSiriからの実行も可能です。
最近はiPhoneのガジェットやApple Watchのコンプリケーションから操作することも多いです。
登録するアクションを絞り込んでおけば探す手間も少なくすぐに操作できて便利です。
Home Assistantアプリのガジェットではセンサ値は表示できないのですが、Scriptableという別の無料アプリを併用すればガジェットにセンサ値を表示することも可能です。
Home Assistantを導入したことで、別のホームアプリやスマートリモコンの純正アプリを使うことはほとんどなくなりました。
参照したい情報が一箇所に集まっていて、簡単な操作もできるというのは思っていた以上に便利です。
特にMatter弄りしている人には是非Home Assistant + Matterアドオンを導入して欲しいです。
Arduino や esp-idf を使った場合に比べて ESPHomeでM5Paperを使うと画面更新が異様に遅いです。
具体的には3秒以上かかります。しかもその間タッチ入力を受け付けません。
ESPHomeの仕様に縛られているところが大きそうなので、ESPHomeを使わずに直接Home Assistant APIを使うファームウェアをPlatformIOやArduino IDEといった別のプラットフォームで開発する方が満足度の高いものを作れそうです。
どうも最近 Nature Remoの障害が多いです。
障害が起きてクラウドAPIが使えなくなるのは仕方ないですが、なぜかMatterからの操作までできなくなるのでなんとかしたいです。
SwitchBotのハブミニも持っているので、Nature Remo Lapis に接続できなかった場合はSwitchBotを使うようにしたいと考えたのですが、どうもNature Remoの障害には
のどちらのケースもあるようです。前者であればHome Assistant側で機器が利用不可になっていることがわかるので、スクリプトで条件式を使ってIRの送信デバイスを切り替えればよさそうです。
ですが後者の場合は利用者側にできることはないと思います。
なのでNatureさんがクラウドが利用できなくてもローカルで動作できるようにしてくれることを待つことにしました。そのうちクラウド側の障害に左右されずに安心してスマートリモコンを使えるようになるはずです。
またNature Remo LapisはローカルAPIにも対応予定となっているので、Matterから使えないエアコンの除湿や、ボタンを一つ一つ登録した機器なども、そのうちローカルAPIを使って低レイテンシで操作できるようになるはずです。
M5Stack Japan Creativity Contest 20242024-06-01 開催
opniz
Ba-Chang Car - 次世代「お婆ちゃんがよく押してる謎のカート」
測定器をとことん使い倒したいと頑張ってみた結果…
デジたま2 the AI
Facebookに投稿する
X(Twitter)に投稿する
