ブログ

みなさんこんにちは、たいくんです。
最近、IKEAから新しく発売されたMatter対応のスマート空気質センサー「ALPSTUGA」（アルプストゥーガ）を購入して、Apple HomeとHome Assistantに追加してみたのでご紹介します。

ALPSTUGAについて

IKEAのスマート空気質センサー

ALPSTUGAは、2025年12月にIKEA初のMatter対応デバイス*として発売された複数製品の内の1つで、CO₂、PM_2.5、温湿度を測定することができるスマート空気質センサーです。
ALPSTUGAは通信方式としてThread（Matter over Thread）を採用しているため、ALPSTUGAを使用するにはThreadに対応したデバイスまたはThreadボーダールーター（HomePodシリーズなど）が必要です（Threadについて詳しく知りたい方はこちらの記事を参照）。

* 厳密には、追加のMatterハブ（IKEA DIRIGERA/ディリフィエラ）を必要とせず、単体でMatterアクセサリとして動作するデバイスとしてIKEA初のMatterデバイス。

なんといっても安い！

ALPSTUGAは私が購入した時は2999円で発売されており、二酸化炭素濃度を計測できるスマートセンサーとしては破格の安さです（この値段で買える製品が他に全くないレベル！）。
しかもMatterに対応しており、プラットフォームを問わず・ハブ不要で動作するのも特徴です。

私は数年前から、好奇心から自分の部屋の二酸化炭素濃度を測定して可視化してみたいと思っていたのですが、欲しいと思っていたSwitchBot CO2センサーは約8000円と高く、他の製品も高いものばかりで、二酸化炭素濃度を測定するためだけに、しかも明確な使用用途が決まっているわけでもなく好奇心のためだけに買うことを考えると、購入に踏み切ることができませんでした。
ESP32を使って二酸化炭素濃度センサーを自作しようとも考えていましたが、それでもパーツを合わせると5000〜6000円ほどになる計算で、「たいして安くもならないのにそこまでする必要があるのか？」と思い、二酸化炭素濃度の測定は半ば諦め状態でした。
しかし、ALPSTUGAは二酸化炭素濃度を測定できるセンサーとしては破格の約3000円だったため、この製品を見つけた瞬間に思わず購入してしまいましたw

私は近くにIKEAがないため、オンラインストアで購入しました。送料・税込みで3499円で、注文から4日で届きました。

ハードウェアについて

こちらの分解レポートによると、センサーにはSensirionのSEN63Cが採用されているようです。
CO₂センサーは一般的に「NDIR方式」と呼ばれているものの方が精度が高いと言われており、厚生労働省も「NDIRセンサーが扱いやすい」と説明していますが、ALPSTUGAに採用されているセンサーはどうやらNDIR方式ではなさそうでした。
しかし、他のCO₂センサーを持っている方が隣にALPSTUGAを並べて設置し、測定値を比較した情報を共有されていましたが、そちらの投稿を見る限り、精度は意外と高そうで期待が持てます。
また、SEN63Cの仕様を見るとCO₂精度は±100.0ppmであると記載されており、スペック上の精度もそこまで悪くなさそうです（参考までに、SwitchBot CO2センサーに採用されているCO₂センサーの精度は±50.0ppm）。

ちなみに、SEN63CをSensirionから単体で購入すると38.39ドル（記事執筆時点の為替レートである1ドル155円計算で約5950円）、420個の一括注文で24.63ドル（約3800円）で購入できるようです。
あれ？ALPSTUGA、センサー単体より安くない…？

開封とセットアップ

開封

パッケージはこんな感じです。かなり小さい箱でかわいいです。

箱の後ろ側はこんな感じです。
左下のほうに「Excl.」（除く）の文字とともにUSB-Cケーブルと電源アダプタに斜線がついたイラストが記載されている通り、電源ケーブルと電源アダプタは付属していないようです。

箱から取り出したところです。
黄色のラベルには、製品ごとに固有のペアリング情報を含む、IKEAアプリのダウンロードリンクを開くためのQRコードが印刷されていました。私は試していませんが、アプリがインストールされていればここからペアリングも行えるようです。

本体の後ろ側はこんな感じで、センサー用の穴とUSB-Cコネクタが付いています（スピーカーは付いていません）。
本体上部には、ディスプレイ表示を切り替えるボタンが1つ付いています。

本体の底面には、各種設定用のボタンが4つと、Matterのペアリングコードが記載されています。

セットアップ

動作の確認

電源ケーブルや電源アダプタは付属していないため、自分で用意する必要があります。
ユーザーガイドによれば5V 1A（5W）で動作するようなので、基本的にどのようなものを使用しても問題なさそうです（5V 0.5AのUSB電源でも動作したとの情報もありました）。私は使用したい場所の近くにUSB電源がなかったため、すぐそばにあったMac miniのUSBハブに接続しましたが、正しく動作しているようです。

電源ケーブルを接続するとすぐにディスプレイが点灯し、二酸化炭素濃度（CO₂）が表示されました。単位はppmです。
画像では薄いためわかりづらいと思いますが、ディスプレイの右側に警告ランプが搭載されており、ディスプレイの表示項目とデータに応じてここが黄色く点灯します。
CO₂表示の場合、1000ppmを超えている間は警告ランプが黄色く点灯し続けます。

本体上部のボタンを1回押すと、PM_2.5表示に切り替わりました。単位はμg/m³です。
PM_2.5表示の場合、15μg/m³を超えている間は警告ランプが黄色く点灯し続けます。

再び押すと温度表示に。

さらにもう一度押すと湿度表示に。

もう一度押すと、最後に時計表示に切り替わります。再び押すとCO₂表示に戻り、押すたびに表示が循環します。
時計表示の場合、CO₂が1000ppmを超えている間、またはPM_2.5が15μg/m³を超えている間は警告ランプが黄色く点灯し続けます。

本体の電源を入れてから15分間はペアリングモードになるようなので、その間にペアリングを行います。
15分間が過ぎてしまったら、本体底面にあるシステムボタン（円形のアイコンがついたボタン）を押すことで再びペアリングモードに入ることができます。

Apple Homeに追加する

まずはApple Homeに追加してみます。追加するにはiPhoneまたはiPadで「ホーム」アプリを開き、右上のプラスボタンから「アクセサリを追加」をタップします。

次に、カメラで本体底面にあるMatterのペアリングコードをスキャンするか、「その他のオプション」をタップしてアクセサリを選択します。

「その他のオプション」からアクセサリを追加しようとした場合、Matterのペアリングコードを入力するか、「カメラで読み取る」をタップしてスキャンします。

ペアリングコードを入力すると、ペアリングが始まります。私はALPSTUGAを時計表示にしていたのですが、このタイミングで時間が同期され、正確な時刻が表示されるようになりました。

ペアリングに成功すると設置場所を尋ねられるので、設置した部屋を選択します。
ちなみに、「識別」をタップすると、本体ディスプレイの右側にある警告ランプが白色で点滅しました。

その後、センサーの名前を設定する画面が表示されるので、お好みの名前を入力します。今回は「空気質センサー」に設定しました。

このような画面が表示されたら設定は完了です。

センサーは、部屋画面の上にある「空気質」から確認することができます。
Apple Homeの画面からは上から順にPM_2.5、空気質、湿度、CO₂の4つを確認することができ、温度は表示されないようです（1つの「空気質センサー」アクセサリとして追加されるため、これとは別に温度センサーが追加されるわけでもありません。おそらくApple Homeの仕様だと思います）。
ただし、温度データ自体は取得しているようで、Siriを使えば温度を知ることができました（「”設定したアクセサリ名” の温度は？」と聞くと、0.5°C刻みで教えてくれます）。

Home Assistantに追加する

Apple Homeに追加することができたので、次はHome Assistantに追加してみます。Apple Homeに追加した段階で自動的にThreadネットワークには参加しているので追加は簡単です。

まずは「ホーム」アプリのアクセサリ詳細画面を開き、下のほうにある「ペアリングモードをオンにする」をタップします。

するとアクセサリがペアリングモードに入り、一時的な設定コードが表示されるので、「コードをコピー」をタップしてコピーしておきます。

次に、Home Assistant設定の「デバイスとサービス」から「統合を追加」を選び、一番上にある「Matterデバイスの追加」を選択します。

このような画面が表示されたら、すでにApple Homeで設定を完了しているため、「はい、すでに使用されています。」を選択します。

ペアリングコードの入力画面が表示されるので、「セットアップコード」のところに先ほどコピーしたコードを入力し、「デバイスを追加」を選択します。

すると、ペアリングが始まるのでしばらく待ちます。

ペアリング中、このような通知が表示されます。

通知が届くとすぐにペアリングが完了し、デバイスがHome Assistantに追加されました。

追加されたエンティティは次の通りです。

• スイッチ（アウトレットとして）
• CO₂
• PM_2.5
• 空気の質
• 温度
• 湿度
• ファームウェアアップデート
• 識別ボタン

この内のスイッチは、本体ディスプレイの点灯状態を切り替えるスイッチのようで、オフにするとディスプレイが消灯しました。
デフォルトではなぜか「アウトレット」（プラグ）として設定されていましたが、私は「スイッチ」に変更しておきました。「照明」でも良いかもしれません。

Threadデバイスの種類を確認してみたところ、「ルーティングエンドデバイス」と記載されていて、ルーター適格エンドデバイス（REED）であることがわかります。
このデバイスをThreadの通信が届きにくい場所に設置することでThreadネットワークの範囲を広げたり、通信を中継したりことができます（Threadについて詳しく知りたい方はこちらの記事を参照）。

レビュー

良いと感じたところ

データの更新頻度が常に一定である

まず初めにALPSTUGAの良いと感じたところは、データの更新間隔が常に一定であるということです。

こちらのグラフは、私の部屋にあるすべての温度計（「メインデスク」と「バックデスク」はHomePod mini）のデータをまとめたグラフですが、ここに写っている緑色のSwitchBot ハブ2のデータをご覧ください。
ハブ2はSwitchBot 温湿度計 / 温湿度計プラスと同じセンサーを搭載しているようで最短更新頻度は4秒と記載されていますが、これは短期間に大きく値が変化した際のみに限り、値の変化が小さい場合はある程度時間が経たないと更新されません（バッテリー駆動の製品ではないのに…）。
つまり、値の変化が少ない場合、しばらく経ってもデータが更新されないことがあります。
私が持っているハブ2以外の温湿度計は一定間隔でデータが更新されますが、ハブ2にはせっかく高精度なセンサーを搭載している（らしい）のに、これではもったいないと常々思っていました。

しかし、ALPSTUGAは値の変化量にかかわらず、（値が少しでも変化すれば）常に10秒に1回はデータが更新されます（温度に限らず、搭載しているすべてのセンサーで10秒に1回更新される）。個人的にこれはうれしい仕様でした。データの更新間隔が比較的短いのも良いところです。

データの表示精度が高い

もう一つ良いと感じたところは、温湿度データの表示精度（取得できるデータの細かさ。データの精度ではない）が高いことです。

Home Assistantでのそれぞれのセンサーの表示精度は次のようになっていました。

• CO₂
  • デフォルト: 小数点第一位（0.1）
  • 最大表示精度: 一の位（1）
• PM_2.5
  • デフォルト: 小数点第一位（0.1）
  • 最大表示精度: 一の位（1）
• 温度
  • デフォルト: 小数点第一位（0.1）
  • 最大表示精度: 小数点第二位（0.01）
• 湿度
  • デフォルト: 小数点第二位（0.01）
  • 最大表示精度: 小数点第二位（0.01）

CO₂とPM_2.5は最大表示精度が一の位までとなっており一般的ですが、温度と湿度は小数点第二位まで取得できるのはとても良いと思いました。
私が持っている他の温度センサーは小数点第一位まで、湿度センサーは一の位までとなっており細かいデータを取得することができなかったのですが、ALPSTUGAは温湿度ともに小数点第二位まで取得することができるため、わずかな変化も検知することができます。

こちらは私の部屋に設置しているすべての湿度計のデータをまとめたグラフですが、先ほども言ったように他の湿度センサーは細かいデータが取れないため、グラフの線がガタガタとしているのがわかるかと思います。
一方、ALPSTUGAは他の湿度センサーと比べて100倍も細かいデータを取ることができるため、とてもなめらかな線になっています。

正直に言ってしまえば、ここまで細かいデータを取れたからといって何かの役に立つというわけではないですし、ほとんどの場合において必要性は全くないのですが、個人的にはもっと細かいデータを取ってみたいと思っていたため、うれしい仕様でした。
シビアな温度管理が求められるような動物を飼育している方などにもうれしいことでしょう。

時計表示機能が付いている

私はALPSTUGAをメインデスクに設置しているのですが、もともとデスクの近くに、電池切れの心配がない電源駆動のデジタル時計が欲しいと思っていました。
ディスプレイの上のほうには電池駆動のアナログ時計（電波式ではない）があり、パソコンでも時刻を確認することはできますが、フルスクリーンで作業したりゲームしたりしているときは物理的な時計があると何かと便利です。
ALPSTUGAには時計表示機能があり、おそらくインターネットに接続されている限りは常に正確な時刻が表示されるため、時刻がずれたり電池切れの心配をしたりする必要がないため、気が楽で結構便利です。
また、時計表示になっていてもCO₂やPM_2.5が基準値を超えている間は警告ランプが点灯するため、時計として使っている時でも換気すべきタイミングがわかるのもポイントです。

2026/1/13 追記:
USB電源を抜き差しした時など、本体の電源を入れ直すと、本体ディスプレイはデフォルトのCO₂表示に戻ってしまうようです（接続しているMacを再起動したときに気がついた）。
最後に選択していたディスプレイ表示を記憶してくれないのは少し残念でした（電源を入れ直したら毎回ボタンを押して表示を切り替える必要がある）。
Matterからディスプレイの表示内容を変更できればよかったのですが、そのような機能は今のところないようなので、今後のファームウェアアップデートに期待です。

やっぱりMatterなのは良い！

ALPSTUGAはMatterに対応していますが、やっぱりいいですね。
ペアリングはとても簡単ですし、Home Assistantでも発売初日からフル機能を使うことができます。
最近はMatterに対応したデバイスもかなり増えてきているため、スマートホームを始めたり、新たなデバイスを追加したりするための敷居がグッと下がってきた感じがしています。
IKEAは今後も、Matterに対応した低価格な照明デバイスやリモコンなども発売予定とのことですので、今後もさらにスマートホームが簡単になっていきそうです。
物価高の今、IKEAは日本で品質の高いスマートデバイスを最も安く手に入れられるメーカーではないでしょうか（私は購入しなかったものの、同時期に発売されたMatter対応水漏れセンサーのKLIPPBOK、開閉センサーのMYGGBETT、人感センサーのMYGGSPRAY、温湿度センサーのTIMMERFLOTTEはそれぞれたったの999円と安い！）。今後のさらなる製品ラインナップ拡充に期待です。

残念だと感じたところ

電源ケーブルが付属していない

最初に困ったことですが、電源ケーブルが付属していないとは思っていませんでした。
電源アダプタが付属していなくても個人的には問題ありませんが、せめてケーブルぐらいは付属していて欲しかったところです。
最近はあらゆる機器がUSB-Cを使用するため、我が家は深刻なUSB-Cケーブル不足ですw

ディスプレイの明るさを調節できない

ALPSTUGAには、現在の測定値や時刻を表示するためのディスプレイが搭載されていますが、残念ながらこのディスプレイの明るさを調節することはできないようです。
幸い、Home Assistantでアウトレットとして追加されるスイッチから点灯・消灯を切り替えることができるので、夜に部屋を真っ暗にして眠りたい方は、部屋の照明を切り替える時のオートメーションなどに組み込むことで自動的にディスプレイを切り替えることができます。

Matterの規格上、スイッチの代わりに調光機能付きの照明デバイスとして公開できるはずですので、今後のファームウェアアップデートに期待です。

粒子状物質がPM_2.5しか計測できない

先ほどハードウェアの部分で紹介した、ALPSTUGAに採用されているセンサーであるSEN63Cは仕様上、PM_1.0、PM_2.5、PM₄、PM₁₀の測定に対応しているようです。しかし、ALPSTUGAはこのうちのPM_2.5しか測定することができません。
これには何かやむを得ない理由があるのか、それとも価格を抑えるために意図的に行っている制限なのかは分かりませんが、PM_2.5以外が測定できないのは少し残念に思いました。
とは言え、私の場合は粒子状物質の測定ではなくCO₂の測定のために購入したので全く不満には思っていません。

今後、これらの測定機能が解放されるのかどうかは分かりませんが、今後のファームウェアアップデートに期待です。

さいごに

今回は、IKEAの新しい空気質センサー「ALPSTUGA」をご紹介しました。
初めは、CO₂の測定機能がついていて約3000円と安いため、どこかクオリティが低かったり安いなりの理由があるのだろうと考えていましたが、いざふたを開けてみると実際はそのような事はなく、安いのに良い製品であるというところに驚きました。
私はこれまでにも様々なスマートセンサーを購入してきましたが、これまでに私が購入したスマートセンサーの中では今のところ間違いなく、コスパや性能面でALPSTUGAが最も良い製品だと思っています。
手軽に部屋の空気質を測定してみたいと考えている方はALPSTUGAが間違いなくおすすめですので、購入を悩んでいる方はぜひ購入してみてください。

最後まで読んでくださりありがとうございました。それでは、また！

みなさんこんにちは、たいくんです。
いつの間にか、Home AssistantのSwitchBot Bluetooth統合でスマートサーキュレーターのサポートが追加されていることに気がついて購入してみたので、実際に使ってみてどんな感じなのか、簡易的なレビューをお届けします。

前置き

SwitchBot スマートサーキュレーターとは？

SwitchBot スマートサーキュレーターはSwitchBotから発売されている、その名の通りスマートフォンなどから操作可能なスマートファンです（ちょっとややこしいw）。
2023年末ごろに発売されたもので、特別新しい製品ではありません。

通信方法はBluetooth Low Energy（BLE）で、SwitchBot ハブ2などのハブと組み合わせることでスマートスピーカーから操作したり、外出先から操作したりできるようになります。
ちなみに、今回はHome Assistantと使うため、SwitchBotのハブがなくてもスマートスピーカーから操作したり、（Home Assistantサーバーを適切に外部に公開している場合に限るものの）外出先から操作したりすることができます。

今回購入したもの

SwitchBot スマートサーキュレーターにはバッテリー搭載で充電式の「SwitchBot スマートサーキュレーター」とバッテリー非搭載でAC電源接続式の「SwitchBot スマートサーキュレーター Lite」がありますが、今回はバッテリー搭載の方を購入しました。
これらの違いはバッテリーとUSB Type-Cコネクタを搭載しているかどうかの違いだけで、他に大きな違いは無いはずですので、どちらを選んでもHome Assistantで使用できると思います。

実際に使ってみる

開封とセットアップ

開封

軽く開封の様子をお届けします。
箱はこんな感じです。結構大きな箱です。後ろに置いてある27インチのiMacを見ていただくと大きさの感じがわかると思います。

箱から本体を取り出したところです。あまり大きさを調べずに買ったのですが、想像よりも一回り大きくてびっくりしました。

袋から取り出したところです。結構かっこいいデザインです。

本体の後ろ側です。底面にUSB Type-Cコネクタと電源ケーブルを接続するコネクタ、そして主電源のスイッチが付いていました。

付属品は電源ケーブルとリモコンのみです。リモコンはこんな感じで、非常にシンプルです。

このサーキュレーターは付属の電源ケーブルで充電する以外にも、USB Type-Cコネクタにお持ちのケーブルを接続することでもサーキュレーターを充電することができます。
外出先に持っていく際などは、わざわざ電源ケーブルを持っていかなくても普段使うケーブルで充電できるのは便利そうです。

SwitchBotアプリでのセットアップ

Home Assistantで使うだけであればSwitchBotのスマホアプリに登録しなくても使うことができますが、自分の場合はアプリでも使う可能性があるため、SwitchBotのアプリにも登録しておきました。

セットアップ自体はめちゃくちゃ簡単で、サーキュレーターの主電源を入れた後、操作パネルの運転切り替えボタンを2秒間長押しするとランプが点滅するので、その状態になるとアプリでサーキュレーターが検出され、すぐに登録されました。
このタイミングでHome Assistantの「発見」にもサーキュレーターが検出されていました。

アプリのホーム画面からサーキュレーターをタップするとこのような画面が表示されます。
運転切り替えボタンとモード選択ボタンが表示され、基本操作は簡単に行えます。

「操作設定」を開くとこのような画面が表示されます。サーキュレーターがオフの時は常夜灯以外の操作項目が非表示になります。

サーキュレーターをオンにすると、モード切り替えや風量、首振りの設定などが表示されるようになります。

首振りは上下と左右でそれぞれ設定することができ、首振りのオンオフ以外に、好きな方向に少しずつ動かしたり、中央に向けたりすることができます。

右上の歯車アイコンをタップすると、その他の設定を開くことができます。
ここからランプの点灯設定や操作時のビープ音を鳴らすかどうかといった設定を変更することができます。

「自動で中心に戻る」をオンにすると、サーキュレーターを止めたときに自動で中心を向くようになりますが、運転を止めるたびに正しい位置を検出するためにキャリブレーションが行われるようで、中心に戻って停止するまで少し時間がかかります。

Home Assistantでのセットアップ

Home Assistantへの登録もとても簡単です。
Home AssistantでBluetoothが使用できるようにしている必要がありますが、統合設定を開くと自動的に検出されたサーキュレーターが表示されるので、「追加」をクリックすると追加することができます。
追加の手順は必要ありません。

追加したデバイスには、以下の3つのエンティティが追加されるようです。

• ファン
• バッテリー残量センサー
  • スマートサーキュレーター Liteでは追加されない可能性が高いです。
• Bluetooth信号センサー
  • このセンサーはデフォルトで無効化されています。

ファンの詳細画面からは運転切り替えボタン、風量スライダー、プリセットモード一覧、首振りモード一覧が表示されます。

プリセットモード一覧には次のものが表示されます（画像はHome Assistant 2025.5なので英語ですが、2025.6では日本語で表示されます）。

• ノーマル
• ナチュラル
• スリープ
• 赤ちゃん

首振りモードは「はい」か「いいえ」のみでした。
首振りモードを「はい」にすると左右の首振りがオンになります。現時点では上下の首振りは設定できないようです。

Matterで追加してみた

SwitchBot ハブ2を持っているので、Matterで追加するとどのように表示されるのか確認してみました。

SwitchBotのアプリから設定するのですが、記事執筆時点では「ラボ機能（ベータ版）」として用意されていて、別の種類のデバイス（非ネイティブ型）として表示される機能を使って設定することができるようです。

実際に試してみたところ、オンオフのみが可能なスマートプラグとして表示されました。

HomeKitでも同様にスマートプラグとして表示されました。

Matter 1.2以降ではデバイスの種類として「ファン」が対応しているのですが、現時点でのSwitchBot ハブとスマートサーキュレーターの組み合わせではMatter 1.0か1.1までなのかもしれません（だからまだベータ版としての提供なのかも？）。
今後のファームウェアアップデートで最新のMatterに対応することを期待しています。

HomeKitでも操作できるようにする

Homebridgeのプラグインは記事執筆時点ではOpenAPIを使ったクラウド経由での制御にしか対応していないようなので、Home AssistantのHomeKit Bridge統合を使うことにしました（過去に作成したブリッジがあったため、既存のブリッジにファンを追加しました）。

詳しい方法については過去に記事を書いているので、そちらをご覧ください。

• 【ハブ2不要】HomeKit で SwitchBot 製品を制御する方法【Homebridge / Home Assistant】

ファンエンティティを1つ追加したところ、このように複数のスイッチが集まったアクセサリが1つ追加されました。
このままでは少し使いづらいので、アクセサリの設定画面にある「個別のタイルに表示」を選択してアクセサリを分けます。

すると、ファンのアクセサリと4つのスイッチに分かれるので、使いやすくなります。

追加されたスイッチはプリセットモードのスイッチで、HomeKitからプリセットを変更できるようです。
しかし、このままではスイッチが4つも追加されて少し邪魔なので、グループアクセサリに設定しました。

これにより、プリセットの変更は少し面倒になった（グループアクセサリの詳細からアクセサリ一覧を開いてプリセットを変更する必要がある）ものの、1つのスイッチアクセサリとして表示されるようになるため、表示されるスイッチの数を減らすことができます。
個人的にはプリセットを使う事はほとんどないため、特に問題はありません。
ちなみにグループアクセサリになっていても、グループ内のアクセサリ名を操作するようにSiriに頼めば、音声でプリセットを変更することができます（例えば「natural」のスイッチ名を「ナチュラルモード」に設定し、「Hey Siri、”ナチュラルモード”をオンにして」などと呼びかけて操作する）。

簡易レビュー

良いところ

ファンが静か

このサーキュレーターは動作音が非常に静かです。
風量にもよりますが、大体20%あたりぐらいまでであれば、少し離れれば風の音はほとんど聞こえなくなります。
また、風を強くすると風の音は大きくなりますが、耳障りな音ではないため、あまりうるさくないのがとても良いところだと思いました（エアコンの種類にもよると思いますが、私が使っている少し古いエアコンの風量を最大にしたときの方がうるさいと感じました）。

風を送る羽根もサーキュレーターとしては少し大きめなので、風量を低めにしても十分に風を感じることができるため、デスクに設置して静かな環境で涼しみながら作業を行うことができます。

風量を無段階で調節できる

このサーキュレーターは無段階で風量を調節することができます。
一般的なサーキュレーターでは風量が数段階しか変更できず、「強と中の間くらいの風が欲しい」と思ってもちょうどいい具合に調節することができませんが、このサーキュレーターではアプリから1%単位で風量を調節することができます。
そのため、簡単にお好みの風量に調節できるのが良いところだと感じました。

先ほど、「風量を低めにしても十分に風を感じることができる」と紹介しましたが、細かく風量を変更できるため、非常に弱い風に設定することもできます。
そのため、「直接風が当たるのは好きじゃないけど、ほんの少しだけ空気の流れが欲しい」といった場合でも対応できます。
また、プリセットの1つである「赤ちゃん」モードにすれば風が非常に弱くなるため、ほんのかすかな風が欲しい場合にちょうど良いでしょう。

最大にするとそこそこ風が強い

風量を最大にすると、あまりうるさくないのにもかかわらず、そこそこ強い風が出てきます。
もっとコンパクトでより強い風が出るサーキュレーターはありますが、ほとんどの場合はそんなに強い風を出す必要は無いため、これだけの風が出てくれば個人的には十分だと思います。
このサーキュレーターは羽根が大きめなこともあり、結構遠くまで強い風を運ぶことができるため、ただ風が強いサーキュレーターよりも部屋の空気を均一にすることができているような感じがしました。

首振りの位置を細かく制御できる

このサーキュレーターは横の首振りと縦の首振りの2種類があり、一般的なサーキュレーターでは首振りをするかしないかの2択でしか設定できないものが多いですが、このサーキュレーターはアプリから向きを細かく変更することができるのが便利だと思いました。
特に、私は重度の身体障害を持っているため自分の手で風の向きを変えることができないのですが、このサーキュレーターであればアプリから好きな方向に変更できるため、大変便利だと感じました。

残念なところ

操作の反応が悪い時がある

この問題はこのサーキュレーターを初めて使ったときにすぐに気づいたことですが、ネットワーク経由から操作したときに反応が悪いことがあります。

これはSwitchBotのアプリからでもHome Assistantからでも同じですが、最後の操作から少し時間が経ってから操作しようとすると、サーキュレーターに接続するまでに少し時間がかかります。
大体、操作を行ってから3〜5秒ほどかかることが多いです。

一度操作を行ってしまえば直近の操作はスムーズに行くことが多いですが、それでも時々反応がつっかかるような感じがあります（ごく稀ではあるものの、ひどいときには30秒近くかかることもある）。
実は、この問題はHome AssistantでSwitchBot ボットを使っているときにも起こっていますが、この反応の悪さは地味にストレスを感じる問題です。
特に、設定でビープ音をオフにしていて、音声で操作したときに反応が悪いと操作に成功したのか失敗したのかがわかるまで時間がかかるため、結構イラッとする時があります。

このサーキュレーターを操作する際、Bluetoothアダプタの接続スロット割り当てモニターを見ていると接続スロットが使用されていることがわかりました。
つまり、このサーキュレーターはアクティブな接続を必要とするデバイスであり、しばらく操作していないとアクティブな接続が切断されるため、再接続するのに少し時間がかかっているようです。

SwitchBot ボットを操作するときにも確認してみたところ、やはり同じく接続スロットが割り当てられていたため、こちらも反応が悪いのは同じような理由である可能性が高いです。

どちらもバッテリー駆動のBluetoothデバイスであるため、仕方がないことなのかもしれません…

電源ケーブルが抜き差ししづらい

このサーキュレーターの電源コネクタは底面についているため、ケーブルを抜き差しするにはサーキュレーターを持ち上げる必要があります。
しかも、コネクタは結構奥にあるため、かなり抜き差ししづらいです。
そのため、せっかくバッテリーがついていてどこでも使えるのがメリットなのに、ケーブルが抜き差ししづらいせいであまり頻繁に持ち運びたいとは思えません。

コネクタを抜き差ししやすい場所に移動させるか、専用の充電台のようなものがあるとより便利になるだろうと思いました。

