Home Assistant: Raspberry Pi OS (64bit)にHome Assistant Supervisedをインストールする

Sympapaです。
Home AssistantをRaspberry PIにインストールしたい場合4つのインストール方法が用意されています。

もっとも簡単なインストール方法は、OSにHome Assistant OSを使用する方法です。
イメージをSDカードに焼くだけでHome Assistant環境が構築出来るので初心者でも迷うことなくインストールできますし、私もこの方法でインストールしてHome Assistantを使っています。
デメリットはOSがHome Assistantを動かすことに特化しているのでRaspberry PIがHome Assistant専用になってしまうことです。私の場合、Raspberry PIはホームオートメーション用途でしか使っていないのですが、Home Assistant以外のNode.JSやDocker上で動くホームオートメーション用スクリプトもたくさん公開されているのでこれらを動かせないのはデメリットになります。

2番目に簡単な方法としてはHome Assistant Containerがあります。
しかしSuperviserがインストールされないのでアドオンが使用できなかったりバックアップができない問題があります。(たぶん)

3番目と4番目のインストール方法は"Home Assistant Supervised"と”Home Assistant Core"です。
"Home Assistant Supervised"であればアドオンも使えますが、これらは「経験豊富なユーザーが利用できる手動のインストール方法」とされています。

先日、Home Assistantを稼働させるRaspberry PIの予備として2台目のRaspberry PI 4を手に入れたのでこれに"Raspberry PI OS (64bit)"をインストールし、経験豊富とは程遠い私がHome Assistant Supervisedのインストールにトライしてみました。
ネット上にいくつかインストールガイドがあって簡単そうに思えたのですが、結果的には結構ドハマりしたので備忘録を兼ねて手順を書いておこうと思います。

■OSのインストール

Windows版のRaspberry Pi imagerを使ってmicro SDカードに”Raspberry Pi OS (64bit)"をインストールしました。

ここの手順は超簡単なので割愛します。
www.raspberrypi.com

インストールが完了したらRaspberry Piにmicro SDカードを挿してマウス、キーボードを繋ぎ、電源を繋いで起動したらネットワークのセットアップをします。

■Home Assistant Supervisedのインストール

