インテグレーション（Integration）：デバイスや追加機能を構成ファイルに読み込む仕組みで、デバイスを独立して扱っているわけではありません。そのため、公式には「デバイス（Device）」ではなく、「インテグレーション（Integration）」と呼ばれています。インテグレーションは日本語で公式に「統合」と訳されていますが、字面だけではその真の用途を理解しにくいので、私は「統合（元件）」と呼んでいます。
Configurationでは、最も下位のオブジェクトを「コンポーネント（Component）」と呼んでいます。そして、これらのインテグレーションを設定するときも、コンポーネントをベースに設定します。
そのため、私はインテグレーションのことを「統合（元件）」と呼ぶのが好きです。
公式ウェブサイトにアクセスすると、上部に「Integrations」というリンクがあります。すべてのインテグレーションはこのページにあり、さまざまな分類に基づいて検索して追加することができます。
デバイスを追加する前に、すでに購入またはインストールしていない限り、通常はどのようなデバイスを使用するかを知りたいと思うでしょう。他のシステムとは異なり、通常、他のシステムには独自のブランドのデバイスがあり、各システムはこれらのデバイスの使用を直接推奨しています。これは、特定のシステム向けに開発されているため、互換性が高くなるためです。
一方、Home Assistantは独自のデバイスを製造せず、多数の開発者がさまざまなデバイス（メーカー）提供的APIを利用して開発し、さまざまなデバイスをHome Assistantに追加しています。そのため、デバイスの選択が非常に重要になります。Home Assistant開発チームは、デバイスの選択に役立つさまざまな指標を設計しました。
品質評価（QUALITY SCALE）：Home Assistantは、すべてのインテグレーションに独自の品質レベルを定義しています。開発チームは、開発者が参照できる一連の評価基準を策定しました。開発者は、これらの基準に基づいて開発を行うことで、対応する評価を得ることができます。私たちは一般ユーザーなので、これらの基準を深く理解する必要はありません。それぞれの基準が何であるか、どのように使用すればよいかを知っていれば十分です。
以下の数つの基準：
第一に「Internal」：例えば、Automation、History等々。基本的に、このタイプはHomeAssistantシステムが自帶する統合コンポーネントであり、彼らは必ずしもこの評分基準に従わない。しかし、システムの自帶機能であるため、独自のランクを持つ。
第二に「No Score」評価なし：基本的に、大半の統合コンポーネントがこのタイプに属する。最も基本的かつ必須の要求を満たすのみだが、彼らの中にBugあるいは問題があるという意味ではない。このランクの統合コンポーネントは、Configration内でYAMLを使って設定しなければならない。実はこれは容易く理解できる。なぜなら、開源のシステムであるため、全ての装置は大半異なる開発者が開発しているため、開発者は皆「まずは有を求め、その後よしを求む」ため、
第三に「Silver」銀級：例えば、Minecraft Server、Spotify等。このタイプ以上の装置は、基本的にエラーハンドリングが非常に良く行われ、全てのエラー及び再接続の試行を管理し、オフライン時に状態を表示し、知らせることができる。同時に、このランク以上の装置は、基本的に統合UI内で設定ができる。
第四に「Gold」黄金級：例えば、Minot Point及びTelldus Live。このタイプの装置は「可能な限りシステム内に生き残る」ことを意味し、断線またはその他の理由で一時的に見つからないために使用不能になることはなく、操作は再接続時に適用される。
第五に「Platinum」プラチナ級：例えば、HUE、Unifi、Daikin等々。このタイプの装置は開発チームの全ての評分基準を完全に満たし、完璧な非同期操作ができる。言い換えれば、反応は超早く、完璧な利用者体験を提供する。
多くの友人たちは、これらのことを読んだ後に、購入時は可能な限りプラチナ級の装置製品を選びたいと思うだろう。しかし、「理想は豊富だが、現実は骨太」である。リストにある統合コンポーネントは、真に「プラチナ級の装置製品」に該当するものに比べて、まるで少ないと言えよう。しかし、前述の通り、このリストの統合コンポーネントは常に増え続けているため、いつかは我々は「完全に統合UIを通じて」装置を設定できるであろう。その日が来るまで、我々は先に「YAML」を学んで我々の需求を達成しよう。本当に言えば、YAMLも本当に難しくない。少し時間をかけて理解すれば、容易く上達できる。
しかし心配なく、装置の選択と同時に、我々には次の指標があり、参考にすることができる。
IoTタイプ（IoT CLASS）：品質スケール（QUALITY SCALE）に比べて、この指標はほとんどが持たないのではない。全ての統合コンポーネントは自らのIoTタイプを持つ。
さて、IoT クラスをいくつか紹介します。
第一に「Assumed State」仮定状態：このクラスの装置は、我々は制御できるだけでなく、その状態を取得できないものです。言い換えれば、我々は最後に送信した指令を基に、装置の現在状態を推測するしかない。例えば、多くの人は赤外線を用いてエアコンを制御するが、確かに赤外線を送信して温度を設定した後、システム内でエアコンの温度を表示できる。しかし、もし他の人がリモコンを用いて温度を変更したら、システム内で表示された温度は間違いになります。
第二に「Cloud Poll」雲端ポーリング：このクラスの装置は、全てのデータが雲端に保存され、状態の変更は必ずシステムによって決定しなければならない。つまり、システムの設置場所は必ずネットワーク接続が必要で、同時にデータは即時性を保証できない。どういう意味か？システムが状態データを取得した直後、状態が変更された可能性がある。したがって、次回のデータ取得まで、時間差が生じる。また、データは雲端システムに保存されているため、通常「API Call」の頻度制限が設けられており、システムは毎分に雲端システムからデータを要求できない。そうでなければ、雲端システムのトラフィックは過負荷状態に陥り、異常が起こる可能性がある。因此、このタイプの統合コンポーネントは通常、更新頻度が比較的低い雲端サービスに該当する。
第三に「Cloud Push」雲端プッシュ：雲端ポーリングと同様、システムの設置場所は必ずネットワーク接続が必要。しかし、このクラスの統合コンポーネントは、状態が変更後、遠隔のシステムが自動的に状態を我々のシステムにプッシュする。つまり、我々が使用している雲端プラットフォームは、できるだけ即時的に我々のシステムに状態の通知をおこなう。この時点で、我々の統合コンポーネントの状態は、雲端ポーリングよりも実際の状態に近づく。
第四に「Local Poll」ローカルポーリング：このクラスのデータはローカルに保存され、ネットワーク環境は不要。このクラスの統合コンポーネントは、ローカル端APIを提供して、我々がそのコンポーネントと通信できる。しかし、状態の変更を自動的に通知はしない。前述の二つの雲端タイプと比較して、必ずしもネットワーク環境が必要ではないため、ネットワークが切断後制御できない問題は発生しない。しかし、「雲端ポーリング」と同様、データは即時性を保証できない。ただし、ローカルデバイスのため、通常は比較的高頻度で状態を取得できる。しかし、これは二重の問題を持つ。どういう意味か？もし高頻度でポーリングをおこなうなら、我々のシステムは頻繁にスレッドを実行してデータを要求しなければならない。結果として、システム資源の無駄な消費が発生する。ポーリングのため、デバイスは必ずしも待機状態に置いて、我々の要求を待つ必要があるため、比較的電力消費が多い。したがって、通常は電池駆動のデバイスはこの方式を採用しない。また、もし開発者が別のスレッドを起動してデータを要求しなければ、我々のシステムは待ち時間を発生する。つまり、システムはデバイスの状態を取得中、他の作業は一時的に停止し、デバイスのデータを取得後再開する必要がある。
第五に「Local Push」ローカルプッシュ：雲端の二つのクラスと同様、ポーリングがあるのならばプッシュもある。同時に雲端プッシュと同様、その利点は、状態が変更された同時に、即時的に我々のシステムに「装置の状態が変更されました」と通知できること。一般的に、電池駆動の装置の大部分はこのタイプに属し、理解しやすい。装置の状態が変更された同時に、我々の状態が変更されたことを公知のシステムに通知できるため、常に待機状態にして電力を浪費する必要はない。通常、電池駆動の装置以外に、継続的に電力を供給する装置もこのタイプに属する場合、一般的にポーリングをサポートする。すなわち、システムがダウンして再起動した時、起動の同時に装置の状態を取得できる。したがって、電池駆動の装置の場合、システム再起動後、通常は即座にその状態を知ることはできず、状態が変更されるのを待たなければならない。その後、その装置の現在の状態を知ることができる。
基本的に、以上に挙げた五つの項目は、装置を選択する際に参考にできる指標である。
手元に入手した装置を制御するには、まずその装置がどのような方式を通じて制御されるかを理解する必要があります。一般的に、いくつかの方式が存在します。最初の方式は直接接続制御です。二番目の方式は「Gateway」を通じて通信制御を行います。三番目の方式は当該ブランドの雲サービスを通じて制御を行いますが、これは絶対的なものではなく、例外もあります。要は、最初に公式の方式を通じて接続と制御を行うことができるようにする必要があります。一般的に、公式の方式で接続できる場合は、HomeAssistantを通じて接続を行うことがほぼできますが、当然の処理で例外もあります。
装置を出品するメーカーは全て自社で装置を生産しているわけではなく、多くは第三者の「オリジナル工場」を通じて生産され、出品時に自社のブランドを付けるだけのものもあります。このような場合は、「オリジナル工場」のAPPを通じて接続を行う方が便利かもしれません。例えば、小米が生産したデスクランプの中には、第三者の「オリジナル工場」が製造したものがあり、そのオリジナル工場が「YeeLight」です。オリジナル工場のAPPの接続方法の説明はここでは省略しますが、HomeAssistantの部分について直接説明します。
HomeAssistantの公式ウェブサイトを開き、上部にある「**Integrations**」をクリックします。このページの上部の検索バーに「YeeLight」と入力します（通常、最初の3文字を入力すれば、すぐに下方の結果欄に表示されます）。
「YeeLight」をクリックし、ページが遷移した後、まず右上方にそのカテゴリ属性が表示されます。ここでは「IoT Class」と表示され、その後方に「Local Push」と表示されています。表示は「その IoT クラスはローカルプッシュで、品質スケールではプラチナ評価を獲得しています。」。
これで、このデバイスがどのような方式を通じて制御されるかを確認することができます。HomeAssistantに追加する詳細な方法については、以降の説明でお伝えします。
API：
APIは「Application Programming Interface」の略称で、ソフトウェア同士が通信するための仕組みです。日本語では「アプリケーションプログラミングインターフェース」と訳されます。
APIを使うことで、異なるソフトウェア間でデータや機能を共有することができます。例えば、天気予報アプリが天気情報のAPIを使って、気象庁のデータを取得することができます。
実行スレッドとは：
実行スレッドは、**プログラムの実行単位**です。これは、**CPU コア上で実行される命令の連続した流れ**と考えることができます。
実行スレッドは、プログラムのパフォーマンスに大きな影響を与える可能性があります。スレッドの数や処理内容によっては、CPU コアの使用率が上がり、パフォーマンスが低下する可能性があります。