ビープ音が大きい

デフォルトではサーキュレーターを操作したときにビープ音が鳴りますが、この音が結構大きいです。
設定を変更するたびに大きな音が鳴るため、細かい調節時にかなりうるさく感じます。
そのため、私はアプリの設定から音を鳴らないように設定しました。

設定では音を鳴らすか鳴らさないかのどちらかしか設定できないため、音量を変更することができたら良いと思いました。

首振りがあまり下を向かない

このサーキュレーターは横の首振りに加え、縦の首振り機能にも対応していますが、上方向では真上まで向くことができるものの、下方向の場合は真正面よりわずかに（2〜3°ぐらい？）下までしか向きません。
高い場所に設置した際、下方向に風を送ることが全くできないため、せめて斜め下ぐらいまで向いて欲しいところです。

首振りが遅い

サーキュレーターは部屋の空気をかき混ぜるためのものなので首振りが遅いのはある意味正常だとは思いますが、もう少し首振りの速度を速くするか、アプリで速度を調節できたら良いと思いました。
一般的な扇風機よりもかなり遅いため、目的の方向に動かすまで少し時間がかかります。
あまり大きな問題ではありませんが、少し気になるところです。

首振りの位置をプリセットで設定できると良い

このサーキュレーターはアプリから首振りの位置を細かく制御することができますが、設定した位置を記録して、ワンタップでその位置に動かせるようにする機能があったら良いと思いました。
設定で「自動で中心に戻る」機能をオンにすると、運転停止時に中心点を見つけるためのキャリブレーションが行われますが、この機能を応用すれば向きを保存して後からその向きに変更することができると思うので、そのような機能が追加されたら大変便利になるだろうと思いました。

Home Assistantで操作できる項目が少ない

これはこのサーキュレーターの問題というよりもHome Assistantの統合の問題ですが、記事執筆時点では基本操作のみで、縦の首振りなどを操作したり、動作の設定を行ったりすることができません。
このサーキュレーターがHome Assistantでのローカル制御に対応したのは最近なのでまだ機能が少ないのは仕方がないことだとは思いますが、今後のアップデートで操作できる項目が増えることに期待しています。

最近のSwitchBotはHome Assistantへの対応を強化しているようなので、そう遠くないうちに対応してくれると嬉しいですね。

Bluetoothのセキュリティ機能がない（重大）

最後に、重大な問題点をご紹介します。
このサーキュレーターはBluetoothを使って操作を行いますが、Bluetoothの通信に暗号化が行われていないため、特別なペアリングなしにサーキュレーターを登録することができてしまいます（ペアリングモードにしなくても、別のHome Assistantインスタンスに検出され、登録・操作できてしまうことを確認しました）。
つまり、サーキュレーターが発するBluetooth信号の範囲内に悪意のあるユーザーがいた場合、勝手に登録されて操作されてしまう危険性があります。
誰でも登録して制御することができてしまうため、かなり重大な問題だと言えるでしょう。

同じくBluetoothを使って制御するSwitchBot ロックシリーズには暗号化機能があり、暗号化キーがないとBluetooth信号の範囲内にいても操作することはできませんが、このサーキュレーターにも同様の暗号化機能が追加されると安心して使えるようになると思いました。

さいごに

今回は、SwitchBot スマートサーキュレーターをHome Assistantで使ってみた結果と簡易的なレビューをお届けしました。

まだ少しの間しか使っていないため、後からさらに良いところや残念なところなどが出てくるかもしれませんが、この記事を書いている段階では「そんなに悪くない製品」だと思っています。
この記事では残念なところの方を多く書いていますが、実際に使っている感じだと多くは重大な問題ではないですし、そもそもローカル制御できるスマートファン自体がかなり少ないですから、それだけでも大きな利点だと思います。
唯一、Bluetoothのセキュリティ機能がないのは最も残念なところではありますが、今後のファームウェアアップデートによって暗号化機能が追加されることを期待しています。

一切クラウドを使わずに制御できて入手性の高いスマートファンをお探しの方は購入されてみてはいかがでしょうか。

最後まで読んでくださりありがとうございました。それでは、また！

みなさんこんにちは、たいくんです。
Home Assistantには登録されたデバイスの履歴を保存する機能があり、温度や湿度などのグラフを見ることができて大変便利ですが、長期統計を保存しておくのには向いていません。
そのため、この記事ではデータベースの「VictoriaMetrics」に長期統計データを保存し、データ視覚化ツールの「Grafana」を使って記録された長期統計を表示する方法を紹介します。

Home Assistantの統計データをVictoriaMetricsに保存するメリット・デメリット

そもそもHome Assistantのデータベースは統計の長期記録に向いていない

Home Assistantはデフォルトのデータベースエンジンに「SQLite」を使用しています。
Recorder統合を通してデータベースに統計データを記録しており、特に何も設定しなくても自動的にデータが記録されていきます。

デフォルトでは、データベースの容量が肥大化しないように、10日間で「パージ」（切り離し）が行われ、「長期統計」に移行します。
長期統計に移行したデータは、Home Assistantの履歴ページでは薄い色のグラフで確認することができます。

長期統計と通常統計の境目を拡大してみるとわかりますが、長期統計のデータは容量が大きくならないよう、間引かれたデータになっています。
長期統計データは基本的に、1時間ごとにサンプリング・平均化されたデータとなっています。

長期統計データは、センサーの「state_class」属性が「measurement」か「total」、または「total_increasing」のいずれかに設定されている場合のみ記録されるため、すべてのセンサーデータが長期統計に保存されるわけではありません。

また、長期統計に記録されるセンサーでも、CPU使用率のような高頻度に更新されるセンサーの場合は間引かれる範囲がとても大きくなってしまう場合があり、古いデータを見たいときに役に立たないこともあります。

このように、Home Assistantの長期統計データは広い範囲のデータの平均値を見たい場合に最適化されており、狭い範囲のデータを見る用途には向いていません。

VictoriaMetricsに保存するメリット

VictoriaMetricsには間引かれていないデータが長期保存される

これは、先ほどHome Assistantの履歴ページで表示していたものと同じ温度センサーの、VictoriaMetricsに保存したデータをGrafanaで表示したものです。

長期統計に切り替わる境目に拡大してみると、こんな感じで間引かれていないグラフになっているのがわかると思います（同じ数値が連続している場所では線が途切れていますが、つなげて表示させることも可能です）。

さらに、より古いデータを拡大して見てみても、間引かれていない完全なデータが記録されているのがわかります。

先ほど確認した、Home Assistantの長期統計では使い物にならなかったCPU使用率のセンサーも、このようにきちんと記録されています。

古いデータを拡大して見てみても、すべてのデータが正しく記録されています。

このように、VictoriaMetricsでは完全なデータを長期間保存しておくことができます。

データベースが軽量

これは、2024年3月7日からデータを保存しているHome Assistantのデータベース情報です。
「推定データベースサイズ (MiB)」のところに推定容量が記載されていますが、非常に多くのセンサーやエンティティを登録していることもあり、「10269.66 MiB」つまり約10.2GiB（約11GB）ほどの容量となっています。
Recorder統合の設定はデフォルトのまま、つまり10日以上経過した古いデータが間引かれているにもかかわらずこの容量ですので、結構大きいですよね。

データベース容量を確認する方法（クリックで開閉）

お使いのHome Assistantのデータベース使用量を確認するには、Home Assistantの「設定」→「システム」→「修復」と進むか、以下のボタンから修復設定を開きます。

その後、右上の「…」から「システム情報」をクリックすると様々なシステム情報が表示され、その中の「Recorder」セクションからデータベース容量を確認することができます。

---

一方こちらは、2024年1月31日からデータを保存しているVictoriaMetricsのデータフォルダ情報です。
一切データが間引かれておらず、Home Assistantのデータベースよりも圧倒的に多くのデータが保存されているのにもかかわらず8.72GB（約8.1GiB）と、データの圧縮効率が非常に高いのがわかるかと思います。

Home Assistantの履歴ページでは広い範囲の統計を表示しようとすると読み込み画面が表示されてしばらく時間がかかりますが、VictoriaMetricsに保存したデータは軽量なので、広い範囲の統計を表示してもあまり待たされずに表示させることができます。

VictoriaMetricsのデメリット

データが二重に記録されるためストレージ容量を消費する

VictoriaMetricsはHome Assistantのデータベースを置き換えるわけではないため、Home AssistantのデータベースとVictoriaMetricsの二重にデータが記録されます。
そのため、小さいストレージで使用している場合、記録するデータが増えるにつれてストレージを圧迫してしまう可能性があります。

Home Assistantの履歴ページでは保存されたデータを確認できない

先ほども言ったように、Home Assistantのデータベースとは別に記録しているため、VictoriaMetricsに保存されたデータを確認するにはGrafanaなどのツールを使う必要があります。
Home AssistantのネイティブUI（履歴ページなど）からはHome Assistantのデータベースしか確認できないため、長期統計を確認するには一手間増えてしまうことになります。

数値データしか記録できない

VictoriaMetricsは仕様上、数値データの記録にしか対応していません。
そのため、アップタイム（稼働時間）センサーのようなテキスト情報や時間情報などを含むセンサーやボタンなどの記録をVictoriaMetricsに保存することはできません。
ただし、スイッチやバイナリセンサーなどは、状態を0（オフ・未検知）と1（オン・検知）の数値としてデータを記録することができます。

Home Assistantでは数値以外のセンサーどころか、スイッチやバイナリセンサーなどの長期統計も記録することができず、それと比べれば記録できる情報ははるかに増えますので、そこまで大きなデメリットでは無いかもしれません。

逆に言えば、数値データであれば何でも記録できることから、例えば電球のオン・オフ状態、明るさ、色温度などといった様々なデータを記録することもできるため、メリットと捉えることもできます。

統計データをVictoriaMetricsに保存するように設定する方法

VictoriaMetricsを設定する

VictoriaMetricsアドオンをインストールする

まずはVictoriaMetricsを実行するためのアドオンをインストールします。
アドオンが使用できないHome Assistantをご利用の場合は、Dockerコンテナなどを使ってVictoriaMetricsをインストールしてください。
この記事ではアドオンを使用する方法を解説します。

VictoriaMetricsアドオンはデフォルトのリポジトリには含まれていないため、VictoriaMetricsアドオンのリポジトリを追加する必要があります。
以下のボタンをクリックすることで追加できます。

手動でリポジトリを追加する方法（クリックで開閉）

Home Assistantの「設定」→「アドオン」→「アドオンストア」と進むか、以下のボタンからアドオンストアにアクセスします。

アドオンストアにアクセスしたら右上の「…」から「リポジトリ」をクリックします。

「追加」欄に次のURLを入力し、「追加」ボタンをクリックします。

https://github.com/VictoriaMetrics-Community/homeassistant-addon-victoriametrics

このように表示されればリポジトリの追加は完了です。

---

リポジトリが追加できたらページを再読み込みするとVictoriaMetricsアドオンが表示されるはずですのでインストールします。

アドオンがインストールできたらアドオンの設定ページを開き、「Retention」の設定を確認します。
これはデータの保存期間を決める設定項目で、デフォルトでは「99y」（99年間）に設定されているので、変更したい場合はここで変更して設定を保存します。
特に変更する必要がない場合はこのままでも問題ありません。

設定が終わったらアドオンを起動します。
「起動時に開始」と「ウォッチドッグ」をオンにしておくことをおすすめします。

アドオンが起動したら、アドオンの「ホスト名」を後で使用するため、どこかにメモしておきます。

InfluxDB統合を設定する

Home Assistantの統計データをVictoriaMetricsに送信するには、InfluxDB統合を使用します。
VictoriaMetricsはInfluxDBと互換性があるため、この統合を使用することができます。

InfluxDB統合を設定するには、configuration.yamlに以下のコードを記述します。

influxdb:
  api_version: 1
  host: アドオンのホスト名
  port: 8428
  max_retries: 3
  measurement_attr: entity_id
  tags_attributes:
    - friendly_name
    - unit_of_measurement
  ignore_attributes:
    - icon
    - source
    - options
    - editable
    - min
    - max
    - step
    - mode
    - marker_type
    - preset_modes
    - supported_features
    - supported_color_modes
    - effect_list
    - attribution
    - assumed_state
    - state_open
    - state_closed
    - writable
    - stateExtra
    - event
    - friendly_name
    - device_class
    - state_class
    - ip_address
    - device_file
    - unit_of_measurement
    - unitOfMeasure
    - color_mode
    - hs_color
    - rgb_color
    - xy_color
    - hvac_action
    - value
    - writeable
    - attribution
    - dataCorrect
    - dayname
  include:
    domains:
      - sensor
      - binary_sensor
      - light
      - switch
      - cover
      - climate
      - input_boolean
      - input_select
      - number
      - lock
      - weather
  exclude:
    entity_globs:
      - sensor.clock*
      - sensor.date*
      - sensor.glances*
      - sensor.time*
      - sensor.uptime*
      - sensor.dwd_weather_warnings_*
      - weather.weatherstation
      - binary_sensor.*_smartphone_*
      - sensor.*_smartphone_*
      - sensor.adguard_home_*
      - binary_sensor.*_internet_access

「アドオンのホスト名」には、先ほど確認したホスト名を入力します。
例えば、先ほどの画像の場合は「1bd4a9fb-victoria-metrics」と入力します。