後で参考にしたいくつかのインストールガイドが書かれたページを書きたいと思いますが、どれも手順どおりにやってもうまくいかず複数のガイドの折衷でなんとかうまくいったので、その手順を書いておきます。が、私自身理解できていない部分も多いのでとんちんかんなことを書いていたら許してやってください(汗
尚、今回書く手順はOSが”Raspberry Pi OS (64bit)"であることが前提となります。

1.OSを最新にする
ターミナルを開いて以下のコマンドを1行ずつ実行します。

sudo apt update && sudo apt upgrade -y
sudo apt full-upgrade -y && sudo apt dist-upgrade -y && sudo apt autoremove -y
sudo reboot

2.Dockerをインストールする
下記のコマンドでDockerをダウンロードしインストールします。

curl -fsSL https://get.docker.com -o get-docker.sh

インストールが終わったらDockerが機能しているかどうかを確認します。
バージョンが正常に表示されたらOKです。

docker --version

3.Dockerにユーザーを追加する
以下のコマンドでDockerにユーザーを追加します。
piの部分はユーザー名ですが、OSのインストール時に弄って無ければpiのままのはずです。

sudo usermod -aG docker pi

4.必要な依存するものをインストールする
以下のコマンドをまとめて貼り付けて実行します。

sudo apt install \
jq \
wget \
curl \
avahi-daemon \
udisks2 \
libglib2.0-bin \
network-manager \
dbus \
apparmor -y

5.Wi-FiランダムMACアドレスを無効にする
Raspberry PIはWi-Fi接続の場合、再起動するたびにランダムなMACアドレスが設定されます。これだと再起動する度にIPアドレスが変わってしまうのでWi-Fi接続の場合はNetworkManagerの設定でランダムMACアドレスを無効にします。
まずは下記のコマンドでファイルを作成し開きます。

sudo mkdir /etc/NetworkManager
sudo mkdir /etc/NetworkManager/conf.d
sudo nano /etc/NetworkManager/conf.d/100-disable-wifi-mac-randomization.conf

開いたファイルの中に以下の記述を加え、Ctrl+O(書き込み) を押した後Enterを押します。

[connection]
wifi.mac-address-randomization=1 
[device]
wifi.scan-rand-mac-address=no

6. AppArmorを構成する
まずは下記のコマンドを入力しEnterを押します。

sudo nano /boot/cmdline.txt

開いたファイルには既に何か書かれていますがその末尾に以下を追加します。

lsm=apparmor

Ctrl+Oを押した後Enterを押し保存したらRaspberry PiをRebootします。

sudo reboot

以下のコマンドでAppArmorがインストールされていることを確認します。

sudo aa-status

7.Home Assistant OS Agentのインストール
まず、以下のページでOS-Agentの最新バージョンを確認します。
github.com

確認したら、以下のコマンドでパッケージをダウンロードします。
”/1.2.2/os-agent_1.2.2_linux_aarch64.deb”の部分は最新版に合わせて書き換えます。
また、今回はOSが64bitであるため"aarch64"を選んでいます。

wget https://github.com/home-assistant/os-agent/releases/download/1.2.2/os-agent_1.2.2_linux_aarch64.deb

ダウンロードが完了したら下記のコマンドでインストールします。

sudo dpkg -i os-agent_1.2.2_linux_aarch64.deb

エージェントがインストールされていることを下記のコマンドで確認します。

sudo gdbus introspect --system --dest io.hass.os --object-path /io/hass/os

8.何か良くわからないエラー対策
私の環境ではこれをしないとHomeAssistant Supervisedのインストール時に"/etc/default/grub"が無いというエラーが発生しました。何をしているのかさっぱりわかりませんが下記のコマンドをrootユーザーで1行ずつ実行します(汗

sudo echo "systemd.unified_cgroup_hierarchy=false" > /etc/default/grub
sudo sed -i -e "1 s/$/ systemd.unified_cgroup_hierarchy=false/" /boot/cmdline.txt
sudo reboot

9.HomeAssistant Supervisedのインストール
Home Assistant Supervisedを下記のコマンドでダウンロードします。

wget https://github.com/home-assistant/supervised-installer/releases/latest/download/homeassistant-supervised.deb

ダウンロードが完了したら下記のコマンドでパッケージをインストールします。

sudo dpkg -i homeassistant-supervised.deb

暫く待つとOSの選択メニューが表示されるのでOS(Raspberrypi4-64)を選択します。
エラーが出なければOKで、「machine: 192.168.x.x:8123 」とか「数分でアクセスできる」的なメッセージが出るはずです。
これで暫く待って他のPCなどから"192.168.x.x:8123”にアクセスすればHome Assistantのログイン画面が表示されます。
。。。のはずですが、"192.168.x.x:4357”でHome Assistant observerにはアクセス出来たのに、1時間経っても"192.168.x.x:8123"にアクセスできませんでした。結局、一か八かでRaspberry Piを再起動したらアクセスできるようになりましたが(汗)

■参考にしたHome Assistant Supervisedのインストールガイド

まず、最初にこちらを参考に公式の方法でインストールしましたが、最後のステップで"homeassistant-supervised"のインストールを開始すると「"Home Assistant OS-Agent"に依存しているのにそれが無い」と怒られました。
"Home Assistant OS-Agent"はインストールしていたのですが、64bit用の"aarch64"ではなく、このガイドに従い32bit用の"armv7"を選んでしまったのが問題だったようです。(上記手順の7.のプロセス)
peyanski.com

次にこちらのガイドに従ってやり直しました。
しかし、Home Assistant Supervisedのインストール(上記手順の9.のプロセス)で"/etc/default/grub"が無いと怒られました。
www.reddit.com

ググった結果、こちらに書かれた解決策で解決しました。これを上記手順8.のプロセスに反映しています。
community.home-assistant.io

■まとめ(？)

なんとかRaspberry Pi OS (64bit)を入れた2台目のRaspberry Pi 4にHome Assistant Supervisedをインストールすることが出来ました。
1台目のRaspberry Pi 4のHome Assistant OS上で動いているHome Assistantの環境をそのまま移行できたりするのかなぁ。
まぁとりあえずは、Home Assistant OSとの挙動の違いがないかをチェックしていこうと思います。

それでは。

2台目のRaspberry PI 4としてOkdoスターターキットを買ったはなし

我が家でHome AssistantがRaspberry PI 4上で稼働し始めてから9ヶ月ほど経ちました。

今では我が家の照明や家電の自動制御はHome Assistantに依存しています。
特に照明の自動化については停止するとかなり困るので、Home Assistantがトラブった時の復旧体制の構築はひとつの課題でした。
ソフト的なトラブルに対してはこまめにバックアップするくらいしか手が無いと思います。Home Assistant上でバックアップを取るのはもちろんですが定期的にSDカードのクローンを作っておけば、とりあえずはSDカードを差し替えるだけで復旧できると思います。

ハード的な不安としては、ひとつめはRaspberry PI 4本体や電源の故障、ふたつめはZigbeeコーディネーターの故障、みっつめはセンサー類の故障があります。
最初は日本で買えず入手に時間がかかるZigBeeコーディネーターが一番の課題で「予備が必要かな」と考えていました。

Raspberry PI 4と電源については、私が住んでいるド田舎でもマルツ店頭へ行けば売っていたので即日入手可能だと思っていたんですよね。
しかし、いつからかRaspberry PI 4はどの通販ショップでも軒並み売り切れの状況、当然ながらド田舎にあるマルツ店頭からも姿を消しています。

そんなワケで予備を購入しようと2ヶ月前の1月後半くらいからRaspberry PI 4を探す旅が始まりました。
最初は品薄状況もショップのことも良くわかっておらず、R社さんでRaspberry PI 4の8GBモデルが2月11日入荷予定となっていたのでポチっとしました。
その数日後に、現在Home Assistantが稼働している1台目のRaspberry PI 4を購入したS社さんで4GBモデルが在庫ありになっているのを見かけたのでポチろうかと思いましたが「1台目と全く同じなのもアレなのでやっぱ先に注文した8GBの方を待とう」と思いスルーしたんですがこれが失敗でした。
先にポチっていた8GBモデルの注文履歴ページには、もともとは2月11日と納期が書かれていたのですが、それが3月21日へ変更になり、いつからか納期が表示されなくなってしまいました(汗

その後は、通販ショップのページを見て回ったりメルカリをウオッチしていましたが、通販ショップでは入荷すると瞬殺、メルカリでの相場はここ1ヶ月でむしろ上がって来ているように見え、22年3月27日現在では4GBモデルは中古でも15,000円を下回ればすぐに売れるって感じでしょうか。
そして先日、メルカリで4GB 13,000円くらいの中古をポチろうと思ったんですが「一応、通販サイトの在庫確認しよ」とググってみたところ、M社さんでRaspberry Pi 4 B 4GB スターターキット ￥9,990(税抜きだけど)が「当日発送」と書かれてました。「　う　そ　？　」
何度も何度もガン見しましたが「当日出荷」です。そして、同じサイトの単体のRaspberry Pi 4 B 4GBには「欠品中」と書かれていました。ちゃんと(笑)
電源も付いて、(デザインが好みではないけど)ファン付ケースもヒートシンクも付いて、更にオマケも付いて新品なのに税込み￥10,989です。いわゆる定価なのに安い！って思える不思議(笑)
そんなワケで慌ててアカウントを作成しポチりました。
ポチってからも半信半疑でしたが本当に当日、発送案内が来ました(笑)
翌日見た時にはもう「欠品中」になってましたが。。。

■開封する

一応、セット内容を見ておきましょう。
まず、スターターキットって代理店がテキトーに寄せ集めたものが届くのかと勘違いしてましたが、届いたのはokdoのロゴが入った立派な箱に入った純正キットでした。

セットの内容は以下のようになっています。

Raspberry Pi 4 4Gb Model B
アルミケース
DC 5V 0.1A ファン
滑り止め防止パッド×4
アルミニウム製ヒートシンク×3
32GB Micro SDカード (プリロード NOOBS V3.3.1) 透明ケース付き
USB Micro SD カードリーダー
1m 4K Micro-HDMI - HDMI ケーブル×2
5V/3A 電源
ドライバ

当然ながら本体に加え、電源、ファン付ケース、ヒートシンクが入っているのですぐに使えます。好みじゃないと思っていたアルミ製のケースも写真で見るよりかっこよかったので今後もこのまま使います。

HDMIケーブルはご丁寧に2本も付いています。Raspberry PI 4の映像出力はMicro-HDMIでどの家庭にでもケーブルが転がっているわけではなく、届いてから「あっ！ケーブルが無い」って気づくパターンもありそうなので同梱されているのはいいですよね。
OS(というかインストーラらしいですが)入りのMicro SDカードも付いているので何も調べなくても起動できそうです。
更にMicro SD カードリーダーまで付いています。
ドライバーまで付いて他に何も用意しなくてもケースに取り付けできます。

と思ったけれどケースの隙間の狭いところにネジを入れなくてはいけないのに付属ドライバーはマグネット無しで痒いところには手が届いていない感が惜しい(笑)

他に何も用意しなくても使い始められるキットになってますね。
上質な紙の日本語解説書も入っています。

しかし肝心の組み立ては「このURLのページを見ろ」でした。他に何も用意しなくてもいいのかと思いきやそこはそうなるんかい(笑)
www.okdo.com

■初めて触るRaspberry PI ( !? )

1台目のRaspberry PI 4にはソッコーでHome Assistant OSをインストールしてHome Assistantを稼働させたので、Raspberry PI が何者なのか私はさっぱりわかっていません。
2台目は基本的にHome Assistant用予備機として購入しましたが、せっかくなので少しだけRaspberry PIのお勉強をしようかなと思っています。あんま興味ないけど(笑)
興味が無いとはいえ、Raspberry PIで動くホームオートメーション用のスクリプトなどは世の中にたくさん転がっています。
Home AssistantもContainerをDocker（←何のことかはさっぱりわかっていない）でインストールした方が、裏で他のスクリプトを走らせておける自由度が高くなりそう（←良くわかっていない）ですし、Home Assistant OSでは出来ないことが色々出来たりするかなぁと。

そんなワケでとりあえず付属しているSDカードに入っているOSで遊ぼうかなと思っていましたが、 調べてみると入っているのは"NOOBS"でインストーラーのようです。
オマケSDカード自体の質もよろしくないと思われるため、Windows PCで手持ちのSDカードにRaspberry PI OS 64bitをインストールしてとりあえず起動してみました。
無事起動しましたが、まぁフツーのちとモッサリしたパソコンでした(笑)

今後はとりあえずDocker環境を構築してHome Assistantを入れてみようかな。
でもHome Assistantの設定やらデバイスって、Home Assistant OS環境からDocker環境に変わっても、そのまま簡単に移行できるんやろか？
色々とわからないことだらけですがとりあえず弄ってみたいと思います。

それでは。

Home Assistant: ZigBeeネットワークの安定化(2) ZHAよりZigBee2MQTT

Sympapaです。
ホームオートメーションにおいて安定性と即応性と誰もが違和感を感じない挙動はとても重要だと思います。
自分しか使わないものであれば癖を掴んでおけばこっちが合わせたりして対処したりもできますが、家は家族みんなが使うものなのでそうはいきません。

Home Assistantを稼働開始してからセンサー類を繋ぐZigBeeネットワークとしてHome Assistantの純正インテグレーションであるZHA(ZigBee Home Automation)を使ってきましたが、センサーなどのデバイスが増えるにつれ稀にセンサーのレポートを取りこぼしオートメーションが発動しないことがありました。それと、稀にデバイスを見失い、再登録しないといけないこともありました。
ググると「ZHAは電球などのルーター(リピーター)機能を持ったデバイスがネットワーク内にあると調子が悪くなる」という情報というか訴えをみかけたので、ルーター機能を持った電球やスマートプラグといったデバイス全てをHome AssistantのアドオンであるZigBee2MQTTへ移行してやったのが約1ヶ月前。

しかしZHAがセンサーのレポートを稀に取りこぼす現象は改善しなかったので、更にセンサー類も大半をZigBee2MQTTへ移行して様子を見ていました。
コーディネーターを除いて47個ある我が家のZigBeeデバイスの内、現在は32個がZigBee2MQTTで接続しています。
しかし移行するとなると新しいデバイスとして認識されることになるので、オートメーションを修正しなくてはならず面倒なんですよね。
オートメーションが複雑化していて移行が面倒な玄関周りのセンサー類と、ボタン数と長押し・ダブルクリックなどパターンの多くて同じく移行が面倒なリモートスイッチ類はZHAに残し、それ以外は全てZigBee2MQTTへ移行してやりました。
結果として3週間ほど経ってもZigBee2MQTTがセンサーのレポートを取りこぼす現象は見かけていませんし、デバイスを見失って復活しない現象も発生していません。それだけでなく何故かZHAの方も安定して稼働するようになりました。

■ZHAが取りこぼすのはAqaraの人感センサーのみ？

ZHAで稀に動作しなかったのはトイレと階段の自動照明オンでした。でも何故か廊下と玄関周りの照明の自動化はずっと安定していたんですよね。
トイレと階段にはAqaraの人感センサーを使っています。一方、廊下と玄関ではHueとSonoffの人感センサーを使っています。
よくよく考えてみるとZHAが取りこぼしていたのはAqaraの人感センサーのみで、それ以外は取りこぼしていなかったように思います。
ググってみるとXiaomi系(Aqaraもそう）のセンサーはZigBee規格に厳密に準拠していないのでHome Assistantで使うには癖があるという噂が出てきます。しかし、Xiaomi系でもAqaraのドア開閉センサーとXiaomiの照度センサーでは特に問題を感じたことが無く真相はわかりません。
しかし、Aqaraの人感センサーがネットワークに存在しない現在のZHAは確かにド安定です。
一方、Aqaraの人感センサーがネットワークに存在するZigBee2MQTTはそれはそれでド安定で稼働しています。
じゃあAqaraの人感センサーの使用を止めれば良いかと言うと、Aqaraの人感センサーは改造すれば更新間隔を5秒に出来るのと照度センサーも内臓しているので使い勝手がとても良く、我が家の人感センサーの8割がコレなので使わないわけにはいきません。
そんなワケでメインのZigBeeネットワークをZigBee2MQTTへ完全移行することに決めました。

■ZigBee2MQTTはZHAよりルーターの使い方がおりこうさん？

ZHAにはもうひとつ気になっていた点があって、ネットワーク内にルーターデバイスがある場合に、センサーなどのエンドデバイスとルーターとの距離やLQI(リンク品質)に関係なく接続するんです。わざわざ遠くのLQIの低いルーターに接続したり、設置してある位置に関係なく、ルーター(とコーディネーター)が複数あると全てに対してエンドデバイスの数をほぼ均等に割り当てているように見えます。
そしてエンドデバイスとルーターが一旦接続したら、LQIが低くてもその組み合わせに固執する傾向があります。
ルーターデバイスをひとつネットワークから外すと、そのルーターにぶら下がっていたエンドデバイスが他のルーターへ自動的に接続してくれない問題も結構発生していました。

それに対しZigBee2MQTTはLQIが比較的高くなるよう適切にネットワークが形成され、あるルーターデバイスがネットワークに存在しなくなってもそのルーターに接続されていたエンドデバイスは割とスムーズに他のルーターへ接続されるようです。

■ZigBee2MQTT VS ZHA

そんなワケですが、ZHAは使うのがラクというメリットがあります。
Home Assistant純正インテグレーションなので導入も簡単ですし、デバイスの追加や削除、名前の変更なども全てHome Assistantの中で完結するので解りやすいです。
ZigBee2MQTTの場合はMQTTの設定も必要になるので導入が少し面倒で、デバイスの追加や削除、名前の変更などもZigBee2MQTTのUIを開いて実行しなくてはいけません。

一方、ZigBee2MQTTは細かいところまで設定できるのが良きです。
例えばHueの人感センサーではHue純正アプリと同様にセンサー感度が設定できたりします。

Hueのデバイスの場合OTAによるファームアップまで出来ます。

あと、人感センサーのタイムアウト時間も設定できます。
通常はそんなもん設定しなくてもデフォルトで使えばいいんですが、私的にはAqaraの人感センサーを改造し更新間隔5秒にして使うケースが多く、しかしデフォルトのタイムアウトは60秒になっているので、人感が無くなった時にリアルタイムにHome Assistant上のステータスを「人感無し」にするにはタイムアウトを短い時間に設定しなくてはいけません。
ZHAではサービス”Zigbee Home Automation: Set zigbee cluster attribute"を使って人感が検出されたらx秒後にリセットするというオートメーションを組んでいましたが、ZigBee2MQTTではUI上でタイムアウトする時間を設定可能です。

初心者に優しいZHA、玄人志向のZigBee2MQTTって感じですが、とはいえHome Assistantを使おうなんて人にとってはZigBee2MQTTを使うのもちょっと手間がかかるってくらいのことなので、これからHome Assistantの導入を考えている方は最初からZigBee2MQTTを導入することをおススメします。

■ZigBee2MQTTで使うコーディネーターとルーター

現在、ZigBee2MQTTのコーディネーターはSonoff Zigbee 3.0 USB Dongle Plusを使っています。
ZHAやZigBee2MQTTのコーディネーターとして使用する分にはファームウェアの書き換えが不要なのと、1500円～2000円と比較的安価に買えるのでこれを選びました。更に、ファームウェアを書き換えたくなった時も特殊なケーブルが不要でUSB経由で可能という初心者に優しい仕様です。
ただ、電波の飛びはあまりよろしくないので広くない家でもルーターデバイスは必要になると思います。
Sonoff Zigbee 3.0 USB Dongle Plusを複数購入しルーター用ファームウェアへ書き換えてルーターとして使うテもありますが、我が家では5個あるHueの電球の方が電波の飛びが良くルーターとして活躍してくれています。

■まとめ

というわけで今回は、メインのZigBeeネットワークをZHAからZigBee2MQTTへ移行したら凄く調子が良くなったし多機能だしこりゃいいわというお話でした。
ZigBeeネットワークの安定化も完了したし、Home Assistantでやりたいことは大体完了した感じです。他にやるとしたら防犯カメラくらいかな。
あと、Home Assistantがぶっ壊れた時に即復旧できる体制構築はしておきたいですね。

最近、家を買う検討をしているのですが、最初は「建売か中古でいいよ」と思っていたのにだんだん欲が出て「やっぱ注文住宅かな」となっていたりします。自動で洗浄してお湯張りしてくれるお風呂とか欲しくなりますね～どんどん予算オーバーになっていく(笑)
今後はそのこととスマートホーム関連を絡めたことを中心に書こうと思います。
あ、今までにやったことのネタもまだまだ残っているので書きますけど(笑)

それでは。

Home Assistant: Moesのニュートラル線不要Zigbeeスマート壁スイッチを試す(1)

Sympapaです。
照明をスマート化する場合、一般的には照明をスマート化する方法と「壁スイッチ」をスマート化する方法の2通りがあります。
(実際には壁スイッチと照明の間に入れるスマートスイッチもありますが、便宜上、今回はそれは無いことにします(笑) )

照明をスマート化する方法では「壁スイッチ」を常時オンにしておかなくてはならず「壁スイッチ」は使えなくなるデメリットがあります。物理スイッチが欲しい場合は別にリモートスイッチを用意しなくてはいけません。例えばPhilips HueのDimmer Switchみたいなやつです。

照明をスマート化する方法としては、電球タイプならPhilips Hueなどのスマート電球を使用すれば良いし、シーリングライトならスマート化されたものも販売されていますが赤外線リモコン付きの灯具であればNature RemoなどのスマートIRリモコンで制御する方法もあります。
ただ最近の住宅はLEDが内臓されたダウンライトが多用されているので、後から照明をスマート化するハードルは高くなって来ているように思います。

一方「壁スイッチ」の方を「スマート壁スイッチ」にする方法ですが、こちらのハードルは更に高くなり壁にぶち当たります。
まず、パナソニックなど日本の「スマート壁スイッチ」は価格がとてつもなく高く、ガラパゴス規格なので他のスマートホームシステムとの親和性が低いという問題があります。まぁそこは安価で他のスマートホームシステムとの親和性が高い海外メーカー製の「スマート壁スイッチ」を使えば解決できるわけですが、電気工事業者が取り扱っているワケもなく誰に工事を頼むのかとか中華製のを壁に埋め込むのって怖いという課題が生じます。

それらの課題をクリア出来たとして、後から「壁スイッチ」を「スマート壁スイッチ」に交換する場合はニュートラル線の壁にぶち当たります。
「スマート壁スイッチ」へはオンオフするためのリレーや通信するためのモジュールに電源を常に供給しなくてはいけません。
そして家に付いている普通の壁スイッチはオフにすると電気回路が切れてしまうため、従来は「スマート壁スイッチ」に交換する場合は別回路から電源を供給しなくてはならず、いわゆる「ニュートラル線」がスイッチの裏に来ている必要がありました。
「ニュートラル線」とは「ライブ」と「ニュートラル」の2極の内、接地されている方のことです。
国と地域によっては「ライブ線」と「ニュートラル線」の両方をスイッチのところまで持ってきて「ライブ線」のみをスイッチでオンオフし、スイッチの先は2極とも照明まで持っていくのが一般的なところもあるらしいです。
一方、日本では「ライブ線」のみをスイッチのところまで持ってきてスイッチの先は照明に繋ぎ、照明の「ニュートラル」側は基幹の「ニュートラル線」に繋ぐのが一般的です。
後者の方が配線が少なく済みそうですが、後で配線を弄るのは大変そうですね。
スイッチの裏まで「ニュートラル線」が来ていればスイッチのところに2極とも来ているので、スイッチをオフにしても壁スイッチに常時電源が供給できるわけです。
壁スイッチ裏の「ニュートラル線」は日本の一般的な住宅には無い場合が多く、これが「スマート壁スイッチ」へ交換したい場合の障壁となります。

しかし最近では「ニュートラル線不要のスマート壁スイッチ」が発売されています。仕組みとしては一般的に、オフの時に照明が点灯しない程度に電気を流してスマート壁スイッチの動作に必要な電源を確保しているようです。照明の消費電力が小さいとスイッチをオフにしている間もゴースト点灯してしまうので、その場合はキャパシタなどを入れないといけない面倒があったりするのですが、「ニュートラル線不要かつキャパシタ不要」をうたっていて100Vに対応しておりサイズも日本の一般的なスイッチと同じというスマート壁スイッチを見つけたので今回はこれを試していきます。

■Moes ZigBee Wall Touch Smart Light Switch ZS-US2-WH-MS

今回購入したのは、MoesのZigBee Wall Touch Smart Light Switch ZS-US2-WH-MSです。
本体の裏にはZTS-USと書かれているんですが、箱にはZS-US2-WH-MSと書かれていてZTS-なのかZS-なのかよーわからん。
https://www.moeshouse.com/products/zigbee-wall-touch-smart-light-switch-with-neutral-wire-no-neutral-wire-no-capacitor-needed-smart-life-tuya-2-3-way-muilti-control-association-hub-required-1-gang-white-us?variant=39797103099985www.moeshouse.com

特徴は製品説明と私の推測を混ぜて書くと以下のような感じです。

 

• Zigbee接続。たぶんW-Fiより消費電力が小さいのでオフの時にLEDがゴースト点灯してしまう問題が生じにくいと思われる。
• ニュートラル線無しで使用した場合にキャパシタ不要。これもたぶんスイッチオフの時にこの壁スイッチが必要とする消費電力が小さいためオフの時にLEDがゴースト点灯しにくいためと思われる。
• ニュートラル線無し/ニュートラル線ありのどちらでも使える。
• 照明を接続せず電源だけ(ニュートラル線を)接続した場合はリモートスイッチとして使える。この機能により疑似3路スイッチも実現可能。
• ガラス製パネルにタッチ式スイッチで質感は高い。手探りで操作することが出来ないので操作性はどうかな？
• 100V～250Vに対応。

■試す

表面はガラス製で見た目の質感はまずまずですが、指紋が付着しやすく目立ちます。
スイッチ部分は直径15mmくらいのタッチ式で、物理的凹凸は一切ないのでスイッチの位置を触って確かめることはできません。
丸く光るインジケーターランプが内臓されています。

私自身は電気工事士の資格を持っていないので今回はコンセントに繋いで試します。
裏側にN,L,L1,L2の端子があります。Nがニュートラル(オプション)、Lがイン側、L1とL2が2個のスイッチのアウト側です。

まずは照明を接続せずにNとLに電源を繋ぎHome AssistantのZigBee2MQTTでデバイス追加を試みました。
スイッチを5秒長押しすることでZigBee接続のペアリングモードに入ります。
無事にデバイスとして追加されましたが"TS0012"という別機種として認識されてしまいました。

スイッチはちゃんと2つ認識しましたが、EU仕様のZTS-EU2はZigBee2MQTTでサポートされていてスイッチの周りが青く光るインジケーターライトのオンオフも出来るらしいのに、"TS0012"として認識されてしまったこれはインジケーターライトのオンオフはサポートされていません。
今度自力でZTS-US2として登録できるかトライしたいと思います。
www.zigbee2mqtt.io

オンになるとスイッチの周りのインジケーターランプが青く光りオフになると消灯します。ん!?オフの時にインジケーターランプが消灯したら暗い時にスイッチが探せないけどこれでいいのか!?
まぁ別機種として認識されてしまっているし、そもそも本来のTuyaのシステムとリンクさせているわけではないので、インジケーターランプについては本来の挙動ではないのかもしれません。

スイッチの挙動ですが、スイッチ側からでもHome Assistant側からでもちゃんとオンオフ出来てステータスの同期も出来ました。照明を接続せずに電源を繋いでいるだけでも機能するのでリモート操作用として使うことも出来ます。
ただ、Philips Hue Dimmer switchなどのリモートスイッチの場合は「長押し」や「ダブルクリック」といった操作もトリガーに出来ますが、これは実際にスイッチであるためか「長押し」や「ダブルクリック」といった操作をトリガーにすることは出来ません。
リモート操作用に使うのであれば、元々リモートスイッチとして売られているモノの方が電池で動いて配線要らずで取り付ける位置も選ばないし便利に使えると思います。
この壁スイッチをリモート操作用として使うケースとしては、ある場所でこの壁スイッチに照明を繋いで使用していて、デザイン的に他の場所のスイッチも統一したいという場合くらいかな。

次に本来の「スマート壁スイッチ」としてのテストです。
手元にあった5.6Wの電球をニュートラル線無しで繋げてみました。使うのはL端子とL1端子です。
オフの時のゴースト点灯もなくキャパシタ無しで安定して動作しました。
停電時から復旧した時の動作は一瞬だけ照明が光りますがその後オフになります。

端子のネジが剝き出しで怖いのでビニールテープを貼って軽く絶縁して試しましたよ。
実際に壁に埋め込んだ時もこれ剥き出しだと怖いですねぇ。配線したまま壁から取り外したいなんてことがあった場合に、端子のネジが剥き出しであることを忘れてブレーカーを落とさずに壁から取り外し端子を触ってしまいそうです。カバーくらい付けてくれたらいいのに。

■Moes ZigBee Wall Touch Smart Light Switch ZS-US2-WH-MSのファーストインプレッションまとめ

100Vにも対応していてニュートラル線もキャパシタも不要、日本で一般的な(パナと同じ)サイズなので、既存の一般的なスイッチとそのまま交換できます。
ニュートラル線無しキャパシタ無しでの挙動も試した限りでは問題なく、日本で既存スイッチをスマートスイッチに交換したい場合の有力候補ではないかと思います。
ただタッチ式スイッチは見た目はいいんですが、操作性に関しては人によって評価が別れそうです。私的には手探りではスイッチを探せない点とクリック感が無いので不採用かなぁ。。。
でも、Zigbee接続でUSサイズ(日本で一般的なものと同サイズ)でニュートラル線不要の「物理ボタンスイッチを備えた」スマート壁スイッチが見つからないんですよねぇ。EUサイズだと100Vでも使えるやつが色々あるのに。。。
あとはCEマークも付いているとはいえ中華製のものを壁に中に入れる抵抗感はありますよね。

それでは。

Home Assistant: Echonet liteカスタムインテグレーションを導入してSHARPのエアコンを同期する

Sympapaです。

私の部屋ではSHARP製のエアコンAY-L22S-Wを使っています。

2020年に購入したもので白物家電は何でもいい派だったのでグレードは下の方のやつですが、プラズマクラスターに惹かれたのと当時私の中の第1次スマートホームブームが来ていたのですが下の方のグレードなのに標準でWi-Fi対応したのでこれを選びました。後付けのWi-Fiアダプタって結構高いんですよねぇ。
Wi-Fi対応モデルが欲しかったわけですが当時はHome Assistantなどの本格的(?)スマートホームとは程遠い世界に居て、ただGoogle Homeと連携出来れば良い感じだったんです。
しかし日本の白物家電のIoT化は使い勝手がもうひとつなんですよね。
SHARPのエアコンを操作するアプリ”CoCoRo Air"の出来はまずまずだと思うのですが致命的なのはGoogle Homeからの音声操作でした。
「OK Google! エアコンをつけて」と言うと3～4秒後くらいに「はい。〇〇のエアコンをオンにしてもよろしいですか？」と聞かれて「はい」と答えると2～3秒後くらいにやっとエアコンがオンになるという仕様でした。誤動作防止なんでしょうが、いちいちオンにしても良いかを聞かれて「はい」と答えオンになるまで何秒もかかるのはちっともスマートじゃありません。
なので結局、Google Homeとの連携はNature Remoを使ったIR信号による操作で行い（Nature Remoだといちいちオンにして良いか聞かれない）、外出先からの操作や温度確認などは”CoCoRo Air"アプリで実行するというスタイルで運用していました。

Home Assistantを導入してからはHome Assistantと連携したかったので、Nature Remoのカスタムインテグレーションを導入し使っていました。
これだとHome Assistantからエアコンを操作できて、更にGoogle Homeからエアコンとして認識されるのでGoogle Homeからの音声操作にも対応できました。

だがしかしです。エアコン付属の赤外線リモコンで実行した操作はHome Assistantと同期されないという、スマートホームマニアなら誰もが一度はぶち当たるであろう壁がありました。
それについては諦めていたのですが、今まで興味の無かったHEMSやEchonet Liteのことを調べていたらHome AssistantにEchonet Liteのカスタムインテグレーションが存在することを知りました。
そしてWi-Fi対応のエアコンでもEchonet Liteに対応させるにはオプションが必要だろうと思い込んでいましたが、私の部屋のSHARP製エアコンAY-L22S-WはEchonet Liteに対応していることが判りました。
そんなワケでHome AssistantにEchonet liteのカスタムインテグレーションを導入したらHome Assistantからエアコンを操作したり状態の取得が出来るようになったよというのが今回のお話です。

■カスタムインテグレーション: echonetlite_homeassistant

github.com
定かではありませんがこのカスタムインテグレーションを開発されているのは外国人さんのようです。Echonet Liteは日本のガラパゴス規格だと思い込んでいましたが海外でも使用されているのかな？日本在住の方かもしれませんが。
Echonet liteのことは高くつく日本の規格くらいに思っていて今まで何も調べてもいなかったので、このカスタムインテグレーションを使って何が出来るのかはさっぱりチンプンカンプンですが、説明には"This component will set up the climate, fan, sensor and select platforms."と書かれていてエアコンには対応していそうです。そして"This custom component makes use of the 'pychonet' Python library also written by yours truly."と書かれていて「自分でPython libraryを書けば対応デバイスを追加できるよ」ってことのようなので期待に胸が膨らみますがPythonとかチンプンカンプンです(汗)
まぁしかしエアコンだけでも同期できれば歓喜ですね。
そして「三菱製 MAC-568IF-E WiFiアダプターを使用し他のアダプター（他のベンダー）も機能する可能性がありますがECHONETliteプロトコルをサポートしている必要があります。」と書かれています。
MAC-568IF-E WiFiアダプターはググると三菱のエアコン用Wi-Fiアダプターのようで海外で販売されているもののようですね。
動作が確認されている機種の中にSHARP製のエアコンが書かれているので期待が膨らみました。

■導入する

HACSで"Echonet"で検索すると出てくるのですが私の環境では何故かエラーが発生し自動ではインストールされませんでした。
なので手動でインストールしました。

1) ここへアクセスします。

2) "Code"を押し"Download ZIP"を押してZIPファイルをダウンロードします。

3) ダウンロードしたZIPファイルを解凍します。

4) Home Assistantの"configuration/custom_components"の中にフォルダ"echonetlite”を作成します。