これらの設定はあくまで一例です。保存したいデータに合わせて「include」（VictoriaMetricsに送信するものに含めるデータ）や「exclude」(VictoriaMetricsに送信するものから除外するデータ）などの設定を変更してください。

influxdb:
  api_version: 1
  host: xxxxxxxx-victoria-metrics
  port: 8428
  max_retries: 3
  measurement_attr: entity_id
  tags_attributes:
    - friendly_name
    - unit_of_measurement
  ignore_attributes:
    - icon
    - source
    - options
    - editable
    - min
    - max
    - step
    - mode
    - marker_type
    - preset_modes
    - supported_features
    - supported_color_modes
    - effect_list
    - attribution
    - assumed_state
    - state_open
    - state_closed
    - writable
    - stateExtra
    - event
    - friendly_name
    - device_class
    - state_class
    - ip_address
    - device_file
    - unit_of_measurement
    - unitOfMeasure
  include:
    domains:
      - sensor
      - binary_sensor
      - light
      - switch
      - cover
      - climate
      - input_boolean
      - input_select
      - input_number
      - number
      - lock
      - weather
  exclude:
    entity_globs:
      - sensor.clock*
      - sensor.date*
      - sensor.glances*
      - sensor.time*
      - sensor.uptime*
      - sensor.dwd_weather_warnings_*
      - weather.weatherstation
      - binary_sensor.*_smartphone_*
      - sensor.*_smartphone_*
      - sensor.adguard_home_*
      - binary_sensor.*_internet_access

設定できたら、右上の赤い保存ボタンをクリックして設定を保存し、Home Assistantを再起動します。

VictoriaMetricsに正しくデータが送信されていることを確認する

Home Assistantが起動したら、VictoriaMetricsアドオンのWeb UIを開き、上の「Query」欄に任意のエンティティIDを入力します。
VictoriaMetricsに送信されるエンティティIDの最後にはエンティティの属性が追加されるので、入力するエンティティIDの最後にはそのエンティティの数値状態であることを表す「_value」をつけます。
エンティティIDを入力する際、「Autocomplete」をオンにしておくことで入力中に候補が表示されるようになるので、そこを選択することで自動的に補完することができます。
入力できたら、「EXECUTE QUERY」をクリックして、グラフが正しく表示されることを確認します

グラフが正しく表示されれば、Home Assistantのデータが問題なくVictoriaMetricsに送信されていることを表しています。
グラフが表示されない場合、InfluxDB統合の設定が間違っている可能性がありますので、もう一度確認してみてください（特にホスト名）。

Grafanaを設定する

Grafanaアドオンをインストールする

正しくデータが記録されていることを確認したら、次はGrafanaを実行するためのアドオンをインストールします。
アドオンが使用できないHome Assistantをご利用の場合は、Dockerコンテナなどを使ってGrafanaをインストールしてください。
この記事ではアドオンを使用する方法を解説します。

Grafanaアドオンは、デフォルトのHome Assistant Community Add-onsリポジトリに含まれているので、リポジトリを追加することなくアドオンをインストールすることができます。

Grafanaアドオンをインストールするには、Home Assistant「設定」→「アドオン」→「アドオンストア」と進んでGrafanaを探すか、以下のボタンからアドオンのページを開き、インストールしてください。

インストールできたらアドオンを起動します。
「起動時に開始」と「ウォッチドッグ」、「サイドバーに表示」をオンにしておくことをおすすめします。

アドオンが起動したらWeb UIを開きます。

データソースを追加する

VictoriaMetricsに保存されたデータをGrafanaで表示できるようにするために、GrafanaとVictoriaMetricsを接続します。

左上のGrafanaロゴをクリックするとメニューが開くので、「Connections」内の「Add new connection」をクリックします。

VictoriaMetricsとの接続には、VictoriaMetricsと互換性のあるPrometheusのプラグインを使って接続するので、データソースとして「Prometheus」を追加します。

データソースに「Prometheus」を選択するとこのような画面が表示されるので、右上の「Add new data source」ボタンをクリックします。

データソースの設定画面が表示されるので、「Name」欄には「VictoriaMetrics」や「Home Assistant」などのわかりやすい名前を入力し、「Prometheus server URL」には以下のURLを入力します

http://homeassistant.local:8428/prometheus

「homeassistant.local」の部分はHome AssistantサーバーのIPアドレスでも構いません。

正しく入力できたら、最も下にある「Save & test」をクリックし、「Successfully queried the Prometheus API.」と表示されればデータソースの接続確認と設定は完了です。
何かエラーが表示された場合は、URLが正しいことをご確認ください。

データが取得できることを確認する

データソースが追加できたら、VictoriaMetricsに保存されているデータがGrafanaで正しく表示できることを確認します。
Grafanaのメニューを開き、「Explore」ページを開きます。

これがExploreページです。この画面から、データソースに保存されたデータを簡単に確認することができます。

右側の「Metric」のところにある「Select metric」欄に先ほどVictoriaMetricsのWeb UIに入力したものと同じエンティティIDを入力します。
入力中に候補が表示されるので、そちらを選択すると簡単です。

このような画面になっていれば準備は完了です。右上の青い再読み込みボタン（「Run query」ボタン）を押してみましょう。

このように、下のほうにグラフが表示されれば正しくデータが取得できています。
この画面ではデータが更新されても自動的にグラフが更新されないため、グラフを更新するにはもう一度再読み込みボタンを押します。
再読み込みボタンの右側にあるボタンから、一定時間ごとにグラフの表示を更新する自動更新機能をオンにすることができます。

ダッシュボードを作成してパネルを設定する

このままではデータを確認するために手間がかかりますので、よく確認するデータをすぐに表示できるように、ダッシュボードを作成しましょう。

ダッシュボードを作成するには、Grafanaのメニューから「Dashboards」ページを開き、「Create dashboard」ボタンまたは右上の「New」から「New dashboard」ボタンをクリックします。

新しいダッシュボードの設定画面が表示されるので、「Add visualization」ボタンまたは右上の「Add」から「Visualization」ボタンをクリックします。

データソースの選択画面が表示されるので、先ほど設定したデータソースを選択します。

Visualizationパネルの設定画面が表示されるので、設定していきます。

パネルの設定画面では、左上にパネルのプレビュー、左下にクエリの設定、右側にパネルの設定が表示されます。

クエリの設定は、先ほどExploreページでテストした時と同様に設定することができます。
1つのパネルに複数のグラフを表示したい場合は、下のほうにスクロールして「Add query」ボタンからクエリを追加することで実現できます。

パネルに表示される凡例名を変更する

デフォルトでは、凡例に表示される名前が非常に長く、人間にとってわかりづらいものとなっているため、人間が読みやすいよう、Home Assistantで設定したエンティティ名に変更してみましょう。
凡例にエンティティ名を表示するには次の2つの方法があります。

1. クエリの設定から表示を変更する
   • 1つのメトリックに対して表示を変更できます。
     複数のクエリがある場合、クエリごとに設定を行う必要があります。
2. パネルの設定から表示を変更する
   • すべてのクエリに対して一括で表示を変更できます。

クエリの設定から表示を変更するには、クエリ設定にある「Options」を開き、「Legend」を「Auto」から「Custom」に変更し、次のように入力します。

{{friendly_name}}

これで、凡例の名前がわかりやすいものに変わっているはずです。
Home Assistantでエンティティ名を変更すると、こちらにも反映されます。

パネルの設定から表示変更するには、パネルの設定を下のほうにスクロールし、「Standard Options」内にある「Display name」に、次のように入力します。

${__field.labels.friendly_name}

これで、凡例の名前がわかりやすいものに変わっているはずです。
Home Assistantでエンティティ名を変更すると、こちらにも反映されます。

これで、凡例の名前を変更することができました。

パネルに表示されるグラフの見た目を変更する

デフォルトでは、このようにシンプルな折れ線グラフが表示されるようになっています。
同じ数値が連続する場合、グラフの線がつながらずに途切れた表示になっているため、少しわかりづらいかもしれません。

グラフを途切れさせずにつながった表示にするには、パネルの設定の「Graph styles」内にある「Connect null values」を「Always」に変更します。
これで、同じ値が連続している場所でもグラフの線をつなげて表示させることができます。
「Always」の代わりに「Threshold」に変更することで、「一定時間以内の間に同じ値が連続している場合のみつなげる」（例えば、1時間まで同じ値が連続している場合はグラフを繋げ、1時間以上同じ値が連続している場合は途切れさせる）といった設定を行うことも可能です。

また、デフォルトでは「データの点」を尖った山または谷として表示するシンプルな折れ線グラフになっていますが、Home Assistantの履歴ページに表示されるグラフのようなカクカクした表示に変更することもできます。

グラフの形を変更するには、パネルの設定の「Graph styles」内にある「Line interpolation」を最も右にある「Step after」（「⤴︎⤵︎」のような形のアイコン）に変更します。
これで、グラフの形がHome Assistantの履歴ページに表示されるものと同じ表示になり、わかりやすくなりました。

ダッシュボードを保存する

パネルの設定が終わったら、上にある「Back to dashboard」ボタンをクリックします。

すると、設定したパネルがダッシュボードに表示されるので、大きさの変更や並び替えを行ったり、新たなパネルを追加したりしてカスタマイズします。

右上にある時計のアイコンから、グラフを表示する期間を変更することができます。

また、グラフ上で表示したい範囲をドラッグアンドドロップすることでその範囲を拡大することもできます。

ちなみに、「Refresh」ボタンの右側にあるボタンからグラフの自動更新間隔を変更することができます。
デフォルトでは自動更新がオフになっていますが、自動更新を設定しておけば、わざわざ「Refresh」ボタンをクリックしなくても定期的にグラフが更新されますので、設定しておくと良いでしょう。

カスタマイズが終わったら、右上の「Save dashboard」ボタンをクリックしてダッシュボードを保存しましょう。

「Title」欄にお好みの名前をつけ、「Save」をクリックすることでダッシュボードを保存することができます。

ダッシュボードのカスタマイズ後に変更を保存する際、そのままではデフォルトのグラフ表示期間（そのダッシュボードを開いたときにデフォルトで選択されているグラフ表示期間）を変更しても保存されない（パネルやレイアウトの変更しか保存されない）ので、デフォルトのグラフ表示期間を変更するには保存画面で「Update default time range」にチェックを入れてから保存します。

作成したダッシュボードにアクセスする

Grafanaを開いたときに表示されるホーム画面では、左側の「Dashboards」から最近開いたダッシュボードを再び開くことができます。
よく使うダッシュボードは、そのダッシュボードの右側にある星のアイコンをクリックすることで、「Starred dashboards」（星をつけたダッシュボード）セクションに常に表示されるようになります。

ホーム画面には最近開いたダッシュボードか星をつけたダッシュボードしか表示されないため、すべてのダッシュボードにアクセスするには、メニューから「Dashboards」ページを開きます。
すると、保存されているダッシュボードの一覧が表示されるため、そこからダッシュボードを開くことができます。

私のダッシュボード

参考までに、私が使用しているダッシュボードをご紹介します。

私は主に、自分の部屋の温湿度を確認することが多いため、温湿度のみをまとめたダッシュボードを使用しています（他のデータはあまり確認しないので、確認したい時になったらExploreページで確認しています）。

左側には大きなグラフを配置しており、右側には現在の温湿度を表示する小さなカードを並べています。
右側に並べている小さなカードは、しきい値によって色が変わるようにしていて、温湿度が高くなった・低くなった際に気づきやすくしています。

このように、古い統計データもきちんと残っています。

注意

エンティティを削除すると統計データも削除される

Home Assistantからエンティティを削除してしまうと、Home Assistantのデータベースだけでなく、VictoriaMetricsからもデータが削除されてしまう場合があります。
そのため、残しておきたいエンティティのデータがある場合は、そのエンティティは削除せずに残しておきましょう。

エンティティの種類によっては、そのエンティティが設定されているデバイスが利用できなくなったときに自動的に削除されてしまう場合があります（レガシー統合など）。
そのようなデータは、あらかじめCSVファイルなどにエクスポートしておくようにしましょう。
ファイルをエクスポートしておけば、VictoriaMetricsから削除されて利用できなくなったデータでもファイルとして残しておくことができます。
この記事では解説しませんが、Grafanaの公式ブログ（英語）で、CSVファイルとしてエクスポートする方法が紹介されているので、確認してみてください。

さいごに

今回は、Home AssistantでVictoriaMetricsとGrafanaを組み合わせて、長期統計を保存し、表示する方法をご紹介しました。
過去の統計データを確認する機会はあまり多くないかもしれませんが、過去のデータを過去にさかのぼって記録することはできないため、将来的に過去のデータを確認できるように記録し続ける事が非常に重要です。
特に、過去のエネルギー使用量などは非常に大事なデータですので、いつまでも自宅のデータを残しておくようにしましょう。

最後まで読んでくださりありがとうございました。それでは、また！

みなさんこんにちは、たいくんです。
HomePodに内蔵されている温湿度センサーの情報をHome Assistantに統合できたら便利だなと思った事はありませんか？
この記事では、HomePodに内蔵された温湿度センサーの情報をHome Assistantに送信して、Home Assistantに統合する方法をご紹介します。

特別なHomeKitアクセサリ

HomePodシリーズはHome Assistantとペアリングできない唯一のHomeKitアクセサリ

HomePod（第2世代）とHomePod miniには温湿度センサーが内蔵されており、他のHomeKit対応温湿度センサーと同様の手順で温湿度を確認することができます。
しかし、HomePodシリーズは他のHomeKitアクセサリとは異なり、初期化以外でペアリングを解除することができず、初期化したとしてもApple製品でセットアップする必要があり、センサー単独でペアリングを行うことができません。
そのため、他のHomeKitアクセサリのように、「HomeKitデバイス統合を使ってHome Assistantとペアリングし、HomeKit Bridge統合を使ってHomeKitと共有する」といった使い方ができません。

HomePodシリーズは「ホームハブ」として機能するため「HomeKitの基盤」としての側面が強く、内蔵センサーはあくまでアクセサリというよりも「付随するもの」、つまり、言ってしまえば「おまけ機能」であるため、他のHomeKitアクセサリとは扱いが大きく異なるのです。

ちなみに、メディアの操作やAirPlay 2の操作についてはHomeKitとは独立しているため、Home AssistantのApple TV統合で制御することができます。

Home Assistantにセンサー情報を送信する方法

HomeKitから情報を送信する方法を取る

先ほど説明したように、HomePodシリーズはHome Assistantと直接ペアリングすることができません。
そのため、Home Assistantと直接ペアリングするのではなく、HomeKitのオートメーション機能を使って、HomePodシリーズのセンサー情報を定期的にHome Assistantに送信するというアプローチを取ります。
実際にこのアプローチでHome Assistantに統合している方を見つけましたので、この記事では最新バージョンで利用可能な手順に変更し、より詳しく解説していきます。

Home Assistantには「REST API」機能があり、Home Assistantと直接通信できないデバイスでも、API機能の1つを使ってデータを送信することでHome Assistantに統合することができます。

APIの準備

REST APIを使用できるようにする

デフォルトではREST API機能が有効になっていないため、API統合を設定して、REST APIを使えるようにします。

API統合はconfiguration.yamlから設定する必要がありますが、とても簡単です。

File editorアドオンがインストールされている場合は、File editorアドオンを開き、左上のフォルダアイコンをクリックしたら「configuration.yaml」をクリックして開きます。

configuration.yamlを開くことができたら、お好みの場所に以下のコードをインデント（先頭のスペース）なしで記述してください。

api:

記述できたら、右上の赤い保存ボタンをクリックし、Home Assistantを再起動します。
これで、API統合の設定は完了です。

アクセストークンを取得する

次は、REST APIで使用するアクセストークンを取得します。

左下のユーザー名をクリックしてユーザー設定から「セキュリティ」と進むか、以下のボタンからセキュリティ設定を開きます。

次に、一番下にスクロールし、「長期間有効なアクセストークン」のところにある「トークンの作成」をクリックします。

アクセストークンに「HomeKitセンサーの更新」などのようなわかりやすい名前をつけ、「OK」をクリックします。

アクセストークンが表示されるので、どこか安全な場所にコピーしておきます。
このトークンは一度しか表示されないのでご注意ください。

これで、REST APIを使用する準備ができました。

なお、アクセストークンは厳重に管理してください。作成したトークンが外部に流出すると、流出したトークンを使ってHome Assistantを不正に操作されてしまう危険性があります（特に、Home Assistantサーバーを外部に公開している場合）。
また、全く使っていないアクセストークンがある場合は残しておかず、削除するようにしましょう（使っているアクセストークンを削除してしまうと、そのトークンを使っているサービスが正常に動作しなくなり、再設定が必要になります）。

切り替えヘルパーを設定する

切り替えヘルパーを作成する

HomeKitのオートメーションをトリガーするために使用する切り替え（真偽値入力 / Input boolean）ヘルパーを作成します。

Home Assistantの「設定」→「デバイスとサービス」→「ヘルパー」と進むか、以下のボタンからヘルパー設定を開きます。

ヘルパー設定を開いたら、右下の「ヘルパーを作成」をクリックします。

ヘルパーの作成画面が表示されたら、「切り替え」を選択します。

お好みの名前とアイコンを設定します。
名前は「HomeKitセンサーの更新」のようなわかりやすいものに設定しておくことをおすすめします。
設定したら右下の「作成」をクリックします。

切り替えヘルパーが作成できたら、作成したヘルパーの設定からエンティティIDを「update_homekit_sensors」のようなわかりやすいものに変更しておくことをおすすめします。

作成したヘルパーをHomeKitに公開する

後でHomeKitのオートメーションで使うために、HomeKit Bridge統合を使って、先ほど作成した切り替えヘルパーをHomeKitに公開します。

Home Assistantの「設定」→「デバイスとサービス」と進んで「HomeKit Bridge」統合を検索するか、以下のボタンからHomeKit Bridge統合の設定を始めます。

「含めるドメイン」には「Input Boolean」を選択して、右下の「送信」をクリックします。

統合が作成できたら作成した統合の設定を開き、「インクルージョンモード」を「include」に変更して、右下の「送信」をクリックします。

「含めるエンティティを選択」では、先ほど作成した切り替えヘルパーを追加して、右下の「送信」をクリックします。

通知を開くとこのような画面が表示されるので、iPhoneやiPadを使ってHomeKitとペアリングします。

ペアリングした後にこのようなスイッチが追加されていれば問題ありません。

オートメーションを設定する

先ほど作成したヘルパーを切り替えるオートメーションを作成する

次は、HomeKitのオートメーションを自動的にトリガーするため、先ほど作成したヘルパーを定期的に切り替えるHome Assistantのオートメーションを作成します。

Home Assistantの「設定」→「オートメーションとシーン」と進むか、以下のボタンからオートメーションの設定を開きます。

オートメーションの設定が開いたら、右下の「オートメーションの作成」をクリックします。

新しいオートメーションの作成画面が表示されたら、「新しいオートメーションを作成」をクリックします。

このオートメーションを作成するには次の2つの方法があります。

1. コードを貼り付けて作成する
   • コピペだけで簡単に作成できます。
2. UIを使って手動で作成する
   • コード貼り付けよりも少し時間がかかりますが、そこまで難しくはありません。

どちらの手順も結果は同じですので、お好みの手順で作成してください。

1つ目のコードを貼り付けて作成するには、新しいオートメーションの画面で右上の「…」から「YAML で編集」をクリックします。

このような画面になったら、画面上に表示されているコードを全て削除します。
その後、以下のコードをコピーして貼り付けます。

alias: HomeKitセンサーの更新
description: ""
triggers:
  - trigger: time_pattern
    seconds: /30
conditions: []
actions:
  - action: input_boolean.turn_on
    metadata: {}
    data: {}
    target:
      entity_id: input_boolean.update_homekit_sensors
  - delay:
      hours: 0
      minutes: 0
      seconds: 1
      milliseconds: 0
  - action: input_boolean.turn_off
    metadata: {}
    data: {}
    target:
      entity_id: input_boolean.update_homekit_sensors
mode: single

オートメーションの名前（alias）を変更したい場合や先ほど作成した切り替えヘルパーのエンティティ名（input_boolean.update_homekit_sensors）が異なる場合は各自置き換えてください。

正しく貼り付けられたら、右下の「保存」をクリックします。
これで、オートメーションの作成は完了です。

2つ目の手動で作成する場合は、「いつ（When）」のところの「トリガーを追加」をクリックして「時間と場所」→「タイムパターン」からタイムパターンを追加します。
タイムパターンの「秒」のところに「/30」と入力します。

次に「どうする（Then do）」のところに、次の3つのブロックを順番に追加します。

1. 真偽値入力(Booleans): オンにする
   • 「アクションを追加」→「ヘルパー」→「真偽値入力(Booleans)」→「オンにする」
2. 遅延
   • 「構成要素」→「時間が経つのを待つ(遅延)」
3. 真偽値入力(Booleans): オフにする
   • 「アクションを追加」→「ヘルパー」→「真偽値入力(Booleans)」→「オフにする」

「真偽値入力(Booleans)」のエンティティには、先ほど作成した切り替えヘルパーを選択します。
「遅延」は1秒（0:00:01:000）に設定します。

正しく設定できたら、右下の「保存」をクリックします。

保存画面が表示されたら、「名前」に「HomeKitセンサーの更新」などのようなわかりやすい名前を入力して、右下の「保存」をクリックします。
これで、オートメーションの作成は完了です。

オートメーションが作成できたら、先ほど作成した切り替えヘルパーの履歴を表示し、指定した時間ごと（今回は30秒ごと）にオン・オフが切り替えられていることを確認します。
指定した時間以上が経過しても切り替わらない場合、作成したオートメーションが正しく保存されているか、オフになっていないかご確認ください。

HomePodのセンサー情報を送信するオートメーションを作成する

切り替えヘルパーがオンになった際に、HomePodのセンサー情報をHome Assistantに送信するHomeKitのオートメーションを作成します。

このオートメーションはmacOSでは作成できない（使用する変数の挿入がmacOSではできないバグや、途中の手順で必ずアプリがクラッシュしてしまうバグがある）ため、iPhoneまたはiPadを使用する必要があります。

iPhoneまたはiPadで「ホーム」アプリを開き、右上の「+」ボタンから「オートメーションを追加」をタップします。

新規オートメーションの画面が表示されたら、「アクセサリがコントロールされたとき」を選択します。

オートメーションをトリガーするアクセサリに先ほど作成した切り替えヘルパーを選択し、「オンになった」にチェックを入れて次に進みます。

自動化するシーンとアクセサリの選択画面が表示されたら、一番下にある「ショートカットに変換」をタップします。

ショートカットの設定画面が表示されるので、最初から追加されている「シーンとアクセサリを設定」を削除します。

「ホーム」アプリの「状態を取得」アクションを追加し、取得したいセンサーを割り当てます。
このアクションは、取得したい（Home Assistantに送信したい）センサーの数だけ追加する必要があります（複数のHomePodがある場合、そのHomePodの分も追加します）。

次に、アクションの検索欄に「URL」と入力し、「URLの内容を取得」アクションを追加します。
まずは温度センサーを送信するアクションを設定します。

「URL」の部分に、次のURLを入力します。

http://homeassistant.local:8123/api/states/sensor.お好みのエンティティID_temperature_by_api

「homeassistant.local」のところはHome AssistantサーバーのIPアドレスやドメイン名でも問題ありません。
「お好みのエンティティID」のところは、Home Assistantに表示させるエンティティIDを入力します。英数字と「_」（アンダースコア）のみ使用可能です（例: 「restroom_homepod_mini」）。

アクション名のところにある下向きの矢印をタップして広げた後、「方法」のところにある「GET」をタップして「POST」に変更します。

「ヘッダ」をタップしたら「新規ヘッダを追加」をタップし、次のように入力します。

• キー: Authorization
• テキスト: 「Bearer 」（最後の半角スペース1つを含む）と入力した後、続けてアクセストークンを入力
  • 例: 「Bearer xxxxxxxxxxxxxxx」

「本文を要求」が「JSON」になっていることを確認し、「新規フィールドを追加」をタップします。

1つ目は「数字」のフィールドを追加し、次のように入力します。

• キー: state
• 数字: 取得したいHomePodの「現在の温度」の変数を挿入
  • 複数のHomePodがあってどれがどの変数かがわからない場合は、左下の「変数を選択」をタップして、先ほど設定した「状態を取得」アクションの下にある使用したいHomePodの変数をタップして挿入します。

2つ目は「辞書」のフィールドを追加し、次のように入力します。

• キー: attributes

「0項目」と書かれているところをタップし、辞書の設定画面を開きます。

辞書の追加画面が開いたら、「新規フィールドを追加」をタップし、複数の「テキスト」フィールドを追加します。

それぞれのフィールドに、以下のように入力します（順不同）。

• 1つ目
  • キー: device_class
  • テキスト: temperature
• 2つ目
  • キー: state_class
  • テキスト: measurement
• 3つ目
  • キー: unit_of_measurement
  • テキスト: °C
• 4つ目（オプション。なくても良い）
  • キー: friendly_name
  • テキスト: Home Assistantに表示させるセンサーの名前
    • 例: 「トイレのHomePod miniの温度センサー」

フィールドが追加できたら、「完了」をタップします。これで、温度センサーを送信するアクションの設定は完了です。

次は、湿度センサーを送信するアクションを設定します。もう一つ「URLの内容を取得」アクションを追加します。

「URL」の部分に、次のURLを入力します。

http://homeassistant.local:8123/api/states/sensor.お好みのエンティティID_humidity_by_api

「homeassistant.local」のところはHome AssistantサーバーのIPアドレスやドメイン名でも問題ありません。
「お好みのエンティティID」のところは、Home Assistantに表示させるエンティティIDを入力します。英数字と「_」（アンダースコア）のみ使用可能です（例: 「restroom_homepod_mini」）。

アクション名のところにある下向きの矢印をタップして広げた後、「方法」のところにある「GET」をタップして「POST」に変更します。

「ヘッダ」をタップしたら「新規ヘッダを追加」をタップし、次のように入力します。

• キー: Authorization
• テキスト: 「Bearer 」（最後の半角スペース1つを含む）と入力した後、続けてアクセストークンを入力
  • 例: 「Bearer xxxxxxxxxxxxxxx」

「本文を要求」が「JSON」になっていることを確認し、「新規フィールドを追加」をタップします。

1つ目は「数字」のフィールドを追加し、次のように入力します。

• キー: state
• 数字: 取得したいHomePodの「現在の相対湿度」の変数を挿入
  • 複数のHomePodがあってどれがどの変数かがわからない場合は、「変数を選択」をタップして、先ほど設定した「状態を取得」アクションの下にある使用したいHomePodの変数をタップして挿入します。

2つ目は「辞書」のフィールドを追加し、次のように入力します。

• キー: attributes

「0項目」と書かれているところをタップし、辞書の設定画面を開きます。

辞書の追加画面が開いたら、「新規フィールドを追加」をタップし、複数の「テキスト」フィールドを追加します。

それぞれのフィールドに、以下のように入力します（順不同）。

• 1つ目
  • キー: device_class
  • テキスト: humidity
• 2つ目
  • キー: state_class
  • テキスト: measurement
• 3つ目
  • キー: unit_of_measurement
  • テキスト: %
• 4つ目（オプション。なくても良い）
  • キー: friendly_name
  • テキスト: Home Assistantに表示させるセンサーの名前
    • 例: 「トイレのHomePod miniの湿度センサー」

フィールドが追加できたら、「完了」をタップします。これで、湿度センサーを送信するアクションも設定は完了です。

他にも設定したいHomePodがある場合は、他のHomePodの分も同様に設定します。
入力する項目が多くて何度も繰り返すのは大変なので、「URLの内容を取得」アクションのアイコンをタップして「複製」をタップすることで同じアクションを複製することができますので、複製してから編集すると簡単です。

オートメーションが設定できたら、右上の「完了」をタップします。

このような画面が表示されたら、必要に応じてオートメーションの名前を設定し、右上の「完了」をタップします。
これで、オートメーションの設定は完了です。

オートメーションが作成できたら、Home Assistantの「設定」→「デバイスとサービス」→「エンティティ」と進むか、以下のボタンからエンティティの一覧を表示します。

エンティティの一覧が表示されたら、検索欄に「_by_api」などと入力し、HomePodのセンサーが追加されていることを確認します。
まだ作成されていない場合はオートメーションが作動していない可能性がありますので、少し待ってみてください。
しばらく待ってもセンサーが作成されない場合、アクセストークンなどの設定が間違っている可能性がありますので、先ほど作成したHomeKitオートメーションの設定を開いて正しいことをご確認ください。

HomeKitオートメーションの設定を確認するには（クリックして開閉）

HomeKitオートメーションの設定画面の右下にある再生ボタンをタップすることでオートメーションを手動で実行することができます。
オートメーションを実行した際、最後の「URLの内容を取得」アクションが行われた結果が一番下に表示されるので、何かエラーが表示されていないかご確認ください。

途中のアクションの結果を見たい場合は、見たいアクションの直後に「停止して出力」アクションを配置してオートメーションを実行します。

作成されたセンサーを使いやすくする

テンプレートセンサーを作成する

REST APIを使って作成されたセンサーには、システム的にセンサーを識別するユニークIDが割り当てられていないため、UIからエンティティの設定を変更することができません。
そのため、後からセンサーの名前を変えたりエンティティIDを変更したりすることができないため、このままでは少し不便です。
そのため、テンプレートヘルパーを使って、設定変更ができるテンプレートセンサーを作成します（後からセンサー名やエンティティIDを変更する予定がなく、設定変更ができなくても問題ない場合はこのまま使っても構いません）。

Home Assistantの「設定」→「デバイスとサービス」→「ヘルパー」と進むか、以下のボタンからヘルパー設定を開きます。

ヘルパー設定を開いたら、右下の「ヘルパーを作成」をクリックします。
ヘルパーの作成画面が表示されたら「Template」を選択します。

テンプレートヘルパーの選択画面が表示されたら、「センサーのテンプレート」を選択します。

テンプレートセンサーの設定画面が表示されるので、それぞれ設定していきます。

「名前」のところには、お好みのセンサー名を入力します。

「状態テンプレート」には以下のコードを入力します。

温度センサーの場合:

{{ states('sensor.APIで作成されたエンティティID_temperature_by_api') }}

湿度センサーの場合:

{{ states('sensor.APIで作成されたエンティティID_humidity_by_api') }}

「APIで作成されたエンティティID」の部分は、各自変更してください。

「測定単位」には以下のものを選択します。

• 温度センサーの場合: °C
• 湿度センサーの場合: %

「デバイスクラス」には以下のものを選択します。

• 温度センサーの場合: 温度
• 湿度センサーの場合: 湿度

「状態クラス」は「測定」を選択します。

「デバイス」の部分はお好みで設定してください（Apple TV統合を設定している場合、そのデバイスに割り当てておくとセンサーを見つけやすくなります）。

それぞれ入力したら、下にある「プレビュー」が正しく表示されていることを確認し、右下の「送信」をクリックします。

作成したセンサーは、このように設定変更ができるようになっています。
センサー名に日本語や漢字を入力した場合はエンティティIDがわかりづらいものとなってしまうため、わかりやすいものに変更しておくことをおすすめします。
元のセンサーの「_by_api」をなくした部分に変更しておくとわかりやすいでしょう（例: 「restroom_homepod_mini_temperature_by_api」→「restroom_homepod_mini_temperature」）。

テンプレートセンサーの設定で「デバイス」を割り当てた場合はこのように、統合のデバイス設定画面に追加されます。

テンプレートセンサーは、「状態テンプレート」で指定したセンサーの状態変更を常に検知するため、元のセンサーの状態が変わったらすぐにテンプレートセンサーに反映されます。
そのため、Home Assistant上の他の温湿度センサーと同じように使うことができます。

おまけ: HomePod mini内蔵温湿度センサーと他のセンサーを比べてみた

HomePod（第2世代）は持っていないので、HomePod miniと他の温湿度センサーを比べてみました。
なお、正確にキャリブレーションされた温湿度センサーは持っていないため、あくまで参考程度ですのでご了承ください。

温度センサーを比較

こちらは、同じ部屋に設置した以下の温湿度計の温度グラフです。

• Smartmi スマート加湿器2（電源オフ）
• Dyson Pure Hot + Cool Link HP03（電源オフ、連続モニタリングオン）
• SwitchBot ハブ2
• HomePod mini x2

同じ部屋といっても設置場所が異なるのと冷房が入っているため、センサーによって温度差が結構ありますが、こうしてグラフで見ると、HomePod miniに内蔵された温度センサーは他の温度センサーと比べて急激な差は検知しにくいようです。

例えば、他の温度センサーが急激に温度上昇を検知しても、HomePod miniの温度センサーはそれを後から追いかけていくように上昇していくのがわかります。
また、温度が細かく上下しているところでは温度変化をあまり検知せず、平坦なグラフになっているのがわかります。

これはおそらく、HomePod miniの内部で発生した熱の影響を最小限に抑えるようにHomePodソフトウェアで補正をかけて記録しているため、正しい温度になるまで少し時間がかかるのかもしれません。
そのため、HomePod miniに内蔵された温度センサーは、急激な温度変化を検知して作動させるようなオートメーションには向いていません。

ちなみに、SwitchBot ハブ2とバックデスクのHomePod miniは結構近いところに設置してありますが、グラフ上で見ると温度差はそこまで大きくないため、（温度変化が落ち着けば）精度は結構高いのかもしれません。
オートメーションに使う場合は、「28°C以上になったら冷房をつける」のように、しきい値を超えた、または下回ったときに作動させるようなオートメーションに使うのが良さそうです。

また、メインデスクのHomePod miniはエアコンの冷風が当たる場所に置いてあるのですが、風が当たる場所では実際の温度よりも低く記録される傾向があるようです（ソフトウェアの補正が強くかかる？個体差かもしれませんが…）。
メインデスクのHomePod miniは加湿器やHP03に近い場所に置いてありますが、エアコンの冷風が当たっている間はこれらよりもかなり低い温度を報告しています（エアコンを切ると他の温度センサーに近い値になります）。
そのため、HomePod miniを使って温度を記録する際は、あまり風が当たらない場所に設置するのが良さそうです。

ちなみに、加湿器の温度がHP03よりも高いのは、電源を切っているためです。電源を入れると風の流れができてHP03に近い温度になります（電源オフの状態では平坦なグラフですが、電源がオンの際は温度の細かい上下変動もしっかり検知できます）。
HP03は連続モニタリングをオンにしており、電源がオフの状態でも低速でファンが回り、わずかに風の流れがあるため、細かい温度変化を検知できています。

湿度センサーを比較

こちらは同じデバイスの湿度グラフです（わかりやすい場所を抜き出したので温度比較の時とは時間帯が異なります）。

先ほど、HomePod miniの温度センサーは他の温度センサーと比べて少し遅れているのがわかりましたが、湿度のほうはあまり遅れておらず、概ね他の湿度センサーと同じようなタイミングで変化を検知できているのがわかります（多少は遅れていますが）。
ただし、温度センサーと同じく、湿度が細かく上下している箇所では変化をあまり検知できていないようです。

おそらく、湿度の場合はHomePod mini内部で発生した熱の影響をそこまで大きくは受けないため、湿度の補正にあまり時間がかからないのかもしれません（もちろん、大きな温度変化が起きた場合は湿度が大きくかけ離れてしまう事があるとは思いますが…）。
そのため、HomePod miniに内蔵された湿度センサーも、急激な湿度変化を検知して作動させるようなオートメーションには向いていません。

ちなみに、こちらもSwitchBot ハブ2とバックデスクのHomePod miniを見てみると、そこまで大きく差があるわけではないので、湿度に関しても精度は悪くなさそうです。
こちらも温度センサーと同様に、しきい値で作動させるようなオートメーションに使うのが良さそうです。

絶対湿度で比較

先ほどの湿度グラフは相対湿度のグラフだったため、温度によって湿度が変わってしまい、本当の湿度で比較することができませんでした。そのため、同じ時間帯の絶対湿度のグラフがこちらです（「Thermal Comfort」カスタム統合で計算）。

メインデスクのHomePod miniはエアコンの冷風が当たっているため絶対湿度が低くなっていますが、それ以外は概ね同じような絶対湿度となっています。
14時10分ごろにエアコンを止めたため温度が上昇し、絶対湿度も上昇していますが、HomePod miniは温度センサーの反応が遅いため、絶対湿度も正しい値になるまでゆっくり追いかけているような感じです（バックデスクのHomePod miniを見るとわかりますが、まるで平均値をとっているかのよう）。
「Thermal Comfort」カスタム統合は温度と相対湿度から絶対湿度を計算しているため、急激な温度変化が起きた際はHomePod miniの温度センサーが急激な温度変化を検知できず、絶対湿度もそれに引っ張られているように見えます。

参考までに、同じ時間帯の温度・相対湿度・絶対湿度のグラフがこちらです。

さいごに

今回は、HomePodシリーズに内蔵されている温湿度センサーの情報をHome Assistantに送信して統合する方法をご紹介しました。
「せっかくHomePodを持っているのに、Home Assistantに対応した温湿度センサーを持っていないから追加できない…」という方でも、新たな製品を購入せずに、すでにお持ちのHomePodに内蔵されたセンサーをHome Assistantのダッシュボードに表示させたり、オートメーションで使用したりすることができます。

HomePod内蔵の温湿度センサーは少々クセがありますが、Home Assistantを使っていてHomePodシリーズをお持ちの方はぜひ試してみてはいかがでしょうか。

最後まで読んでくださりありがとうございました。それでは、また！

みなさんこんにちは、たいくんです。
以前、「【VirtualBox】Home Assistant のインストール方法と使い方【目指せ最強のスマートホーム！】」という記事を書いたのですが、内容が古くなってしまい、手順が異なる場所も出てきました。
最近ブログをリニューアルしたので、この機会に記事を新しく書き直すことにしました。
また、実用的で便利な使い方ができるような手順もご紹介します。

Home Assistantとは？

この記事をご覧になっている方はご存知の方も多いかと思いますが、「Home Assistant」はApple HomeKitやGoogle Home、Amazon Alexaなどのような、スマートホーム向けプラットフォームの1つです。

できること

Home Assistantはとても高機能で、本当に何でもできます。
注目すべき機能として以下のようなものがあります。

• 1000以上のブランドに対応
  • 多種多様な製品を接続して、一元管理することができます。
• 強力なオートメーション（自動化）
  • 高度なオートメーションエンジンによって、思い通りのオートメーションを組むことができます。
• 自由自在に制御できるダッシュボード
  • ドラッグアンドドロップで並び替えたり、様々なカードを配置したりしてカスタマイズすることができます。
• 独自の音声アシスタント「Assist」*
  • 自然言語を使って直感的にHome Assistantを制御することができます。
• アドオンを使ってシステムを拡張
  • Home Assistantの機能だけにとどまらず、様々なアプリケーションを実行することができます。
• すべてのスマートホームのデータは自宅にとどまる
  • ほとんどのデバイスはローカルで通信し、制御するため、クラウドは必要ありません。クラウド以外に選択肢がない場合はクラウドも使用することができますが、データはクラウドには保存されず、すべてローカルで処理されます。
• モバイルアプリ
  • モバイルアプリからHome Assistantを操作したり通知を受け取ったりするだけでなく、位置情報をHome Assistantに送って、オートメーションに活用したりすることもできます。
• 自宅の電力マネジメント
  • 高度な電力マネジメント機能によって、ソーラーパネルの状態を監視・最適化したり、電力の使用状況を確認して節電したりすることができます。
• 様々な画面をダッシュボードの表示に使える「Home Assistant Cast」
  • テレビやスマートディスプレイなどにHome Assistantの画面をキャストし、様々なデバイスにダッシュボードを表示させることができます。
• NFCタグ
  • NFCを使って音楽を鳴らしたり、オートメーションを動作させたりすることができます。

このように、とても多くの機能が搭載されています。

ローカル制御が素晴らしい

Home Assistantは「システムは自宅で動作するべきであり、クラウド上ではない」といった理念のもと開発されたオープンソースのプラットフォームです。
つまり、（HomeKitを除いた）他のプラットフォームとは異なり、ローカル制御に重きを置いて開発されています。
上記でも紹介しましたが、クラウドを通さずに直接デバイスと通信することができるため、操作の遅延が短くなったり、クラウドがダウンしていても操作できたりといった恩恵を受けることができます。

私は長年Home Assistantを使っていますが、ローカルで制御できるというのは本当に素晴らしいことだと実感しています。
もちろん、クラウドの方が難しい設定なしにセットアップしたり外出先から簡単に操作したりすることができますが、クラウドサーバーがダウンしてしまう事は少なくなく、操作したいときに操作できなかったら意味がありません。
また、クラウドに依存していると、せっかく買ったスマートデバイスでもメーカーが倒産するなどしてクラウドサーバーが提供されなくなった場合に、全く操作できなくなってしまうリスクもあります。
ローカル制御であればこうした心配は一切なく、安心して使い続けることができます（最初にメーカーのアプリなどを使ってセットアップしなければならないものもありますが…）。

これからスマートホームを構築しよう・新しいデバイスを購入しようと考えている方は、可能な限りローカル制御に対応したデバイスを購入されることを強くおすすめします。
Home Assistantに対応したデバイス（統合**）はこちらから確認することができます。
フィルターの「IoT Class」を「Local Push」または「Local Polling」に指定すると、ローカル制御に対応した統合のみを表示することができます。

Local PushとLocal Pollingの違いは以下の通りです。

• Local Push
  • スマートデバイスが、デバイスの状態をHome Assistantに送ります。
    デバイスの変更は、Home Assistant上ですぐに検知できます。
• Local Polling
  • Home Assistantが、デバイスの状態を定期的に（例えば、15秒に1回など）スマートデバイスに取りに行きます。
    デバイスの変更は、変更が起きた後、Home Assistantが状態を取りに行った際に検知されます（最長で更新間隔分遅延する場合があります）。

* 残念ながら、記事執筆時点では標準搭載されているAssistのエンジンは日本語に対応していません（LLMを使って日本語に対応させることはできます）。

** Home Assistantでは、デバイスを接続したり制御したりするためのプログラム（機能）のことを「統合」と呼びます。

日本ではまだあまり使われていない

Home Assistantは、こちらのページで統計情報が公開されています（分析を共有することを選択したユーザーのみ）。
このように、Home Assistantのアクティブ利用ユーザー（インストール）数は右肩上がりで上昇し続けています。

しかし、地域別利用状況を見ると、記事執筆時点ではアメリカでのユーザー（インストール）数は81906となっていますが、日本は1421と、決して多くはありません。
Home Assistantはほとんどが日本語に対応しているにもかかわらず、ユーザー数があまり多くない理由として、個人的には次のようなものが考えられると思います。

• そもそも日本ではスマートホームがあまり普及しておらず、スマートデバイスが（他の地域と比べて）あまり使われていない
• 日本で購入できるスマートデバイスの選択肢が少ない
• 日本で購入できるものでも、独自規格やクラウドサービスに依存するスマートデバイスが多い
• Home Assistantのドキュメントが英語のみ
• 日本語でのHome Assistantの情報が少ない

以前と比べればスマートホームは広がりつつありますが、それでも他の地域と比べればまだまだ普及していないと思います。
また、日本で購入できるデバイスでも、クラウドサービスに依存するような製品が多く、独自の規格やサービスでしか使用できないといったような互換性の低さも問題だと思います。
しかし、最近は「Matter」のような標準規格が登場したこともあり、これからはスマートデバイスの選択肢が増え、一元管理ができて、プライバシーについても気にかけるユーザーが増えてくるだろうと思っています。
そのため、そういったことを望むユーザーには、Home Assistantはぴったりなプラットフォームであると言えるでしょう。

Home Assistantのドキュメントが英語のみしか提供されていない事は（言語によって情報に差異がないように維持し続けるのは難しいため）ある程度仕方がないことかとは思いますが、今後、日本でのHome Assistantユーザーが増えていけば、日本語での情報もさらに増えていくと思われます。
以前と比べれば日本語での情報も増えてきつつあるため、これらの点を考えれば、Home Assistantを始めるには悪くないタイミングだと言えるでしょう。

Home Assistantのインストールについて

Home Assistantを使うにはサーバーが必要

Home Assistantはデバイスと通信し、制御し、データを保管するために、Home Assistantを動かすためのサーバーが必要になります。
サーバーといっても、そんな大それたものではありませんのでご安心ください。
新たな機材を用意する必要はなく、お持ちの機材だけでサーバーを立ち上げることができます。

Home Assistantの様々なインストール方法

Home Assistantには、大きく分けて4つのインストール方法があります。
それが以下の通りです。

• Home Assistant OS
  • すべての機能が揃った方法で、とても簡単かつ初心者向け。管理も簡単。
• Home Assistant Container
  • Home Assistantの中心機能だけのコンテナベースの方法で、比較的簡単。管理も比較的簡単。
• Home Assistant Core（サポート終了予定のため非推奨）
  • 手動でPython仮想環境を使ってインストールする方法で、とても難しく、上級者向け。管理が難しい。
• Home Assistant Supervised（サポート終了予定のため非推奨）
  • 手動でSupervisorをインストールする方法で、難しく、上級者向け。管理は簡単。

違いは以下の通りです。

どのインストール方法を選んでもHome Assistantの基本機能を使うことができますが、Home Assistant OSを使うのが最も簡単でおすすめです。
この記事でも、Home Assistant OSを使ったインストール方法をご紹介します。

* これらのインストール方法は、Home Assistant 2025.6より非推奨になりました。Home Assistant 2025.12のリリースを以ってサポート終了となります。
これらのインストール方法を使用している場合は、Home Assistant 2025.12のリリースまでにサポートされている他のインストール方法（OSかContainer）に移行する必要があります。

** OSの管理は自分で行う必要があります。
なお、この方法はmacOSには対応していません（Macで使いたい場合はDebianをインストールする必要があります）。

MacをHome Assistantサーバーとして使用する

今回インストールするHome Assistant OSは、その名の通りOSですので、macOSの上に直接インストールすることはできません。
そのため、macOSの上に仮想マシンを作成し、そこにインストールします。

今回はIntelプロセッサを搭載した古いMacと、Appleシリコンを搭載した新しいMacのどちらにも対応した方法をご紹介します。

Home Assistantサーバーとして使用するのにおすすめのMac

Home Assistantの要求スペックはそこまで高くないため、よほど古いものでない限り、基本的にはどのMacにインストールしても速度的に問題が起こる事は無いでしょう。
過去に2012年モデルのMacBook Proにインストールして使っていましたが、全く不満のない速度で動作していました。

ただし、Home Assistantサーバーは可能な限り24時間365日動作させたいものなので、長時間動き続けても消費電力が低いものにインストールするのが望ましいです。
例えば、Mac miniは比較的消費電力が低いため、サーバーとして使うのにも向いています。
一方、iMacやMac Proなどは高性能な分、消費電力が高いため、長時間動かし続けるような用途には向いていません。
ただし、Appleシリコンを搭載したMacであれば、Intelプロセッサを搭載したMacよりも高性能ではるかに消費電力が低いため、基本的にはどの機種を使っても良いでしょう。
もちろん、これらはあくまで推奨というだけで、他のMacにインストールしても問題ありません。

一方、ノートパソコン（MacBookシリーズ）にインストールするのはおすすめとは言えません。
デスクトップよりもMacBookシリーズの方が消費電力が低い場合が多いですが、常時電源に接続して使用していると、バッテリーが劣化したり膨張したりしてしまう可能性が高まります。
古いMacBook Proなど、バッテリーを取り外すことができるモデルの場合はバッテリーを取り外して使用すればこのような問題を回避することができますが、そうでない場合はMacBookをサーバーとして使用するのはおすすめしません。
お試しで使ってみる分には全く問題ありませんが、本格的にサーバーとして運用する場合はMacBookシリーズではなく、デスクトップを使用されることを強くおすすめします。

ちなみに、仮想マシンを使ってインストールするため、Macに搭載されたメモリ容量が少ないとメモリ不足になってしまう場合があります。
Home Assistant OSをインストールする前に、インストール先のMacに最低でも8GB以上、できれば16GB以上のメモリが搭載されていることをご確認ください。

使用する仮想化ソフト

今回、Home Assistant OSを仮想マシンにインストールして使います。
そのため、仮想マシンを作成して起動できるようにするための仮想化ソフトを使用する必要があります。

この記事では、以下の2つの仮想化ソフトを使ってインストールする方法をご紹介します。

• VirtualBox
• UTM

どちらもIntelプロセッサを搭載したMacとAppleシリコンを搭載したMacのどちらにも対応した無料で使用できるソフトで、どちらを使っても機能的には大きな差はありません。
そのため、使用するソフトはお好みでお選びください。

VirtualBoxは古くからあるソフトで、インターネット上に多くの情報があるため、困ったときに情報が手に入りやすいかと思います。
UTMは比較的新しいソフトで、バックエンドには強力なQEMUを採用しています。新しめのソフトということもあり、UIが洗練されていて使いやすく、高速に動作する印象があります。

インストールする際はどちらもインストールする必要はなく、どちらか1つだけをインストールすれば問題ありません。

VirtualBoxを使ってインストールする

まずは、VirtualBoxを使ってHome Assistant OSをインストールする方法をご紹介します。
UTMを使う方法については、「UTMを使ってインストールする」セクションまで飛ばしてください。

VirtualBoxをインストールする

VirtualBoxはこちらから無料でダウンロードすることができます。
インストール方法はとても簡単ですので割愛します。

VirtualBox用のHome Assistant OSイメージをダウンロードする

VirtualBoxでHome Assistant OSを使用するためのイメージをダウンロードする必要があります。

ダウンロードするにはこちらにアクセスします。
アクセスするとこのような画面が表示されるので、下のほうにスクロールします。

「Assets」と書かれたところに様々なイメージが表示されるので、以下のものをクリックしてダウンロードします。

• Intelプロセッサ搭載のMac
  • haos_ova-XX.X.vdi.zip
• Appleシリコン搭載のMac
  • haos_generic-aarch64-XX.X.vmdk.zip

よく確認すべきところは太字にしています。

ダウンロードしたファイルはZIPで圧縮されているので展開して、誤って削除してしまわないような場所に移動しておきましょう（仮想マシンの動作にはダウンロードしたファイルが使われるため、削除してしまうと仮想マシンが起動できなくなってしまいます）。

VirtualBoxで仮想マシンを作成する

VirtualBoxを起動したら、上にある「新規」をクリックします。

次の項目を設定します。

• 名前
  • 「Home Assistant OS」などのわかりやすい名前を入力します。
• フォルダー
  • 仮想マシンが保存されるフォルダを指定します。特になければデフォルトの場所でも問題ないでしょう。
• タイプ: Linux
• Subtype: Oracle Linux
• バージョン
  • Intelプロセッサを搭載したMac: Oracle Linux (64-bit)
  • Appleシリコンを搭載したMac: Oracle Linux (ARM 64-bit)

設定したら、下のほうにある「ハードウェア」をクリックします。

次の項目を設定します。

• メインメモリー: 2048 MBまたはそれ以上（4096 MB以上を推奨）
  • 多くのアドオンを使う予定の場合は、メモリ容量を多めに割り当てることをおすすめします。
    割り当てが多すぎると不安定になってしまう場合があるため、最大でも搭載容量の半分程度にしておきましょう。
• プロセッサー数: 2またはそれ以上
  • 多くのコアが搭載されたMacの場合は4コア以上を割り当てることをおすすめします。
    こちらも割り当てが多すぎると不安定になってしまう場合があるため、最大でも搭載コア（スレッド）数の半分程度にしておきましょう。
• EFIを有効化(一部のOSのみ): チェックを入れる

設定したら、1つ下の「ハードディスク」をクリックします。

「すでにある仮想ハードディスクファイルを使用する」を選択したら、右にある黄色いフォルダアイコンをクリックします。

このような画面が表示されたら、左上の「追加」をクリックして、先ほどダウンロードしたイメージファイルを追加したら、右下の「選択」をクリックします。

このように、追加したファイルが表示されていれば問題ありません。
「完了」をクリックします。

仮想マシンが作成できたら、まだ起動はせず、上にある「設定」をクリックします。

左側の「オーディオ」をクリックしたら、「オーディオコントローラー」を「Intel HD オーディオ」に変更します。

次に、左側の「ネットワーク」をクリックしたら、「割り当て」を「ブリッジアダプター」に変更します。
必要に応じて、「名前」を使いたいネットワークアダプターに変更してください（例えば、Wi-Fiとイーサネットのどちらにも接続している場合、「enX: Ethernet」を選択して、Home Assistantの通信をイーサネットで行うように指定することをおすすめします）。
設定できたら、右下の「OK」をクリックして設定を保存します。

設定が終わったら仮想マシンを起動します。
このような画面が表示されれば起動プロセスが始まっています。

しばらく待って、このような画面が表示されたらHome Assistant OSが問題なく起動しています。
ここから先のHome Assistantのセットアップについては、以下の「Home Assistantを設定する」セクションに進んでください。

UTMを使ってインストールする

次は、UTMを使ってHome Assistant OSをインストールする方法をご紹介します。

UTMをインストールする

UTMはこちらから無料でダウンロードすることができます。UTMの開発者を支援したい方は、Mac App Storeから有料版をご購入ください（UTMの自動アップデート以外は機能の差異はありません）。
インストール方法はとても簡単ですので割愛します。

UTM用のHome Assistant OSイメージをダウンロードする

UTMでHome Assistant OSを使用するためのイメージをダウンロードする必要があります。

ダウンロードするにはこちらにアクセスします。
アクセスするとこのような画面が表示されるので、下のほうにスクロールします。

「Assets」と書かれたところに様々なイメージが表示されるので、以下のものをクリックしてダウンロードします。

• Intelプロセッサ搭載のMac
  • haos_ova-XX.X.qcow2.xz
• Appleシリコン搭載のMac
  • haos_generic-aarch64-XX.X.qcow2.xz

よく確認すべきところは太字にしています。

ダウンロードしたファイルはXZで圧縮されているので展開しておきましょう。

UTMで仮想マシンを作成する

UTMを起動したら、左上にある「+」をクリックします。

「仮想化」をクリックします。

下にある「その他」をクリックします。

起動デバイスは「なし」を選択して、右下の「続ける」をクリックします。

次の項目を設定します。

• メモリ: 2048 MiBまたはそれ以上（4096 MiB以上を推奨）
  • 多くのアドオンを使う予定の場合は、メモリ容量を多めに割り当てることをおすすめします。
    割り当てが多すぎると不安定になってしまう場合があるため、最大でも搭載容量の半分程度にしておきましょう。
• CPUコア数: 2またはそれ以上
  • 多くのコアが搭載されたMacの場合は4コア以上を割り当てることをおすすめします。
    こちらも割り当てが多すぎると不安定になってしまう場合があるため、最大でも搭載コア（スレッド）数の半分程度にしておきましょう。

設定したら、右下の「続ける」をクリックします。

ストレージは後で設定するため、そのまま右下の「続ける」をクリックします。

何も変更せずに、右下の「続ける」をクリックします。

名前に「Home Assistant OS」などのわかりやすい名前を入力したら、「仮想マシン設定を開く」にチェックを入れて、右下の「保存」をクリックします。

左側の「ネットワーク」をクリックしたら、「ネットワークモード」を「ブリッジ（詳細）」に変更します。

次にとは、左側の一番下のほうにある「VirtIOドライブ」または「IDEドライブ」をクリックしたら、左下の「削除」をクリックします。

ドライブが削除できたら、左下の「新規…」をクリックします。
ディスクの追加画面が表示されたら「読み込む…」をクリックして、先ほどダウンロードしたイメージファイルを追加します。

このように、右上に先ほどダウンロードしたファイル名と同じ名前が表示されていれば問題ありません。

そのままではディスクの容量が小さすぎて、Home Assistantがすぐに容量不足になってしまうため、「サイズを変更…」をクリックします。
サイズ変更画面が表示されたら、32GiB以上の容量を入力して「サイズを変更」をクリックします。

このような警告画面が表示されますが、「サイズを変更」をクリックすることで容量を増やすことができます。
設定できたら、右下の「保存」をクリックして設定を保存します。

設定が終わったら仮想マシンを起動します。
このような画面が表示されれば起動プロセスが始まっています。

もし、Appleシリコン搭載のMacを使用していて、仮想マシンを起動してから最初の数秒間画面が表示された後、「Display output is not active.」と表示されたまま進まなくなってしまった場合は、一旦左上の電源マークのボタンをクリックして仮想マシンを停止します。

次に、右上の設定アイコンをクリックして設定を開きます。

左側の「ディスプレイ」をクリックし、「仮想ディスプレイカード」を「virtio-ramfb」から「virtio-gpu-pci」に変更して設定を保存します。
これで、ディスプレイが正しく表示されるようになるはずです。

しばらく待って、このような画面が表示されたらHome Assistant OSが問題なく起動しています。
ここから先のHome Assistantのセットアップについては、以下の「Home Assistantを設定する」セクションに進んでください。

Home Assistantを設定する

初期設定を行う

Home Assistant OSを起動してしばらくすると、上記のような画面が表示されるので、同じネットワーク内に接続したパソコンからウェブブラウザで「http://homeassistant.local:8123/」または「http://画面に表示されているIPv4アドレス:8123/」（この画像の例だと「http://192.168.1.236:8123/」）にアクセスします。
上記の画面が表示されてからすぐにアクセスしても接続できない場合があります。その場合は、少し待ってからアクセスしてみてください。

アクセスできたら、このような画面が表示されるはずです。
初回起動時は様々な準備を行っているため、準備が終わるまでしばらく待ちます。

準備が終わると「ようこそ！」と書かれた画面が表示されるので、「私のスマートホームを作成」をクリックします。

Home Assistantで使用するユーザーアカウントを作成します。

• 名前
  • あなたの名前を入力します。
• ユーザー名
  • ログイン時に入力するユーザー名を入力します。
• パスワード
  • ログインする際に使用するパスワードを入力します。
    サーバーを外部に公開して外出先からもアクセスできるようにする場合、パスワードマネージャーの自動生成機能などを使って、強力なパスワードを設定しておくことを強くおすすめします。
• パスワードの確認
  • 「パスワード」欄で入力したパスワードをもう一度入力します。

すべて入力できたら、右下の「アカウントの作成」をクリックします。

自宅の場所を入力します。
ここで設定した場所はHome Assistantサーバーのみに保存され、天気予報を取得したり、オートメーションやクラウドベースの統合などで使用されたりします。
クラウドサーバーに保存されるわけではないため、正しい場所を設定しておくことをおすすめします。

Home Assistantの改善に使用される匿名の使用状況や統計データなどを送信するかどうかを選択します。
こちらはお好みで設定してください。

Home Assistantに登録できるデバイスをお持ちの場合、このような画面が表示される場合があります。
右下の「完了」をクリックするとHome Assistantの初期設定が完了します。

これで、Home Assistantの初期設定は完了です。

ほぼ必須のアドオンを追加する

ここからは、Home Assistantを使い続ける上でほぼ必須ともいえるアドオンを追加します。

これからインストールするアドオンは高度なものですので、デフォルトではインストールすることができません。
そのため、ユーザー設定を開いて「詳細モード」をオンにする必要があります。

ユーザー設定を開くには、サイドバーの最も下にあるユーザー名をクリックするか、以下のボタンをクリックすることで開くことができます。

このボタンは「My Home Assistant」というサービスを使って作成されたボタンです。
初めてMy Home Assistantにアクセスした際に自分のHome AssistantサーバーのURLを設定しておくことで、ボタンをクリックした際に指定のページにリダイレクトすることができます。
ここで設定したURLはブラウザ内にのみ保存されており、外部に送信される事はありませんのでご安心ください（ブラウザの設定でCookieが無効になっているとうまく機能しませんのでご注意ください）。

詳細モードを有効化したら「設定」→「アドオン」→「アドオンストア」と進むか、以下のボタンからアドオンストアにアクセスします。

アドオンストアを開いたら、以下のアドオンをインストールします。

• File editor
  
• Terminal & SSH
  

アドオンのページを開いたら、「インストール」ボタンをクリックすることでインストールできます。

アドオンがインストールできたら、「開始」ボタンをクリックするとアドオンを起動することができます。
「サイドバーに表示」をオンにすることで、アドオンがサイドバーに追加されてすぐにアクセスしやすくなるため、特に理由がなければオンにしておくと良いでしょう。
また、「ウォッチドッグ」をオンにしておくと、何らかの理由でアドオンが強制終了してしまった場合に自動的にアドオンが再起動するようになります。

2つのアドオンをインストールして起動させたら準備は完了です。

File editorについて

Home Assistantには、UIから設定できるものと「configuration.yaml」にコードを記述して設定するものがあります。
記事執筆時点では、多くの項目がUIから設定できるようになってきていますが、それでもまだ、古い統合や設定項目などはconfiguration.yamlから設定しなければならないものがあります。

File editorアドオンは、configuration.yamlなどのシステムファイルへ簡単にアクセスしたり編集したりできるようにするアドオンで、設定変更を簡単に行えるようになります。
この記事でFile editorアドオンを使う場面はありませんが、Home Assistantを使っているとconfiguration.yamlを変更する機会が結構ありますので、このアドオンをインストールしておいて損はないでしょう。

Terminal & SSHについて

Terminal & SSHアドオンは、ブラウザでターミナルにアクセスしたり、Home AssistantサーバーにSSHで接続できるようにしたりする高度なアドオンです。
先ほどご紹介したFile editorとは異なり、ターミナルへのアクセスやSSHでのアクセスが必要になる機会はあまりないかもしれませんが、次の「HACSをインストールする」セクションで必要になります。

HACSをインストールする

Home Assistantには標準機能に加えて、コミュニティによって作成されたカスタム統合やテーマなどを追加できるようにするためのHome Assistant Community Store（HACS）と呼ばれるものがあります。
HACSをインストールしておくことで、標準機能だけではHome Assistantに接続できなかったデバイスでもカスタム統合によって接続できるようになったり、お好みのテーマをインストールして見た目をガラッと変えたりすることが簡単にできるようになります。
そのため、HACSをインストールすることをおすすめします。

なお、HACSの利用には無料で作成できるGitHubアカウントとインターネット回線が必要になりますのでご注意ください。

HACSをインストールするには、先ほどインストールしたTerminal & SSHアドオンを開き、次のコマンドを入力して実行します。

wget -O - https://get.hacs.xyz | bash -

コマンドを実行するとHACSのインストールが始まります。

再び入力可能な状態になったらインストールは完了です。
インストールが終わったらHome Assistantを再起動します。

Home Assistantを再起動するには、サイドバーまたは以下のボタンから「設定」を開き、右上の「…」から「Home Assistantを再起動」をクリックします。

HACSを設定する

Home Assistantが起動したら、「設定」→「デバイスとサービス」と進むか、以下のボタンから「統合」設定を開きます。

右下の「統合を追加」をクリックしたら「HACS」と検索して追加します。
検索してもHACSが表示されない場合、ブラウザのキャッシュをクリアするか、ハード再読み込みする必要があります。

HACSを追加しようとするとこのような画面が表示されます。
次の4つの項目に同意する（チェックを入れる）必要があります。

• Home Assistantのログにアクセスする方法を知っている
  「設定」→「システム」→「ログ」と進むか、以下のボタンからログにアクセスすることができます。
  
• HACSにはアドオンがないことを知っている
  アドオンは「アドオンストア」からのみ入手可能で、HACSにはアドオンが存在しません（カスタム統合とアドオンは別物です）。
• HACS自身を含むHACS内の全てはカスタムであり、Home Assistantによってテストされていないことを知っている
  すべてコミュニティによって作成されたものですので、Home Assistantの公式によるテストは行われていません。
• Home Assistantで問題が発生した際、すべてのcustom_componentsを動かしなければならないことを知っている
  Home Assistantが正常に起動しなくなった場合など、custom_components（カスタム統合）を無効化して自分で原因を見つける必要があります。

これらの項目に同意したら、右下の「送信」をクリックします。

次は、GitHubのアカウントを使ってHACSを承認する必要があります。
GitHubのアカウントをお持ちでない場合はこちらからアカウントを作成してください。

GitHubアカウントの準備ができたら、「https://github.com/login/device」にアクセスして、Home Assistantの画面上に表示されている8桁のコードを入力します。

コードを入力したらこのような画面が表示されます。
公開されている情報を読み取り専用でアクセスすることを要求されるので、「Authorize hacs」をクリックしてHACSを承認します。

承認に成功すると、Home Assistantの画面にこのようなものが表示されるので、「SKIP AND FINISH」をクリックします。

これで、HACSの設定は完了です。
サイドバーの「HACS」からHACSにアクセスすることができます。

ダッシュボードを設定しよう

デフォルトのダッシュボードである「オーバービュー」は、登録したデバイスが一覧で並んでいるだけの味気ないものとなっています。
そのため、カスタマイズ可能なダッシュボードを作成しましょう。

ダッシュボードを追加するには、「設定」→「ダッシュボード」と進むか、以下のボタンからダッシュボードの設定を開き、右下の「ダッシュボードを追加」をクリックします。

ダッシュボードの追加画面が表示されるので、お好みのものを選択します。

「新しいダッシュボードを一から作る」を選択すると、自分で高度にカスタマイズできるダッシュボードを作成することができます。

「エリア（実験的）」を選択すると、エリア（部屋）別のビュー（タブ）が作成され、簡単に使い始めることができます。
「実験的」と書かれている通り、記事執筆時点ではまだ実験的機能であり、また、カードを並び替えてカスタマイズすることはできません（表示するエリアの順番を変更することはできます）が、部屋別のダッシュボードがとても簡単に作成できるため、初心者には最もおすすめです。

他にも、地図やウェブページといった特定の機能だけを使ったダッシュボードを作成することもできます。

作成したいダッシュボードを選択したら、このような画面が表示されるので、次の項目を設定します。

• タイトル
  • サイドバーに表示されるダッシュボード名を入力します。
• アイコン
  • サイドバーに表示されるアイコンを指定します。
• URL
  • このダッシュボードにアクセスするためのURLスラッグを入力します。
    1つ以上の「-」（ハイフン）を入れる必要があります。
• 管理者のみ
  • このダッシュボードを管理者アカウントでのみアクセス可能にします。
• サイドバーに表示
  • このダッシュボードをサイドバーからアクセスできるようにします。

「URL」以外は後から変更することができます。
設定したら、右下の「作成」をクリックするとダッシュボードが作成されます。

今回は「エリア（実験的）」を使ってダッシュボードを作成しました。
こんな感じで、ホームタブには部屋別のデバイスが表示され、部屋別にタブが作成されます。
部屋のタブを開くと、デバイスの種類（「照明」や「空調」など）によってグループ化された画面が表示されます。

私のダッシュボードの例

私が使用しているダッシュボードの例をご紹介します。
ダッシュボードカスタマイズの参考にしてみてください。

ホームタブ

私はこんな感じで、高度にカスタマイズしたダッシュボードを使用しています。
HACSを使って様々なカスタムカードやカスタム統合をインストールし、整っていて使いやすいダッシュボードを目指しました。
また、自作のカスタムテーマ「Blue Theme by taikun114」を使用しています（HACSからインストールできるので、ぜひ使ってみてください！）。

今後、おすすめのカスタムカードやカスタム統合などをご紹介する記事も書こうと思っているので、お楽しみに！

私の部屋ビュー

私の部屋ビューはこんな感じになっています。
ホームタブ以外はすべて、タブの設定から「サブビュー」に設定していて、タブが全く表示されないようにしています。

種類ごとにグループ化しており、よく使うものだけを配置しています。
また、グループ名をクリックすることで他のカード（よく使うもの以外）も表示するようにしています。

さすがに、ここまでの高度なカスタマイズは大変でしたが、とても使いやすいものに仕上がっていて、とても気に入っています。

バックアップを設定しておこう

必ずHome Assistantのバックアップを設定しておきましょう。
せっかくカスタマイズして使っていたのに、万が一の事態が発生してデータが消えてしまうととても悲しいものです。
バックアップを作成しておけばこうした自体を避けられるだけでなく、サーバーが故障したり別のサーバーに移行したりするときに簡単に移行することもできます。

バックアップを設定するには、「設定」→「システム」→「バックアップ」と進むか、以下のボタンからバックアップの設定を開きます。

バックアップの設定が開いたら、「バックアップを設定する」をクリックします。

Home Assistantで作成されるバックアップは暗号化されており、復元する際に「暗号化キー」が必要になります（暗号化キーをなくすと復元できず、データを失うことになってしまいます）。
バックアップの設定から暗号化を切ることもできますが、プライベートな情報が数多く保存されているため、暗号化は切らずに使うことを強くおすすめします。

復元に必要な暗号化キーが画面に表示されるので、どこか安全な場所にコピーしておきましょう。
また、緊急キットには復元に必要な（暗号化キーを含む）情報が記載されたテキストファイルをダウンロードすることができるので、ダウンロードして安全な場所に保存しておきましょう。
なお、これらの情報は後からでも確認できます（できる限り早めに保存しておきましょう）。

暗号化キーを保存したら自動バックアップの設定画面が表示されます。
特に理由がなければ、「推奨」を選択することをおすすめします。

これで設定は完了です。
設定が終わるとバックアップが作成されます。

3-2-1バックアップルールに則ったバックアップを設定しよう

みなさんは、「3-2-1バックアップルール」をご存知でしょうか？
3-2-1バックアップルールとは以下のようなものです。

1. 3つのデータコピーを作成する
2. 2つのコピーは異なる別のメディアに保存する
3. 1つのコピーはオフサイト（クラウドなど、自宅外）に保存する

このような戦略でバックアップすることで、データ消失リスクを最小限に抑えることができます。
例えば、自宅内の異なるメディア（NASなど）だけにバックアップしていると、災害などによって自宅内のデータにアクセスできなくなってしまった場合、データが消失してしまいます。
しかし、オフサイトにも保存しておけば、このような事態を回避することができます。

Home Assistantの場合、例として以下の3つの場所にバックアップしておけば、3-2-1バックアップルールに則ったバックアップとなります。

1. Home Assistantのローカルストレージ
2. NAS
3. クラウドドライブ

このようにバックアップしておくことで、データ消失のリスクを最小限に抑えられます。

デフォルトでは、Home Assistantサーバーのローカルストレージのみにバックアップが保存されます。
そのため、Home Assistantサーバーが故障してしまった場合、バックアップデータを取り出すことができなくなってしまう可能性があるため、必ず別の場所にもバックアップを作成するように設定しておきましょう。

バックアップの場所を追加する

バックアップに対応した統合を追加することで、バックアップ先として設定することができるようになります。
バックアップに対応した統合は、こちらから確認することができます。
可能であれば、2つ以上の場所を追加しておきましょう。

バックアップに対応した統合を追加したら、再びバックアップの設定に戻り、下のほうにある「バックアップ設定」内の「バックアップの保存先」をクリックします。

バックアップの保存先を選択する画面が「場所」のところに表示されるので、先ほど追加した統合のスイッチをオンにします。

これで、次回バックアップが作成された際に、ここで設定した場所にアップロードされます。

ネットワークドライブを追加してバックアップ先に使用する

NASやSambaサーバーなどといったネットワークストレージがある場合、Home Assistantのストレージ設定からネットワークストレージを追加することができます。
ネットワークドライブを追加するには、「設定」→「システム」→「ストレージ」と進むか、以下のボタンからストレージの設定を開きます。

ストレージの設定が開いたら、「ネットワークストレージを追加」をクリックします。

次の項目を設定します。

• 名前
  • UIに表示される名前で、マウントポイント名でもあります。
    英数字と「_」（アンダースコア）のみ使用できます。
• 使用方法: バックアップ
• サーバー
  • ストレージサーバーへのドメイン名またはIPアドレスを入力します。
• プロトコル
  • 使用するプロトコルを選択します。

さらに、必要に応じて接続に必要な情報を入力します。
設定したら、右下の「接続」をクリックするとネットワークストレージを追加することができます。

ネットワークドライブを追加できたら、再びバックアップの設定に戻り、下のほうにある「バックアップ設定」内の「バックアップの保存先」をクリックします。

バックアップの保存先を選択する画面が「場所」のところに表示されるので、先ほど追加したネットワークドライブのスイッチがオンになっていることを確認します（オンになっていなければオンにします）。

これで、次回バックアップが作成された際に、ここで設定した場所にアップロードされます。

Macをサーバーとして使うための便利な使い方

停電復帰時に自動的にMacが起動するように設定する（デスクトップのみ）

デフォルトでは、Macの電源が入っているときに停電などによって電源が切れてしまった場合、電源が復旧しても自動的に電源が入りません。
Macをサーバーとして使用する場合、予期せぬ電源断から復帰したときに、自動的にMacの電源が入るように設定しておくと良いでしょう。

記事執筆時点で最新のmacOS Sequoiaでは、「システム設定」の「エネルギー」設定を開いて、「停電時に自動的に起動」をオンに設定することで、電源が復旧した際に自動的に電源が入るようになります（停電前にシステム終了していた場合は電源は入りません）。

古いバージョンのmacOSを使用している場合は、設定の場所がわずかに異なる場合があります。
バージョン別の設定方法については、Appleのサポートドキュメントをご覧ください。

仮想マシンをヘッドレスモードで起動する

Home Assistantサーバーは基本的に、起動するとこのような画面が表示されます。
通常利用時はコマンドラインを使用する事は無いため、基本的にディスプレイは不要です。
そのため、ディスプレイなしの「ヘッドレスモード」で仮想マシンを起動するように設定しておきましょう。
こうしておくことで、不要なウィンドウを表示させずに済みます。

まずは、あらかじめ仮想マシンの電源を切っておきます。
仮想マシンの電源を切るには、Home Assistantの「設定」を開き、右上の「…」から「Home Assistantを再起動」をクリックします。
すると、再起動に関するメニューが表示されるため、「詳細オプション」を開き、「システムのシャットダウン」をクリックすると仮想マシンの電源を切ることができます（電源が切れるまで少し時間がかかる場合があります）。

VirtualBoxでヘッドレス化する

仮想マシンの起動ボタンの右側にあるメニューをクリックして、「ヘッドレス起動」をクリックすることで、ヘッドレスモードで起動することができます。

ディスプレイが必要になった際は、仮想マシンの電源を切って通常起動するか、仮想マシンの電源が入っているときに「表示」ボタンをクリックすることでウィンドウが表示されます。

UTMでヘッドレス化する

仮想マシンの設定を開き、左側の「ディスプレイ」をクリックしたら、左下の「削除」をクリックしてディスプレイを削除します。
その後、右下の「保存」ボタンをクリックして設定を保存します。
その状態で仮想マシンを起動することで、ヘッドレスモードで起動します。

ディスプレイが必要になった際は、仮想マシンの電源を切って設定を開き、左側の「デバイス」のところにある「新規…」をクリックしてディスプレイを追加します。
UTMの場合、仮想マシンの電源が入っている状態ではディスプレイを接続することができないため、必ず仮想マシンの電源を切る必要があります。

Macの起動時にHome Assistantサーバーが起動するように設定する

実は、このままではMacの電源を入れてもHome Assistantサーバーは自動的に起動しないため、手動で仮想マシンの電源を入れる必要があります。
何らかの理由でMacが再起動したときに自動的に起動しなければ、とても不便ですよね。
そのため、Macのログイン時に自動的に仮想マシンが起動するように設定します。

まずは、あらかじめ仮想マシンの電源を切っておきます。
仮想マシンの電源を切るには、Home Assistantの「設定」を開き、右上の「…」から「Home Assistantを再起動」をクリックします。
すると、再起動に関するメニューが表示されるため、「詳細オプション」を開き、「システムのシャットダウン」をクリックすると仮想マシンの電源を切ることができます（電源が切れるまで少し時間がかかる場合があります）。

VirtualBoxの場合

まずはターミナルを使って、仮想マシンが起動できることを確認します。

ターミナルを開いたら、次のコマンドを入力して実行します。

VBoxManage list vms

コマンドを実行すると、VirtualBoxで作成された仮想マシンが一覧で表示されるので、Home Assistantサーバーの仮想マシンの名前を確認しておきます。

仮想マシンの名前が確認できたら、次のコマンドを実行して、仮想マシンが起動することを確認します。

VBoxManage startvm "仮想マシンの名前" --type headless

VirtualBoxを開くか、しばらくしてから「http://homeassistant.local:8123/」にアクセスして、仮想マシンが問題なく起動したことを確認します。
問題なく起動したことを確認したら、もう一度仮想マシンをシャットダウンします。

次に、「テキストエディット」を開き、新規書類を作成します。

新規書類が作成できたら、メニューバーの「フォーマット」から「標準テキストにする」をクリックします。

標準テキストになったら、以下のように入力します。

VBoxManage startvm "仮想マシンの名前" --type headless
exit

「仮想マシンの名前」の部分は、先ほどターミナルでコマンドを実行したものと同じものに置き換えます。

入力できたら、どこかわかりやすい場所にファイルを保存します。
ファイルを保存する際、拡張子を「.command」に変更して保存します。

ファイルを保存できたら、保存したファイルをダブルクリックして開きます。
すると、おそらくこのような画面が表示されると思います。
これは、実行権限が付与されていないためです。

そのため、一旦「OK」をクリックして閉じます。

実行権限を付与するため、ターミナルを開いて以下のコマンドを入力してください（まだ実行はしないでください）。

chmod +x 

最後に半角スペースが1つあるので、忘れずに入力します。
ここまで入力したら、先ほど保存したファイルをターミナルウィンドウにドラッグアンドドロップします。
すると、ファイルパスが自動的に入力されるので、コマンドを実行します。

正しくコマンドが実行されると、何も出力されずに実行が終了します。

もう一度、作成したファイルを開きます。すると、今度は正しく実行されるはずです。
一瞬、このようなウインドウが表示され、すぐに消えるはずです。

最初にターミナルでコマンドを実行した時と同じく、もう一度VirtualBoxを開くか、しばらくしてから「http://homeassistant.local:8123/」にアクセスして、仮想マシンが問題なく起動したことを確認します。
仮想マシンが正しく起動していれば問題ありません。

これで、ファイルを開くだけで仮想マシンを起動することができるようになりました。

最後に、作成したファイルをログイン項目に追加します。

記事執筆時点で最新のmacOS Sequoiaでは、「システム設定」の「一般」→「ログイン項目と機能拡張」を開いて、「ログイン時に開く」のリストに作成したファイルをドラッグアンドドロップします。
これで、macOSにログインした際に、仮想マシンが自動的に起動するようになります。
そのMacをサーバー用としてしか使用しない場合、「自動ログイン」をオンにしておくと、電源を入れたら全自動で仮想マシンが起動するようになります（自動ログインを使うとセキュリティレベルが低下するためご注意ください）。

古いバージョンのmacOSを使用している場合は、設定の場所がわずかに異なる場合があります。
バージョン別の設定方法については、Appleのサポートドキュメントをご覧ください。

UTMの場合

まずはターミナルを使って、UTMをコマンドラインから操作するためのツール「utmctl」が使用できることを確認します。

ターミナルを開いたら、次のコマンドを入力して実行します。

utmctl --help

または

utmctl -h

コマンドを実行した際、「command not found: utmctl」と表示された場合は、次のコマンドを実行してutmctlを使用できるようにします。

sudo ln -sf /Applications/UTM.app/Contents/MacOS/utmctl /usr/local/bin/utmctl

コマンドを実行すると「Password: 」と表示されるので、Macの管理者パスワードを入力します（入力中は何も表示されませんがしっかり入力されています）。
コマンドが正しく実行されると、何も出力されずに実行が終了します。
その後、もう一度先ほどのコマンドを実行してみて、コマンドの使い方が表示されれば問題ありません。

次は、以下のコマンドを実行します。

utmctl list

コマンドを実行すると、UTMで作成された仮想マシンが一覧で表示されるので、Home Assistantサーバーの仮想マシンの名前を確認しておきます。

仮想マシンの名前が確認できたら、次のコマンドを実行して、仮想マシンが起動することを確認します。

utmctl start "仮想マシンの名前"

コマンドを実行したら、念のためもう一度以下のコマンドを実行して、仮想マシンの起動に成功したことを確認します。

utmctl list

「Status」が「stopped」から「started」に変化していれば、仮想マシンが起動したことを表しています。

UTMを開くか、しばらくしてから「http://homeassistant.local:8123/」にアクセスして、仮想マシンが問題なく起動したことを確認します。
問題なく起動したことを確認したら、もう一度仮想マシンをシャットダウンします。

次に、「テキストエディット」を開き、新規書類を作成します。

新規書類が作成できたら、メニューバーの「フォーマット」から「標準テキストにする」をクリックします。

標準テキストになったら、以下のように入力します。

utmctl start "仮想マシンの名前"
exit

「仮想マシンの名前」の部分は、先ほどターミナルでコマンドを実行したものと同じものに置き換えます。

入力できたら、どこかわかりやすい場所にファイルを保存します。
ファイルを保存する際、拡張子を「.command」に変更して保存します。

ファイルを保存できたら、保存したファイルをダブルクリックして開きます。
すると、おそらくこのような画面が表示されると思います。
これは、実行権限が付与されていないためです。

そのため、一旦「OK」をクリックして閉じます。

実行権限を付与するため、ターミナルを開いて以下のコマンドを入力してください（まだ実行はしないでください）。

chmod +x 

最後に半角スペースが1つあるので、忘れずに入力します。
ここまで入力したら、先ほど保存したファイルをターミナルウィンドウにドラッグアンドドロップします。
すると、ファイルパスが自動的に入力されるので、コマンドを実行します。

正しくコマンドが実行されると、何も出力されずに実行が終了します。

もう一度、作成したファイルを開きます。すると、今度は正しく実行されるはずです。
一瞬、このようなウインドウが表示され、すぐに消えるはずです。

最初にターミナルでコマンドを実行した時と同じく、もう一度UTMを開くか、しばらくしてから「http://homeassistant.local:8123/」にアクセスして、仮想マシンが問題なく起動したことを確認します。
仮想マシンが正しく起動していれば問題ありません。

これで、ファイルを開くだけで仮想マシンを起動することができるようになりました。

最後に、作成したファイルをログイン項目に追加します。

記事執筆時点で最新のmacOS Sequoiaでは、「システム設定」の「一般」→「ログイン項目と機能拡張」を開いて、「ログイン時に開く」のリストに作成したファイルをドラッグアンドドロップします。
これで、macOSにログインした際に、仮想マシンが自動的に起動するようになります。
そのMacをサーバー用としてしか使用しない場合、「自動ログイン」をオンにしておくと、電源を入れたら全自動で仮想マシンが起動するようになります（自動ログインを使うとセキュリティレベルが低下するためご注意ください）。

古いバージョンのmacOSを使用している場合は、設定の場所がわずかに異なる場合があります。
バージョン別の設定方法については、Appleのサポートドキュメントをご覧ください。

Macを再起動する際の注意

仮想マシンを起動した状態でMacを再起動する場合、先に仮想マシンの電源を切る必要があります。

仮想マシンの電源を切るには、Home Assistantの「設定」を開き、右上の「…」から「Home Assistantを再起動」をクリックします。
すると、再起動に関するメニューが表示されるため、「詳細オプション」を開き、「システムのシャットダウン」をクリックすると仮想マシンの電源を切ることができます（電源が切れるまで少し時間がかかる場合があります）。

仮想マシンの電源を切らずにMacを再起動すると、仮想マシンを強制終了することになってしまいます。
これは、パソコンの電源ボタンを長押しして強制終了しているのと同じで、仮想マシンの中でデータの読み書きが行われている最中に強制終了されてしまうと、データが破損してしまう場合があります。
特にHome Assistantは、スマートデバイス情報の履歴を定期的に読み書きしているため、データベースが破損してしまう場合もあります。
最悪の場合、仮想マシンが起動できなくなってしまう可能性もありますので、Macを再起動したり電源を切ったりする際は、先に仮想マシンの電源を切ることを忘れないようにしましょう。

さいごに

今回は、MacをHome Assistantサーバーとして使用する方法と、Home Assistantの基本的な設定方法についてご紹介しました。
Home Assistantは非常に高機能で使いやすく、個人的には最高のホームサーバー用OSではないかと思っています。
とても使いやすいバックアップ機能も内蔵されており、万が一の事態が発生した場合に対処しやすいのもうれしいポイントです。

この記事では解説しませんでしたが、Home Assistantサーバーを外部に公開することで、外出先からでもHome Assistantにアクセスすることができ、スマートデバイスを制御することができます。
多くのプラットフォームとは異なり、Home Assistant自体が「ハブ」として機能するため、追加のハードウェアを用意しなくてもオートメーションを使ったり、デバイスを細かく制御したりできるため、手軽に始められて末永く使い続けることができます。

ちなみに、Home Assistantは毎月大型アップデートが配信されており、様々な機能が追加されます。
そのため、現時点では接続できないデバイスでも、今後のアップデートによって対応する可能性もあります。
また、大型アップデートの間にも何度かマイナーアップデートが配信され、様々なバグ修正や改善も行われています。
定期的なアップデートが配信され続けることも、今後も安心して使い続けられる点の1つです。

別のスマートホームプラットフォームを使っている方や、まだHome Assistantを使ったことがない方は、この機会にぜひ使ってみてはいかがでしょうか。

最後まで読んでくださりありがとうございました。それでは、また！

みなさんこんにちは、たいくんです。
2025年4月にTCLから発売された新しいARグラス「RayNeo Air 3s」を使い始めて約2ヶ月経過したので、実際に使ってみてどう感じたのか、以前使っていたXREAL Airと比較しつつ、RayNeo Air 3sの良いと感じたところと残念だと感じたところをレビューします。

前置き

RayNeo Air 3sを購入するまでの流れと、なぜRayNeo Air 3sを選んだのかについて紹介します。

レビューのみを見たい方は前置きを飛ばしてください。

XREAL Airが壊れてしまった

以前、XREALのXRグラスであるXREAL Air（当時はNreal Air）をレビューしましたが、購入してから毎日使っていたところ、テンプル部分が折れて壊れてしまいました…
壊れた後も2度ほど修理に出して使っていたのですが、修理しても3ヶ月ほどで全く同じところが折れてしまい、使えなくなってしまいました。

修理してから3ヶ月で壊れてしまったため、再び修理に出してもまたすぐに壊れてしまうだろうと思い、新しいAR / XRグラスを購入することにしました。

RayNeo Air 3sを選んだ理由

XREAL Airが折れたのは2025年の1月ごろで、まだRayNeo Air 3sが発売されていませんでした。

新しく購入するARグラスの候補として、XREAL Airの不満点が改善されていそうかつ耐久性も高そうな前世代であるRayNeo Air 2sを見つけ、なかなか良さそうだと思っていました。
しかも、ちょうどRayNeo Air 2sが割引されていたので買おうか悩んでいたのですが、様々なレビューを見ていたところ、映像の端がぼやけたりグラス側の設定が保存されず、ケーブルを抜き差しすると設定がリセットされてしまったりといったネガティブなレビューが目立つように感じたため、なかなか購入には踏み切れませんでした。
そのため、XREAL Airの折れた部分をテープでぐるぐる巻きにして騙し騙し使っていたのですが、そんな中、前世代から性能が改善され、より低価格になったRayNeo Airシリーズの新モデル「RayNeo Air 3s」が4月に発売されるという情報を見つけたため、こちらを購入することにしました。

購入の決め手となったのは以下の点です。

• 前世代であるRayNeo Air 2sの内蔵スピーカー音質の評価が高かった
  • 新しいモデルでも同様ではないかと考えた
• 前世代の問題点だったディスプレイの端がぼやける問題が改善されたと公式が謳っている
  • 実際に先行で試した人も、改善されたと言っていた
• テンプル部分の耐久性が高そうに見えた
• 価格が安かった
• かっこいいデザイン

この中でも、最大の決め手は価格です。
当時探していた耐久性が高そうなAR / XRグラスはどれも5万円以上するものばかりで、なかなか気軽に買えるような値段ではありませんでした。

そんな中登場したRayNeo Air 3sのAmazon価格は、発売記念クーポンと合わせて32,999円という、AR / XRグラスの中ではかなり安い価格でした。
クーポンなしの価格でも39,999円と、最新世代のAR / XRグラスの中では最安クラスではないかと思います。

この低価格で音質も良いと考えたら、かなりお得ではないかと思い、速攻で注文しました。

視力矯正レンズも注文した

私は視力が悪く、視力矯正レンズがなければ何も見えないため、同時に視力矯正レンズも注文しました（XREAL Air用の視力矯正レンズとは互換性がありません）。

以前XREAL Airの視力矯正レンズを注文したところと同じJUN GINZAでレンズを作製していただきました。
当時のJUN GINZAのページではRayNeo Air 2用のレンズしか説明がなく、新しいRayNeo Air 3sでも作製していただけるか心配だったため問い合わせしたところ、RayNeo Air 3s用のレンズであることを記載していれば問題ないとのご返答をいただきましたので注文しました。

レンズ（スタートアップ 単焦点 / 薄型）が7480円と「度数特殊加工料金」の5500円、送料1100円を合わせて14,080円でした（すべて税込み）。
記事執筆時点でページを確認したところ、レンズが7480円から7810円に少しだけ値上げしているようです。

レンズを注文してから完成品が届くまで9日ほどでした。

JUN GINZAのページではお知らせとして「当面の間お仕上がりまでの期間を10日間から20日間に変更させていただきます。」と書かれていたので、それを考えると早い方だと思います。
以前XREAL Airのレンズを注文した時よりも長くかかりましたが、その時と比べてAR / XRグラスを使う人がとても多くなったと思いますし、それに伴って視力矯正レンズの需要も増えたのだと思います。

XREAL Airとの違い

以前使用していたXREAL AirとRayNeo Air 3sの違いは以下の通りです。比べた際に優れている方を太字にしています。

これらの違いについて見ていきます。

トラッキングセンサー

頭の動きをトラッキングするセンサーですが、RayNeo Air 3sにはセンサーが搭載されていません。
そのため、頭の動きに応じて映像を動かしたり、仮想空間に複数のディスプレイを並べて使うといった事には対応していません。
分類も異なり、XRグラスに分類されるXREAL Airに対して、RayNeo Air 3sはARグラスに分類されます。

スピーカー

XREAL Airには左右に1つずつ、計2つのスピーカーが搭載されていますが、RayNeo Air 3sは倍の左右に2つずつ、計4つのスピーカーが搭載されています。
これにより、「よりシャープな高音、より豊かな中音、そしてより深みのある低音」を実現したとしています。

また、RayNeo Air 3sには「ウィスパーモード 2.0」という機能が搭載されており、これをオンにすることで音漏れを軽減させることができるようです（自分はこの機能を使う機会がないため、今回はこの機能のレビューは行いません）。

マイク

XREAL Airにはマイクが付いていますが、実はRayNeo Air 3sにはマイクが搭載されていません。

そもそも、グラスに付いているマイクを使う機会はほとんどないですし、XREAL Airに搭載されていたマイクはあまり音質が良いものではなかったため、正直、個人的にはグラスにマイクが付いていてもついていなくてもどちらでも良いかなと思います（スマートフォンに搭載されているマイクの方がよっぽど音質が良いと思います…w）。

ディスプレイの最大輝度

XREAL Airの400ニトに対し、RayNeo Air 3sは650ニトと、250ニト明るくなっています。
この違いがどのくらいあるのかについては後ほどのレビューで紹介します。

OSD機能

XREAL AirにはOSD（オンスクリーンディスプレイ）は搭載されていませんが、RayNeo Air 3sには上記画像のようなOSDが搭載されており、メニューボタンを押すことで表示することができます。
OSDがあることで、音量や明るさを変更したときに現在の設定がどのくらいであるかのゲージや、設定変更の画面が表示されるので、設定変更時に役立ちます。

XREAL Airにはこの機能が無いため、音量を変更しても、実際に音を聞かなければどのくらいの音量かわかりません（デバイス側の音量を見ればわかりますがw）し、明るさを変更しても今の明るさがどのくらいかもわかりづらいです。
また、XREAL Airは音量と明るさ以外の付加機能は少ないです。搭載されている機能は以下の通りです。

• ディスプレイの点灯・消灯切り替え
• オーディオモードの切り替え
  • USBオーディオモードとDisplayPortオーディオモード
• 3Dモードの有効・無効切り替え

一方RayNeo Air 3sはOSDが搭載されており、操作した際に画面に表示されるため、こちらの方が操作性は高いでしょう。
また、RayNeo Air 3sにはいくつか付加機能も搭載されています。搭載されている機能は以下の通りです。

• ウィスパーモードのオン・オフ切り替え
• リフレッシュレートの切り替え
  • 60Hzと120Hz
• ディスプレイカラーの切り替え
  • Standard
  • Game
  • Movie
• 3Dモードの有効・無効切り替え

XREAL Airと比べて、ウィスパーモードやディスプレイカラーの変更ができるようになったのが大きな違いだと思います。

その他の違いについて

重量と視野角については、スペック表ではRayNeo Air 3sの方がわずかに優れていますが、正直、ほとんど体感できる差ではないと思います。
そのため、実質ほとんど変わらないといっても差し支えないでしょう。

レビュー

良いと感じたところ

内蔵スピーカーの音質が良い

RayNeo Air 3sを使ってまず最初に感じた良いところは、内蔵スピーカーの音質が高いことです。

XREAL Airのレビュー記事をご覧いただくとわかりますが、XREAL Airの内蔵スピーカーは低音域が全く聞こえず、音楽を聴いたり映画を観たりするのには向いていませんでした。
私はYouTubeの動画を観るためにMacに接続して使っていて、最初は「この程度なら問題ない」と思っていたのですが、しばらく使っていると低音域が全く聞こえないのが気になってしまったため、以前ブログでも紹介したMacのイコライザーソフト「eqMac」を使って音質を調整して使っていました。

音量が小さくなりすぎず、かつ低音もそれなりに聞こえるラインを探ったところ、イコライザーはこんな感じに設定し、音が割れないようにコンテンツに応じてゲインを調節しながら使用していました。
これでも低音はほとんど聞こえませんが、それでもないよりは幾分もマシになり、人の声なども前より聞こえやすくなりました。

このようにしてかなり設定を詰めながら使っていたのですが、RayNeo Air 3sではそんなことをしなくても、しっかりと低音が聞こえます。
というかむしろ、横向きになって寝ているときは耳がベッドにかなり近くなるため、本体の内蔵スピーカーから出た音がベッドに反射し、低音がうるさいほどに大きく聞こえますw

そのため、横向きになっているときはeqMacを使って低音域を小さくしながら使っています。
仰向けになっているときはイコライザーをオフにして使っています。

中音域や高音域についても音質は高い方で、人の声もくっきりはっきりと大きく聞こえます。
そのため、動画再生どころか音楽を聴いたり映画を観たりしても全然使えるレベルの音質です。
こんな薄いテンプルに入っているスピーカーからこんな音が出るとは思っていなかったので、びっくりしました。

もちろん、イヤホンやヘッドホンなどをお持ちの方はそちらを使った方が音質が高いと思いますが、気軽にYouTubeの動画を観たり音楽を聴いたりする程度であれば、内蔵スピーカーで聴いても全然問題ないレベルの音質です。

ただし、音量を大きめにすると少しだけこもったような音質になってしまいます。
やはりスピーカーが小さいので、音量を上げると少々無理をしているような印象があります。
普通にYouTubeの動画を観る程度では大きい音量にする事はほとんどないので大きな問題ではありませんが、大きい音量で使うことが多い人はイヤホンやヘッドホンなどを接続して使うのがおすすめです。

内蔵スピーカーの音量が大きい

スピーカーつながりで音量についてですが、音量が大きく聞こえます。
XREAL Airは内蔵スピーカーの音量がそんなに大きくなかったため、視聴するコンテンツによっては内蔵スピーカーの音量を最大にしても聞こえにくいことがありましたが、RayNeo Air 3sではそのようなことが一切なく、中くらいの音量でもしっかりと聞こえます。

そのため、RayNeo Air 3sを使い始めてから最大音量で使う事はなくなりました。
というか、そもそも内蔵スピーカーの最大音量がとても大きくなったので、実際に使う際は音量を1/3や1/4程度で使っていますが、このくらいの音量設定でも十分よく聞こえます。

今までは音量が小さかったので、音量の小さいコンテンツを視聴する際は地味にストレスを感じていましたが、音量を上げなくてもしっかり聞こえますし、聞こえにくいコンテンツも音量を上げればしっかり聞こえるようになるので、視聴体験は格段に良くなったように感じます。

ディスプレイが明るい

XREAL Airでも十分に明るいと感じていましたが、RayNeo Air 3sではもう1段階明るくなったように感じます。
この差は劇的ではありませんが、明るい環境で使うときにはより見やすくなったと思います。

RayNeo Air 3sでは、2つの有機ELパネルを重ねたタンデムOLEDを採用しているため、これがこの明るさに貢献しているのでしょう。

XREAL Airと比べてめちゃくちゃ明るくなったわけではないため、太陽に照らされた環境ではまだ明るさが足りないかもしれません。
ただし、室内や直射日光の当たらない屋外の明るい環境では全く問題なく見えるくらいの明るさですので、一般的な使い方では全く困る事は無いでしょう。
むしろ、そんなに明るくない環境ではむしろ眩しいと感じるくらいですので、明るさを最大にして使う事はあまりないと思います。

私は寝る前にベッドで横になりながら使っていますが、部屋を暗くしているので、明るさを最大にしているとかなり眩しいです。
そのため逆に言えば、映画を観る際は部屋を暗くして明るさを上げることで、まるで映画館で観ているような大迫力の映像体験を得られることでしょう（ディスプレイの見え方についてはXREAL Airと同じく、超大画面のディスプレイがあるように見えるわけではないので、その点では迫力に欠けるとは思いますが…）。

USBケーブルが抜けにくい

RayNeo Air 3sはXREAL Airとは異なり、反対側の右側のテンプルにUSBコネクタが付いています。

私は普段使う際は左側を向いて寝ながら使っているため、RayNeo Air 3sではケーブルが右の後ろから出てくることになります。
そのため、ケーブルを頭で踏んでしまうことが多く、少し動くとケーブルを引っ張ってしまうこともあります。
しかし、RayNeo Air 3sのケーブルは簡単には抜けないようになっているので、多少ケーブルを引っ張ってしまってもケーブルが抜けてしまう事はありません。

XREAL Airでも簡単に抜けてしまう事はありませんが、多少力を入れれば簡単に取り外せてしまうため、稀ではありますが、多少気をつけて使わないと誤ってケーブルが抜けてしまうことがありました。
RayNeo Air 3sの場合は結構力を入れなければケーブルが抜けないため、RayNeo Air 3sを使い始めてから今まで、意図せずケーブルが抜けてしまった事は一度もありませんでした。

使っているときにケーブルが抜けてしまうとストレスになってしまいますし、自分の場合は自分でケーブルを接続することができないので、ケーブルが抜けにくいのはとても嬉しいポイントです。

ただし、これはあくまで付属のケーブルを使った場合の話です。
RayNeo Air 3sはUSB Type-Cケーブルを使いますが、他社製のケーブルの場合、全然しっかり固定されず、多少引っ張るとすぐに抜けてしまいます。
もしかしたら、付属のケーブルには専用のロック機構のようなものが付いているのかもしれません。

RayNeo Air 3s用のケーブル単体では売っていないようでしたので、付属のケーブルが壊れてしまったら困ってしまいそうです。
付属のケーブルがすぐに壊れてしまわないことを祈るのみです…。

長時間使っていても鼻が痛くなりにくい

RayNeo Air 3sに付属しているノーズパッドは、内部が空洞になっている構造をしていてクッション性が高く、しばらく使っていても鼻が痛くなりにくいです。
XREAL Airのノーズパッドはあまりクッション性が高くなかったため、しばらく使うと鼻が痛くなることがありました。
私は連続して長めに使うことが多いので、鼻が痛くなりにくいのはとても嬉しいポイントです。

また、ノーズパッドに使われているシリコン部分が取れにくいことも嬉しいところです。
XREAL Airではシリコン部分が頻繁に取れてしまい、かなりのストレスでした（自分の手では取り付けることができないため）。
RayNeo Air 3sを使い始めてから一度も取れたことがないため、ノーズパッドのストレスから解放されたのはとてもよかったです。

テンプルがしなやか

XREAL Airはテンプルの締め付けが少しきつめで、しばらく使っているとこめかみのあたりが痛くなってしまうことがありました。
しかし、RayNeo Air 3sではそのようなことがなく、しなやかで締め付けが優しいので長時間使っていてもあまり痛くなる事はありませんでした。
また、かといって本体がすぐに下がってきたり、頭から外れてしまうようなこともなく、ちょうどいい感じに頭にフィットするように感じました。

XREAL Airのテンプルが折れてしまったのは、この締め付けの強さが原因の1つでもあるのかもしれないと思っていて、本体が下がらないようにしっかりホールドさせようとした結果、テンプルの根元に負担がかかってしまって折れたのではないかと思います。
RayNeo Air 3sの場合は締め付けが強くないため、本体やテンプルへの負荷が少なそうで、耐久性にも期待できそうな感じがします。

残念だと感じたところ

グラス側でしか音量調節ができない

RayNeo Air 3sはXREAL Airと異なり、接続したデバイスとグラス側の音量が連動しません（USBオーディオデバイスとして認識されません）。
AndroidデバイスやWindows PCではグラス側に加え、デバイス側でも音量を変更することができます（それぞれ独立した音量調整ができます）が、iPhoneやiPad、Macの場合はデバイス側は最大音量に固定されるためデバイス側では音量変更ができず、グラス側で音量調整を行う必要があります。
私の場合は自分の手でボタン操作を行うのが難しいため、これは非常に残念なポイントだと思いました。

前世代のRayNeo Air 2sのレビューを見た際にもこのようなことが書かれていて、新しいモデルで改善されていることを期待していたのですが、残念ながらこの機能は変わらなかったようです…。

ただし、Macの場合は先ほども何度か紹介したeqMacを使うことでMac側でも音量調整ができるようになるため、私の場合はグラス側の音量を大きめに設定し、eqMacを使って音量を調整するようにしています。
このようにすることでこの問題点を回避することができたので、（多少不便ではあるものの）特別困る問題ではなかったのがよかったです。

視力矯正レンズの問題

こちらも大きな問題では無いものの、XREAL Airと同じく、視力矯正レンズが結構近いです。
XREAL Airのレビューの時にも書きましたが、まつ毛が長い人はレンズにまつ毛が当たります。
これにより、瞬きするたびにまつ毛がレンズに触れ、レンズがすぐに汚れてしまいます…。これは地味にストレスです。

RayNeo Air 3sの場合はノーズパッドを前後に3段階動かすことができるのですが、レンズフレームはノーズパッドに固定しているため、ノーズパッドを前後に動かしたところでレンズの距離は変わりません。
そのため、グラスを少し目から離した位置に置いて使うか、レンズにまつ毛が当たるのを我慢する必要があります。

また、XREAL Airにはなかった新たな問題点として、レンズフレームがずれたり、取れたりしやすくなったことです。
XREAL Airの場合は視力矯正レンズがノーズパッドにしっかりと固定されるため、ずれることもなければ取れることもありませんでした。
しかし、RayNeo Air 3sではノーズパッドへの固定が甘く、少しレンズを動かすとレンズフレームが斜めになったり、斜めになったレンズフレームを元に戻そうと少し強めに力を入れると、レンズフレームがノーズパッドから取れてしまうことがあります。

レンズが近いのは仕方ないとしても、レンズフレームの固定についてはもう少しどうにかならなかったのかなと思います…。

ディスプレイの品質が悪い

RayNeo Air 3sを使い始めて最初に感じた問題点として、ディスプレイの色が悪いことです。
全体的に黄色っぽいというか緑色っぽいというか、とにかく違和感がある色合いでした。
グラスの設定でディスプレイカラーを「Standard」から別のものに変えてみたのですが、それでも違和感は改善されず、ディスプレイカラーを変更するとコントラスト感も微妙な感じになってしまいました。

いろいろと試行錯誤したところ、結局ディスプレイカラーは「Standard」に戻し、Macのディスプレイ設定*で色合いを青紫方向に動かして調整しました。
画面上に表示される最も明るい白色が「自分の目で白色に見える色合い」になるように調整した結果です。
こうしてみると、デフォルトの色合いが黄緑色方向に寄っていたんだなと思いました。

このように調整したことで、全体的な色合いはだいぶ良くなりました（それでも少し変な色合いな感じがしますが、強い違和感はなくなりました）。
ただし、この設定はあくまで全体的な色合いの調整ですので少し暗い色になるとまだ緑色っぽいような感じが残ります。
これ以上はどうしようもないので、色合いについてはこういうもんだと割り切って使う必要がありそうです（XREAL Airのように将来のファームウェアアップデートで改善されれば良いですが…）。

また、色合い以外にも、映像がわずかに歪んでいるように感じます。
XREAL Airを使っていたときには全く歪みを感じる事はなく、表示部分はきれいな長方形でしたが、RayNeo Air 3sでは左右がわずかに下方向（または中央が上方向）に歪んでいて、ほんの少しだけ扇形のように見えます。
歪みによって映像が見づらくなる事はありませんが、RayNeo Air 3sを使い始めた時は違和感を感じました。
しばらく使った今ではそんなに気にならなくはなりましたが、他のAR / XRグラスから買い替えようと思っている方は少し注意した方が良いでしょう。

さらに歪みだけではなく、ディスプレイ自体の視野角が少し狭いです。
ここでの「視野角」は上記の比較で見た視野角（FOV）のことではなく、ディスプレイを斜めから見たときに色合いが変わらない範囲のことです。
「AR / XRグラスのディスプレイは斜めから見ることができないから視野角なんて関係ないのでは？」と思うかもしれませんが、実は視野角が狭いと、ディスプレイの中央から離れたところを見る際に気になります。
ディスプレイの中央は正面から見ることになりますが、ディスプレイの端（特に左右）は、少しだけ斜めから見ることになります。

RayNeo Air 3sのディスプレイは視野角が少し狭く、端っこなどを見る場合など、左目と右目でわずかに色合いや明るさが異なるように見える場所があります。
XREAL Airの場合はIPSパネルのディスプレイを見ているような感じでしたが、RayNeo Air 3sはTNパネルのディスプレイを見ているような感じで、特に明るさの違いが気になるため、画面の端っこにある文字を見る際などに少し見づらさを感じます（しばらく見ていると目が疲れそうな感じ）。

また、視野角が狭いことで、スイートスポット（快適に視聴できる範囲）の狭さも感じます。
グラスをほんの少し上に持ち上げて、ディスプレイを少し下から覗き込むように見ると、色合いが結構変化します。
また、グラスを左右に少しずらして斜め横からディスプレイを見ても、色合いが変化しているのがわかります。
瞳孔間距離（IPD）が広い方などは映像の見づらさを感じる可能性があります（RayNeo Air 3sではIPDを調節することはできません）。

やはり、こうした点でコストカットされているのだろうなと感じます。
ただし、前世代のRayNeo Air 2sのレビューで見たようなディスプレイの端がぼやけて見えるような感じは全くなかったため、この点はしっかり改善されているのだと思います。

実際の見え方を言葉だけでお伝えするのは難しいため、どんな感じに見えるかを視覚的に表した画像を作成しました。
外側（サングラス部分）のレンズは少し黄色っぽい色付きのレンズになっていて、周りの世界はこんな感じに黄色く薄暗く見えます。

周りが明るい環境だとディスプレイの後ろが少しだけ透けて見えます。
後ろが透けて見えて欲しくない場合はディスプレイの明るさを上げて部屋を暗くするか、何かでレンズを覆う必要があります（レンズシールドは付属していないため要注意）。

調整する前のディスプレイの色合い（「Standard」モード時）はこの画像のように、少し黄緑色っぽく見えます。
また、ディスプレイの歪みもほんのわずかではありますが、湾曲したように見えるのがわかるかと思います。

参考までに、特に色合いや歪みなどに手を加えていないスクリーンショットがこちらです。
この画像と比べながら見るとどんな感じに見えるかがわかるかと思います。

* システム設定から「ディスプレイ」設定を開き、カラープロファイル一覧の中にある「プロジェクタ…」をクリックすることで色合いの調整画面を開くことができます。

付属のケーブルが取り回しづらい

RayNeo Air 3sに付属のケーブルはXREAL Airに付属するものとは異なり、少し太めで硬いケーブルです。
XREAL Airに付属するケーブルはメッシュ素材でしなやかな取り回しやすいケーブルが付属していたので、長時間使っていてもあまり不快感はなかったのですが、RayNeo Air 3sを使い始めた時はケーブルが邪魔に感じることがありました。

また、XREAL Airに付属するケーブルよりも少し短めなので、接続するデバイスが少し離れた場所にあると少し使いづらいです（その分ケーブルの耐久性が高いと良いのですが…）。
そのため、柔らかくてもう少し長めのケーブルが付属していたらよかったなと感じました。

ディスプレイの表示によってノイズが聞こえることがある

最後は、使っていて気づいたちょっと意外な問題点です。

XREAL Airの時には一切なかったのですが、RayNeo Air 3sでは、ディスプレイに特定の画面を表示させると本体の右側から「ジー」という、虫の羽音や蛍光灯のようなノイズ音が聞こえることです。
例えば、画面の半分以上が白い背景で小さな黒い文字が多く並んでいる状態や、その逆に画面の半分以上が暗い背景で小さな白い文字が多く並んでいる状態の時など、細かいものが連続して並んでいる画面を表示している時に聞こえることが多いです（スクロールするなどして画面上に表示される文字の数が少なくなるとノイズの音量も小さくなります）。
この音がスピーカーから鳴っているのかどうかはわかりませんが、右側だけしか聞こえないことから、搭載されている何らかのチップなどから音が鳴っているのかもしれません（USBコネクタが右側にあり、発熱を感じるのも右側のみのため、右側のテンプル内にメイン基板が入っている可能性が高いです）。

フルスクリーンで動画を見ているときにこのような音が鳴る事はほとんどないため気にならないことが多いですが、RayNeo Air 3sで（記事を読んだり文章を書いたりする作業など）何らかの作業をしている場合はこの音が結構気になります。

スピーカーから音を鳴らさずに静かな環境で作業したい方や不快な音が鳴って欲しくない人は要注意です。
私のように動画視聴がメインであれば大きな問題ではないと思います。

総評

前モデルから低価格になって手に入れやすくなったARグラス「RayNeo Air 3s」を身体障害者が2カ月間使ってみて感じたことをレビューしました。

以前使っていたXREAL Airはかなり気に入って使っていたのですが、あまり耐久性が良くなかったため壊れやすいのが残念でしたが、今回のレビューしたRayNeo Air 3sはいくつか欠点はあれど、内蔵スピーカーの音質が良くなっていてデザイン性も高く、XREAL Airを使っていた時に感じていたノーズパッドによる鼻の痛みやUSBコネクタの抜けやすさがなくなり、今回のRayNeo Air 3sもかなり気に入りそうな感じがしました。

ディスプレイ品質の悪さについては残念ながら使い手側ではどうすることもできませんが、色合いについては使うデバイス側である程度調整することはできますし、XREAL Airを使っていた時に感じていた多くの不満点が解消されたので、個人的にRayNeo Air 3sはとても良いARグラスではないかと思います。
ただし、使っているときに片側からノイズが聞こえることがある問題はかなり気になるので、次世代モデルではここで挙げた問題点が改善されていると良いと思いました。

前世代のRayNeo Air 2sのレビューで見たディスプレイの端がぼやける問題やケーブルを抜き差しすると設定（明るさや音量など）が初期状態にリセットされてしまうといった問題点はしっかり改善されているのは評価が高いです。

RayNeo Air 3sは最新のAR / XRグラスの中ではかなり低価格な部類だと思いますが、使っている際に支障を感じるような大きな問題点はなかったため、この記事で挙げた不満点を特に問題ないと感じる人であれば、間違いなく購入することをおすすめします。
他のXRグラスとは異なり、頭を動かして見るコンテンツを楽しむ事はできませんが、はじめてのARグラスとしてや、コンパクトなディスプレイとして使いたい方にはとてもぴったりだと思います。
一方で完璧なARグラスではないため、ここで挙げた不満点に対して少しでも不安を感じる人であれば別のAR / XRグラスを選択することをおすすめします。

最後まで読んでくださりありがとうございました。それでは、また！

みなさんこんにちは、たいくんです。

2022年10月4日に、スマートホームの新規格「Matter 1.0」が開始されました。
それにより、様々なメーカーやデバイスがMatterの対応を続々と開始していますが、Matterに興味を持った方の中には、Matterが何か、Matterに対応すると何が起きるのかなどを理解していない方も多いのではないでしょうか？
この記事では、Matterとは一体何か、Matterに対応すると何が起きるのか、Threadネットワークとは一体何か、Threadに対応すると何が起きるのかを、詳しく解説していきます。

Matterとは？

スマートホームの新しい規格

Matterとは、無線通信規格標準化団体「Connectivity Standards Alliance」（CSA）が制定した、スマートホームの新規格です。

2023年10月時点で最新のMatter 1.2では、対応デバイス同士の接続に使用される通信には、イーサネット、Wi-Fi、Thread、Bluetooth Low Energy（BLE）があります。

そして、動作には主に、Wi-Fi（Matter over Wi-Fi）とThread（Matter over Thread）のネットワークが使用されます。
BLEは、接続するデバイス同士の検証に使用されます。
イーサネットは、Wi-FiかThread（または両方の）ネットワークで構築されたMatter対応のスマートデバイスにアクセスするための1つの経路として使用されます。

Threadについての詳細は後述の「Threadとは？」をご覧ください。

多くの企業が参加している

記事執筆時点でのMatterに参加している企業の数は270社以上です。
その中にはAmazon、Apple、Googleなど、主要なプラットフォームを提供している企業も参加しています。

そして、すでにAmazon、Apple、GoogleなどはMatter（Matter対応デバイスを制御するためのMatterコントローラー機能）に対応しています。

そのため、かなり期待できる規格だと言えそうです。

Matterコントローラーについて

Matter対応デバイスを制御するためには、ハブとなるMatterコントローラーが必要です。
こう聞くと、わざわざコントローラーを用意するのは大変だと思うかもしれませんが、実は身近な製品がMatterコントローラーとして機能します。

例えば、2023年5月時点でのAmazon、Apple、Google製品では、以下のデバイスがMatterコントローラーとして機能します。

• Amazon Echo Dot 第3世代、第4世代、第5世代
• Amazon Echo Dot with clock 第3世代、第4世代、第5世代
• Amazon Echo 第3世代、第4世代
• Amazon Echo Studio
• Amazon Echo Pop
• Amazon Echo Input
• Amazon Echo Flex
• Amazon Echo Show 5 第1世代、第2世代、第3世代
• Amazon Echo Show 8 第1世代、第2世代
• Amazon Echo Show 10 第3世代
• Amazon Echo Show 15
• Apple HomePod 第1世代、第2世代
• Apple HomePod mini
• Apple TV HD*
• Apple TV 4K 第1世代、第2世代、第3世代*
• Apple iPadシリーズ* **
• Google Home
• Google Home Mini
• Google Nest Audio
• Google Nest Mini
• Google Nest Hub 第1世代、第2世代
• Google Nest Hub Max
• Google Nest Wifi Pro ルーター（日本未発売）

* ホームハブとして設定した場合に利用できます。

** Appleの新しいホームアーキテクチャにアップグレードした場合は利用できなくなります。

スマートホームに興味がある人であれば、これらの製品を1つ以上持っている方も少なくないと思います。

また、これらの製品を持っていない方でも、お使いのスマートフォンやタブレットに、Matterコントローラー機能が内蔵されたアプリケーション（Appleの「ホーム」やGoogleの「Google Home」など）をインストールすることでも、Matter対応デバイスを制御することができるようになります。
ただし、外出先などの異なるネットワークから制御したり、オートメーション（スマートデバイスの自動制御）を確実に実行したりすることができない場合があります。そのため、（Matter対応デバイスの安定動作のためにも）1つ以上はMatterコントローラーとなるスマートデバイス（上記など）を用意しておくべきでしょう。
アプリケーションはあくまで「Matter対応デバイスを制御するだけのもの」であり、「ハブではない」ため、注意が必要です。

他にも、利用するプラットフォームごとに、そのプラットフォーム用のMatterコントローラーが必要になります（例えば、Apple HomeKitの場合はHomePodやApple TVなどのホームハブが必要）。

なお、Wi-Fiネットワークではなく、Threadネットワークを利用するMatter対応デバイスを制御する場合は、Threadボーダールーター機能を内蔵するデバイスが必要になります。
詳しくは後述の「Threadとは？」をご覧ください。

以前までの不便が解消される

以前は、Amazon Alexa、Apple HomeKit、Google Homeなど、様々なメーカーが様々なプラットフォームを提供してきましたが、それゆえに「特定の製品が特定のプラットフォーム上でしか動作しない」といったことが起こっていました。
例えば、カーテン開閉デバイスの「SwitchBot カーテン」（と、SwitchBot ハブミニなどの旧型ハブを使った場合）は、Amazon AlexaやGoogle Homeなどでは機能するものの、Apple HomeKitには対応していないため、機能しないといった現象です。

プラットフォームがたくさんあるという事は、製品を作るメーカーがたくさんのプラットフォームに対応させる必要があり、また、利用するユーザーは自分が使いたいプラットフォームに対応している製品のものを購入する必要があるため、メーカーにとっても、ユーザーにとっても不便でした。

しかし、Matterの登場により、これらの常識が一変します。

Matterでどう変わる？

あらゆるプラットフォームに対応する

以前まではスマートデバイスを購入する際、自分の使いたいプラットフォーム（例えばApple HomeKitなど）に対応しているかどうかを確認する必要がありました。

しかし、現在では多くのプラットフォームがMatter対応デバイスの制御に対応しています。
逆に言えば、Matterに対応しているという事は、多くのプラットフォームにも対応しているということになります。

そのため、これからの時代はスマートデバイスを購入する際、「Matterに対応しているか」を確認するだけで良くなります。

他にも、メーカーは、様々な企業が提供する独自規格ひとつひとつに対応する必要がなく、「Matter」という1つの規格に対応さえすれば、様々なプラットフォームで動作させることができるようになります。

先程の例で言えば、カーテン開閉デバイスの「SwitchBot カーテン」に、Matter対応のハブである「SwitchBot ハブ2」を組み合わせることで、Matter対応のプラットフォーム（以前は利用できなかったApple HomeKitなど）に登録して制御することができるようになります。

Matterという規格は、製品を作るメーカーや製品を利用するユーザーにとって、負担が減るものになっています。

様々なプラットフォームで同時に利用できる

Matterの登場以前は、一部の製品以外は1つのプラットフォームでしか動作させることができませんでした。

例えば、スマートライトである「Nanoleaf Essentials」（Matterに対応する前のもの）は、Apple HomeKitやGoogle Homeなどに対応していますが、Apple HomeKitでセットアップした後はApple HomeKitに紐付くため、Google Homeなどの他のプラットフォームに登録することができなくなります。
Apple HomeKit以外で利用したい場合は、Apple HomeKitからペアリングを解除し、利用したいプラットフォームでセットアップを行う必要があります。
もちろん、Apple HomeKitからペアリングを解除したため、Apple HomeKitで制御することができなくなりました。

このように、（Philips Hueなどの）一部の製品を除き、多くの製品は複数のプラットフォーム上で同時に製品を制御する事は出来ませんでした。

それが、Matterに対応していれば、Matterに対応したすべてのプラットフォームに同時に登録することができ、もちろん、同時に利用することもできます（要するに、1つのデバイスを複数のプラットフォームで共有できるということ）。

また、複数のプラットフォーム間でMatter対応デバイスの状態は共有されているため、例えばApple Homeアプリで電球をオフにすると、他に登録しているプラットフォームでも電球がオフになったと表示されます。

もちろん逆に、Google Homeアプリで電球をオンにすると、他に登録しているプラットフォームでも電球がオンになったと表示されるのです。

スマートスピーカーのメーカーを縛られなくなる

しかし、スマートホームを構築してきたユーザーの中には、このメリットがいまいち理解できないという方もいるかもしれません。
確かに、以前は1つのプラットフォームに集中して利用する必要があったため、他のプラットフォームと同時に利用することがないと考えている方もいると思います。

複数のプラットフォームで同時に利用できることのメリットとしては、「スマートスピーカーのメーカーを選ばない」ことだと思います。

例えば、以前まではApple HomeKitでスマートホームを構築してきたため、スマートスピーカーにApple HomePodシリーズを利用していたとします。
しかし、Apple HomePodシリーズは他のスマートスピーカーと比べて品質が高い分、価格も高くなってしまい、Apple HomePodシリーズを家中にたくさん置くことが出来ませんでした。
そのため、音声でスマートデバイスを制御する際、Apple HomePodシリーズが近くにある部屋でないと音声で制御することができません。

これがMatterに対応した今であれば、それぞれのプラットフォームに登録する手間が増えるものの、一度登録してしまえば、Matter対応のスマートスピーカーを様々な部屋に設置し、様々なスマートスピーカーを利用してスマートデバイスを制御することができるようになります。

つまり、リビングにはApple HomePodシリーズを、廊下にはAmazon Alexa搭載デバイスを、自室にはGoogle Assistant搭載デバイスを設置して、それぞれのスマートスピーカーで1つのスマートデバイスを制御する、といったことが可能になります。
例えば、リビングにあるApple HomePodシリーズや、廊下にあるAmazon Alexa搭載デバイス、自室にあるGoogle Assistant搭載デバイスのどれからでも廊下の電気を制御することができる、というわけです。

当たり前ではありますが、注意すべきなのはスマートスピーカーがMatterに対応したからといって、Matterではない既存のスマートデバイスが他のプラットフォームに登録できるようになるわけではありません（要するに「Apple HomeKit」などの既存の規格は既存のまま）。
スマートスピーカー側もスマートデバイス側も、Matterに対応している必要があります。

また、スマートスピーカーはあくまで「Matterコントローラー」です。つまり、制御する側であり、制御される側ではないため、プラットフォームの異なるスマートスピーカーを制御することはできません（例えば、Apple HomeKitでGoogle Nest Audioは制御できない）。

スマートデバイスをローカルで制御できる

Matterに対応したデバイスは、基本的にはローカルネットワークから制御されます（一部のデバイスはメーカーからの独自機能を提供するため、クラウドに常時接続されるデバイスもありますが、基本的な制御はローカルから行えます）。
そのため、高速なレスポンスと、動作の安定性、セキュリティやプライバシーが高まります。

また、スマートデバイスの製造元が提供するクラウドサービスがダウンしたり、サービス終了などにより提供されなくなったりした場合でも、スマートデバイスが制御できなくなることがなく、壊れるまで使い続けることができます。

従来のスマートホームと組み合わせられる

Matterは、従来のスマートホームとシームレスに統合するため、今まで頑張って構築してきたスマートホームを置き換える必要はありません。
今までのスマートホームにMatter対応のデバイスを追加し、両方を利用することができるのです。

従来のスマートデバイスをMatter対応にアップグレードできる可能性がある

従来のスマートデバイスに、Matter対応のハブなどを追加したり、ソフトウェアアップデートをインストールしたりすることによって、Matter対応にアップグレードできる可能性があります。

例えばSwitchBotの場合は、SwitchBotの新しいハブである「SwitchBot ハブ2」を購入してシステムに追加すると、SwitchBot製品が（全てではありませんが）Matter対応にアップグレードできます。

IKEAの場合は、IKEAの新しいハブである「DIRIGERA/ディリフィエラ スマート製品用ハブ」を購入してシステムに追加すると、IKEAのスマート製品がMatter対応にアップグレードできます。

Philipsの場合は、Philips Hue ブリッジのソフトウェアアップデートによってMatter対応にアップグレードできることが発表されています。
Bluetooth接続の製品のみを持っている場合は、Philips Hue ブリッジを導入し、ソフトウェアアップデートを適用することで、Philips Hue ブリッジに登録されたほぼすべてのデバイスがMatter対応にアップグレードできます。

このように、既存のスマートデバイスを買い替えなくてもMatter対応にアップグレードできる可能性が残されていて、上記で説明したような恩恵を受けられる場合があります。

なぜこのようなことができるのかというと、実はMatterは新しい通信技術を使ったものではありません。
既存の通信技術を用いて、様々なメーカーやプラットフォーム上で相互運用できるように開発された規格なのです。
そのため、Matterで利用するために必要なチップなどが搭載された既存のデバイスの場合、（メーカーの裁量や、搭載されているハードウェア次第ではありますが）ソフトウェアアップデートによってMatterを利用することができる場合があるのです。
必要なチップなどが搭載されていない既存のデバイスの場合は、必要なチップなどを搭載したハブがメーカーから発売された場合、それを追加することでMatterを利用する事できます。

注意: プラットフォーム独自機能が利用できなくなる可能性がある

Matterは、様々なプラットフォーム上で動作するように互換性重視で設計されています。
そのため、現時点では残念ながらプラットフォームが独自に提供する機能が利用できなくなる可能性があります。

例えば、Apple HomeKitの場合、照明デバイスでは「適応型照明」という機能があります。
これは、1日を通して照明の色を自動で調整する機能です。午前中の明るい時間帯には集中力を高めるとされている（色温度の高い）青白い光に、夕方から夜にかけて温かみのある（色温度の低い）オレンジ色に変わっていきます。

この機能はApple HomeKitに対応し、なおかつ適応型照明機能に対応した照明デバイスである必要があります。

Matterの場合、適応型照明に対応していない照明デバイスと同じく、Apple HomeKitに「一般的な照明デバイスとして認識させる」だけであり、「適応型照明機能に対応した照明デバイスとして認識させる」わけではないため、高度な制御には対応していません。

実際に試した方も、適応型照明機能が利用できない照明デバイスとして認識されると報告しています。

さらにスマート照明のPhilips HueをMatter対応とすることで、一つのデメリットも見えてきました。Philips HueをHomeKit対応デバイスとして使っていた時にはHomeKitの固有機能である適応型照明が使えていました。

しかしMatter対応デバイスとしてホームアプリに登録すると、この機能が使えません。このような例は他のスマートホーム関連製品でも起こり得そうです。Matterは最低限の互換性を確保することを優先して、こうした機能は省略されているのかもしれません。

Philips HueをMatterデバイスとしてホームアプリに登録するデメリット – ふーてんのiPad

追記: iOS 18以降では、Matter照明デバイスにも適用型照明のサポートを拡大したため、ハードウェアの最小要件を満たしている照明デバイスでは適用型照明を利用することができるようになりました。

それ以外にも、「HomeKit セキュアビデオ」という、一部のHomeKit認証されたセキュリティカメラやドアベルに搭載されたカメラで利用できる機能があります。
これは、収録された映像をホームハブが解析し、人物や動物、車などを認識し、録画できるようになる機能です。

現在のMatterではセキュリティカメラに対応していませんが、今後対応したとしても、この機能は利用できない可能性が高いです。

このように、プラットフォームが独自に提供する機能が利用できない可能性があるため、そこは注意する必要があります。

なお、製品がMatter対応のものや、Matter対応にアップグレードされた製品であっても、（Philips Hue デバイスのように）Matterに加えて使いたいプラットフォームに個別に対応している場合は、「Matter製品として」ではなく、「そのプラットフォーム対応の製品として」登録することで、そのプラットフォームが独自に提供する機能を利用することができます。
そのため、これらの制限は、プラットフォーム登録時に注意する必要があります。

Threadとは？

スマートデバイス向けのメッシュネットワーク

Matterを語るにあたって欠かせないのが「Thread」です。
Threadネットワークとは、スマートデバイス（IoT）向けに作られたもので、Threadボーダールーターとそれに接続するデバイスからなるメッシュネットワーク技術です。
メッシュ、つまり、網目のように接続されることから「メッシュネットワーク」と呼ばれます。

Matterを利用するには、Wi-Fiネットワークを利用する方法と、Threadネットワークを利用する方法があります（2つを同時に利用することも可能）。
必ずしもThreadネットワークを利用しなければならないという事はありませんが、Threadネットワークを利用するメリットはたくさんある（そして、身近なデバイスがThreadに対応している）ため、Threadネットワークの概念を多少なりとも理解しておくべきだと思います。

今までのスマートデバイスとは違い、Matterの登場によって、Wi-FiやBluetoothだけでなく、Threadネットワークが利用できるデバイスが一気に増えると思われます。

Threadデバイスの種類

Threadに対応したデバイスには、大きく3つに分けられます。

• Threadボーダールーター（Thread Border Router。「Thread境界ルーター」などとも呼ばれる）
• ルーター（Router）*
• エンドデバイス（End Device）

Threadボーダルーターとは、Threadネットワークとそうでないネットワーク（Wi-Fiやイーサネット、クラウド）をつなぐデバイスです。
Threadネットワークにアクセスするために1つ以上必要です。複数のボーダールーターを設置することで、Threadネットワークにアクセスするための安定性が向上します。

ルーターは、別のThread対応デバイスにパケットを転送する仲介機能や、Threadネットワークを拡張する機能を持つデバイスです。
他のルーターやエンドデバイスと接続する中継器としての役割を果たします。また、複数のルーターを設置することで、複数の通信経路が確保され、Threadネットワーク内の安定性が向上します。

エンドデバイスは、上記機能は持たず、Threadネットワークに参加する機能のみを持つデバイスです。
上記デバイスとは異なり、エンドデバイスは1つのルーター（またはボーダールーター）とのみ接続します。エンドデバイス同士が接続する事はありません。他のThread対応デバイスにパケットを転送しないため、低電力で動作させることが可能です。
ルーター1台あたりにつき、511台までのエンドデバイスが上限となります。

ルーターとエンドデバイスは、親子関係です。
ルーターが親となり、エンドデバイスが子となります。

基本的には、これらの3つを理解しておけば問題ないでしょう。

* この記事では、ThreadルーターとWi-Fiルーターを区別するため、Threadルーターのことを「ルーター」、Wi-Fiルーターのことを「Wi-Fiルーター」と記述しています。なお、Threadネットワーク以外のネットワークを、わかりやすいようにWi-Fiネットワークで紹介していますが、イーサネットを使った有線での接続も可能です（ボーダールーターが接続されているローカルネットワークと同一のネットワークに限る）。

エンドデバイスの種類

エンドデバイスの中には、エンドデバイスだけではなくルーターとしても機能するものがあります（先ほど紹介した「Nanoleaf Essentials」はこれにあたります）。
これを「ルーター適格エンドデバイス（Router Eligible End Device。以下「REED」）」といいます。

REEDがエンドデバイスとして機能している時、新しいエンドデバイスを接続する際にこのREEDを経由する必要がある場合はルーターとして機能しますが、他のルーターを経由するなどして、このREEDを通して接続するエンドデバイスが1つもなくなった場合は、このREEDがエンドデバイスとして機能します（ただし、Threadの仕様としてREEDがエンドデバイスとして機能している時、Threadネットワーク内のルーターの数が16未満である場合は、このREEDがルーターとして機能します。また、Threadネットワーク内のルーターの数が24台以上になると、自動的にエンドデバイスとして機能するように調整されます）。

REEDの場合は、このようにして自身をルーターにアップグレードしたり、エンドデバイスにダウングレードしたりすることができます。

逆に、ルーターとして機能させることができない純粋なエンドデバイスのことを「フルエンドデバイス（Full End Device。FED）」といいます。

Thread対応デバイスには他にも様々な種類があるため、興味のある方は、GoogleによるThreadのオープンソース実装である「OpenThread」のガイドをご覧ください（機械翻訳のため、少しわかりにくい部分があります。その場合は英語でご覧ください）。

Threadボーダールーターについて

Threadネットワークは、Wi-Fiネットワークなどとは異なる独自のネットワークです。そのため、Threadネットワークを構築し、アクセスするためにはThreadボーダールーターが1つ以上必要になります（ルーターのみだとThreadネットワークにアクセスできません）。

記事執筆時点において、Threadボーダールーターとして機能するデバイスは以下のようなものがあります。

• Amazon Echo 第4世代
• Apple HomePod 第2世代
• Apple HomePod mini
• Apple TV 4K 第2世代
• Apple TV 4K 第3世代（Wi-Fi + Ethernetモデルのみ）
• Google Nest Hub 第2世代
• Google Nest Hub Max
• Google Nest Wifi ルーター（まもなく対応予定）
• Google Nest Wifi 拡張ポイント（まもなく対応予定）
• Google Nest Wifi Pro ルーター（日本未発売）
• Nanoleaf Shapes（ファームウェアバージョン6.1.1以上）
• Nanoleaf Elements（ファームウェアバージョン6.1.1以上）
• Nanoleaf Lines

ここで挙げたものは一例に過ぎず、今後さらなる対応デバイスが増えていくことでしょう。
Thread認証デバイス（ボーダールーターに限らない）はこちらの公式サイトをご覧ください。

先ほど説明したようにThreadネットワークは独自のネットワークのため、ボーダールーターがWi-Fiネットワークの通信圏内にあれば、接続するデバイスがWi-Fiネットワーク圏外でも（ボーダールーターと通信可能なルーターが近くにある限り）、利用することができます。

ちなみに、異なるメーカーのボーダールーターを様々なプラットフォームで共有することができる場合が多いです（例えば、Appleの場合は他社製ボーダールーターにも対応）。
そのため、基本的には利用するプラットフォームごとにボーダールーターを用意する必要はないと考えて問題ありません。

また、異なるメーカーのボーダールーターやルーターを使って既存のThreadネットワークを拡張したり、強化したりできます。
Amazonの場合は「Threadネットワークの認証情報を共有する」と正式に発表しているため、AmazonのThreadボーダールーター・ルーターの場合は既存のThreadネットワークを拡張・強化できることがわかります。
Googleの場合も、こちらの記事で既存のThreadネットワークを拡張することができると記載されています。

通信経路の例

Threadネットワークの通信経路の例はこんな感じです。
ルーターやエンドデバイスの数に応じて経路は動的に変わりますが、エンドデバイスに到達するにはルーター（またはボーダールーター）を経由する必要があることがわかると思います。

この例の場合、エンドデバイス1にアクセスするためには、以下の経路でアクセスされます。

1. ボーダールーター
2. ルーター1
3. エンドデバイス1

エンドデバイス2または3にアクセスするためには、以下の経路でアクセスされます。

1. ボーダールーター
2. ルーター1
3. ルーター2
4. エンドデバイス2または3

動作中のルーターがダウンした場合はこのように、残りの動作しているルーターを経由するように、即座に通信が切り替えられます。
この例の場合は、動作しているルーターが「ルーター2」のみのため、すべてのエンドデバイスにアクセスする際にルーター2が経由されます（ボーダールーターが経由される場合もある）。

Threadネットワークはこのように、安定した通信ができるように設計されているのが特徴です。

Threadでどう変わる？

Wi-FiやBluetoothの届かない所にも設置できる

この画像は通信可能な距離を視覚的に表したものです。実際の通信経路を表しているわけではないためご注意ください。

以前までのWi-FiやBluetoothを使用するスマートデバイスの場合、Wi-FiやBluetoothの電波が届かない所（玄関先や庭、2階や3階の端など）にはスマートデバイスを設置できなかったため設置自由度が低いのが問題でした。

Wi-FiやBluetoothの場合は、スマートデバイスと接続先（Wi-Fiルーターやスマートフォンなど）の距離が制限されるため、遠くまで接続する場合はより強力なWi-Fiルーターに置き換えるか、途中に中継器となるアクセスポイントを設置する必要があります。
Bluetoothの場合は中継器があまり一般的ではないため、基本的にはスマートデバイスと接続先のBluetooth通信圏内に限定されます。

それがThreadでは、それぞれのデバイスが通信できる距離かつボーダールーターがWi-Fiに接続できる距離であれば、Wi-FiやBluetoothなどの電波強度に左右されずに自由な場所にデバイスを設置することができるようになります。
つまり、ルーター同士がお互いに通信可能な距離であれば、理論上は無限に通信可能な距離を伸ばすことができます。

遠く離れた場所にあるデバイスが直接ボーダルーターにアクセスできなくても、その中間地点にあるルーターを通じてボーダルーターと通信を行うため、遠くにあるデバイスでも問題なく通信が行えるのです。

対応デバイスの安定性（冗長性）が増加する

スマートデバイスと接続先の距離が離れていると、接続はできていても通信が不安定になり、操作に遅延が発生したり、時々応答しなくなってしまったりする事態が起こってしまいます。

ところがThreadネットワークでは、メッシュネットワーク技術を用いて、Thread対応デバイス（ルーター）がお互いに通信を行うため、複数の通信経路が確保されます。それにより、離れた場所にあるThread対応デバイス（ルーターとエンドデバイス）への通信安定性が向上します。

また、Threadネットワークには単一障害点がないように設計されています。
単一障害点とは、ある1つの場所に障害が発生するとシステム全体が動作しなくなってしまう場所のことをいいます。

例えば、以前までのWi-Fiを利用するスマートデバイスの場合、接続先のWi-Fiルーターが1つしか設置されていない（冗長化されていない）場合、すべてのスマートデバイスが1つのWi-Fiルーターに集中して接続しているため、そのWi-Fiルーターが故障してしまうと、そのWi-Fiルーターに接続していたすべてのスマートデバイスにアクセスすることができなくなります。この場合はWi-Fiルーターが単一障害点となり得ます。

しかし、Threadの場合は多くの製品がボーダールーターとして動作するため、複数のボーダールーターまたはルーターを設置しておけば、いくつかのデバイスがダウンしたとしても、残りのデバイスで（ダウンしたデバイスを除いた）全てのスマートデバイスを接続状態にしておくことができます。この場合はThreadネットワーク内に単一障害点が存在しないことになります（1つのボーダールーター設置していない場合は、これが単一障害点になり得るため注意）。

Threadでは、ボーダールーターの数を増やすことで簡単に冗長性を高めることができるのが特徴です。

対応デバイスの速度が向上する

Threadネットワークは非常に高速です。
従来のスマートデバイスでは制御に時間がかかったり、応答なしになってしまうことがよくありましたが、Threadネットワークは安定していて、高速に動作します。

そのため、今までのような低速なスマートデバイスにイライラすることがなくなります。

対応デバイスのセキュリティが高まる

Threadネットワークは非常に高度なセキュリティで保護されています。
そのため、Threadネットワークに接続されているデバイスは高いセキュリティレベルを保有しています。

また、Threadネットワークに参加する時も認証されたデバイスのみが参加でき、ネットワーク内のすべての通信が暗号化されているため、安全性が高いと言えます。

MatterとThreadでスマートホームを構築する方法

必要なもの

MatterとThreadを使ったスマートホームを構築するためには、以下のデバイスが必要になります。

• Matterコントローラー（使いたいプラットフォームに対応したもの。1つ以上）
• （Threadを利用する場合）Threadボーダールーター（1つ以上、安定性を高める場合は2つ以上）
• Matter対応スマートデバイス（好きなだけ）

最低限これらのデバイスがあればMatterとThreadでスマートホームが構築できます。

構築の例

• プラットフォームはApple HomeKit
• HomePod mini 2台
• Philips Hue ブリッジ 1台
• Philips Hue フルカラー シングルランプ E26 1600lm 4台
• Nanoleaf Lines 1セット
• Nanoleaf Essentials Bulbs 2台
• SwitchBot ハブ2 1台
• SwitchBot ロック 1台

このような構成の場合、MatterコントローラーとなるホームハブがHomePod miniになります。
ThreadボーダールーターはHomePod miniとNanoleaf Linesで合わせて3台になります。

本来SwitchBot製品はApple HomeKitで制御することができませんが、SwitchBot ハブ2を使って、Matter経由でApple HomeKitからの制御を実現しています。

また、この構成の場合ではNanoleaf LinesやNanoleaf Essentials BulbsはMatterに対応していませんが、Matter対応デバイスと組み合わせて使うことができます。

やっておくと便利なこと

使うプラットフォームは1つだけでも問題なく利用できますが、複数のプラットフォームにも同時に登録しておくと、他のメーカーのスマートスピーカーが利用できるなど、便利なことが増えます。

スマートデバイスの数が増えてくると一度に登録するのは大変になってくるため、他のプラットフォームを使う予定があまりなくても初めのうちにやっておくことをおすすめします。

これからのMatterに期待すること

対応デバイスの増加

記事執筆時点では、Matterの登場からあまり時間が経っていないため、Matterに対応したデバイスがまだまだ少ないのが現状です。

そのため、今はまだMatterでスマートホームを構築する良い時期ではないかもしれません。
しかし、私はこれからMatterがどんどん広がっていき、「スマートホームといえばMatter」というレベルまで成長すると信じています。
今後、Matter対応のデバイスがどれだけ増えるか、とても楽しみです。

対応機種がまだまだ少ないからといってスマートホームの構築を後回しにするのではなく、今からゆっくりと揃えていけば、Matterが主流になった頃にさらに便利な世界が広がっていくと思います。

対応デバイスの種類の増加

実は、Matter 1.0 / 1.1では対応したデバイスの種類が少ないのです。
Matter 1.2で対応機種が増えたものの、現時点ではかなり期待していたセキュリティカメラにはまだ対応していません。

Matter 1.0 / 1.1で対応しているデバイスの種類は以下の通りです。

• ブリッジ（ZigbeeやZ-Waveなどを使用するデバイスをMatterに取り込むためのもの）
• Matterコントローラー
• ドアの鍵
• 空調コントロール（サーモスタットやエアコンなど）
• 照明（電球やテープライトなど）と電源（スマートプラグなど）
• メディアデバイス（テレビやオーディオなど）
• 安全・セキュリティセンサー（防犯アラームなど）
• 窓周辺とシェード（ブラインドなど）

Matter 1.2で新たに対応したデバイスの種類は以下の通りです。

• 冷蔵庫
• ルームエアコン（以前までの空調コントロールに加え、風量変更等ができるように）
• 食洗機
• 洗濯機
• ロボット掃除機
• 煙・一酸化炭素警報器
• 空気質センサー
• 空気清浄機
• ファン（扇風機や換気扇など）

すでに、カメラ、家電製品、ロボット掃除機、電気自動車の充電、エネルギー管理（ソーラー発電や電気使用量の管理）などをサポートするための定義を始めているそうなので、今後のMatterに期待です。

Threadの普及

実は、Matterの登場以前にもThread対応デバイスは存在していましたが、あまり一般的ではありませんでした。どの製品が対応しているのか、どうすれば使えるのかが広く知られておらず、そもそも「Thread」というものを聞いたことがなかったという人も多いと思います。
しかし、Matterの登場によりThreadが一般的になり、Thread対応のデバイスが普及していくことでしょう。

Threadでは、接続されているデバイスの数が増えれば増えるほど安定する*という面白い特性のため、様々なデバイスがThreadに対応し、普及することを期待しています。

* 1つのThreadネットワークに接続できるデバイスの種類には上限があります（最大32個のルーターが接続できるため、最大16352台のエンドデバイスが上限となります）。

プラットフォーム独自機能が利用できるように

上記「注意: プラットホーム独自機能が利用できなくなる可能性がある」で説明したように、Matterではプラットフォームが独自に提供する機能が利用できない可能性があります。

これに関してはMatterに期待することというより、プラットフォームを提供している企業側に期待することかもしれません。

特に上記の例で言えば、Apple HomeKitの適応型照明はAppleが独自に認証した照明デバイスのみ対応しているため、この機能を他の照明デバイスにも解放しなければ、Matter経由で登録した照明デバイスではこのような機能を利用することができません。

そのため、規格側ではなく、プラットフォーム側に対応してもらうしかない（または、Matterに加えてそのプラットフォームにも対応している必要がある）のが現状です。

まだまだ課題はありますが、現時点でとても便利な規格になっているので、今後にとても期待です！

最後まで読んでくださり、ありがとうございました！それではまた！

みなさんこんにちは、たいくんです。
最近、訳あってリビングのテレビを新調しました。
新しいテレビとしてLG製のテレビを選んだのですが、リモコンを使わずに（iPhoneやiPad、Siriを使って）声だけで制御できるようにしたので、その方法をご紹介します。

テレビを買い換えた理由

前置きが少し長いので、方法だけ知りたい方は「声だけで制御できるようにする方法」まで飛ばしてください。

リビングのテレビが壊れた

あの後、しばらくすると画面がだんだん真っ暗になり、映らなくなるようになった・・・。
電源を入れ直すとしばらくは映るけど、ノイズがひどいままで、しばらくすると画面が消えていく・・・。
まだ4年しか使ってないのに壊れるなんて早すぎる

— たいくん (@i_am_taikun) 2022年11月24日

実は、リビングで使用していたSONY BRAVIA KJ-75X8500Fが壊れました。
壊れる直前までは何事もなく、全く問題なく使用していたのですが、突然映像が乱れ始め、最終的には画面が真っ暗になってしまいました。
映像が乱れ始めた時は雨が強く降っていたため、電波障害的なものだと思っていましたが、チャンネルを変えても入力を変えても乱れたままだったので、「壊れてしまったんだ」と思いました。

何度も根気強く電源を入れたり消したりを繰り返していると、乱れた状態ではあるものの、真っ暗にならずに表示することはできたのですが、やはり映像は乱れた状態かつカクカクのため、見ていてストレスが溜まります。

実際の画面がこんな感じです。
まるで、物をぶつけてパネルを壊してしまったかのような表示ですが、実際にはテレビに何かものをぶつけたわけでもなく、パネルがダメージを受けているわけでもありません。

実は、このテレビが壊れる半年前に、システムの挙動がおかしかったため、SONYに有償で基盤を交換してもらいました（システムの挙動がおかしかったのはAndroid TVの仕様だったみたいで修理の意味は無かった・・・）。
その際にパネル側ではなく、CPUやストレージなどが付いているメイン基盤を交換してもらったのですが、おそらく今回の故障はメイン基盤ではなくパネル基盤が壊れてしまったのかもしれません。

当時40万円ほどで購入したこのテレビですが、たったの4年で壊れてしまうというのは驚きましたが、さすがにまた修理に出すのも気が引けるなと思い、買い替えを決断しました。

LG 75UQ8000PJCを選択

そこで選んだのがLGの75UQ8000PJCです。
このテレビはAmazon限定モデルで、おそらく75UQ9100PJDがベースになっているものと思われます。

この2つのモデルのスペックを見比べると、（スペック表のみの比較ではあるものの）パネルの性能はほぼ変わらず、異なるのは

• 音声調整機能
  75UQ8000PJC: AIサウンド（バーチャル5.1ch）
  75UQ9100PJD: AIサウンドプロ（バーチャル5.1.2ch）
• USBポートの数
  75UQ8000PJC: 1
  75UQ9100PJD: 2
• HDMIポートの数
  75UQ8000PJC: 2
  75UQ9100PJD: 3
• テレビスタンドの形状
  75UQ8000PJC: 「ハ」の字型
  75UQ9100PJD: 逆T字型

程度で、他は消費電力が若干違うかなというレベルの違いでした。

リビングでは、AVアンプを使って音を出しているため、音声調整機能に関しては使う予定がありません。
USBポートの数についても、外付けハードディスクなどを接続する予定がないため、使うこともありません。
HDMIポートの数は、AVアンプ側に複数個付いているため、テレビ側の数が少なくても問題ありません。
最後に、テレビを壁掛けしているため、テレビスタンドの形状についてもあまり気にしません。

以上のことから、ベースモデルよりも少し安いAmazon限定モデルでも問題ないと思い、こちらを選びました。

LG製のテレビを選んだ理由

私がLG製のテレビを選んだ理由は、以下の通りです。

1. 75インチ以上の4Kテレビであり、安い
2. Apple AirPlay 2 / HomeKitに対応している
3. Android TV / Google TV以外のOSである
4. SONY製ではない

私が購入した時は、14万円ほどでした。今まで使っていたものが40万円ほどだったので、かなり安くなっていて驚きました。

私がテレビを選んでいるときにはこれよりさらに安いものもありましたが、2つ目の条件を満たさなかったため、除外しました。

3つ目の理由については、Android TV / Google TVが嫌いだからというわけではなく、単純に使ったことのないOSを使ってみたいという好奇心からです。

Android TVもGoogle TVも良いOSではありますが、「せっかくテレビを新しくするのだから新鮮さが欲しい」と思い、webOS搭載のLG製を選びました。
Hisense製のテレビはどちらのOSでもありませんが、2つ目の条件を満たさなかったため、除外しました。

4つ目の理由についてですが、決してSONYが嫌いというわけではありません。
もちろん今回のテレビが壊れたのはたまたまだとは思いますが、また同じメーカーのテレビを選んで壊れたらどうしようという不安があって、選びませんでした。
とは言っても、SONY製を選ばなかった最大の理由は、（2つ目の条件を満たすもので）価格が他のものより少し高いと感じたからであって、「絶対にSONY製のテレビは買いたくない」と思っていたわけではありません。

使っていて気になった事

このテレビは安かったためか、初期状態では映像があまりきれいではありませんでした。
なんだか全体がピンクがかっていて、明るさも薄暗かったです。また、輝度ムラも少し気になります。
「色合い」をグリーン方向に+50に設定してもほとんど変わりませんでしたが、なぜか「色温度」の初期設定が±50の範囲で（青色方向に）+20になっていたため、「色合い」、「色温度」ともに0にしたところ改善されました。
明るさに関しては、「映像省エネ設定」をオフにして、「パネルの輝度」を上げることで、画面がだいぶ明るくなりました。
その他の設定としては「鮮明度」関係の設定はすべて0かオフにしました。画質の自動調整機能を使っていて、オンの方が良いと感じた事は一度も無いため、あまり信用していませんw

初期設定では色合いや画質が悪く、「失敗したかも」と思っていましたが、設定を追い込むことでかなり改善されました。

最初、家族は気にならないと言っていましたが、さすがに画質がひどすぎると思ったので設定を変えたところ、家族は「かなり良くなった！」と驚いていました。
やはり、画質の設定は大事ですね。

輝度ムラの様子をうまく撮影できなかったため、イメージ画像を作成しました。
そこまでひどい輝度ムラではないため、動いている映像を見ているとほとんど気になりませんが、白い画面が映ったときには少し気になります。

これに関しては設定でどうにもできないので、仕方がありません。輝度ムラがひどくなかったのが幸いです。

声だけで制御できるようにする方法（HomeKit編）

HomeKitを設定する

AirPlay 2 / HomeKitに対応したテレビであれば、HomeKitを設定することで、Siriを使って音声で電源の切り替えを行ったり、iPhoneやiPadの「Apple TVリモコン」から操作を行うことができるようになります。

HomeKitの設定方法は以下の通りです。

1. こちらの公式ガイドを参考に、テレビでAirPlayメニューを開きます。
2. 「AirPlayとHomeKitの設定」まで到達したら、「HomeKitを設定」を選択して、ペアリング可能な状態にします。
3. ペアリング可能な状態になったら、iPhoneまたはiPadの「ホーム」App（以下「ホーム」）で、テレビを追加します。

これでHomeKitの設定は完了です。

iPhoneやiPad、HomePodなどのSiriを使って、「ホーム」に登録したテレビの電源を切り替えることができるようになりました。

「ホーム」で設定したテレビを長押しもしくはダブルクリックし、下の方にスクロールすると「テレビの設定を表示」と書かれたボタンがあるので、それを選ぶと、テレビの設定画面を表示することができます。

iPhoneまたはiPadのアクセシビリティ設定で「音声コントロール」をオンにすることで、「ホーム」からテレビの設定を開き、「リモコン」Appを使って声でテレビの設定を変更することができます。

声だけで制御できるようにする方法（Homebridge編）

Homebridgeを設定する

様々なスマートデバイスをHomeKit対応にできるHomebridgeを使えば、HomeKitに対応していないテレビをHomeKitに対応させるだけでなく、通常、HomeKitでは行うことができない機能をアクセサリとして割り当てることができます。

ここでは、この機能を使って、「チャンネルボタン」を「スイッチ」としてHomeKitに認識させます。
これを行うと「Hey Siri、”チャンネル名”（設定したスイッチの名前）をつけて」と言うことで、チャンネルを変更することができるようになります。

この機能を使うためには、まずHomebridgeをセットアップする必要があります。
Homebridgeをセットアップする詳しい方法は、こちらの記事で解説しているのでご覧ください。

Homebridgeのセットアップが終わったら、「Homebridge webOS TV」というプラグインをインストールします。

プラグインをインストールしたら、Homebridgeとテレビを接続するための設定を行います。

HomeKitに認識させたいテレビの名前を「Device name」に入力します（Homebridgeのログにも表示されます）。

Homebridgeと接続するテレビのIPアドレスを「TV ip address」に入力します。
テレビのIPアドレスが自動で変わってしまわないよう、テレビ側の設定かルーターの設定で固定しておくことをおすすめします。

テレビのMACアドレスを「TV mac address」に入力します。

テレビのIPアドレスとMACアドレスは、ルーターの設定か、テレビの設定から確認することができます。
テレビの設定からIPアドレスを確認する方法はこちらの公式操作ガイドを、MACアドレスを確認する方法はこちらの公式ガイドをご覧ください。

これらの最低限の設定が終わったら、設定を保存し、Homebridgeを再起動します。
Homebridgeが起動したら、設定したテレビを「ホーム」に追加します。

これで、テレビをHomeKitに登録することができました。

テレビが標準でHomeKitに対応している場合は、Homebridgeのプラグイン設定で「Advanced settings」内の「Hide the TV service」にチェックを入れ、設定を保存してHomebridgeを再起動することで、テレビ内蔵のHomeKitとHomebridgeで登録したテレビの重複を解消することができます。テレビがHomeKitに対応していない場合はこの手順を行う必要はありません（HomeKitに対応していないテレビでこの操作を行った場合、Siriを使ってテレビの電源を切り替えることができなくなります）。
Homebridgeが起動すると、「ホーム」に登録したテレビが自動的に削除されます。削除されない場合は、手動で削除してください。

チャンネルボタンを設定する

次は、チャンネルボタンを設定します。

テレビとHomebridgeが接続された状態でテレビのチャンネルを変更すると、次のようなメッセージがログに記録されていることがわかります。

[XX/XX/XXXX, XX:XX:XX] [webostv] [テレビ名] Channel changed. Current channel: XXX, チャンネル名, channelId: X_XX_XX_XXXXX_XXXXX_XXXX_XXXXX

※説明しやすいように色付けしてあります。

赤色で表されているところはチャンネル番号、緑色で表されているところはチャンネルIDです。チャンネルを変更すると、これらの数字・名前が変化していると思います。

これらの数字・名前をプラグインに登録していきます。

Homebridgeのプラグイン設定で「Channel buttons」を開くと、以下の3つの入力欄が現れます。

1. Channel number
2. Channel id
3. Channel name

1つ目には、上記メッセージの赤色の数字を入力します。
2つ目には、上記メッセージの緑色の数字を入力します。
3つ目には、わかりやすいチャンネル名を入力します。上記メッセージ内に含まれるチャンネル名でなくても構いません。ここで設定した名前がスイッチの名前になります（「ホーム」からでも変更できます）。

これらの設定を、登録したいチャンネルの分、設定していきます。
私は、よく使うチャンネル8個を登録しました。

なお、「App buttons」の設定も行うことで、アプリケーションを起動するスイッチを設定することもできます。

これらの設定が終わったら、設定を保存し、Homebridgeを再起動します。
Homebridgeが起動すると、「ホーム」に、設定したスイッチが表示されます。

登録したチャンネルの数が多いとスイッチのアクセサリが多く表示されてしまうため、グループアクセサリに設定することをおすすめします（「ホーム」から設定可能）。

これで、Siriを使ってチャンネルを変更することができるようになりました。

ただし、これでは「“チャンネル名“ にして」ではなく「“チャンネル名“ をつけて」と言う必要があります。
リビングのテレビはほとんどが私の家族が使用しているのですが、「わざわざチャンネル名を言うのが面倒」とのことでした。

シーンを設定する

そこで、「Hey Siri、7チャンにして」というように、「ホーム」の「シーン」機能を使って、「“チャンネル番号“ にして」という言い方でチャンネルを変更できるように設定しました。

シーンの名前を呼びたい名前（例えば「7チャン」など）にして、アクセサリを変更したいチャンネル名のスイッチを1つ追加し、オンにするように設定します。

こちらも、登録したいチャンネルの分、設定する必要があります。
かなり大変でしたが、これらの設定を行うことで、声を使って簡単にチャンネルを変更することができるようになりました。

さいごに

今回は、LGのスマートテレビを声で制御できるように設定しました。
声だけで制御できるようにすることで、わざわざリモコンを手に持たなくても電源やチャンネルを切り替えることができるようになります。

私はリビングのテレビをほとんど使わないものの、ふとした時に自分でも操作できたらいいなと思い、設定しました。
また、チャンネルを変更できるようになったことで、指定の時間にチャンネルを切り替えるオートメーションも作れるようになったため、非常に便利です。
毎週何曜日のこの時間は必ずこの番組を見るというルーティーンがある方は、その時間になったら自動でチャンネルを切り替えるオートメーションを設定することで、わざわざリモコンを持ってチャンネルを切り替える手間がなくなったり、チャンネルを切り替え忘れて前半を見損った、といった出来事がなくなったりと、地味に便利なのでぜひ使ってみてください！

最後まで読んでくださり、ありがとうございました！それではまた！

みなさんこんにちは、たいくんです。
以前レビューしたXREALのARグラス「XREAL Air」のMRアプリ「Nebula」がmacOSに対応したので、今回は実際に使ってみてどうなのか、初期ベータ版アプリのレビューをしていきます*。

* レビューは、この記事を最初に執筆した2022年10月27日時点でのレビューとなります。最新バージョンのレビューではないため、内容が変わっている可能性があります。あらかじめご了承ください。

Nebula for Mac

対応デバイス

記事の最終更新時点での最新バージョン（ベータ）の対応デバイスは以下の通りです。

• XREAL Air
• XREAL Air 2 / Air 2 Pro / Air 2 Ultra
• Nreal Light

対応Macの要件は以下の通りです。

• macOS Monterey (12.0)以降
• 2019年またはそれ以降のMacBookシリーズ*

* MacはUSB-Cを搭載している必要があります。DisplayPort Alt modeを使用するため、USB Type-Aを変換しても使えません。
対応Macに「MacBookシリーズ」とありますが、iMacやMac mini、Mac Studio、Mac Proでも使用できるはずです。

** アプリケーションはarm64やユニバーサルバイナリではなくx86_64のようなので、Intel Macでも動作しました（というかこの記事のレビューにはIntel Macを使用しました）。Apple Silicon MacではRosetta 2経由で動作しているようです。

2023/2/17 追記:

コメントで「Intel Macで動作しない」との情報をいただきましたので、現時点で最新バージョンをダウンロードし、ファイルを確認したところ、どうやらarm64に変更されているようでした。このことから、Intel Macでは動作しなくなりました。
以前のバージョンでは、バグはあれどIntel Macでも問題なく動作していたため、少し残念ではありますが、本来はApple Silicon Macが必要と謳われていたため仕方がないことかもしれません・・・。

2023/9/13 追記:

ふと気になったので、最新バージョンをダウンロードして確認してみたところ、いつの間にかユニバーサルバイナリに更新されていました！
当初はApple Silicon Macのみのサポートでしたが、Intel Macもサポート対象になったようです。
Intel Macでアプリケーションも問題なく起動することを確認しました。そのため、Intel Macしか持っていない方でも試せるようになったので、試してみてはいかがでしょうか？

ダウンロード

XREAL Japanの公式サイトから無料でダウンロードできます。

インストール

ダウンロードしたディスクイメージを開いたら、Nebula for Macのアイコンをアプリケーションフォルダへドラッグアンドドロップします。
コピーが終わったらインストールは完了です。

使い方

アプリケーションを開くと、ARグラスとMacを接続するように指示されるので、接続します。

すると、画面録画の許可を求める画面が表示されるので、「設定に進む」をクリックします。

このウィンドウが表示されたら「“システム環境設定”を開く」をクリックします。

システム環境設定で、Nebula for Macのチェックを入れ、「終了して再度開く」をクリックします。

これで、Macの画面がARグラスに表示されるようになります。頭を動かすと、ディスプレイ（スクリーン）の位置があるべき場所に固定されているのがわかるはずです（右を向くとディスプレイが左側に移動する、など）。

この画面から、スクリーンの数や、スクリーンの距離を選択することができます。初期設定では1枚のスクリーンと、最も近い距離に設定されています。

また、ウィンドウ中央下側の紫の四角形のアイコンをクリックしながら頭を動かすと、スクリーンの位置を動かすことができます。ただし、1枚1枚のスクリーンを動かすことができず、全体を同時に動かすことになります。

レビュー

注意

このレビューは、Nebula for Mac初期ベータ版とIntel Macを使用したレビューです。このレビューで取り上げた欠点・不満点などは、正式リリース時には解消している可能性があります。

良いところ

どこでもトリプルスクリーン環境を実現できる！

仕事などでMacを使う際、作業の効率化を図るためにマルチスクリーン環境にしているという方も多いと思いますが、外出先などではなかなかマルチスクリーン環境にするのは難しいですよね。しかし、XREAL Air / Lightとこのアプリケーションがあれば、いつでもどこでも最大3つのスクリーンを使って作業をすることができます。
そのため、中央で作業、左側で使用するファイル、右側で動画を再生といったことがどこでもできるようになります。しかも、ディスプレイを広げる必要がないため、狭い場所でも問題ありません。

家でも外出先でもプライバシーが守られる！

これはAR / MRグラスだからこそというものですが、他人に見られたくない機密情報などを画面に表示せず、メガネをかけている人だけが見ることができるため、安心して使えるのは大きなメリットだと思います。
人が多い場所で作業する時、画面を覗き込まれてしまう可能性がありますが、この機能を使えば覗き込まれても全く問題ありません。

90Hzだから動きが滑らか！

表示されるMacの画面は60Hz*ですが、3D空間は90Hz**で表示されているので、頭を動かしたときにスムーズにスクリーンが動くため、疲れにくい（＋多分酔いにくい***）のがすごく良いと思いました。
まだベータ版のため、カクついたり引っかかったりする時はありますが、滑らかに動いている時はかなり快適に使えます。

* Macで使用しているディスプレイのリフレッシュレート設定によります。

** Nreal Airのプレスキットには、「up to 90Hz（最大90Hz)」と記載されていますが、記事の最終更新時点での製品ページには「120Hzに達している」と記載されているため、もしかしたら120Hzで動作している可能性があります（非常に滑らかだと感じるため、体感的に、60Hzではないことは確か）。

*** 私は3D酔いに強いためこういったデバイスで酔った事はありませんが、動きが滑らかなので3D酔いしやすい人でも酔いにくいと思われます。

ヘッドトラッキングの精度が高い！

私はXREAL Airのヘッドトラッキングを初めて使ったのですが、これの精度がかなり高く、驚きました。頭をそこそこ激しく振っても、表示されているスクリーンの位置はほとんどズレません。そのため、使っているときに違和感がかなり少ないのがいいと思いました。

残念なところ

Mission Controlが全く使えない

このアプリケーションは、XREAL Airを3840×1080の横長ディスプレイとして認識させ、そこにUnityの3D空間をフルスクリーンで表示しているようで、Mission Controlを起動するとフルスクリーン状態が解除され、左右で違う映像が表示されるため、全く使い物になりません。
仕組み上仕方がないのかもしれませんが、XREAL Airのディスプレイだけフルスクリーンが解除されないようになれば、より快適に使えるようになると思うので、正式リリース時や、今後のバージョンアップに期待したいところです。

メインスクリーンがミラーリングになっている

左右のサブスクリーンは3D空間上にのみ存在しますが、メインスクリーン（中央のスクリーン）はMacのディスプレイとミラーリングになっているため、メインスクリーンに表示されているものは誰でも見ることができてしまうというのは少し残念だと思いました。
正式リリース時や、今後のバージョンアップでMacのディスプレイとメインスクリーンを別々に表示できるようになることを期待したいところです。
解決するまでは、Macのディスプレイの明るさを最小にして使うのがいいと思います。