5) さっきダウンロードして解凍したフォルダの”custom_components/echonetlite/"の中に入っているファイルを全て、Home Assistantの"configuration/custom_components/echonetlite"の中へコピーします。

6) Home Assistantを再起動します。

7) Home Assistantの[設定]>[インテグレーション]を開き、[＋ インテグレーションを追加]ボタンを押します。

8) "echonet"で検索すると”Echonet lite”が見つかるので選びます。

9) 対象となるデバイスのIPアドレスとDescriptionを問うダイヤログが表示されます。
今回の場合、エアコンのIPアドレス（ローカル）と適当なエアコンの名前を入力しました。

10) 無事登録出来た場合はインストール済インテグレーションの画面にこんな風に追加されます。

11) 基本的にエアコンは自動で構成されるようですが、こんなオプション設定画面があります。

■使ってみる

Home Assistantから運転モード、温度設定、風量設定などは普通にコントロールできて、エアコン付属の赤外線リモコンから操作した場合もHome Assistantと同期されました。
赤外線リモコンの操作がHome Assistantに反映されるまでに数十秒かかる時がありますがSHARP純正アプリ”CoCoRo Air"への反映も同様なので、リモコン操作を行ってもエアコン側からの発信は数十秒に1回しか実行しないというエアコン側の仕様なのかもしれません。Home Assistantから操作した場合の遅延は無いのでまぁ問題無いですけどね。
あと、エアコン稼働後に赤外線リモコンでオフにすると自動で内部清浄モードに入るよう設定しているのですが、内部清浄モードに入ると 'other'というモードをステータスとして返すらしく、このモードにカスタムコンポーネントが対応していないようでログにエラーが記録されます。
エラーが出ても内部清浄モードの間はエアコンはオフとして認識されているようなので問題はなさそうです。