まだ自由度が少ない

初期ベータ版ということもあり、まだまだ自由度は低く感じます。
スクリーンの枚数が最大3枚までだったり、スクリーンのひとつひとつを動かしたり、向きを変えたりするといった事はまだできません。
正式リリース時や、今後のバージョンアップに期待したいところです。

著作権保護された映像を表示できない

アプリケーションの仕組み上仕方がないものですが、画面録画機能を使って仮想ディスプレイをキャプチャし、3D空間上に表示しているため、著作権保護された映像を再生すると録画中とみなされ、再生することができません。
そのため、映画などを表示することができないのは少し残念ですが、これについてはアップデートで解決できるようなことではないと思うので、改善される可能性は低いでしょう。

ちらつきがひどい

公式が認識している問題でもありますが、明るい画面においてのちらつきがひどく、かなり目が疲れます。通常使用時（Air Castingモード）の表示ではちらつくことが全くないため、初期ベータ版アプリケーションのバグだと思われます。
このバグについては、正式リリース時には解決されると思います。

総評

手に入れやすい価格のARグラスとしてXREAL Airが発売され、ついにMacでも使えるようになったことで、本格的に「AR / MRの時代」がやってきている感じがして、かなり面白くなってきました。
初期ベータ版とは言え、完成度もそこそこ高く使いやすいため、XREAL Airがさらに流行りそうな感じがします。
人口の多いWindowsにも対応すれば、街のいたるところでXREAL Airを使っている人を見かけるようになるかもしれません。

XREAL Airがますます便利になるアプリケーションなので、XREAL AirとMacをお持ちの方はぜひ試してみてください！

最後まで読んでくださり、ありがとうございました！それではまた！

みなさんこんにちは、たいくんです。
ほとんどのSwitchBot製品はHomeKitに対応しておらず、Siriなどから制御することができません。Matter対応のSwitchBot ハブ2・ハブミニを使っても、Matter経由のHomeKitから制御できるデバイスは限られており、すべてのSwitchBot製品が制御できるわけではありません。
他にも、Matterではエアコンのリモコンなどの機能が限られてしまう場合もあります。

そこで今回は、HomebridgeやHome Assistantを使って、Matter対応のハブをお持ちの方もそうでない方も、様々なSwitchBot製品をHomeKit対応にする方法を紹介します。

事前準備

初期設定が必要

SwitchBot製品は、事前にスマートフォンアプリを使って初期設定を完了しておく必要があります。
また、クラウド経由で制御する場合、制御するアクセサリの「クラウドサービス」をオンにしておく必要があります。

Homebridgeで対応させる方法

対応機器

Homebridgeでは、OpenAPIを使ったクラウド経由での制御と、Bluetooth（BLE）通信を使ったローカル制御の2つが行えます。
対応するSwitchBot製品は以下の通りです。