消費電力、外気温、室温の取得も出来ます。湿度が「利用できません」なのは安物のエアコンだから湿度計は内臓してないのかなぁ。。。
コントロールってところは良くわかりません(汗

■まとめ

今回は、Home AssistantにEchonet Liteのカスタムインテグレーションをインストールしたら、私の部屋のSHARP製Wi-Fi対応エアコンを同期できたというお話でした。Home Assistantとエアコンの同期はやりたかったけれどハードルが高かったので、このカスタムインテグレーションで簡単に同期出来たのはかなり嬉しい出来事でした(^^

それでは。

Home Assistant: Nature Remoのカスタムインテグレーションを導入する

Sympapaです。

だいぶ前からHome Assistantに今回記事にするNature Remoのカスタムインテグレーションを導入していたのでタイトルはちょっと偽りですが(笑)
Home AssistantとNature Remoを簡単に連携できるカスタムインテグレーションの導入について書いていきます。

スマートリモコンを使用されている方の中にはNature Remoを使っている方も多いのではないかと思います。私もHome Assistantを導入する前からNature Remoを愛用しており今も3台使っています。

Home Assistantを導入して最初に取り組んだのはHome AssistantからNature Remoを動かすことでした。
Nature RemoはクラウドAPIもローカルAPIも使えるので連携は可能です。
照明やテレビなんかはNature RemoをただのIR信号発信機だと考えてHome Assistantからの指示でIR信号を飛ばすだけでもそれなりの状態になりますし、照明の場合はHome Assisatntのlightインテグレーションを使えばGoogle Homeから照明として認識されるのでGoogle Homeとの連携や同期もバッチリ出来ます。
しかしエアコンに関しては、リモコンの信号が運転モードと温度などの無数の組み合わせで構成されているため、Home Assistantからの指示でIR信号を発射するようにするだけでも一筋縄ではいきません。

だがしかし、世の中にはハッカーさんの作ったありがたいカスタムインテグレーションがあります。
Nature Remoはたぶん日本でしか売っていないので外国人ハッカーさんが作ったNature Remoのカスタムインテグレーションは存在しませんが、日本の数少ないHome Assistantユーザーの中にNature Remoのカスタムインテグレーションを作成されたハッカーさんがいらっしゃいます。

Nature Remoのカスタムインテグレーションとしてはこちらが有名だと思います。
Nature Remoに登録したエアコンとNature Remo E/E Liteのモニターした電力をHome Assistantに統合できるものになります。
github.com

このカスタムインテグレーションは21年3月から更新されてはいませんが、これをベースに改良されている方がいらっしゃいます。
私が見つけたものを2つ挙げておきます。
github.com
github.com

私が調べた限りでは現時点で一番機能が充実しているのはこちらのようで、エアコンとNature Remo E/E Liteの電力以外に、照明とスイッチとNature Remo内臓の温度, 湿度, 照度センサーがサポートされているので、私はこちらを使わせていただいています。ありがたや。
たぶんクラウドAPI経由で操作していて、エアコン,照明,スイッチはGoogle Homeからもエアコンとして認識されHome AssistantとGoogle Home間は同期されます。素敵。
温度, 湿度, 照度はHome Assistantのセンサーとして使えます。
github.com

■導入方法

私はマニュアルでインストールしました。

1)ここへアクセスします。

2)"Code"を押し"Download ZIP"を押してZIPファイルをダウンロードします。