• SwitchBot スマートサーキュレーター（OpenAPIのみ）
• SwitchBot スマート加湿器
• SwitchBot 気化式加湿器
• SwitchBot 気化式加湿器 Plus
• SwitchBot 温湿度計
• SwitchBot 温湿度計プラス（米国・日本モデル）
• SwitchBot 防水温湿度計
• SwitchBot 人感センサー
• SwitchBot 開閉センサー
• SwitchBot 水漏れセンサー
• SwitchBot カーテン / カーテン2
• SwitchBot カーテン3
• SwitchBot ブラインドポール（OpenAPIのみ・部分的なBLE対応）
• SwitchBot スマート電球（OpenAPIのみ・部分的なBLE対応）
• SwitchBot シーリングライト / シーリングライト プロ（OpenAPIのみ・部分的なBLE対応）
• SwitchBot テープライト（OpenAPIのみ・部分的なBLE対応）
• SwitchBot ロック
• SwitchBot ロック Pro
• SwitchBot ロボット掃除機 K10+（米国モデル、OpenAPIのみ）
• SwitchBot お掃除ロボット S10（米国モデル、OpenAPIのみ）
• SwitchBot ロボット掃除機 S1 / S1 Plus（日本モデル、OpenAPIのみ）
• SwitchBot プラグ（OpenAPIのみ）
• SwitchBot プラグミニ（米国・日本モデル）
• SwitchBot ボット

OpenAPIを使ったクラウド経由での制御には、SwitchBot ハブミニ（Matter対応・非対応の両モデル）、またはSwitchBot ハブ2が必要です（もしかしたらハブプラスや、シーリングライト プロに搭載されているハブ機能も使用できる可能性はありますが、未確認です）。

SwitchBot ハブ2内臓の温湿度センサーと照度センサーも対応しています（OpenAPIとBLE）。

SwitchBot ハブミニ、またはSwitchBot ハブ2を使って制御できる赤外線デバイスは以下の通りです（OpenAPIのみ）。

• テレビ
• プロジェクター（テレビとして表示）
• セットトップボックス
• DVD（セットトップボックスとして表示）
• ストリーマー（ストリーミングスティックとして表示）
• スピーカー
• ファン
• ライト*
• 空気清浄機*
• エアコン
• カメラ*
• 掃除機*
• 給湯器*
• その他*

* オンとオフの切り替えのみ対応

Homebridgeをインストールする

Homebridgeをインストールする方法は、こちらの記事で詳しく紹介しているのでご覧ください。

プラグインをインストールする

今回は、「Homebridge SwitchBot」というプラグインを使用します。このプラグインは、SwitchBotの開発元が作成した、言わばSwitchBot公式のプラグインです。

Homebridgeのプラグイン画面で、「SwitchBot」と検索して表示された、「Homebridge SwitchBot」というプラグインをインストールしてください。

プラグインの設定をする

OpenAPIを使って制御する場合、「OpenAPIトークン」と「シークレットコード」が必要になります。

OpenAPIトークンを取得するには、以下の手順に従ってください。

1. SwitchBotアプリを開き、プロフィールタブ内の「設定」をタップします。
2. 「アプリバージョン」のところを10回連続でタップします。その後、表示された「開発者向けオプション」をタップします。
3. 「トークンを取得」をタップします。

すると、トークン及びシークレットキーが表示されるので、SwitchBotプラグインの「Token」、「Secret」のところにそれぞれ入力します。

その後、Homebridgeを再起動すると、SwitchBotアプリに登録されているすべてのアクセサリがHomeKitに表示されるようになります。

BLEを使って制御する場合は、「noble」の準備事項（prerequisites）に従う必要があります。
BLEを使って制御するように設定するには、まず「SwitchBot Device Settings」内で「Device Name」（HomeKitに表示されるデバイス名）と制御したいSwitchBotデバイスのMACアドレス*を「Device ID」に入力します。
その後、「Device Type」（SwitchBot製品の種類）を選択し、「Connection Type」を「BLE/OpenAPI」または「BLE」を選択します。

プラグインの設定にある「Hide Device」にチェックを入れると、特定のデバイスのみを非表示にすることができます。
既にHomeKit（またはMatter）に対応している製品や、HomeKitに追加したくない製品などの場合に有効化します。

OpenAPIの場合は、情報取得の間隔が最短30秒（かつ、スマート加湿器を除いてHomebridgeへのプッシュにも非対応）のため、人感センサーなどのリアルタイムの情報が必要なデバイスには向いておらず、そのようなデバイスはBLEで設定することをおすすめします。
OpenAPIでは、人感センサーを使って照明をつけるオートメーションは全く使い物になりませんでした。センサーが反応してから照明がつくまでに時間がかかりすぎます。
BLEの場合は、APIの取得回数制限がないため、ほぼリアルタイムで情報を同期させることができます。

ただし、Macの場合はBLE制御ができないようで、エラーが表示されてしまいました（最近のmacOSでは動作しない場合があるようです。macOS 12.3以降で動作するようになったという情報もありましたが、私の場合はうまくいきませんでした）。
そのため、私はこの先のセクションで紹介するHome Assistantを使ってHomeKitに対応させました。

macOSの場合、Bluetoothを使用できるようにするためにシステム設定の「プライバシーとセキュリティ」内にある「Bluetooth」から、「node」にBluetoothの使用権限を与える必要があります。nodeは「/usr/local/bin/」内にあります。
「usr」フォルダは隠しフォルダになっているため、Shift + Command + .（ピリオド）を押して隠しフォルダを表示するか、Finderの「フォルダへ移動…」から「/usr/local/bin/」へ移動した後、「node」をシステム設定の「下のアプリケーションにBluetoothの使用を許可。」の下に表示されているリストにドラッグアンドドロップします。

* SwitchBotアプリから確認するか、OpenAPIトークンを入力後にプラグインの「DEVICES」タブから確認できます。

その他の方法でSwitchBot ロックを対応させる方法

記事執筆時点では、以前まではAPIを使った制御ができたのですが、API仕様の変更によりロック・ロック解除ができなくなってしまいました。そのため、Samsung SmartThingsを経由して、HomeKitに対応させます。

2022/10/13 追記:

SwitchBot公式プラグインのアップデートにより、再びSwitchBot ロックを動作させることができるようになりました。
しかし、この方法を使えば情報取得のタイミングを30秒よりも少なくできるため、よりリアルタイムに近い状態を取得することができます。

先程のプラグインを使って設定した場合、HomeKitにロックが表示されるのですが、ロック・ロック解除ができません。そのため、プラグインの設定で、ロックを非表示に設定しておきましょう。

HomeKitに対応させる前に、先にSmartThingsとSwitchBotを連携させておいて、SmartThingsからSwitchBot製品を制御できることを確認しておいてください。

SwitchBot ロックを対応させるには、Homebridgeに「homebridge-smartthings-ik」と検索して表示される「SmartThings Plugin」というプラグインをインストールする必要があります。
このプラグインは、SmartThingsに登録されたデバイスをHomeKitから制御できるようにするというプラグインです。

プラグインをインストールしたら、こちらのリンクからSmartThings APIを使うためのパーソナルアクセストークンを生成する必要があります。

「Token Name」にはわかりやすい名前を、「Authorized Scopes」では「Devices」にチェックを入れます。
SmartThingsに複数のアクセサリが登録されている場合、HomeKitに追加したくないデバイスを除外できるようにするには、「Locations」のチェックも入れる必要があります（「Locations」機能をつかって、指定したLocation内のデバイスを除外するようです）。
最後に、「GENERATE TOKEN」をクリックして、生成されたトークンをコピーしておきます。

コピーしたトークンを、先ほどインストールしたプラグインの設定にある「Access Token」のところにペーストし、設定を保存したらHomebridgeを再起動します。
すると、SmartThingsに登録されたデバイスがHomeKitの画面に現れるはずです。

HomeKitに追加したくないデバイスを除外するには、除外するデバイスが設置してあるLocation名を「Location Name」のところに入力します。

プラグインのバージョン1.1.12より「IgnoreDevices」機能が追加されました。HomeKitに追加したくないデバイスは「Devices to Ignore」にデバイスの名前を入力します。

ロックが施錠されていて、解錠操作をしていないのに、HomeKitには「解錠中…」の表示が消えない時があるなど、動作が若干不安定ですが、Siriからの解錠・施錠は問題なくできるので、OpenAPI / BLEでの制御ができるようになるまではこの方法で使うのがいいと思います。

プラグインのバージョン1.1.10より、定期的にデバイスの状態を読み取ることができる設定が追加されました。これにより、鍵が解除された時や施錠された時などにほぼリアルタイムでHomeKitに通知することができるようになりました。
そのため、「解錠中…」の表示が消えない不具合は解消されました。

Home Assistantで対応させる方法

Home Assistantでは、OpenAPIを使ったクラウド経由での制御（公式、またはカスタム統合）と、Bluetooth（BLE）通信を使ったローカル制御、Matterを使ったローカル制御の3つが行えます。

対応機器（公式統合を使ったOpenAPI）

OpenAPIを使って制御する場合、「OpenAPIトークン」と「シークレットコード」が必要になります。Homebridgeの時と同じ方法でコードを入手してください。

Home Assistantに含まれる統合を使ったOpenAPIでの制御に対応するSwitchBot製品は以下の通りです。

• SwitchBot スマートサーキュレーター
• SwitchBot プラグ（Wi-Fiのみ対応の日本限定モデル）
• SwitchBot プラグミニ（HomeKit対応・非対応の両モデル）
• SwitchBot 温湿度計
• SwitchBot 温湿度計プラス
• SwitchBot 温湿度計 Pro
• SwitchBot CO2センサー（温湿度計）
• SwitchBot 防水温湿度計
• SwitchBot ロック
• SwitchBot ロックPro
• SwitchBot ロボット掃除機 K10+ / K10 Pro
• SwitchBot ロボット掃除機 S1 / S1 Plus
• SwitchBot リレースイッチ1
• SwitchBot リレースイッチ1PM

OpenAPIを使ったクラウド経由での制御には、SwitchBot ハブミニ（Matter対応・非対応の両モデル）、またはSwitchBot ハブ2が必要です（もしかしたらハブプラスや、シーリングライト プロに搭載されているハブ機能も使用できる可能性はありますが、未確認です）。

追加されるセンサーは10分（600秒）に一度、クラウドサーバーに更新を要求します。
これは、SwitchBotのクラウドAPIがユーザーに、1日あたり1万回までのリクエストに制限されているためです。

制御できる赤外線デバイスは以下の通りです。

• 「その他」を除く全ての赤外線リモコン
• エアコン

なお、エアコン以外の赤外線リモコンは「オン」と「オフ」状態を切り替える「スイッチ」エンティティとして登録されます。

対応機器（カスタム統合を使ったOpenAPI）

OpenAPIを使って制御する場合、「OpenAPIトークン」と「シークレットコード」が必要になります。Homebridgeの時と同じ方法でコードを入手してください。

HACSからインストールすることができるカスタム統合を使った、OpenAPIでの制御に対応する赤外線デバイスは以下の通りです。

• エアコン
• テレビ・IPTV・ストリーマー・セットトップボックス
• DVD・スピーカー
• ファン
• 照明
• 空気清浄機
• 給湯器
• 掃除機
• カメラのシャッター
• その他

自分で学習させたカスタムボタン・コマンド機能もサポートしています。
それぞれの赤外線リモコンで利用可能な機能については、カスタム統合の公式ページをご覧ください。

対応機器（BLE）

Bluetoothでの制御に対応するSwitchBot製品は以下の通りです。

• SwitchBot スマートサーキュレーター
• SwitchBot スマート加湿器
• SwitchBot 空気清浄機
• SwitchBot 空気清浄機Table
• SwitchBot 温湿度計
• SwitchBot 温湿度計プラス
• SwitchBot 温湿度計 Pro
• SwitchBot CO2センサー（温湿度計）
• SwitchBot 防水温湿度計
• SwitchBot 人感センサー
• SwitchBot 開閉センサー
• SwitchBot 水漏れセンサー
• SwitchBot リモートボタン
  • 現時点ではバッテリー残量の取得のみ
• SwitchBot カーテン / カーテン2
• SwitchBot カーテン3
• SwitchBot ブラインドポール
• SwitchBot ロールスクリーン
• SwitchBot スマート電球
• SwitchBot テープライト
• SwitchBot シーリングライト
• SwitchBot プラグミニ（HomeKit対応・非対応の両モデル）
• SwitchBot ロック*
• SwitchBot ロックPro*
• SwitchBot ロックUltra*
• SwitchBot ロックLite*
• SwitchBot ロボット掃除機 K10+
• SwitchBot ロボット掃除機 K10+ Pro
• SwitchBot ロボット掃除機 K10+ Pro Combo
• SwitchBot ロボット掃除機 K20+ Pro
• SwitchBot お掃除ロボット S10
• SwitchBot ボット
• SwitchBot リレースイッチ1
• SwitchBot リレースイッチ1PM
• SwitchBot ハブ2**
• SwitchBot ハブミニ（Matter対応）**
• SwitchBot ハブ3**

* 設定するためには、暗号化キーが必要です。暗号化キーは、SwitchBotアカウントからインポートする方法と、手動で入力する方法があります。
暗号化キーを手動で入力する場合は、こちら（英語）の方法を使って暗号化キーを入手してください。この記事では詳細の解説は割愛します。
なお、どちらの手順もSSOアカウント（Apple、Google、Amazonの外部アカウントを使って登録したアカウント）では実行することができないためご注意ください（私はSSOアカウントだったので、わざわざ通常のアカウントを作り直し、持っているデバイスを全て登録し直しました…）。

** 記事の最終更新時点では、ハブ内蔵センサー情報の取得のみに対応しており、赤外線リモコンの操作には対応していません。
取得できるセンサー情報は次の通りです。

• ハブ2
  • 温湿度
  • 照度
• ハブミニ（Matter対応）
  • 温湿度（ハブ2 / 3用のケーブルを接続した場合）
• ハブ3
  • 温湿度
  • 照度
  • モーション

対応機器（Matter）

Matterでの制御に対応するSwitchBot製品は以下の通りです。

• SwitchBot スマートサーキュレーター
• SwitchBot 空気清浄機
• SwitchBot 空気清浄機Table
• SwitchBot 温湿度計
• SwitchBot 温湿度計プラス
• SwitchBot 温湿度計 Pro
• SwitchBot CO2センサー（温湿度計）
• SwitchBot 防水温湿度計
• SwitchBot 人感センサー
• SwitchBot 開閉センサー
• SwitchBot カーテン / カーテン2
• SwitchBot カーテン3
• SwitchBot ブラインドポール
• SwitchBot ロールスクリーン
• SwitchBot スマート電球
• SwitchBot シーリングライト / シーリングライト プロ
• SwitchBot テープライト
• SwitchBot ロック
• SwitchBot ロックPro
• SwitchBot ロボット掃除機 K10+ / K10+ Pro / K10+ Pro Combo
• SwitchBot お掃除ロボット S10
• SwitchBot ロボット掃除機 S1 / S1 Plus
• SwitchBot プラグミニ（HomeKit対応・非対応の両モデル）
• SwitchBot ボット
• SwitchBot ハブ2（内蔵の温湿度計と赤外線リモコン*）
• SwitchBot ハブミニ（Matter対応）（ハブ2 / 3用の電源ケーブル内蔵温湿度計と赤外線リモコン*）
• SwitchBot ハブ3（内蔵の温湿度計と赤外線リモコン*）

* 対応する赤外線リモコンの種類は、SwitchBot ハブでのMatterブリッジに対応していて、さらにHome AssistantのMatter統合にも対応している必要があります。
SwitchBot ハブでのMatterブリッジに対応している赤外線リモコンの種類と対応しているデバイスについてはこちらご覧ください。
記事の最終更新時点で、Home AssistantのMatter統合に対応しているドメイン（エンティティの種類）は以下の通りです。

• バイナリセンサー（「オン」か「オフ」状態を検出するエンティティ）
• ボタン
• 車両
• 空調（エアコンやサーモスタットなど）
• カバー（ブラインドやシャッターなど）
• ファン（扇風機や換気扇など）
• 照明
• ロック
• 番号（速度や設定値などの入力）
• ポンプ
• 選択（モードや設定などの切り替え）
• センサー（温湿度やアップタイムなど、数値やテキストを検出するエンティティ）
• スイッチ（「オン」と「オフ」状態を切り替えるエンティティ）
• アップデート（ファームウェアアップデート）
• バキューム（ロボット掃除機）
• バルブ（水栓、ガス栓、空気栓。スプリンクラーなど）
• 給湯器

赤外線リモコンのうち、おそらくエアコンのリモコンは「空調」として、その他のリモコンは「スイッチ」として登録されるものと思われます。

その他のデバイスについては、SwitchBotのファームウェア側の対応によります。

Home Assistantをインストールする

Home Assistantをインストールする方法は、こちらの記事で詳しく紹介しているのでご覧ください。

公式統合のOpenAPIで制御する場合

「統合」設定で、「統合を追加」をクリックして、「SwitchBot Cloud」と入力して、表示された統合をクリックして設定してください。

APIトークンとAPIキーの入力画面が表示されるので、SwitchBotアプリから入手したコードを入力して、右下の「送信(SUBMIT)」をクリックすると設定完了です。

カスタム統合のOpenAPIで制御する場合

まずはHACSから、または手動でカスタム統合「SwitchBot Remote IR」をダウンロード・インストール後、Home Assistantを再起動します。

「統合」設定で、「統合を追加」をクリックして、「SwitchBot Remote IR」と入力して、表示された統合をクリックして設定してください。

上のボタンをクリックして統合の設定を開始することもできます。

ハブの名前については、複数台のハブをお持ちでもそれぞれ識別される事は無い（複数台のハブが登録されていても、1つのハブとして認識される）ため、お好みの名前で構いません。

それぞれのデバイスの設定を変更したい場合は、ハブ一覧の「設定」をクリックします。

ハブに登録されているデバイスが表示されるので、設定を変更したいデバイスを選択し、「送信(SUBMIT)」をクリックします。

選択したデバイスの設定画面が表示されます。表示される設定内容は、デバイスの種類によって異なります。

自分で学習させたカスタムボタンを追加したい場合は、最も下にある「Button names」に、SwitchBotアプリに登録したボタンの名前を正確に（英語の名前は、大文字小文字も正確に）入力します。
登録したボタンは、ボタンエンティティとして1つずつ追加されます。

Bluetoothで制御する場合

まずはHome Assistantに「Bluetooth」統合を追加する必要があります。
内蔵Bluetoothアダプタがうまく使えない場合は、USB接続のBluetoothアダプタを使用するか、ESP32を使ったBluetoothプロキシを設定する必要があります。
対応するBluetoothアダプタはこちらの公式ドキュメントに書かれています。私はこちらのアダプタを使用しました。
Bluetoothアダプタを接続したら、「統合」設定で、「Bluetooth」統合を追加します。

その後、SwitchBotデバイスが自動で検出されるのを待つか、手動でSwitchBot統合を設定する必要があります。
自動で検出されたら、「設定」をクリックして設定します。
手動で設定する場合は、「統合を追加」をクリックして、「SwitchBot Bluetooth」と入力して、表示された統合をクリックして設定してください。

Matterで制御する場合

iPhoneやiPadで「ホーム」アプリを開き、直接、Matter対応のSwitchBot ハブを登録すると、HomeKitで使用することができます（SwitchBotアプリから、Matterに登録するデバイスを選択する必要があります）。
この記事では、HomeKitに対応していないデバイスをHomeKitで制御する方法を目的としているため、Home AssistantにMatterデバイスを登録する方法については割愛します。

HomeKit統合を設定する

HomeKitに対応させるには、「HomeKit Bridge」統合を設定する必要があります（既存のブリッジがある場合、ロック以外は既存のブリッジに追加しても構いません）。
「HomeKitデバイス」ではないため、ご注意ください。

追加するときに、「含めるドメイン」を、HomeKitに登録したいSwitchBotデバイスのドメイン（エンティティの種類）を選択します。今回は、Bluetoothで通信している温湿度計と人感センサーを追加するため「Binary Sensor」と「Sensor」を選びました。

登録したいデバイスのエンティティの種類がわからない場合は、「統合」設定のエンティティ一覧から、登録したいデバイスを探します。
そのデバイスのエンティティIDが、どのような文字列で始まっているかを確認します。
この画像の場合は、「binary_sensor.」で始まっていることから、このエンティティはバイナリセンサー（オンかオフであるかを検出するセンサー）であることがわかります。 ここで確認したものを、上記の「含めるドメイン」で選択します。

なお、ロックを登録する場合は、1つだけのドメインを選択する必要があります（1つのブリッジにこのデバイスを登録すると正しく動作しなくなるため、単体で登録する必要があります）。
複数のSwitchBot ロックを登録する場合、複数の設定を作成する必要があります。

ドメインを選択したら、「送信(SUBMIT)」をクリックして、統合を追加します。

HomeKit Bridge統合が追加されたら、「設定」をクリックして、統合を編集します。
「インクルージョンモード」を「exclude」から「include」に変更して、「送信(SUBMIT)」をクリックします。

これで、HomeKit Bridgeに含めるアクセサリを、これから指定するエンティティのみに制限することができます。
ちなみに、ロックを選択した場合、上記設定に加えて「モード」を「accessory」に変更します。
これによりブリッジとしてではなく、アクセサリ単体として動作するようになります。

その後表示される「含めるエンティティを選択」の画面で、追加したいSwitchBotデバイスのエンティティを選択して、「送信(SUBMIT)」をクリックします。
今回は、温湿度計の温度センサー（センサー）・湿度センサー（センサー）と、人感センサーのモーションセンサー（バイナリセンサー）を選択しました（「accessory」モードにした場合、1つのエンティティのみ選択することができます）。

次に、「高度な設定」が表示されますが、ここでは何も設定せずに「送信(SUBMIT)」をクリックします。

設定が終わったら、HomeKit Bridge統合に名前をつけておくことをおすすめします。

設定が終わったら、Home Assistantの通知に表示されている画面からSwitchBotデバイスをHomeKitに登録します。

これで、設定が完了しました。

さいごに

今回紹介した方法で、HomeKitに非対応のSwitchBotデバイスをHomeKitに対応させることができるようになります。
これにより、SwitchBotデバイスをSiriなどで制御できるようになります。

私はHomebridgeでハブ2の赤外線リモコンを、Home Assistantで以下のデバイスをHomeKit対応にしています。

• SwitchBot スマートサーキュレーター
• SwitchBot 温湿度計
• SwitchBot 防水温湿度計
• SwitchBot 人感センサー
• SwitchBot ロック
• SwitchBot ボット
• SwitchBot ハブミニ（Matter非対応）の赤外線リモコン

まだHome Assistantでは、赤外線リモコンの高度な操作には対応していませんが、今後のアップデートで対応すればかなり便利に使えると思うので、今後に期待したいところです。

Home Assistant 2023.10より、Home Assistantで赤外線リモコンの操作に対応したので、今後のアップデートで対応デバイスが増えることを期待しています。

余談

私のように身体障害などを抱えて生活している方にとっては、非常に便利な生活になると思うので、試す価値は十分にあると思います。
赤外線デバイスをSiriで操作できるようになって、今までエアコンのリモコンに手を伸ばすのがかなり苦痛で、リモコンを床に落としてしまった場合はエアコンを操作することができず、非常に困っていたのが、声だけで操作できるのは非常に楽です。

Macの場合はHomebridgeがなぜかBluetooth通信ができず、人感センサーが全く役に立っていないため、早いところHome Assistantに対応してほしいところです。
Home Assistant 2022.9.0よりSwitchBot 人感センサーに対応し、無事に機能するようになりました！

ちなみに、HomebridgeのSwitchBot公式プラグインでSwitchBot ロックが対応していたのですが、API仕様の変更により使えなくなってしまいました。
開発者側が間も無くBLE APIを公開するとのことなので、Home Assistantにも早く対応することを願っています。
Home Assistant 2023.1.0よりSwitchBot ロックに対応しました！

やはり、クラウド制御よりもローカル制御の方が（サーバーダウンなど）何かあった時にも強いですからね。

最後まで読んでくださり、ありがとうございました！それではまた！