3)ダウンロードしたZIPファイルを解凍します。

4)Home Assistantに”custom_components/nature_remo”フォルダを作成します。（”custom_components”フォルダはもともとあるかもしれません）

5)解凍されたフォルダから下記の6つのファイルを”custom_components/nature_remo”へコピーします。
未だにHome Assistantを使いこなせていない私は、File editorアドオンからひとつひとつファイルをアップロードしました(汗

__init__.py
climate.py
light.py
manifest.json
sensor.py
switch.py
services.yaml

6)ここへアクセスしNature Remoのアクセストークンを作ります。

7)configuration.yamlに以下の記述を加えます。

nature_remo:
  access_token: !secret nature_remo_token

8)secrets.yamlに以下の記述を加えます。

nature_remo_token: あなたのアクセストークン

9)Home Assisatantを再起動します。

■使う

Nature Remo内臓の温度,湿度,照度センサーとNature Remoに登録されているエアコン,照明,スイッチのエンティティが自動で作成されます。

エアコンは普通にモードや温度を操作することが出来て、更にGoogle Homeからエアコンとして認識されます。
なのでGoogle Homeにエアコンとして登録すれば、Home AssistantとGoogle Home間は同期され、例えば「OK Google! エアコンの温度を20℃にして」でエアコンの温度を20℃に設定した場合、Home Assistant上の設定温度も20℃に変更されます。逆も同期されます。

温度,湿度,照度は”sensor”としてエンティティが作られます。
温度は3分間隔で更新されていますが、湿度は1分間隔、照度は30秒で更新されているように見えます。
それぞれ別々のタイミングで取得しているのかな？

■というわけで

Home AssistantとNature Remoを簡単に連携できて、自前で出来なかったエアコンの連携もバッチリのカスタムインテグレーションの導入について書いてみました。
テレビも連携出来ると完璧ですが、Home Assistant自体にチャンネルも扱える汎用テレビ用インテグレーションが無いようなので難しいのかもしれません。
まぁテレビの場合は電源オンオフさえHome Assistantと同期できれば良い感じですけどね。

それでは。

Home Assistant: ZigBeeネットワークの安定化(1) ZHAからZigBee2MQTTへの移行を考える

Sympapaです。

人感センサー、ドア開閉センサーはホームオートメーションにおいて欠かせませんが、後付けで構築する場合にはセンサー類は無線であることと小さいことが必須となります。
我が家のHome Assistantのセンサー類はZigBee接続のものを使っていますが、ZigBeeはWi-Fiより電池消費が少なくメッシュ構築によってBluetoothよりネットワークの範囲が広げられるというホームオートメーション向きのネットワーク規格のようです。
省電力だから電池が小さくて済むのでセンサー筐体のサイズも小さくなり、それでいてルーター（リピーター）またはその機能が内臓されたデバイスを配置すれば家中どこにでも電波が届くという素敵さ。
小さいセンサーを好きなところに貼り付けてホームオートメーションを構築できるというとても良い時代になりました。

今回は我が家のHome Assistantで使用しているZigBeeネットワークの安定化について書いていきたいと思います。

■なんだかZHAの調子が悪い

Home AssistantHome AssistantにはZigBeeネットワークを使用するためにインテグレーションとしてZHA(ZigBee Home Automation)が用意されています。アドオンとして用意されているZigBee2MQTT，Deconzを使用することもできます。(他にもあるのかもしれませんが）
私はHome Assistantを使い始めた時にZHAでZigBeeネットワークを構築したのでZHAをメインで使用しています。
コーディネーターとしてファームウェアの書き換えが不要かつ電波の飛びが良いという噂だったHUSBZB-1を選び、HUSBZB-1がZHAにしか対応していなかったのがZHAを選んだ理由です。

その後、ZigBee2MQTTも追加してサブで試用してきました。
コーディネーターはSonoff Zigbee 3.0 USB Dongle Plusを使っています。
Sonoff Zigbee 3.0 USB Dongle Plusはやはりファームウェアの書き換えが不要なので選びましたが、電波の飛びがあまりよろしくありません。

そんなワケでZHAをメインで使用し続けていましたが、ZHAのデバイス数が増えるに従い、時々センサーのレポートを取りこぼしたり、ごく稀にセンサーがネットワークから切断され「利用不可」となり復帰しない問題が起きるようになりました。
大した頻度ではないのですが、家族も使う家の自動化であるため99.99999%の確実動作が求められるのです。

色々とググった結果と経験から「ZHAはネットワークにルーターが存在すると不安定になる」可能性が高いと考えました。
ZHAはセンサーなどのエンドデバイスがどのルーターに接続するかを自動で選びますが、距離やLQIに関係なく選んでいるように見え、遠くの電波の飛びもよろしくないルーターに接続したりします。
そしてルーターを指定してエンドデバイスを追加しても、適切とは思えないルーターが自動で選択されてしまいます。

他にも、電球などに内臓されているルーターは通信をドロップしやすいといった情報もあったりしますが、その点の真相はわかりません。

ならばルーターを排除すれば良いのではないかと思うわけですが、電源が接続されている電球やスマートプラグなどのデバイスはルーター機能を持っているものが多く無効化できません。
ルーター機能を持ったデバイスを全てサブのZigBee2MQTTへ移行したとしても、電池で駆動するエンドデバイスだけで40個近くあります。
コーディネーター: HUSBZB-1だけで接続できるデバイス数は定かではないのですが、調べると32個までだという情報が多くそれ以上のデバイスを接続するにはルーターの追加が必要になるそうです。

■メインをZigBee2MQTTへ移行してみることにした

では、ZigBee2MQTTに移行すればZHAのような問題はないのか？
少なくともZigBee2MQTTでは、センサーなどのエンドデバイスが接続するルーターの選択はZHAよりも適切に行われているように見えます。
まず、ZigBee2MQTTはエンドデバイスを追加する時に接続するルーターを指定しなければ基本的にコーディネーターに接続され、その後変更されないように見えます。
ルーターを指定してエンドデバイスを追加した場合は最初は指定したルーターへ接続され、その後、自動でそのエンドデバイスを他のルーターへの接続へ変更する場合はあるようですが、よりLQIの高いルーターを選んでいるように見えます。
なのでエンドデバイスを追加する時に接続するコーディネーター/ルーターを適切に指定してやれば、少なくともそれよりLQIが低くなる接続に自動的に変更されることはなさそうです。

そんなワケでメインのZigBeeネットワークをZHAからZigBee2MQTTへ移行するべく、ルーター機能を持った全てのデバイスとエンドデバイスの半分以上をZigBee2MQTTへ移し、ZHAにはルーターが無い状態として様子を見ることにしました。
多数のオートメーションが絡んでいるエンドデバイスをZHAからZigBee2MQTTへ移行するのは苦労するのでそういったものはZHAに残したままとし、トイレや廊下のまわりなど動作の異常に気づきやすい箇所のエンドデバイスを移行しました。

ZHAにはルーターが無い状態となりましたが、コーディネーター:HUSBZB-1の電波の飛びがすこぶる良いのでLQI的には問題ありません。というか、むしろ電球などのルーターの電波の飛びはHUSBZB-1より遥かに悪いのでルーターを排除した方が全てのエンドデバイスでLQIが高くなります。
一方のZigBee2MQTTは、コーディネーター: Sonoff Zigbee 3.0 USB Dongle Plusの電波の飛びはよろしくなく、電球などのルーターの電波の飛びもよろしくないので家中に合計9個のルーターを配置(ってかほとんどは電球などですが)してカバーすることにしました。

■まとめ

というわけで今回は、メインのZigBeeネットワークをZHAからZigBee2MQTTへ移行したら安定するのか試してみるというお話でした。
数週間様子を見て、また結果を書きたいと思います。
一応、ZigBeeネットワークの安定化とトラブル時に速攻で復旧できる体制構築が完了したら、Home Assistant導入によりどっぷりハマった私の中の「第2次スマートホームブーム」は終了となる予定です(笑)
「第2次スマートホームブーム」のゴールについてはまたその内書きたいと思います。
ってかスマートホーム関連しか書いてないこのブログはどうすんだろね？(笑)

それでは。