JP7111295B2 - 現場における複数の相互作用システム - Google Patents

Description

＜関連出願の相互参照＞
本出願は、あらゆる目的のために参照文献として本明細書に援用される、「Ｍｕｌｔｉｐｌｅ Ｉｎｔｅｒａｃｔｉｎｇ Ｓｙｓｔｅｍｓ ａｔ ａ ｓｉｔｅ」と題する、２０１４年１２月８日出願の米国仮特許出願第６２／０８８，９４３号に対する優先権を主張する。

「スマートウィンドウ」と称される場合がある、エレクトロクロミック窓などの電子的に着色可能な窓は、限られた設備において利用されている。このような窓が受け入れられ、より幅広く利用されるにつれて、スマートウィンドウと相互作用する、ビル及び関連するインフラストラクチャのための様々なシステムが存在する可能性があるため、ますます高度化した制御及び監視システムが求められる。相互作用するビルシステムを管理する改良技術が必要である。

本開示の特定の態様は、窓制御システムならびに、照明システム、ＨＶＡＣシステム、セキュリティシステム及び／または家電機器制御システムであってもよい、少なくとも１つの他のシステムを含む、複数の相互作用システムに関する。窓制御システム及び少なくとも１つの他のシステムは、アプリケーションプログラミングインターフェース（ＡＰＩ）を介して通信するように構成される。窓制御システムは、１つまたは複数の光学的に切り替え可能な窓の光学的状態を制御するように構成される。

特定の実施形態において窓制御システムは、少なくとも１つの光学的に切り替え可能な窓の遷移を制御するように構成される窓制御装置を含む。特定の実施形態において窓制御システムは、ネットワークを介して通信するように構成される１つまたは複数の窓制御装置との電気通信を行う、複数のエレクトロクロミック窓を含む。

特定の実施形態において、少なくとも１つの他のシステムは家電機器制御システムである。特定の実施形態において、少なくとも１つの他のシステムはＨＶＡＣシステムである。いくつかの実施態様において、相互作用システムはさらに、ＨＶＡＣシステムを制御するように構成されるビル管理システムを含む。このような場合ＡＰＩは、窓制御システム及びビル管理システムが通信することを可能にするように構成されてもよい。特定の実施形態において、少なくとも１つの他のシステムは照明システムである。

いくつかの実施態様において、窓制御システム及び少なくとも１つの他のシステムは、窓制御システムによって取得されたか、または生成されたデータを少なくとも１つの他のシステムに提供するように構成される。いくつかの実施態様において、窓制御システムが少なくとも１つの他のシステムの１つまたは複数の装置を制御するように、窓制御システム及び少なくとも１つの他のシステムが構成される。

特定の実施形態において、少なくとも１つの他のシステムが窓制御システムの１つまたは複数の装置を制御するように、窓制御システム及び少なくとも１つの他のシステムが構成される。このような実施形態において、少なくとも１つの他のシステムはＨＶＡＣシステムまたは照明システムである。一例として、窓制御システムの装置は、センサ及び／または光学的に切り替え可能な窓を含む。

本開示の別の態様は、窓制御システムならびに、照明システム、ＨＶＡＣシステム、セキュリティシステム及び家電機器制御システムからなる群から選択された、少なくとも１つの他のシステムであってもよい、複数の相互作用システム間の通信方法に関する。いくつかの実施形態において、本方法は、以下の動作によって特徴づけられる。（ａ）窓制御システムからの、または少なくとも１つの他のシステムからの、窓制御システム及び少なくとも１つの他のシステムの他方宛ての、窓制御システムと少なくとも１つの他のシステムとの間の通信のためのアプリケーションプログラムインターフェース（ＡＰＩ）によって規定されたフォーマットを有する通信を受信することと、（ｂ）通信に含まれる命令及び／またはデータを、宛先である窓制御システムまたは少なくとも１つの他のシステムに提供することと、（ｃ）宛先である窓制御システムまたは少なくとも１つの他のシステムにおいて、通信に含まれる命令及び／またはデータを利用した１つまたは複数の動作を実行すること。

特定の実施形態において窓制御システムは、少なくとも１つの光学的に切り替え可能な窓の遷移を制御するように構成される窓制御装置を含む。窓制御システムはまた、ネットワークを介して通信するように構成される、１つまたは複数の窓制御装置との電気通信を行う複数のエレクトロクロミック窓を含んでもよい。

特定の実施形態において、少なくとも１つの他のシステムは家電機器制御システムである。特定の実施形態において、少なくとも１つの他のシステムはＨＶＡＣシステムである。このようないくつかの実施形態では、ビル管理システムがＨＶＡＣシステムを制御するように構成され、ＨＶＡＣシステムがＡＰＩを介して窓制御システムからの通信を受信する。特定の実施形態において、少なくとも１つの他のシステムは照明システムである。

いくつかの実施態様において、少なくとも１つの他のシステムが窓制御システムからの通信を受信し、通信は、窓制御システムによって取得されたか、または生成されたデータを含む。いくつかの実施態様において、少なくとも１つの他のシステムが窓制御システムからの通信を受信し、通信は、少なくとも１つの他のシステムの１つまたは複数の装置を制御するための窓制御システムからの命令を含む。

いくつかの実施態様において、窓制御システムが少なくとも１つの他のシステムからの通信を受信し、通信は、窓制御システムの１つまたは複数の装置を制御するための少なくとも１つの他のシステムからの命令を含む。一例として、窓制御システム上で制御される装置は、センサ及び／または光学的に切り替え可能な窓を含む。さらなる例として、少なくとも１つの他のシステムはＨＶＡＣシステム及び／または照明システムである。

これら及びその他の特徴及び利点について、関連する図面を参照してさらに詳細に説明する。

ＡＰＩを介して互いにインターフェース接続する窓システムを含む、相互作用システムのブロック図である。 外部システムとインターフェース接続するスマートウィンドウシステムのブロック図である。 窓制御ネットワークと相互作用するためのビル管理システム（ＢＭＳ）を有する現場の実施形態の概略図を示す。 ビルネットワークのブロック図を示す。 ビルの１つまたは複数の着色可能な窓の機能を制御するための窓ネットワークの構成要素の図である。 消色から着色及び着色から消色へとエレクトロクロミック・デバイスを駆動することと関連する電圧及び電流プロファイルを示すグラフである。 消色から着色へとエレクトロクロミック・デバイスを駆動することと関連する、特定の電圧及び電流プロファイルを示すグラフである。 窓制御装置の簡略ブロック図の構成要素を示す。 着色可能な窓及び少なくとも１つのセンサを含む部屋の概略図を示す。 ビル内の１つまたは複数のエレクトロクロミック窓の制御方法のための予測制御ロジックのいくつかのステップを示すフローチャートである。

本願では特に、切り替え可能な光学機器を利用するビルまたは他の現場の制御機能に関与する１つもしくは複数の、または独立したシステム間の通信のためのプラットフォームについて説明する。このような独立したシステムは、窓制御システム及び、住宅用製品（例えば、サーモスタット、煙警報器を制御するＮＥＳＴ（登録商標）（カリフォルニア州、パロアルト、Ｎｅｓｔ Ｌａｂｓ））、ＨＶＡＣシステム、セキュリティシステム、照明制御システムなどを制御するシステムなどの１つまたは複数の他の独立したシステムを含む。システムはともに、切り替え可能な窓及び、商業用、住宅用、または公衆の場であってもよい現場の他のインフラストラクチャを含む、複数の特徴及び／または製品を制御し、及び／または監視する。開示される実施形態を用いて利用されてもよい、ネットワーク及び関連するインフラストラクチャが、いずれも参照文献として本明細書に援用される、２０１４年１１月２６日出願の米国仮特許出願第６２／０８５，１７９号、及び、２０１５年１１月２４日出願の米国特許出願第１４／９５１，４１０号と同様に、図１Ａ～図１Ｅにおいても提示される。

場合によって現場は、１つまたは複数の配備装置の切り替えを制御する１つまたは複数の制御装置を備える。現場はまた、装置の切り替えのタイミング及び方法に関する判定を行う際に利用するデータを提供する、光センサ、熱センサ及び／または占有センサなどのセンサを備えてもよい。特定の実施形態において、現場では、窓及び／または鏡などの構造体上のエレクトロクロミック・デバイスなどの切り替え可能な光学機器を用いる。以下の説明において、切り替え可能な光学機器はしばしば、「窓」または「エレクトロクロミック窓」と称される。このような用語が切り替え可能な光学機器を有する他の窓の構造体を含むことを理解すべきである。さらに、切り替え可能な装置はエレクトロクロミック・デバイスに限定されず、画素化されていなくてもよい、液晶デバイス、電気泳動装置などの他の切り替え可能な装置を含む。

相互作用システムの１つは通常、窓制御ネットワークである。現場の相互作用システムは、１つのシステムのセンサ出力または他の情報を、異なるシステムの動作に関する判定を行うために利用してもよい。さらにシステムは、それが単一の現場（または複数の現場）から収集する情報を分析し、命令または異なるシステムのための他の命令を制御してもよい。１つのシステムは、適当な場合は、異なるシステム上の要素の機能を制御してもよい。例えば、窓ネットワーク制御システムは、窓システムが窓の色合いレベルを制御する部屋またはゾーンの照明レベルまたは空調レベルを調整するために、照明システム及び／またはＨＶＡＣシステムへと命令を送信してもよい。独立したシステムが相互作用することを可能にするためには、アプリケーションプログラミングインターフェース（ＡＰＩ）を介してそれらシステムの特性及び／または機能を表す必要がある。

システムは、そうしなければ外部システムには不明瞭であるデータ及び／または機能に外部システムがアクセスすることを可能にするために、ＡＰＩを用いる。ＡＰＩはアクセスを可能にするために、構文及びポータルを提供する。例えば、窓制御システムのためのＡＰＩは、ＵＲＬ、ユーザ名及びハンドシェイクを介した窓センサデータ（例えば、温度）へのアクセスを可能にしてもよい。ＨｏｍｅＫｉｔ（登録商標）に対応する定義は、Ａｐｐｌｅ（登録商標）（カリフォルニア州、クパチーノ、Ａｐｐｌｅ Ｉｎｃ．）ホームアプライアンスを制御するためのＡＰＩを示す。Ｔｈｒｅａｄ（登録商標）に対応する定義は、ＮＥＳＴ及びＳａｍｓｕｎｇ（韓国、ソウル、Ｓａｍｓｕｎｇグループ）を含む多数の他のテクノロジー企業の機器を制御するためのＡＰＩを示す。Ｔｈｒｅａｄ（登録商標）及びＨｏｍｅＫｉｔ（登録商標）は、メッセージングのための標準的接続プロトコルを定義する。

＜用語＞
「ｏｐｔｉｃａｌｌｙ ｓｗｉｔｃｈａｂｌｅ ｄｅｖｉｃｅ（光学的に切り替え可能な装置）」または「ｓｗｉｔｃｈａｂｌｅ ｏｐｔｉｃａｌ ｄｅｖｉｃｅ（切り替え可能な光学機器」」は、電気入力に応じて光学的状態を変化させる薄型装置である。本機器は、２つ以上の光学的状態間を可逆的に切り替える。これらの状態間の切り替えは、所定の電流及び／または電圧を装置に適用することによって制御される。本装置は通常、少なくとも１つの光学活性層をはさむ２つの導電性薄膜を含む。光学的状態に変化を駆動する電気入力が導電性薄膜に加えられる。特定の実施態様において、導電性膜との電気通信を行うバスバーによって入力が行われる。

光学的に切り替え可能な装置の例は、エレクトロクロミック・デバイス、特定の電気泳動装置、液晶デバイスなどを含む。光学的に切り替え可能な装置は、窓、鏡、ディスプレイなどの様々な光学的に切り替え可能な製品上に設けられてもよい。特定の実施形態において、これらの製品は通常、画素化されていないフォーマットで提供される。

「ｏｐｔｉｃａｌ ｔｒａｎｓｉｔｉｏｎ（光学的遷移）」は、光学的に切り替え可能な装置の、任意の１つまたは複数の光学特性の変化である。変化する光学特性は例えば、着色、反射率、屈折率、色などであってもよい。特定の実施形態において、光学的遷移は定義される開始光学的状態及び定義される終了光学的状態を有する。例えば、開始光学的状態は８０％の透過率であってもよく、終了光学的状態は５０％の透過率であってもよい。光学的遷移は通常、光学的に切り替え可能な装置の２つの導電性薄膜に適切な電位を加えることによって駆動される。

「ｓｔａｒｔｉｎｇ ｏｐｔｉｃａｌ ｓｔａｔｅ（開始光学的状態）」は、光学的遷移の開始直前の光学的に切り替え可能な装置の光学的状態である。開始光学的状態は通常、着色、反射率、屈折率、色などであってもよい光学的状態の大きさとして定義される。開始光学的状態は、例えば、９０％または４％の透過率などの、光学的に切り替え可能な装置のための最大または最小光学的状態であってもよい。あるいは、開始光学的状態は例えば、５０％の透過率などの、光学的に切り替え可能な装置の最大と最小光学的状態の間のいずれかに当たる値を有する中間の光学的状態であってもよい。

「ｅｎｄｉｎｇ ｏｐｔｉｃａｌ ｓｔａｔｅ（終了光学的状態）」は、開始光学的状態からの完全な光学的遷移の直後の光学的に切り替え可能な装置の光学的状態である。完全な遷移は、特定のアプリケーションのために完了すると理解される方法で光学的状態が変化する際に発生する。例えば、完全な着色は、７５％の光透過率から１０％の透過率への遷移と見なされる場合がある。終了光学的状態は、例えば９０％または４％の透過率などの光学的に切り替え可能な装置の最大または最小光学的状態であってもよい。あるいは、終了光学的状態は例えば、５０％の透過率などの、光学的に切り替え可能な装置の最大と最小光学的状態間のいずれかに当たる値を有する中間の光学的状態であってもよい。

「Ｂｕｓ ｂａｒ（バスバー）」は、光学的に切り替え可能な装置の領域に及ぶ透明導電性電極などの導電層に取り付けられた導電性ストリップを指す。バスバーは、外部リードから導電層へと電位及び電流を伝える。光学的に切り替え可能な装置は、それぞれが装置の単一の導電層に接続される２つ以上のバスバーを含む。様々な実施形態においてバスバーは、装置の長さまたは幅の長さのほとんどに及ぶ細長い線の形状である。バスバーは多くの場合、装置の縁付近に位置する。

「Ａｐｐｌｉｅｄ Ｖｏｌｔａｇｅ（印加電圧）」またはＶ_ａｐｐは、エレクトロクロミック・デバイス上の逆極性の２つのバスバーに加えられる電位の差異を指す。各バスバーは、別個の透明導電層に電気的に接続される。印加電圧は、光学的遷移の駆動または光学的状態の保持などの異なる大きさまたは機能であってもよい。透明導電層間には、エレクトロクロミック材料などの光学的に切り替え可能な装置の材料がはさまれる。透明導電層のそれぞれは、バスバーが接続される位置とバスバーから離れた場所との間の電位低下を受ける。一般的に、バスバーからの距離が広がるほど、透明導電層の電位低下も大きくなる。透明導電層の局所電位は本明細書においてしばしば、Ｖ_ＴＣＬと称される。逆極性のバスバーは、光学的に切り替え可能な装置の面に渡り、互いに左右に離間してもよい。

「Ｅｆｆｅｃｔｉｖｅ Ｖｏｌｔａｇｅ（実効電圧）」またはＶ_ｅｆｆは、光学的に切り替え可能な装置上の任意の特定の場所における正極性及び負極性透明導電層間の電位を指す。デカルト空間では、装置上の特定のｘ，ｙ座標のための実効電圧が定義される。Ｖ_ｅｆｆが測定される点において、２つの透明導電層は（装置の材料によって）はｚ方向に離間するが、同じｘ，ｙ座標を共有する。

「Ｈｏｌｄ Ｖｏｌｔａｇｅ（保持電圧）」は、装置を終了光学的状態で無期限に維持するために必要な印加電圧を指す。

「ｄｒｉｖｅ Ｖｏｌｔａｇｅ（駆動電圧）」は、光学的遷移の少なくとも一部の間にもたらされる印加電圧を指す。駆動電圧は、光学的遷移の少なくとも一部を「ｄｒｉｖｉｎｇ（駆動）している」と見なされてもよい。その大きさは、光学的遷移の開始直前の印加電圧の大きさとは異なる。特定の実施形態において、駆動電圧の大きさは、保持電圧の大きさよりも大きい。駆動及び保持電圧の例の応用を、図３に示す。

窓「ｃｏｎｔｒｏｌｌｅｒ（制御装置）」は、エレクトロクロミック窓のエレクトロクロミック・デバイスの色合いレベルを制御するために利用される。いくつかの実施形態において窓制御装置は、消色状態と着色状態の２つの色合い状態（レベル）の間でエレクトロクロミック窓を遷移させることが可能である。他の実施形態において、制御装置はさらに、（例えば、単一のエレクトロクロミック・デバイスを有する）エレクトロクロミック窓を中間の色合いレベルへと遷移させることができる。いくつかの開示される実施形態において、窓制御装置は、エレクトロクロミック窓を４つ以上の色合いレベルへと遷移させることが可能である。特定のエレクトロクロミック窓は、それぞれが２つの状態のライトである２つ（またはそれ以上の）エレクトロクロミック・ライトを単一のＩＧＵにおいて利用することによって、中間の色合いレベルを可能にする。

いくつかの実施形態において、窓制御装置は、エレクトロクロミック窓における１つまたは複数のエレクトロクロミック・デバイスに電力を提供することができる。特定の実施形態において、窓制御装置のこの機能は、アンテナ受信機能及び／または以下に記載する他の機能などの１つまたは複数の他の機能によって増大される。本明細書に記載の窓制御装置は、装置の光学的状態を切り替えるための電力を供給してもよい。例えば、制御装置はそれ自体の電源を有し、窓電源から窓への電源投入を命令する。他の実施形態において、光学的に切り替え可能な装置のための電源は窓制御装置から離間してもよい。しかし、エレクトロクロミック窓に電源を供給するために別途配線を行う必要がなくなるため、窓制御装置を有する電源を含み、窓に直接電源を供給するよう制御装置を構成することが便利である。

さらに本明細書に記載の窓制御装置は、ビル制御ネットワークまたはビル管理システム（ＢＭＳ）などのネットワークに窓制御装置を統合することなく、単一の光学的に切り替え可能な窓または複数のこのような窓の機能を制御するように構成されてもよい、スタンドアロン制御装置として説明される。しかし、窓制御装置は、ビル制御ネットワークまたはＢＭＳに統合されてもよい。

窓制御ネットワーク‐窓制御ネットワークは現場における窓などの複数の光学的に切り替え可能な装置を制御し、窓の制御に関連するデータにアクセスし、及び／またはそれを維持する。それは１つまたは複数の現場における切り替え可能な光学機器及び関連する制御装置ならびにセンサに関するデータを受信し、このデータから装置の切り替えに関する判定を行ってもよい。それはデータを送信し、及び／または、現場（複数可）における窓へのメッセージを制御してもよい。それはまた、潜在的な問題を検出し、及び／または提示し、装置及び／または制御装置の実行における傾向を特定し、切り替え可能な光学機器などを制御するためのアルゴリズムを修正してもよい。開示される実施形態において、窓制御ネットワークは、他のシステムと相互作用する。窓制御ネットワークについてさらに、図１Ａ～図１Ｄの記載を含めて以下に説明する。本開示による利用に適した様々な窓制御ネットワークの例は、いずれも参照文献としてその全体が本明細書に援用される、２０１２年４月１７日出願の米国特許第８，７０５，１６２号、２０１５年１１月２４日出願の米国特許出願第１４／９５１，４１０号、及び２０１５年１０月２９日出願の米国仮特許出願第６２／２４８，１８１号に記載されるものを含む。窓制御ネットワークは、ネットワークインフラストラクチャなしで、単一の制御装置及び／または窓を含んでもよいタイプの窓制御システムであると見なされてもよい。

現場‐これは、切り替え可能な光学機器のビルまたは他の設置場所である。切り替え可能な装置はネットワーク内に提供され、一体的に窓制御システムを構成する１つまたは複数のアルゴリズムの制御のもとで操作される。１つの光学的状態から別の状態への遷移は、その全体が参照文献として本明細書に援用される、２０１３年２月２１日出願の米国特許出願第１３／７７２，９６９号に記載されるプログラムまたはロジックなどによって命令されてもよい。現場は、窓制御ネットワークと通信する他のシステムを備えてもよい。他のシステムの例は、照明システム、ＨＶＡＣシステム、ファンシステム、セキュリティシステム、及びスマートサーモスタットサービスまたは他の家電機器サービスを含む。他のシステムは場合によっては、複数のシステムにおける装置を制御するための、ユーザによるカスタマイズ可能なインターフェースである。ユーザは例えば、ユーザのために加えられる窓の色合い、室温、及び照明の選好を有してもよい。このような選好は、例えば携帯機器を介したユーザの手動入力、または、ユーザが部屋またはゾーンに入る際の、例えばユーザが装着するデジタルセンサまたはスマート携帯電話との通信を介した、ユーザの近接を検出するシステムによってトリガされてもよい。現場の例は、居住用ビル、オフィスビル、学校、空港、病院、政府ビルなどを含む。その部屋は、ＮＥＳＴが提供するような、ネットワーク制御サーモスタットを有してもよい。

図１Ａは、現場と関連する、窓制御システム１０３、及び関連する窓１１１、ならびに他のシステムを示す。図は、複数の相互作用システム及び、それらの間のインターフェースを示す。上述のように、窓システム１０３とインターフェースする他のシステムは、ＨＶＡＣシステム、セキュリティシステム、及び照明システムなどのサードパーティ製システム１０９を含む。窓制御システム１０３はまた、ＮＥＳＴ（登録商標）などのビル制御サービスエンティティ１０５とインターフェースしてもよい。また、システム１０３は、１つまたは複数の現場に関する監視及び／またはパフォーマンス情報を提示するためにコンサルタントなどによって利用されてもよいサードパーティ製ダッシュボード１０７とインターフェースすることができる。これらのシステム（１０３、１０５、１０７、及び１０９）のいずれかによって提供されるサービスは、様々な場所のいずれかにおいてホストされてもよい。例えばそれらは内部サーバ及び関連するデータベースにおいてローカルでホストされてもよいか、またはそれらは専用または所有の仮想化サーバの集合（例えば、クラウドベースのサービス）において外部でホストされてもよい。図１Ａは、ＡＰＩが存在してもよいエンティティ間の論理的位置を示す。ファイアウォールは、これらの場所のいずれかに存在し得る。様々な実施形態において、「ｔｈｉｒｄ ｐａｒｔｙ ｓｙｓｔｅｍｓ（サードパーティ製システム）」、「ｂｕｉｌｄｉｎｇ ｃｏｎｔｒｏｌ ｓｅｒｖｉｃｅ ｅｎｔｉｔｉｅｓ（ビル制御サービスエンティティ」」及び「ｄａｓｈｂｏａｒｄｓ（ダッシュボード）」は、窓制御システムを制御するエンティティ以外のエンティティによって制御されるシステムである。しかし、必ずしもその通りとは限らない。サードパーティ製システムは単に、全体的にまたは部分的に窓制御ネットワークのインフラストラクチャ（複数可）から離間する、それ自体の物理的及び／または論理的インフラストラクチャを有するシステムであってもよい。

＜窓制御システムのためのＡＰＩ＞
いくつかの実施形態においてＡＰＩは、窓システムによって収集されたデータを外部システムが閲覧することを可能にする。これは窓システムによって直接収集されたデータを含み、また、外部システムに関連し、窓システムによってそれが収集する生データから得られる情報を含む。

いくつかの実施形態においてＡＰＩは、窓制御システムがサードパーティ製のシステムにアクセスし、それを制御することを可能にする。例えば照明制御システムは、特定の条件下で窓制御システムが照明制御システムにアクセスすることを可能にするＡＰＩを提供してもよい。いくつかの実施態様において窓制御システムは、窓制御システムが外部システムの態様を制御することをＡＰＩを介して可能にするか、またはトリガする、関連するヒューリスティックスを用いる。

いくつかの実施形態においてＡＰＩは、外部システムが特定のゾーンにおける窓の着色などの窓制御システムの態様を制御することを可能にする。上述のように、外部システムが窓制御システムの機能にアクセスすることが可能になるようトリガする特定の条件が存在してもよい。

ＡＰＩインターフェースは通常、窓制御システムの窓制御装置から離れた装置またはシステム上で利用されるか、または実行される。例えばＡＰＩは、窓制御ネットワークにおいて、クラウドレベルまたは主制御装置レベルで実行されてもよい。しかし、これに限る必要はなく、実際には、ＡＰＩを窓制御装置において実行させて（または窓制御装置にフェイルオーバーＡＰＩ処理能力を含ませて）、窓ネットワークの機能が損なわれる場合に、システム間の通信を維持することが望ましい場合がある。このような実施態様において、ローカルの窓制御装置（複数可）はサードパーティ製システムとローカルで通信し、占有者のための快適性及びサービスを維持することができる。

＜窓制御システムのためのＡＰＩの実施例＞
１．窓制御システムは、未処理の収集情報及び／または未処理の情報から得られた処理済みの情報を、インターフェースするシステムに提供する。
ａ）送信情報は、感知データ、予測イベント、ならびに現場及び装置製品及び設定情報を含んでもよい。
ｂ）例（窓、ゾーン、ファサード、ビルまたは他の現場の側面のそばの、以下のいずれか）
温度―屋内または屋外
感知された日射量―方向
屋内フォトセンサ―ガラスまたは方立
太陽熱利得
占有―赤外線、動き、―部屋の中の人数
太陽計算機（角度、強度）―方位角的、傾き
天候―雲量
積雪―凍った湖
現場及び装置の設定情報―以下の例
ＧＥＴ／ｓｉｔｅｓは、適用可能なｉｐアドレスを含む現場に関するメタデータを提示する。
ＧＥＴ／ｓｉｔｅ／｛ｓｉｔｅ＿ｉｄ｝は、具体的な現場及びゾーングループならびにその現場内のゾーンに関するメタデータを提示する。
ＧＥＴ／ｚｏｎｅ／｛ｚｏｎｅ＿ｉｄ｝は、どの装置及びサービスが利用可能であるか、などの具体的なゾーンに関する情報を事前設定する。
ｃ）この情報を受信する、インターフェースするシステムは、この情報を利用して、それ自体の（窓でない）機器の制御あるいは管理のために判定を行ってもよい。
ｄ）インターフェースするシステムは、それ自体のダッシュボードにおいてこの情報を提示することができる。
ｅ）設定情報は、ピアインターフェースを行うシステムが現場の所有者が設定に利用する窓ゾーンの文脈内でサービスを提供することを可能にする。例えば現場の所有者はゾーン情報を一度設定し、照明、暖房、家電機器などの制御において同じゾーンを利用することができる。窓制御システムのためのゾーンについて、その全体が参照文献として本明細書に援用される、２０１３年４月１２日出願のＰＣＴ特許出願番号第ＰＣＴ／ＵＳ１３／３６４５６号の文脈でさらに説明する。

２．窓制御システムは、それ自体の窓着色情報（現在及び／または将来）を、インターフェースするシステムに提供する。
ａ）例えば窓ネットワークは、時間ＸにおいてゾーンＺの窓の濃度を３０％上げる。遷移には時間Ｔがかかる。
ｂ）情報は、ゾーンごとに、または現場に関する他の設定情報とともに提供することができる。１（ｅ）の本態様が適用される。
ｃ）この情報を受信するインターフェースするシステムは、この情報を利用して、それ自体の（窓でない）機器の制御あるいは管理のために判定を行ってもよい。
ｄ）インターフェースするシステムは、それ自体のダッシュボードにおいてこの情報を提示することができる。

３．窓制御システムは、付加価値コンテンツをインターフェースするシステムに提供する。
ａ）窓ネットワークは、（窓、ゾーンなどごとの）センサデータならびに現在および将来の色合いレベルなどの、その利用可能な情報を利用して、窓ではない、相互作用するシステムに有用な付加価値コンテンツを定義する。
ｂ）このようなコンテンツの例は、以下を含む。
ＨＶＡＣのための、太陽計算機を用いて感知され、及び／または予測されるような、ファサードを通じたエネルギー量。同様に時間に基づく（フロアごと、方向ごとの）粒度。それらが提供する必要があるＢＴＵ数を計算する。ファサードまたは窓の開放に必要な加熱／冷却ＢＴＵ。
スマート家電機器サービスのために、サーモスタットの温度及び窓の温度から判定された温度勾配を提示する。差異が大きい場合、インターフェースするシステムが快適性のために加熱（または冷却）を強める必要があることを示す可能性がある。
照明制御システムのために、例えば、窓からの光量及び方向、太陽計算機、環境条件（雲、雪、反射）、占有、ユーザ開始着色決定などによって判定される推奨照明レベルを提示する。
ｃ）この情報を受信するインターフェースするシステムは、この情報を利用して、それ自体の（窓でない）機器の制御あるいは管理のために判定を行ってよい。
ｄ）インターフェースするシステムは、それ自体のダッシュボードにおいてこの情報を提示することができる。

４．窓制御システムは、その機能を示す。
ａ）スマート家電機器制御サービス、照明システム、またはセキュリティシステムなどのインターフェースするシステムは、それ自体の必要性に基づいて色合い決定を行ってもよく、及び／または（ＢＡＣｎｅｔなしに）窓の色合いレベルのコマンドを窓ネットワークへと送信してもよい。
ｂ）ホームオートメーションの例‐窓制御システムは、スマートサーモスタット（または他の家電機器）サービス（例えば、ＮＥＳＴ（登録商標））が窓の着色を制御することを可能にする。これは、時間帯、占有、及び、スマート家電機器サービスが有し、利用する他のタイプの情報に基づいてもよい。同様に実施形態は、サーモスタット及び着色の遠隔制御を可能にする。実施形態は、外部サービスにおいて窓を透明にするための休暇モードを可能にし、照明においてパイプが凍結する可能性を低減させることを可能にする。実施形態は、警備会社が特定の時間に家の窓を暗くすることを可能にし、照明をつけることを可能にする。実施形態は、窓を午後１０時に透明にし、隣人が家の中を見ることを可能にする。
ｃ）セキュリティ／占有の例‐窓制御システムは、施錠時に暗くなり、盗難の際に透明になるなどの、窓システムの制御を可能にする。
ｄ）窓制御機能は、ゾーンごとに、または現場に関する他の設定情報を用いて示すことができる。１（ｅ）の本態様が適用される。

５．窓制御システムは、インターフェースするシステムの機器を制御する。
ａ）例えば、照明または空気調和システムは、着色／消色の判定に基づいて、窓制御システムが照明または空気調和を制御する許可を与える。
テレビ、コンピュータ、及びオフィス機器などの電気機器によって熱が生成される。プラグ負荷（オフィス機器など）の感知は、現場に負荷センサ（関心領域ごとのリアルタイム電力モニタ）を設けることによって可能とされてもよい。これらのセンサは、ＨＶＡＣまたは照明システムの一部であってもよい。特定の実施形態において、窓制御システムは、このようなシステムから（ＡＰＩを介して）装置にアクセスし、それらから情報を収集し、その後、その情報を収集した他のデータと組み合わせ、その結果を利用して、インターフェースするシステムの装置を制御する。例えば窓システムは、プラグ負荷を読み取り、それをファサードに当たる入射エネルギー及び現在のＨＶＡＣ加熱／冷却ＢＴＵと組み合わせて、場所におけるエネルギーの利用を最適化してもよい。
ｂ）ネットワーク化したサーモスタットの制御例
窓制御システムは、窓システムが窓の着色を通じて熱負荷を低減した、または低減し始める際に、空調を止めるようにサーモスタットに命令する。
窓制御システムにおける センサは、例えば、窓制御装置及び／または壁のインターフェースにおいてビーコンが利用するＢＬＥ（Ｂｌｕｅ Ｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ）によって占有を検出する。この情報を用いて、窓制御システムはそのモードを外出モードから帰宅モードに変更するようサーモスタットに命令する。
ｃ）窓制御システムは、インターフェースするシステムのＡＰＩ（例えば、サーモスタット制御ＡＰＩ）にコールすることによって、制御を実行してもよい。あるいは、インターフェースするシステムは、窓制御システムのＡＰＩをサブスクライブし、窓制御システムが提供する情報に基づいて動作を行ってもよい。

６．ユーザによってカスタマイズ可能なシステムは、窓制御システム及び他のピアシステムとインターフェースする。ユーザによってカスタマイズ可能なシステムはユーザの選好を提示して、現場のシステム上で装置を制御し、それらをユーザが予め定義した状態にする。
ａ）例えばユーザは、ユーザのために加えられる、窓の色合い、室温、及び照明の選好を有してもよい。
ｂ）このような選好は、例えば携帯機器を介したユーザの手動入力、または、ユーザが部屋またはゾーンに入る際の、例えばユーザが装着するデジタルセンサまたはスマート携帯電話との通信を介した、ユーザの近接を検出するシステムによってトリガされてもよい。

＜窓制御システム＞
他のシステムとのインターフェース接続に適した窓システムの一例を、図１Ｂに示す。そこに示すように、窓システム１１のインターフェースロジックは、複数の窓制御装置（１～３）、センサ（１～２）、ならびに、切り替え可能な窓及び制御装置と関連する任意の他のインフラストラクチャとインターフェースする。システム１１は、本明細書にて他に記したように構成されてもよい窓制御装置ネットワークを介して、窓制御装置、センサ、及び他のインフラストラクチャにアクセスしてもよい。システム１１はまた、それぞれがその機能に関連する情報を送信し、及び／または受信することができる、ワークステーション、ポータブルコンピュータ、スマートフォンといった携帯機器などを通じてアクセス可能な、複数の外部システムまたはサービス１～４（例えば、スマート家電機器ネットワークサービス（例えば、ＮＥＳＴ（登録商標））またはＨＶＡＣシステム）と相互作用する。いくつかの実施態様において、サービスまたはシステムは、窓システムに利用可能な情報のサブセットのみへのアクセスを許可されてもよい。

システム１１は、様々なハードウェア及び／またはソフトウェア構成において実装されてもよい。示される実施形態において、システム１１は、データウェアハウス１３、分析サーバ１５、及びレポートサーバ１７を含む。示される例において、例えば、制御装置の階層を含む窓制御ネットワークによる、窓制御装置及び／またはセンサとの直接のデータウェアハウスインターフェースについて、図１Ｃ～Ｅを参照して以下に記す。データウェアハウスは、これらの特徴からのデータを関係データベースまたは他のデータ格納部に格納する。一実施形態においてデータは、Ｏｒａｃｌｅ（登録商標） ＤＢ、Ｓｅｑｕｅｌ ＤＢ，またはカスタム設計されたデータベースなどの、データベースまたは他のデータリポジトリに格納される。データウェアハウス１３は、本明細書において他に記すような、いくつかのセンサ及び制御装置のタイプのいずれかから情報を取得してもよい。示される実施形態において、分析サーバ１５及びレポートサーバ１７は、外部システムとインターフェースして、サービス及びレポートをそれぞれ提供する。一実施形態において、レポートサーバは、Ｔａｂｌｅａｕ（登録商標）、Ｊｕｍｐ（商標）、Ａｃｔｕａｔｅ（ＯｐｅｎＴｅｘｔ）、またはカスタム設計されたレポート生成装置を実行する。示される実施形態において、データウェアハウス１３及び分析サーバ１５はそれぞれ、情報をレポートサーバ１７に提供する。データウェアハウス１３通信と分析サーバ１５との間の通信は双方向である。外部サービス及び／またはシステムとのインターフェースは、外部サービス／システムのそれぞれにＡＰＩを利用するためのロジックによって構成される通信インターフェース１２５を介して行われてもよい。ウィンドウインテリジェンスシステム１１及び外部システム／サービスのそれぞれの要件に応じて、それらの間の通信は双方向または一方向であってもよい。ウィンドウインテリジェンスシステムは、通信ブロック１２５において実装される無線接続またはケーブル接続を介して外部システム／サービスとインターフェースしてもよい。

窓ネットワーク構成の例を図１Ｃ～図１Ｅに記し、以下で説明する。窓ネットワークシステムは通常、それぞれが制御装置、照明センサなどの複数のセンサ、ならびに、ネットワーク制御装置及び主制御装置などの１つまたは複数の高レベル制御装置によって直接制御される、複数の切り替え可能な光学機器を含む。

特定の実施形態において、ウィンドウインテリジェンスシステム１１は、「ｃｌｏｕｄ（クラウド）」上で実装される。システムは集中させるか、または分散させることができ、また、クライアントアプリケーションを利用して、権限者によりどこからでもアクセスすることが可能である。システムの様々な構成要素は、１つまたは複数の現場において、全ての現場から離れた場所において、及び／またはクラウド上で、ともに、または離れて位置してもよい。システム１１の付加的な特徴、機能、モジュールなどは、データ及びイベントレポータならびにデータ及びイベントログ、ならびに／またはデータベースを含んでもよい。

センサ及び制御装置の監視を通じて、ウィンドウインテリジェンスシステムは、以下のサービスのうちの任意の１つまたは複数などの多くのタイプのサービスを提供してもよい。
ａ．カスタマーサービス‐本システムは、切り替え可能な装置、センサ及び／または制御装置からのデータが外部システムにおける問題を示す際にそれを認めるように構成することができる。それに応じて、サービス担当者を呼び出して問題を修正させるか、または問題がある旨を伝達させることが可能である。場合によっては、潜在的な問題にフラグが立てられ、外部システムに明らかになる前に解決される。窓システムは、外部システムを用いて問題をオートコレクトするように構成されてもよい。別段の記述がない限り、本明細書に記載されるような問題、イシュー、エラーのいずれかは、窓制御システムにおけるヒューリスティックスを利用してオートコレクトすることができる。
問題の検出時にはアラート通知が送信されてもよい。
本システムはまた、先読みデータをＨＶＡＣシステムなどの外部システムに提供し、それによって、このようなシステムがユーザの快適性を向上させ、及び／またはエネルギーを節減することを可能にしてもよい。
ｂ．観察される利用傾向に基づいて設置をカスタマイズする。ユーザの選好は時間の経過とともに、プログラムに組み込まれてもよい。一例として、窓システムは、エンドユーザ（例えば、占有者）が特定の時間帯に暖房または照明制御アルゴリズムをオーバーライドしようと試みる方法を判断してもよく、この情報を利用してユーザの将来の行動を予測する。それは、学習したユーザの選好にしたがって色合いレベルを設定するために、関連する外部システムを通知し、及び／または窓制御アルゴリズムを修正してもよい。
ｃ．他の外部システムまたは設備に学習した手法を利用する（例えば、午後の雷雨接近時に窓を着色し、窓を照らし、部屋を暖房／冷房する最善の方法）。切り替え可能な装置のネットワークの基地局からの総体的経験及び情報を利用することで得られる利点がある。例えば、制御アルゴリズムを微調整し、特定のマーケットセグメントのために窓／ネットワーク製品をカスタマイズし、及び／または新しいアイデア（例えば、制御アルゴリズム、センサ配置）を試す上で役立つ。
ｄ．エネルギーコンサルティングサービス。このようなサービスは、ビルのエネルギー消費、窓の色合い決定、（例えば、ビルの異なる側面における）日射フラックス、ローカルの天候情報（雲量、温度など）などのビルに関する情報を利用してもよい。このような情報は、例えば、月、週、日、時間、分などの様々な時間単位で提供されてもよい。エネルギーコンサルティングサービスは、情報が取得されたビル（複数可）及び／または同様のビル（例えば、近隣のビル、同様の気候における、または同様の緯度におけるビル）のための分析及び／または提案を行う上で、このような情報を利用してもよい。また、エネルギーコンサルティングサービスは、ユーティリティ、ＨＶＡＣ機器サプライヤ、キャンパス、電力網などへの制御サービスを提供するエンティティなどのエネルギーインフラストラクチャエンティティに分析及び／または提案を提示するために、情報を利用してもよい。
ｅ．情報を売買するベンダー。いくつかのベンダーは様々なソースからの情報を統合し、バイヤーのニーズにカスタマイズした有用なタグをまとめる。

＜監視データ＞
以下の説明において、窓システムによって監視されてもよいいくつかのタイプの現場情報の例を提示する。情報は、個別の切り替え可能な装置のための電圧及び／または電流対時間のデータ、対時間のセンサ出力データ、制御装置ネットワークのための通信及びネットワークイベント及びログなどの様々なソースから提供されてもよい。可変時間は、時間帯または暦日と同様に、太陽位置、天候などの外部イベントと関連付けてもよい。定期的な構成要素を伴う情報は、周波数領域及び時間領域において分析されてもよい。

１．窓制御装置Ｉ／Ｖデータからの、
ａ．ピーク電流の変化。これは、光学的遷移の生成のために駆動電圧にランプを加える際に生じる場合がある。図２及び３を参照。
ｂ．保持（漏洩）電流の変化。これは、切り替え可能な装置の終了状態において観察されてもよい。漏洩電流の増大率は、装置内でショートが起こる可能性と相関し得る。ショートにより、装置内でハローなどの望ましくない欠陥が生じる場合がある。
ｃ．必要な電圧補償の変化。電圧補償は、電源から切り替え可能な装置への導電路における電圧低下を補うために必要な電圧の変化である。
ｄ．移送される全電荷の変化。これは、一定時間の間及び／または切り替え可能な装置の特定の状態の間に（例えば、駆動中または保持中に）測定されてもよい。
ｅ．電力消費の変化。電力消費は、窓または制御装置ごとに、（Ｉ＊Ｖ）によって計算されてもよい。
ｆ．同一の負荷を有する同じファサード上の他のＷＣ（窓制御装置）との比較。これにより、制御装置によって制御される特定の装置ではなく、特定の制御装置に問題があることを監視システムが判断することが可能になる。例えば窓制御装置は、それぞれが同じ問題を示す５つの絶縁ガラスユニットに接続され得る。５つの装置が同じ問題を被る可能性は低いため、監視システムは制御装置が原因であると結論付けることができる。
ｇ．異常プロファイルのインスタンス。例えば、二重着色／二重消色。二重着色／消色は、正常な駆動サイクル（電圧及び／または電流プロファイル）が加えられ、切り替え可能な装置が切り替えられていないことが判明する状況を指す。この場合、第２の駆動サイクルを実行しなければならない。
ｈ．切り替え特性対外部天候。特定の温度または天候条件において、監視システムは、特定の切り替え結果または実行を予想する。予想される反応からの乖離は、制御装置、切り替え可能な装置及び／またはセンサの問題を示す。

本明細書に記載の変化及び比較は、例えば、ネットワーク制御装置レベルで収集されたデータから生成することができる。履歴データ（日、週、月、年）はウィンドウインテリジェンスシステム内に保存され、このようなデータは比較のために利用することができる。このようなデータを用いて、温度による変動を識別し、適当な場合には無視することができる。様々な変化は、合わせてまたは組み合わせて、窓、制御装置、センサなどにおける問題の定義を提供してもよい。上述のパラメータのうちの任意の１つまたは複数により、電源から切り替え可能な装置への（かつ、それを含む）任意の位置において、インピーダンスの増大を特定してもよい。この経路は、切り替え可能な装置、装置に接続されるバスバー、バスバーへのリードアタッチ、リードアタッチまたはＩＧＵへのコネクタ、コネクタ（またはＩＧＵ）と電源との間のワイヤ群（「ｐｉｇｔａｉｌ（ピッグテール）」と称される場合がある）を含んでもよい。一例として、パラメータ１ａ～１ｅの任意の１つまたはそれ以上の変化が、窓枠の水によって生じた腐食を示してもよい。これらのパラメータの組み合わせを利用したモデルはこのような腐食の定義を認識し、この問題を遠隔にて正確に報告してもよい。

２．窓制御装置状態及びゾーン状態からの変化
ａ．任意の窓制御装置がゾーンと同期しない場合の原因は、通信上の問題である可能性がある。例えば、１つのゾーン複数の制御装置が存在し、これらの制御装置の１つが予想される動作を行う場合、窓システムは、異常な制御装置が通信ネットワークに関するコマンドを受信していないか、またはそれにしたがっていないと結論付ける可能性がある。本システムは問題の原因を隔離し、それを修正するための措置を取ることができる。
ｂ．ゾーンの最長切り替え時間及び全てのガラスを同じ速度で切り替えさせるための調整。本システムは、所望の速度または予想速度で切り替えを行っていない特定の切り替え可能な装置を特定してもよい。窓システムは装置を交換または修正することなく、装置が予想速度で切り替えを行うように、切り替えアルゴリズムを修正してもよい。例えば、装置の切り替えが遅すぎることが観察される場合、その駆動のためのランプまたは駆動電圧が増大してもよい。これは遠隔で行うことが可能である。

３．システムログからの、
ａ．通信エラー頻度の何らかの変化‐騒音の増大または装置の劣化。制御装置から受信される通信の速度が落ちるか、または停止する場合がある。あるいは、送信通信が認識されないか、または実行されない場合がある。
ｂ．ピッグテールが断線を示し始めている場合の接続劣化。特定の実施形態においてコネクタは、それが断線し始めていることを示す信号を出す。窓制御装置は、窓システムにおいて記録することが可能であるこのような信号を受信してもよい。

４．センサデータからの、
ａ．時間の経過による何らかの劣化。これは信号強度の低下として明白に表れる場合がある。それは、センサへの損傷、センサ上の汚れ、センサの前に現れる障害物などを含む様々な要因によって引き起こされる可能性がある。
ｂ．外部天候との相関。窓システムは通常、フォトセンサ出力が天候と相関するはずであると仮定する。
ｃ．インテリジェンスが正確に動作するように万全を期すための、ゾーン状態変化との比較。窓システムは通常、そのフォトセンサ出力が特定の状態変化の基準を満たす場合にゾーンが状態を変化させると予想する。例えば、晴天条件への遷移をセンサが示す場合、ゾーン内の切り替え可能な装置は着色を行う。特定の実施形態において、ゾーンごとに１つまたは複数のフォトセンサが存在する。
ｄ．試運転後の周囲の何らかの変化。一例として、センサの前に木が育つか、またはセンサの前にビルが建設される。このような周囲の変化は、複数のセンサが同様に影響を受ける変化に影響される（例えば、それらのフォトセンサ出力が同時に低下する）ことによって明示されてもよい。試運転は特に、現場におけるセンサ、制御装置及び／または切り替え可能な光学機器の配置に関する情報を提供する。試運転については、その全体が参照文献として本明細書に援用される、２０１３年４月１２日出願のＰＣＴ出願第ＰＣＴ／ＵＳ２０１３／０３６４５６号においてさらに説明されている。
ｅ．中央または多機能センサからのデータ。いくつかの実施形態においてビルは、窓の着色または他のビル管理に関連する様々なパラメータのための感知データを提供する多機能センサを有する。このような多機能センサに含まれてもよい個別のセンサの例は、温度センサ、方向フォトセンサ（例えば、異なる方位角及び／または高さ方向に配向した３つ以上のフォトセンサ）、湿度センサなどを含む。フォトセンサは、可視光、赤外線放射、紫外線放射、またはその任意の組み合わせをとらえてもよい。特定の実施形態において多機能センサは、天候に関連するデータを提供する。一例では、その全体が参照文献として本明細書に援用される、２０１５年１０年６日出願の米国特許出願第６２／２３８，１００号に記載されているように、センサはリングセンサである。

５．状態変化の原因のログファイル分析からの、
ａ．ゾーンによるオーバーライド‐ゾーンの制御アルゴリズムのさらなる調整。窓システムは特定の現場の要件を学習し、要件に対応するためのその学習アルゴリズムを適応させてもよい。様々なタイプの学習が、その全体が参照文献としてすでに本明細書に援用された、２０１３年４月１２日出願のＰＣＴ出願第ＰＣＴ／ＵＳ２０１３／０３６４５６号に説明されている。
ｂ．ｉＯＳ対壁面スイッチオーバーライド‐顧客の選好。オーバーライドが観察される場合、監視システムはオーバーライド、壁面スイッチまたは携帯機器を起動させる装置の種類を認めることが可能である。壁面スイッチのより頻繁な利用により、携帯機器上の窓のアプリケーションのトレーニングに関するイシューまたは問題を示すことができる。
ｃ．様々な状態の時間／頻度‐各状態の有用性。複数の着色状態が利用可能であり、一部が利用されていない場合、特定の状態に問題があることを遠隔監視システムに対して示すことができる。本システムは、状態の透過率または他の特性を変化させてもよい。
ｄ．マーケットセグメントによる変動。現場の切り替え特性の特定の状態または他の特性の利用頻度（人気）は、マーケットセグメントと相関してもよい。窓システムはこれを学習すると、マーケット特有のアルゴリズムを発展させ、提供することができる。マーケットセグメントの例は、空港、病院、オフィスビル、学校、政府ビルなどを含む。
ｅ．遷移の総数‐保証期間及び寿命の間のサイクルのマーケットセグメントにより予想される数。これにより、現場のライフサイクル情報が提供されてもよい。

６．エネルギー計算
ａ．ゾーンによって節減される季節ごとのエネルギー、季節ごとの全システムエネルギー節減。窓システムは、エネルギー節減を判定し、改善を行うアルゴリズム、装置タイプ、構造体などを特定してもよい。ＨＶＡＣシステム及びスマートサーモスタットサービスまたは他の家電機器サービス（例えば、ＮＥＳＴ（登録商標））などの外部システムに、パフォーマンス情報を提供し、提案を行う。
ｂ．ゾーンごとに予告エネルギー負荷情報をＡＣシステムに提供する。ビルは大きな熱質量を有するため、空調及び暖房は直ちには効果を発揮しない。窓システムは太陽計算機または他の予測ツール（本明細書にて他に説明する）を利用して、遷移を早く開始させることができるように、ＨＶＡＣシステムまたはＮＥＳＴ（登録商標）に予告を行うことが可能である。この情報をゾーンごとに提供することが望ましい。

７．窓アンテナ
ａ．特定の実施形態において、窓及び／または関連する構造体（例えば、制御装置、ＩＧＵスペーサ、及び枠）には、アンテナが取り付けられるか、または組み込まれている。このような窓アンテナの例は、その全体が参照文献として本明細書に援用される、２０１５年１１月２４日出願のＰＣＴ特許出願番号第ＰＣＴ／ＵＳ２０１５／０６２３８７号において説明されている。
ｂ．窓アンテナは、携帯電話などの通信可能機器を持つ占有者及び／または訪問者の場所を提供することができる。
ｃ．侵入者及び他のセキュリティ関連の情報の存在（例えば、窓がプライバシー設定を起動している場合）
ｄ．窓アンテナによって提供されるサービスにおいて利用されるか、または利用可能な帯域

特定の実施形態において、窓、制御装置及び／またはセンサの実行または反応を、時間的な初期点において確認し、その後、繰り返して再確認する。場合によっては、傾向、乖離、安定性などを検出するために、最新の実行／反応測定値が前の実行／反応測定値と比較される。必要であれば、比較時に検出された傾向または乖離に対する対応を行うために、調整を行うことができるか、またはサービスを提供することができる。窓、センサ、または制御装置のための関連するパラメータの集合は、装置の「ｆｉｎｇｅｒｐｒｉｎｔ（フィンガープリント）」としての役割を果たしてもよい。このようなパラメータは、本明細書においてほかに記すように、電圧応答、電流応答、通信性能などを含む。いくつかの実施形態において、窓、センサ及び／または制御装置は工場において確認され、任意にフィンガープリントされる。例えば、切り替え可能な窓は関連するパラメータを抽出することができる手順において、焼け焦げる可能性がある。問題を示す窓は、それらの現在のパフォーマンスを前のフィンガープリントと比較し、輸送／設置後または動作中に問題が発生したか否かを任意に判断することができる。フィンガープリントはまた、装置が試運転される（例えば、現場に設置され、最初に検出され、目録にのせられる）際に、任意で自動的に、生成することができる。試運転については、その全体が参照文献として本明細書に援用される、２０１３年４月１２日出願のＰＣＴ特許出願番号第ＰＣＴ／ＵＳ２０１３／０３６４５６号に記載されている。

＜ビル管理システム（ＢＭＳ）及びスマートアプライアンスシステム＞
ＢＭＳは、換気、照明、電力システム、エレベータ、火災システム、及びセキュリティシステムなどの現場の機械及び電気機器を監視し制御することができる、現場（例えば、ビル）に設置されたコンピュータベースの制御システムである。特定の実施形態において、ＢＭＳは、窓システムと通信して、制御信号を受信し、監視された情報を現場のシステムから通信させるよう設計されるか、またはそうするように構成されてもよい。ＢＭＳは、単数のコンピュータまたは複数のコンピュータへの通信チャネルによる相互接続を含むハードウェア、及び、占有者、現場管理者及び／または窓システム管理者が設定する選好に従った現場における条件を維持するための関連するソフトウェアからなる。例えばＢＭＳは、イーサネット（登録商標）などのローカルエリアネットワークを利用して実装されてもよい。ソフトウェアは、例えば、インターネットプロトコル及び／またはオープン標準に基づき得る。ソフトウェアの一例は、Ｔｒｉｄｉｕｍ，Ｉｎｃ．（バージニア州、リッチモンド）のソフトウェアである。ＢＭＳを一般的に利用した１つの通信プロトコルは、ＢＡＣｎｅｔ（ビルオートメーション及び制御ネットワーク）である。

ＢＭＳは大型ビルにおいて最も一般的であり、少なくともビル内の環境を制御するために通常、機能する。例えばＢＭＳは、ビル内の温度、二酸化炭素レベル、及び湿度を制御してもよい。通常、ヒータ、空気調和機、送風機、通気口などのＢＭＳによって制御される多数の機械装置が存在する。ビル環境を制御するために、ＢＭＳは定義された条件で、これらの様々な装置をオン・オフしてもよい。典型的な新しいＢＭＳのコア機能は、暖房及び冷房コスト／需要を最小化しながら、ビルの占有のための快適な環境を維持する。このように、新しいＢＭＳは、例えばエネルギーを節減し、ビル運転コストを低減させるべく、様々なシステム間の相乗を監視し制御するためだけでなく、最適化するために利用される。

いくつかの実施形態において、窓制御システムが１つまたは複数のエレクトロクロミック窓または他の着色可能な窓を制御するように構成される場合、窓制御システムはＢＭＳとインターフェースする。一実施形態において、１つまたは複数の着色可能な窓のそれぞれは、少なくとも１つの完全に固体及び無機のエレクトロクロミック・デバイスを含む。別の実施形態において、１つまたは複数の着色可能な窓のそれぞれは、完全に固体及び無機のエレクトロクロミック・デバイスのみを含む。別の実施形態において、１つまたは複数の着色可能な窓は、「Ｍｕｌｔｉｐａｎｅ Ｅｌｅｃｔｒｏｃｈｒｏｍｉｃ Ｗｉｎｄｏｗｓ」と題する、２０１０年８月５日出願の米国特許出願第１２／８５１，５１４号に記載するように、多状態のエレクトロクロミック窓である。

図１Ｃは、セキュリティシステム、暖房／換気／空調（ＨＶＡＣ）、ビルの照明、電力システム、エレベータ、火災システムなどを含むビルのいくつかのシステムを管理するＢＭＳを有する現場ネットワーク１１００の実施形態の概略図である。セキュリティシステムは、回転式改札口、電磁駆動式ドア錠、監視カメラ、盗難警報器、金属探知機などにアクセスする磁気カードを含んでもよい。火災システムは、火災警報器、及び、給水配管制御を含む火災抑制システムを含んでもよい。照明システムは、屋内照明、屋外照明、緊急警報灯、避難誘導表示、及び非常口照明を含んでもよい。電力システムは、メイン及びバックアップ用発電装置、ならびに無停電電源（ＵＰＳ）グリッドを含んでもよい。

ＢＭＳはまた、窓ネットワーク１１０２とインターフェースする。この例では、窓ネットワーク１１０２は、主ネットワーク制御装置１１０３、中間ネットワーク制御装置１１０５ａ及び１１０５ｂ、ならびにエンドまたはリーフ制御装置１１１０を含む、窓制御装置の分散型ネットワークとして示される。エンドまたはリーフ制御装置１１１０は、図４及び５を参照して説明される窓制御装置４５０と同様であってもよい。例えば、主ネットワーク制御装置１１０３は、例えば、ＡＰＩを介したＢＭＳとのインターフェース接続を行う役割を担ってもよく、ビルの各窓がそれ自体のエンドまたはリーフ制御装置１１１０を有する一方で、ビル１１０１の各フロアは１つまたは複数の中間ネットワーク制御装置１１０５ａ及び１１０５ｂを有してもよい。この例において、制御装置１１１０のそれぞれは、ビル１１０１の特定の着色可能な窓を制御する。特定の実施形態において、窓ネットワーク１１０２及び／または主ネットワーク制御装置１１０３は、データウェアハウスなどのウィンドウインテリジェンスシステムまたはその構成要素と通信する。

制御装置１１１０のそれぞれは、それが制御する着色可能な窓から離れた場所に置くことができるか、または着色可能な窓に統合することができる。簡潔にするために、ビル１１０１の少数の着色可能な窓のみが、主窓制御装置１１０２によって制御されるものとして示される。典型的な設定においては、窓制御装置の分散型ネットワークであってもよい窓ネットワーク１１０２によって制御されるビル内の多数の着色可能な窓が存在してもよい。代替的な実施例において、単一の着色可能な窓の機能を制御する単一のエンド制御装置はまた、本明細書に開示される実施形態の範囲に該当する。

窓制御装置からのフィードバックを組み込むことによって、着色可能な窓を自動制御することができるため、ＢＭＳは例えば、１）環境制御、２）エネルギー節減、３）セキュリティ、４）制御オプションの柔軟性、５）信頼性の低さ及び保守の低さによる、他のシステムの改善された信頼性及び使用寿命、６）情報利用可能及び診断、７）スタッフの有効利用、ならびにこれらの様々な組み合わせの向上をもたらすことができる。

いくつかの実施形態において、ＢＭＳは存在しなくてもよく、または、ＢＭＳは存在してもよいが主ネットワーク制御装置と直接通信しなくてもよく、もしくは、主ネットワーク制御装置と高いレベルで通信しなくてもよい。これらの実施形態において、着色可能な窓を自動制御することができるため、主ネットワーク制御装置は例えば、１）環境制御、２）エネルギー節減、３）制御オプションの柔軟性、４）信頼性の低さ及び保守の低さによる、他のシステムの改善された信頼性及び使用寿命、５）情報利用可能及び診断、６）スタッフの有効利用、ならびにこれらの様々な組み合わせの向上をもたらすことができる。これらの実施形態において、ＢＭＳの保守は、着色可能な窓の制御に干渉しない。

特定の実施形態において、ＢＭＳはＡＰＩを介して窓システムと通信して、制御信号を受信し、ＢＭＳによって制御される１つまたは複数のシステムから監視されたデータを送信してもよい。

図１Ｄは、現場（例えば、ビル）のためのネットワーク１２００を用いる代替的な実施形態のブロック図である。ネットワーク１２００は、ＢＡＣｎｅｔを含む任意の数の異なる通信プロトコルを用いてもよい。示されるように、現場ネットワーク１２００は、窓システム１２０５、照明制御パネル１２１０、ＢＭＳ１２１５、セキュリティ制御システム１２２０、ユーザコンソール１２２５、スマートサーモスタットサービスまたは他の家電機器サービス（例えば、ＮＥＳＴ（登録商標））１２２７を含む。現場におけるこれらの異なる制御装置及びシステムは、現場のＨＶＡＣシステム１２３０、照明１２３５、セキュリティセンサ１２４０、ドア錠１２４５、カメラ１２５０、着色可能な窓１２５５及びサーモスタット１２５７からの入力を受信するか、及び／またはそれを制御するために利用されてもよい。

照明制御パネルは、屋内照明、屋外照明、緊急警報灯、避難誘導表示及び非常口照明を制御するための回路または他のロジックを含んでもよい。照明制御パネル（例えば、パネル１２１０）はまた、現場の部屋における占有センサにアクセスしてもよい。ＢＭＳ１２１５は、現場ネットワーク１２００の他のシステム及び制御装置からデータを受信し、また、それらへとコマンドを出すサーバを含んでもよい。例えば、ＢＭＳ１２１５は、窓制御装置１２０５、照明制御パネル１２１０及びセキュリティ制御システム１２２０のそれぞれからデータを受信し、また、それらコマンドを出してもよい。セキュリティ制御システム１２２０は、磁気カードのアクセス、回転式改札口、電磁駆動式ドア錠、監視カメラ、盗難警報器、金属探知機などを含んでもよい。ユーザコンソール１２２５は、現場の異なるシステムの動作のスケジューリングを行い、それを制御し、監視し、最適化し、かつトラブルシューティングを行うために現場管理者が利用することができるコンピュータ端末であってもよい。Ｔｒｉｄｉｕｍ，Ｉｎｃ．のソフトウェアは、ユーザコンソール１２２５のために、異なるシステムからのデータの視覚的表現を生成してもよい。

異なる制御のそれぞれは、個別の装置／機器を制御してもよい。窓システム１２０５は、窓１２５５を制御する。照明制御パネル１２１０は、照明１２３５を制御する。ＢＭＳ１２１５は、ＨＶＡＣ１２３０を制御してもよい。セキュリティ制御システム１２２０は、セキュリティセンサ１２４０、ドア錠１２４５及びカメラ１２５０を制御する。データは現場ネットワーク１２００の一部である異なる装置／機器及び制御装置の全ての間で交換され、及び／または共有されてもよい。

場合によっては、現場ネットワーク１１００または現場ネットワーク１２００のシステムは、日次、月次、四半期、または年次スケジュールに従って実行されてもよい。例えば、照明制御システム、窓制御システム、ＨＶＡＣ及びセキュリティシステムは、人々が作業日の間のいつ現場にいるかを示す２４時間スケジュールで実行されてもよい。現場は夜間にエネルギー節減モードに入ってもよく、システムは日中に、占有者の快適性を提供しながら、現場のエネルギー消費を最小化する方法で動作してもよい。別の例として、システムは休暇期間中にエネルギー節減モードを停止するか、またはエネルギー節減モードに入ってもよい。

スケジューリング情報は、地理情報と組み合わせられてもよい。地理情報は、例えばビルなどの現場の緯度及び経度を含んでもよい。ビルの場合、地理情報はまた、ビルの各側面が面する方向に関する情報を含んでもよい。このような情報を利用して、ビルの異なる側面の異なる部屋は、異なる方法で制御されてもよい。例えば、冬季のビルの東向きの部屋のために、窓制御装置は太陽光によって部屋が暖まるように、午前中に窓が着色されないよう命令してもよく、照明制御パネルは太陽光からの明かりのために、照明が暗くなるよう命令してもよい。西側の窓の着色はエネルギー節減に一切影響しない可能性があるため、西向きの窓は午前中に部屋の占有者により制御可能であってもよい。しかし、東向きの窓及び西向きの窓動作のモードは、夕方に切り替えられてもよい（例えば、日没時、西向きの窓は着色されず、熱と光の両方のために、太陽光を受け入れることを可能にする）。

例えば、現場ネットワーク、外窓（例えば、ビルの屋内をビルの外部から隔てる窓）のための着色可能な窓及びいくつかの異なるセンサを含む、図１Ｃにおけるビル１１０１などの現場の例について以下に記載する。ビルの外窓からの光は一般的に、窓から約２０フィートまたは約３０フィートのビルの屋内の光に効果を有する。すなわち、外窓から約２０フィートまたは約３０フィート以上のビル内の空間は、外窓からほとんど光を受けない。ビル内の外窓から離れたこのような空間は、ビルの照明システムによって照らされる。

さらに、ビル内の温度は、外部の光及び／または外部の温度によって影響されてもよい。例えば、寒い日に、ビルが暖房システムによって加熱される際に、ドア及び／または窓に近い部屋はビルの屋内領域より早く熱を失い、屋内領域に比べてより低温になる。

屋外条件を監視するために、ビルは、ビルの屋上に外部センサを含んでもよい。あるいはビルは、各外窓と関連する外部センサまたはビルの各側面上の外部センサを含んでもよい。太陽が一日を通して位置を変化させるにつれて、ビルの各側面上の外部センサは、ビルの側面の放射照度を追跡することが可能である。

窓制御装置が現場ネットワークに統合される場合、外部センサからの出力は、現場ネットワーク及び／または窓システムに入力されてもよい。場合によっては、これらの出力が、ローカルの窓制御装置への入力として行われてもよい。例えばいくつかの実施形態において、任意の２つ以上の外部センサからの出力信号が受信される。いくつかの実施形態においては１つのみの出力信号が受信され、いくつかの他の実施形態においては、３つ、４つ、５つまたはそれ以上の出力が受信される。これらの出力信号は、現場ネットワークを介して受信されてもよい。

いくつかの実施形態において、センサ（複数可）によって受信される出力信号は、ビル内の暖房システム、冷房システム及び／または照明によるエネルギーまたは電力消費を示す信号を含む。例えば、ビルの暖房システム、冷房システム及び／または照明のエネルギーまたは電力消費は、エネルギーまたは電力消費を示す信号を出すために監視されてもよい。装置はビルの回路及び／または配線とインターフェースされるか、またはそれに取り付けられ、この監視を可能にしてもよい。あるいは、ビル内の電力システムは、ビル内の個別の部屋またはビル内の部屋のグループのための暖房システム、冷房システム及び／または照明によって消費される電力を監視することができるように設置されてもよい。

着色可能な窓の着色を色合いの定められたレベルへと変化させるために、着色命令を出すことができる。例えば図１Ｃを参照すると、これは、１つまたは複数の中間ネットワーク制御装置１１０５ａ及び１１０５ｂへとコマンドを出す主ネットワーク制御装置１１０３を含んでもよく、次に１つまたは複数の中間ネットワーク制御装置１１０５ａ及び１１０５ｂがエンド制御装置１１１０にコマンドを出し、エンド制御装置１１１０はビルの各窓を制御する。主ネットワーク制御装置１１０３は、ＢＭＳ及び／または窓システムから受信したコマンドに基づいて、コマンドを出してもよい。エンド制御装置１１００は電圧及び／または電流を窓に加えて、命令に従って色合いに変化を生じさせてもよい。

いくつかの実施形態において、着色可能な窓を含む現場は、現場に電力を供給する、単一のまたは複数のユーティリティによって実行される要求応答プログラムに登録するか、または参加してもよい。プログラムは、ピーク負荷発生が予想される際に現場のエネルギー消費が低減されるプログラムであってもよい。ユーティリティは予想されるピーク負荷発生の前に、警報信号を送信してもよい。例えば警報は、予想されるピーク負荷発生の前日に、午前中に、または約１時間前に送信されてもよい。ピーク負荷発生は、暑い夏の日に、例えば冷房システム／空気調和機がユーティリティから大量の電力をひきこんでいる際に発生することが予想され得る。警報信号は、ビルのＢＭＳによって、窓システムによって、または、ビルにおいて着色可能な窓を制御するように構成される窓制御装置によって、受信されてもよい。この警報信号は、着色制御を診断するオーバーライド機構とすることができる。ＢＭＳまたは窓システムはその後、着色可能な窓における適切なエレクトロクロミック・デバイスを暗い色合いレベルに遷移させて、ピーク負荷が予想される時間にビル内の冷房システムの電力引き込みを低減するように窓制御装置（複数可）に命令することができる。

いくつかの実施形態において、現場の窓の着色可能な窓（例えば、エレクトロクロミック窓）は、ゾーン内で同じ方法で命令される着色可能な窓を有するゾーンに分類されてもよい。例えば現場の外窓（すなわち、屋内をビルの外部から隔てる窓）は、ゾーン内で同じ方法で命令される着色可能な窓を有するゾーンに分類されてもよい。例えば、ビルの異なるフロアの、またはビルの異なる側面の着色可能な窓の集合は、異なるゾーンにあってもよい。ある場合には、ビルの１階において、東向きの着色可能な窓の全てがゾーン１でにあってもよく、南向きの着色可能な窓の全てがゾーン２にあってもよく、西向きの着色可能な窓の全てがゾーン３にあってもよく、かつ、北向きの着色可能な窓の全てがゾーン４にあってもよい。別の場合に、ビルの１階の着色可能な窓の全てがゾーン１にあってもよく、２階の着色可能な窓の全てがゾーン２にあってもよく、かつ、３階の着色可能な窓の全てがゾーン３にあってもよい。さらに別の場合には、東向きの着色可能な窓の全てがゾーン１にあってもよく、南向きの着色可能な窓の全てがゾーン２にあってもよく、西向きの着色可能な窓の全てがゾーン３にあってもよく、かつ、北向きの着色可能な窓の全てがゾーン４にあってもよい。さらに別の場合として、１階の東向きの着色可能な窓は異なるゾーンに分けることができる。ビルの同じ側面及び／もしくは異なる側面ならびに／または異なるフロアの任意の数の着色可能な窓は、１つのゾーンに割り当てられてもよい。

いくつかの実施形態において、ゾーン内の着色可能な窓は同じ窓制御装置によって制御されてもよい。いくつかの他の実施形態において、ゾーン内の着色可能な窓は異なる窓制御装置によって制御されてもよいが、窓制御装置は全て、センサから同じ出力信号を受信し、ゾーン内の窓の色合いのレベルを決定するために同じ機能またはルックアップテーブルを利用してもよい。

いくつかの実施形態において、ゾーン内の着色可能な窓は、透過率センサから出力信号を受信する窓制御装置または制御装置によって制御されてもよい。いくつかの実施形態において、透過率センサはゾーン内の窓に近接して搭載されてもよい。例えば透過率センサは、ゾーン内に含まれるＩＧＵを含む枠内に、またはその上に搭載され（例えば、枠の方立、横桟内に、またはその上に搭載され）てもよい。いくつかの他の実施形態において、ビルの単一の側面上の窓を含むゾーン内の着色可能な窓は、透過率センサから出力信号を受信する窓制御装置または制御装置によって制御されてもよい。

いくつかの実施形態において、センサ（例えば、フォトセンサ）は、出力信号を窓制御装置に提供し、第１のゾーン（例えば、主制御ゾーン）の着色可能な窓を制御してもよい。窓制御装置はまた、第２のゾーン（例えば、従制御ゾーン）における着色可能な窓を第１のゾーンと同じ方法で制御してもよい。いくつかの他の実施形態において、別の窓制御装置は、第２のゾーンにおける着色可能な窓を第１のゾーンと同じ方法で制御してもよい。

いくつかの実施形態において、現場管理者、第２のゾーン内の部屋の占有者、または他の人物は、（例えば着色またはクリアコマンドまたはＢＭＳのユーザコンソールからのコマンドを利用して）、着色状態（レベル）または透明状態などの色合いレベルに入るように第２のゾーン（すなわち、従制御ゾーン）内の着色可能な窓に手動で命令してもよい。いくつかの実施形態において、第２のゾーン内の窓の色合いレベルがこのような手動コマンドで上書きされる際に、第１のゾーン（すなわち、主制御ゾーン）内の着色可能な窓は、透過率センサから出力を受信する窓制御装置の制御下に留まる。第２のゾーンは一定時間、手動コマンドモードに留まり、その後、透過率センサから出力を受信する窓制御装置の制御下に復帰してもよい。例えば第２のゾーンはオーバーライドコマンドの受信後１時間手動モードに留まってもよく、その後、透過率センサから出力を受信する窓制御装置の制御下に復帰してもよい。

いくつかの実施形態において、現場管理者、第１のゾーン内の部屋の占有者、または他の人物は（例えば、着色コマンドまたはＢＭＳユーザコンソールからのコマンドを利用して）、着色状態または透明状態などの色合いレベルに入るように第１のゾーン（すなわち、主制御ゾーン）内の窓に手動で命令してもよい。いくつかの実施形態において、第１のゾーン内に窓の色合いレベルがこのような手動コマンドで上書きされる際に、第２のゾーン（すなわち、従制御ゾーン）内の着色可能な窓は、外部センサから出力を受信する窓制御装置の制御下に留まる。第１のゾーンは一定時間、手動コマンドモードに留まり、その後、透過率センサから出力を受信する窓制御装置の制御下に復帰してもよい。例えば第１のゾーンはオーバーライドコマンドの受信後１時間手動モードに留まってもよく、その後、透過率センサから出力を受信する窓制御装置の制御下に復帰してもよい。いくつかの他の実施形態において、第２のゾーン内の着色可能な窓は、第１のゾーンのための手動オーバーライドが受信される際の色合いレベルに留まってもよい。第１のゾーンは一定時間、手動コマンドモードに留まってもよく、その後、第１のゾーン及び第２のゾーン両方が透過率センサから出力を受信する窓制御装置の制御下に復帰してもよい。

本明細書に記載の着色可能な窓の制御方法のいずれかは、窓制御装置がスタンドアロン窓制御装置であるか、または現場ネットワークとインターフェースされるかに関わらず、着色可能な窓の色合いを制御するために利用されてもよい。

上述の説明におけるＢＭＳへの言及は、いくつかのまたは全ての例において、スマートサーモスタットービスまたはＮＥＳＴ（登録商標）などの他の家電機器サービスへの言及により代替することができる。窓システムとＢＭＳまたは家電機器サービス間の通信は、上述のように、ＡＰＩを介したものとすることができる。

本開示のいくつかの特徴は、その全体が参照文献として本明細書に援用されている、２０１４年１１月２６日出願の米国仮特許出願第６２／０８５，１７９号に記載のネットワークなどのメッシュネットワーク上で実装されてもよい。メッシュネットワーク上の装置は、ネットワークによって知られた情報を利用することができる。例えば１つまたは複数のウィンドウのＧＰＳ座標が知られている場合、他の窓ではない装置はＧＰＳデータ及び全ての他の（窓及び窓ではない）装置の相対位置に基づいて、それらの正確な場所を知ることができる。ＧＰＳは通常ビル内部では作用しないため、ビルの内部の装置の位置をＧＰＳで直接感知することは困難であるか、または不可能である。このため、窓自体及びネットワーク上の様々な装置の相対位置から習得した絶対位置情報を利用することによって、ビルの内部にある窓ではない装置であっても、それらの正確な場所を知ることができる。いくつかの実施態様において、このようなネットワーク装置は、自動生成される地図にポピュレートされてもよい。例えば、それぞれメッシュネットワークに接続することが可能であるエレクトロクロミック窓及びプリンタをオフィスビルが利用する場合、制御装置（複数可）によって生成される地図は、ネットワークに接続される窓及びプリンタの全ての相対位置を示してもよい。ビルの占有者は、（例えば、スマートフォンアプリケーション、コンピュータなどにロードされる）この地図を利用して、メッシュネットワーク上のそれらの最も近いプリンタまたは他の関連する装置を発見する手助けをすることができる。占有センサ及びＨＶＡＣ構成要素はまた、メッシュネットワークに接続されるか、または、それとインターフェースしてもよい。このような場合、制御装置（複数可）によって生成される地図は占有センサからの情報に基づいて特定の部屋が占有されているか否かを示してもよく、他のＨＶＡＣ構成要素からの情報に基づいて他の条件（例えば、実際の温度、サーモスタット設定、湿度、照明の状態など）を示してもよい。付加的な装置がシステムのためのさらなるデータを部品に提供するため、メッシュネットワーク上の装置の数の増加とともに、地図の正確さ及び精度は向上する。

メッシュネットワーク上の窓はメッシュネットワーク上の他の装置と相互作用するように構成されてもよく、例えばそれらはＡＰＩを介してまたは直接、サーモスタットまたは他のＨＶＡＣ構成要素と相互作用する。例えば窓または窓の集合が着色される（それによって窓（複数可）を通じて熱がビルに入る速度が低減する）場合、窓（複数可）は、サーモスタットまたは他のＨＶＡＣ構成要素信号を送信し、空調を通じて起こる冷却の度合いを低減させてもよい。空調を通じた冷却度合いを増大させるために、または暖房システムを制御するために、同様の信号が送信されてもよい。さらに、エレクトロクロミック窓によって（例えば、センサ、実行などを通じて）収集された情報はサーモスタットまたは他のＨＶＡＣ構成要素と共有され、サーモスタットまたはＨＶＡＣによる決定を通知する手助けをしてもよい。

いくつかの実施形態において制御装置は、感知された様々な窓の相対位置及び正確な位置／配向に基づいて窓を制御するための命令を有してもよい。例えば制御装置は、太陽が東向きの部屋を暖めることを防ぎ、太陽が東向きの部屋を直接照らしていない午後遅くに東向きの窓を無色にするために、早朝に東向きの窓を着色する命令を有してもよい。任意の制御方式が利用されてもよく、ユーザまたは設置者によって制御装置にプログラムされてもよいか、またはベンダーなどの製造者によって事前にプログラムされてもよい。いくつかの実施形態において、窓制御装置はサーモスタットと同じ方法で（単一の窓または複数の窓の制御オプション）プログラム可能である。

＜無線または有線通信＞
いくつかの実施形態において、本明細書に記載の窓制御装置は、窓制御装置、センサ及び別個の通信ノードとの間の有線または無線通信のための構成要素を含む。無線または有線通信は、窓制御装置と直接インターフェースをとる通信インターフェースを用いて実現されてもよい。このようなインターフェースは、マイクロプロセッサに固有であるか、またはこれらの機能を有効化する付加的な回路を介して提供することが可能である。さらに、現場ネットワークの他のシステムは、異なるシステム要素間の有線または無線通信のための構成要素を含んでもよい。

無線通信のための別個の通信ノードは、例えば、別の無線窓制御装置、エンド、中間，または主窓制御装置、遠隔制御装置、ＢＭＳ、または窓システムとすることができる。窓制御装置において、以下の動作の少なくとも１つのために無線通信が利用される。着色可能な窓５０５（図５）のプログラムミング及び／または動作、本明細書に記載の様々なセンサ及びプロトコルからの、着色可能な窓５０５からのデータの収集、及び、着色可能な窓５０５の無線通信のための中継点としての利用。着色可能な窓５０５から収集されるデータはまた、ＥＣデバイスが起動された回数、時間の経過によるＥＣデバイスの効率性などの計算データを含んでもよい。これらの無線通信特徴については、以下により詳細に説明する。

一実施形態において無線通信は、例えば赤外線（ＩＲ）及び／または無線周波（ＲＦ）信号を介して、関連する着色可能な窓５０５を操作するために利用される。特定の実施形態において制御装置は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＥｎＯｃｅａｎ（登録商標）、Ｗｉ－Ｆｉ、ＺｉｇＢｅｅ（登録商標）などの無線プロトコルチップを含む。窓制御装置はまた、ネットワークを介した無線通信を有してもよい。窓制御装置への入力は、エンドユーザによって壁面スイッチで、直接または無線通信を介して、手動で入力することができるか、または入力は、着色可能な窓が一つの構成要素であるか、または窓システム管理システムからである、現場のＢＭＳからとすることができる。

一実施形態において、窓制御装置が制御装置の分散型ネットワークの一部である場合、無線通信は、それぞれが無線通信構成要素を有する制御装置の分散型ネットワークを介して複数の着色可能な窓のそれぞれからデータを転送するために利用される。例えば図１Ｃを再び参照すると、主ネットワーク制御装置１１０３は中間ネットワーク制御装置１１０５ａ及び１１０５ｂのそれぞれと無線通信を行い、次に中間ネットワーク制御装置１１０５ａ及び１１０５ｂのそれぞれは、それぞれが着色可能な窓と関連するエンド制御装置１１１０と無線通信を行う。主ネットワーク制御装置１１０３はまた、ＢＭＳまたは窓システムと無線通信を行ってもよい。一実施形態において、窓制御装置における通信の少なくとも１つのレベルは、無線で実行される。

いくつかの実施形態において、無線通信の１つ以上のモードが窓制御装置の分散型ネットワークにおいて利用される。例えば主窓制御装置は、Ｗｉ－ＦｉまたはＺｉｇＢｅｅ（登録商標）を介して中間制御装置への無線通信を行ってもよい一方で、中間制御装置がＢｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）、ＥｎＯｃｅａｎ（登録商標）、または他のプロトコルを介して、エンド制御装置と通信する。別の例において、窓制御装置は無線通信のためのエンドユーザの選択における柔軟性のために、冗長無線通信システムを有する。

＜着色可能な窓の機能を制御するためのシステムの実施例＞
図１Ｅは、実施形態による、現場における１つまたは複数の着色可能な窓（例えば、図１Ｃに示すビル１１０１）の機能（例えば、異なる色合いレベルへの遷移）を制御するためのシステム１４００の窓ネットワークの構成要素のブロック図である。システム１４００は、窓システムによってＢＭＳ（例えば、図１Ｃに示すＢＭＳ１１００）を通じて管理されるシステムの１つであってもよく、または、窓システムによって直接管理され、及び／もしくは、ＢＭＳから独立して動作してもよい。

システム１４００は、その機能を制御するために、制御信号を着色可能な窓へと送信することができる主窓制御装置１４０２を含む。システム１４００はまた、主窓制御装置１４０２との電子通信を行うネットワーク１４１０を含む。着色可能な窓（複数可）及び／またはセンサデータの機能を制御するための制御ロジック及び命令は、ネットワーク１４１０を介して主窓制御装置１４０２へと伝達されてもよい。ネットワーク１４１０は、有線または無線ネットワーク（例えば、クラウドネットワーク）とすることができる。いくつかの実施形態において、ネットワーク１４１０は、（例えば、ＡＰＩを介して）ＢＭＳと通信し、ＢＭＳがネットワーク１４１０を通じて着色可能な窓（複数可）を制御するための命令をビル内の着色可能な窓（複数可）へと送信することを可能にしてもよい。場合によっては、ＢＭＳは窓システムと通信し、窓システムから着色可能な窓（複数可）を制御するための命令を受信してもよい。他の実施形態において、ネットワーク１４１０は窓システムと通信し、窓システムがネットワーク１４１０を介して着色可能な窓（複数可）を制御するための命令をビル内の着色可能な窓（複数可）へと送信することを可能にしてもよい。特定の実施形態において、主窓制御装置１４０２及び／または主ネットワーク制御装置１４０３は、データウェアハウスなどの窓システムまたはその構成要素と通信するよう設計されるか、または構成される。

システム１４００はまた、いずれも主窓制御装置１４０２との電子通信を行う、着色可能な窓（図示せず）のＥＣデバイス４００及び壁面スイッチ１４９０を含む。この説明例において、主窓制御装置１４０２は制御信号をＥＣデバイス（複数可）へと送信し、ＥＣデバイス（複数可）を有する着色可能な窓の色合いレベルを制御することができる。各壁面スイッチ１４９０はまた、ＥＣデバイス（複数可）及び主窓制御装置１４０２と通信する。エンドユーザ（例えば、着色可能な窓を有する部屋の占有者）は、ＥＣデバイス（複数可）を有する着色可能な窓の色合いレベル及び他の機能を制御するために壁面スイッチ１４９０を利用することができる。

図１Ｅにおいて、主窓制御装置１４０２は、主ネットワーク制御装置１４０３、主ネットワーク制御装置１４０３、及び複数のエンドまたはリーフ窓制御装置１１１０と通信する複数の中間ネットワーク制御装置１４０５を含む、窓制御装置の分散型ネットワークとして示される。複数のエンドまたはリーフ窓制御装置１１１０のそれぞれは、単一の中間ネットワーク制御装置１４０５と通信する。主窓制御装置１４０２は窓制御装置の分散型ネットワークとして示されるが、主窓制御装置１４０２はまた、他の実施形態においては、単一の着色可能な窓の機能を制御する単一の窓制御装置とすることができる。図１Ｄにおけるシステム１４００の構成要素はいくつかの点で、図１Ｂを参照して説明される構成要素と同様であってもよい。例えば、主ネットワーク制御装置１４０３は主ネットワーク制御装置１１０３と同様であってもよく、中間ネットワーク制御装置１４０５は中間ネットワーク制御装置１１０５と同様であってもよい。図１Ｅの分散型ネットワーク内の窓制御装置のそれぞれは、処理装置（例えば、マイクロプロセッサ）及び、処理装置との電気通信を行うコンピュータ可読媒体を含んでもよい。

図１Ｅにおいて、各リーフまたはエンド窓制御装置１１１０は、単一の着色可能な窓のＥＣデバイス（複数可）４００と通信し、ビル内のその着色可能な窓の色合いレベルを制御する。ＩＧＵの場合、リーフまたはエンド窓制御装置１１１０は、ＩＧＵの色合いレベルを制御するＩＧＵの複数のライト上のＥＣデバイス４００と通信してもよい。他の実施形態において、各リーフまたはエンド窓制御装置１１１０は、複数の着色可能な窓と通信してもよい。リーフまたはエンド窓制御装置１１１０は着色可能な窓に統合されてもよいか、またはそれが制御する着色可能な窓から離間してもよい。図１Ｅにおけるリーフ及びエンド窓制御装置１１１０は、図１Ｃにおけるエンドまたはリーフ制御装置１１１０と同様であってもよく、及び／または、図５を参照して説明される窓制御装置４５０と同様であってもよい。

エンドユーザ（例えば、部屋の占有者）は、壁面スイッチ１４９０と通信する着色可能な窓の色合いレベル及び他の機能を制御するために各壁面スイッチ１４９０を操作することができる。エンドユーザは壁面スイッチ１４９０を操作し、関連する着色可能な窓内のＥＣデバイス４００へと制御信号を伝達することができる。壁面スイッチ１４９０からのこれらの信号は場合によっては、主窓制御装置１４０２からの信号をオーバーライドしてもよい。それ以外の場合には（例えば、高需要の場合）、主窓制御装置１４０２からの制御信号は、壁面スイッチ１４９０からの制御信号をオーバーライドしてもよい。各壁面スイッチ１４９０はまた、リーフまたはエンド窓制御装置１１１０と通信し、壁面スイッチ１４９０から送信された制御信号に関する情報（例えば、時間、日付、必要な色合いレベルなど）を、主窓制御装置１４０２へと送信して戻す。場合によっては、壁面スイッチ１４９０は手動で操作されてもよい。それ以外の場合には、壁面スイッチ１４９０は、例えば、赤外線（赤外線）及び／または無線周波（ＲＦ）信号を利用して制御信号との無線通信を送信する遠隔装置（例えば、携帯電話、タブレットなど）を利用するエンドユーザによって無線制御されてもよい。場合によっては、壁面スイッチ１４９０は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＥｎＯｃｅａｎ（登録商標）、Ｗｉ－Ｆｉ、ＺｉｇＢｅｅ（登録商標）などの無線プロトコルチップを含んでもよい。図１Ｅに示される壁面スイッチ１４９０は壁（複数可）上に位置するが、システム１４００の他の実施形態は、部屋内のどこか他の場所にスイッチを位置させてもよい。

例えば、主及び／または中間窓制御装置とエンド窓制御装置との間の無線通信は、直結通信ラインの設置を省く利点をもたらす。これはまた、窓制御装置とＢＭＳとの間の無線通信についても同様である。一態様において、これらの役割を担う無線通信は、ビル内の環境最適化及びエネルギー節減のために、窓を操作し、例えば、ＢＭＳへとデータを提供するためのエレクトロクロミック窓への、また、そこからのデータ転送にとって有用である。窓の位置データ及びセンサからのフィードバックがこのような最適化のために相乗してもよい。例えば、ビルの様々な環境を最適化するために、細かいレベルの（窓ごとの）微気候情報がＢＭＳに提供される。

上述の説明におけるＢＭＳへの言及は、いくつかのまたは全ての例において、スマートサーモスタットービスまたはＮＥＳＴ（登録商標）などの他の家電機器サービスへの言及により代替することができる。窓システムとＢＭＳまたは家電機器サービス間の通信は、上述のように、ＡＰＩを介したものとすることができる。

＜例示的な切り替えアルゴリズム＞
光学的遷移に沿って加速するために印加電圧は当初、特定の光学的状態で均衡を保って装置を保持するために必要とされるよりも大きさで提供される。この手法は、図２及び３において示される。図２は、消色から着色及び着色から消色へとエレクトロクロミック・デバイスを駆動することと関連する電圧及び電流プロファイルを示すグラフである。図３は、消色から着色へとエレクトロクロミック・デバイスを駆動することと関連する特定の電圧及び電流プロファイルを示すグラフである。

図２は、エレクトロクロミック・デバイスの光学的状態遷移サイクル（着色に続く消色）を引き起こす、単純な電圧制御アルゴリズムを利用するエレクトロクロミック・デバイスのための完全な電流プロファイル及び電圧プロファイルを示す。グラフにおいて全電流密度（Ｉ）は、時間の関数として表される。上述のように、全電流密度は、電気化学的に活性な電極間の、エレクトロクロミック遷移に関連するイオン電流密度、及び電子漏洩電流との組み合わせである。多数の異なるタイプのエレクトロクロミック・デバイスは、示される電流プロファイルを有する。一例では、酸化タングステンなどの陰極エレクトロクロミック材料は、対向電極におけるニッケル酸化タングステンなどの陽極エレクトロクロミック材料と組み合わせて利用される。このような装置において、負電流は装置の着色を示す。一例では、リチウムイオンは、エレクトロクロミック電極を陽極着色する酸化ニッケルタングステンから、エレクトロクロミック電極を陰極着色する酸化タングステンへと流れる。それに応じて、正に帯電した流入するリチウムイオンを補償するために、電子は酸化タングステン電極へと流れ込む。したがって、電圧及び電流は、負の値を有して示される。

示されるプロファイルは、電圧を設定レベルへランプアップし、その後、光学的状態を維持するための電圧を保持することで起こる。電流ピーク２０１は、光学的状態の変化、すなわち、着色及び消色と関連する。電流ピークは特に、装置を着色するか、または消色するために必要なイオン電荷の供給を表す。ピーク下の網掛け部分は、数学的に、装置を着色するか、または消色するために必要な全電荷を表す。当初電流スパイク（部分２０３）の後のカーブ部分は、装置が新しい光学的状態にある間の電子漏洩電流を表す。

図において、電圧プロファイル２０５は電流カーブ上に重ねられる。電圧プロファイルは、以下のシーケンスに従う。負のランプ（２０７）、負の保持（２０９）、正のランプ（２１１）及び正の保持（２１３）。電圧がその最大の大きさに達した後及び、装置がその定義される光学的状態に留まる時間の間、一定のままであることに留意されたい。電圧ランプ２０７は装置をその新しい着色状態に駆動し、電圧保持２０９は、反対方向にある電圧ランプ２１１が着色から消色状態への遷移を駆動するまで、装置を着色状態に維持する。いくつかの切り替えアルゴリズムにおいて、電流キャップが加えられる。すなわち、装置への損傷（例えば、材料層を通った速すぎるイオン移動の駆動により、材料層が物理的に損傷を受ける可能性がある）を防ぐために、電流は所定のレベルを超えることを許されない。着色速度は印加電圧のみではなく、温度及び電圧ランピングレートの関数である。

図３は、特定の実施形態による、電圧制御プロファイルを示す。示される実施形態において、電圧制御プロファイルは、消色状態から着色状態への（または中間の状態への）遷移を駆動するために用いられる。エレクトロクロミック・デバイスを反対方向に、着色状態から消色状態へと（またはより強い着色からより弱い着色状態へと）駆動させるために、同様の、しかし、反対のプロファイルが利用される。いくつかの実施形態において、着色から消色への電圧制御プロファイルは、図３において示されるプロファイルの鏡像である。

図３に示される電圧値は、印加電圧（Ｖ_ａｐｐ）値を表す。印加電圧プロファイルは、破線によって示される。対比のために、装置内の電流密度は実線によって示される。示されるプロファイルにおいて、Ｖ_ａｐｐは、遷移を開始させる、成分３０３を駆動するためのランプ、遷移を駆動させ続けるＶ_{ｄｒｉｖｅ}成分３１３、成分３１５を保持するためのランプ、及びＶ_ｈｏｌｄ成分３１７の、４つの成分を含む。ランプ成分は、Ｖ_ａｐｐ及びＶ_{ｄｒｉｖｅ}の変動として実装され、Ｖ_ｈｏｌｄ成分は、一定の、またはほぼ一定のＶ_ａｐｐの大きさをもたらす。

成分を駆動するためのランプは、ランプレート（増大する大きさ）及びＶ_{ｄｒｉｖｅ}の大きさによって特徴づけられる。印加電圧の大きさがＶ_{ｄｒｉｖｅ}に達する時、成分を駆動するためのランプが完了する。Ｖ_{ｄｒｉｖｅ}成分は、Ｖ_{ｄｒｉｖｅ}の値及びＶ_{ｄｒｉｖｅ}の持続時間によって特徴づけられる。Ｖ_{ｄｒｉｖｅ}の大きさは、上述のように、エレクトロクロミック・デバイスの全面に渡って安全だが有効な範囲でＶ_ｅｆｆを維持するために選択されてもよい。

成分を保持するためのランプは、電圧ランプレート（減少する大きさ）及びＶ_ｈｏｌｄの値（または任意には、Ｖ_{ｄｒｉｖｅ}とＶ_ｈｏｌｄとの間の差異）によって特徴づけられる。Ｖ_ａｐｐはランプレートに応じて、Ｖ_ｈｏｌｄの値に達するまで下降する。Ｖ_ｈｏｌｄ成分は、Ｖ_ｈｏｌｄの大きさ及びＶ_ｈｏｌｄの持続時間によって特徴づけられる。実際に、Ｖ_ｈｏｌｄの持続時間は通常、装置が着色状態に（または反対に消色状態に）保持される時間の長さによって管理される。駆動するためのランプ、Ｖ_{ｄｒｉｖｅ}及び成分を保持するためのランプとは異なり、Ｖ_ｈｏｌｄ成分は、装置の光学的遷移の物理から独立した任意の長さを有する。

それぞれのタイプのエレクトロクロミック・デバイスは、光学的遷移を駆動するための電圧プロファイルのそれ自体の特徴的な成分を有する。例えば、比較的大型の装置及び／または高抵抗の導電層を有する装置には、成分を駆動するためのランプにおいて、Ｖ_{ｄｒｉｖｅ}のより大きい値及びより大きい可能性があるランプレートが必要になる。大型装置にはまた、Ｖ_ｈｏｌｄのより大きい値が必要となる可能性がある。２０１２年４月１７日出願の、参照文献として本明細書に援用される、米国特許出願第１３／４４９，２５１号は、広範な条件の光学的遷移を駆動するための制御装置及び関連するアルゴリズムを開示する。そこで説明される通り、印加電圧プロファイルの成分（本明細書における、駆動するためのランプ、Ｖ_{ｄｒｉｖｅ}、保持するためのランプ及びＶ_ｈｏｌｄ）のそれぞれは、現在の温度、透過率の現在のレベルなどのリアルタイム条件に対応するために、独立的に制御されてもよい。いくつかの実施形態において、印加電圧プロファイルの各成分の値が（それ自体のバスバーの分離、抵抗率などを有する）特定のエレクトロクロミック・デバイスのために設定され、現在の条件に基づいて変化する。すなわち、このような実施形態において、電圧プロファイルは、温度、電流密度などのフィードバックを考慮しない。

示されるように、図３の電圧遷移プロファイルに示される全ての電圧値は、上述のＶ_ａｐｐ値に対応する。それらは上述のＶ_ｅｆｆ値に対応しない。すなわち、図３に示される電圧値は、エレクトロクロミック・デバイス上の逆極性のバスバー間の電圧差を表す。

特定の実施形態において、電圧プロファイルの成分を駆動するためのランプは、安全に、しかし迅速にイオン電流を誘起してエレクトロクロミック電極と対向電極との間で流れさせるために、選択される。図３に示すように、プロファイルの一部を駆動するためのランプが終了し、Ｖ_{ｄｒｉｖｅ}の一部が開始するまで、装置内の電流は電圧成分を駆動するためのランプのプロファイルに従う。図３の電流成分３０１を参照のこと。経験的に、または、他のフィードバックに基づいて、電流及び電圧の安全なレベルを判定することができる。参照文献として本明細書に援用される、２０１２年８月２８日発行、２０１１年３月１６日出願の、米国特許第８，２５４，０１３号は、エレクトロクロミック・デバイスの遷移中に安全な電流レベルを維持するためのアルゴリズムの例を提示する。

特定の実施形態において、Ｖ_{ｄｒｉｖｅ}の値は、上述の考察に基づいて選択される。それは特に、エレクトロクロミック・デバイスの全面のＶ_ｅｆｆの値が大型のエレクトロクロミック・デバイスを安全かつ有効に遷移させる範囲に留まるように選択される。Ｖ_{ｄｒｉｖｅ}の持続時間は、様々な考察に基づいて選択することができる。これらの１つは、装置の大幅な着色を引き起こすために十分な時間、駆動電位が保持されることを保証する。このために、Ｖ_{ｄｒｉｖｅ}が適正である時間の長さの関数として装置の光学密度を監視することによって、Ｖ_{ｄｒｉｖｅ}の持続時間が経験的に定められてもよい。いくつかの実施形態において、Ｖ_{ｄｒｉｖｅ}の持続時間が規定された時間に設定される。別の実施形態において、Ｖ_{ｄｒｉｖｅ}の持続時間が通過するイオン電荷の所望の量のに対応するように設定される。示されるように、電流はＶ_{ｄｒｉｖｅ}の間にランプダウンする。電流セグメント３０７を参照のこと。

別の考察は、光学的遷移中に利用可能なリチウムイオンが陽極着色電極から陰極着色電極（または対向電極）へのそれらの推移を完了した結果として、イオン電流が減衰するにつれての装置内の電流密度の低下である。遷移が完了する際に、装置を流れる電流のみがイオン電導層を通じた漏洩電流である。結果として、装置の面における電位の抵抗降下が減少し、Ｖ_ｅｆｆの局所の値が増大する。これらのＶ_ｅｆｆの増大した値は、印加電圧が低減しない場合に、装置に損傷を与えるか、または装置を劣化させる可能性がある。このように、Ｖ_{ｄｒｉｖｅ}の持続時間を決定するための別の考察は、漏洩電流と関連するＶ_ｅｆｆのレベルを低減させることが目的となる。印加電圧をＶ_{ｄｒｉｖｅ}からＶ_ｈｏｌｄへと低下させることで、装置の面上でＶ_ｅｆｆが低減されるだけでなく、漏洩電流も同様に低減する。図３に示す通り、成分を保持するためのランプの間に、装置の電流はセグメント３０５において遷移する。電流はＶ_ｈｏｌｄの間、安定した漏洩電流３０９に落ち着く。

図４は、開示される実施形態の、いくつかの窓制御装置４５０の構成要素及び他の窓制御装置システムの構成要素のブロック図を示す。図４は窓制御装置の簡略ブロック図であり、窓制御装置に関しては、いずれも発明者としてＳｔｅｐｈｅｎ Ｂｒｏｗｎの氏名を記し、いずれも「ＣＯＮＴＲＯＬＬＥＲ ＦＯＲ ＯＰＴＩＣＡＬＬＹ―ＳＷＩＴＣＨＡＢＬＥ ＷＩＮＤＯＷＳ」と題する、いずれも２０１２年４月１７日出願の米国特許出願番号第１３／４４９，２４８号及び１３／４４９，２５１号において、また、発明者としてＳｔｅｐｈｅｎ Ｂｒｏｗｎ他の氏名を記し、「ＣＯＮＴＲＯＬＬＩＮＧ ＴＲＡＮＳＩＴＩＯＮＳ ＩＮ ＯＰＴＩＣＡＬＬＹ ＳＷＩＴＣＨＡＢＬＥ ＤＥＶＩＣＥＳ」と題する、２０１２年より詳細４月１７日出願の、米国特許出願第１３／４４９，２３５号においてより詳細に記載されており、それらの全てが参照文献として、本明細書に援用される。

図４において、示される窓制御装置４５０の構成要素は、マイクロプロセッサ４１０または他の処理装置を有する窓制御装置４５０、電力幅変調器（ＰＷＭ）４１５、信号調整モジュール４０５、及び、設定ファイル４２２を有するコンピュータ可読媒体４２０（例えば、メモリ）を含む。窓制御装置４５０は、ネットワーク４２５（有線または無線）を介して、エレクトロクロミック窓内の１つまたは複数のエレクトロクロミック・デバイス４００と電子通信を行い、命令を１つまたは複数のエレクトロクロミック・デバイス４００に送信する。いくつかの実施形態において、窓制御装置４５０は、ネットワーク（有線または無線）を介して主窓制御装置への通信を行うローカルの窓制御装置であってもよい。

開示される実施形態において、現場は、ビルの外部と内部の間にエレクトロクロミック窓を有する少なくとも１つの部屋を有するビルであってもよい。１つまたは複数のセンサは、ビルの外部に、及び／または部屋の内部に位置してもよい。実施形態において、１つまたは複数のセンサからの出力は、窓制御装置４５０の信号調整モジュール４０５に入力されてもよい。場合によっては、１つまたは複数のセンサからの出力は、ＢＭＳに、または、窓システムに入力されてもよい。示される実施形態のセンサはビルの垂直壁の外側に位置するものとして記されるが、これは簡略化のためであり、センサは、室内または他の外面などの他の場所にあってもよい。場合によっては、同じ入力を測定するために２つ以上のセンサが利用されてもよく、これによって、１つのセンサが故障するか、またはその他の場合に誤読み出しを行う際に冗長性を提供することができる。

＜部屋センサ及び窓制御装置＞
図５は、少なくとも１つのエレクトロクロミック・デバイスを用いた着色可能な窓５０５を有する部屋５００の概略図を示す。着色可能な窓５０５は、部屋５００を含むビルの外部と内部との間に位置する。部屋５００はまた、着色可能な窓５０５に接続され、その色合いレベルを制御するように構成される窓制御装置４５０を含む。外部センサ５１０は、ビルの外部の垂直面上に位置する。他の実施形態において、内部センサはまた、部屋５００内で周辺光を測定するために利用されてもよい。さらに他の実施形態において、占有者センサはまた、占有者が部屋５００にいる際の判定を行うために利用されてもよい。

外部センサ５１０は、フォトセンサなどの、太陽などの光源から、または表面からセンサに反射される光から装置に入射する放射光、大気中の粒子、雲などを検出することが可能な装置である。外部センサ５１０は、光電効果に起因する電流の形式で信号を生成してもよく、信号は、センサ５１０へ入射する光の関数であってもよい。場合によっては、装置は放射照度の観点から、ワット／ｍ^２の単位または他の同様の単位で放射光を検出してもよい。それ以外の場合には、装置は、フートキャンドルの単位または同様の単位で可視範囲の波長の光を検出してもよい。多くの場合、放射照度及び可視光のこれらの値の間には、直線関係が存在する。

太陽光からの放射照度値については、太陽光が地球を照らす角度が変化するため、時間帯及び時季に基づいて予測することができる。外部センサ５１０は、ビル、天候の変化（例えば、雲）などによって、反射され、遮断された光を示す、リアルタイムの放射光を検出することができる。例えば、曇りの日、太陽光は雲によって遮断され、外部センサ５１０によって検出される放射光は、雲のない日よりも低い。

いくつかの実施形態において、単一の着色可能な窓５０５と関連付けられた１つまたは複数の外部センサ５１０が存在してもよい。１つまたは複数の外部センサ５１０からの出力は、例えば、外部センサ５１０の１つについては、外部センサ５１０上に降りた鳥などのオブジェクトによって遮蔽されているか否かを判断するために、互いに比較することが可能である。いくつかのセンサについては信頼度が低く、及び／または高価であるため、場合によっては、ビル内の比較的少数のセンサを利用することが望ましい。特定の実施態様において、太陽からビル、またはおそらくビルの一面に入射する放射光の電流レベルを判定するために、単一のセンサまたは少数のセンサが用いられてもよい。雲が太陽の前にかげるか、または、建設車両が沈む太陽の前で駐車されている可能性もある。これらの場合、通常ビルに入射すると算出される太陽からの放射光量からの乖離が生じる場合がある。

外部センサ５１０はフォトセンサの一種であってもよい。例えば、外部センサ５１０は、電荷結合素子（ＣＣＤ）、フォトダイオード、フォトレジスタ，または太陽電池であってもよい。それらは、光強度を測定し、光レベルを表す電気出力を提供するため、フォトセンサ及び他のセンサ技術の将来的な発展も有用であることが当業者には理解される。

いくつかの実施形態において、外部センサ５１０からの出力が、ＢＭＳまたは窓システムに入力されてもよい。入力は、電圧信号の形式であってもよい。ＢＭＳまたは窓システムは入力を処理し、直接または（図１Ｃに示す）主窓制御装置１１０２を通じて窓制御装置４５０に着色命令を有する出力信号を出してもよい。着色可能な窓５０５の色合いレベルは、構成情報、オーバーライド値などに基づいて決定されてもよい。窓制御装置４５０はその後、所望の色合いレベルに遷移させるために着色可能な窓５０５に電圧及び／または電流を加えるようにＰＷＭ４１５に命令する。

開示される実施形態において、窓制御装置４５０は、４つ以上の異なる色合いレベルの任意の１つへ遷移させるために、着色可能な窓５０５に電圧及び／または電流を加えるように、ＰＷＭ４１５に命令することができる。開示される実施形態において、着色可能な窓５０５は、０（最も明るい）、５、１０、１５、２０、２５、３０、及び３５（最も暗い）と記される、少なくとも８つの異なる色合いレベルに遷移することが可能である。色合いレベルは可視透過率値及び、着色可能な窓５０５を通じて送信された光の太陽熱利得係数（ＳＧＨＣ）値に直線的に対応してもよい。例えば上記８つの色合いレベルを利用すると、最も明るい色合いレベルである０は０.８０のＳＧＨＣ値に対応してもよく、５の色合いレベルは０.７０のＳＧＨＣ値に対応してもよく、１０の色合いレベルは０.６０のＳＧＨＣ値に対応してもよく、１５の色合いレベルは０.５０のＳＧＨＣ値に対応してもよく、２０の色合いレベルは０.４０のＳＧＨＣ値に対応してもよく、２５の色合いレベルは０.３０のＳＧＨＣ値に対応してもよく、３０の色合いレベルは０.２０のＳＧＨＣ値に対応してもよく、３５（最も暗い）の色合いレベルは０.１０のＳＧＨＣ値に対応してもよい。

窓制御装置４５０または、窓制御装置４５０と通信する主窓制御装置と通信するＢＭＳまたは窓システムは、外部センサ５１０からの信号及び／または他の入力に基づいて所望の色合いレベルを決定するために、任意の制御ロジックを用いてもよい。窓制御装置４１５は、所望の色合いレベルに遷移させるために、電圧及び／または電流をエレクトロクロミック窓５０５に加えるようにＰＷＭ４６０に命令することができる。

上述の説明におけるＢＭＳへの言及は、いくつかのまたは全ての例において、スマートサーモスタットービスまたはＮＥＳＴ（登録商標）などの他の家電機器サービスへの言及により代替することができる。

＜ビル内の窓を制御するための制御ロジック＞
図６は、実施形態による、現場での１つまたは複数の着色可能な窓の制御方法のための例示的な制御ロジックを示すフローチャートである。制御ロジックはモジュールＡ、Ｂ及びＣのうちの１つまたは複数を利用し、着色可能な窓（複数可）の色合いレベルを計算し、着色可能な窓（複数可）を遷移させるための命令を送信する。制御ロジックにおける計算は、ステップ６１０においてタイマーで計測される間隔を置いて、１からｎ回実行される。例えば、色合いレベルについては、モジュールＡ、Ｂ及びＣのうちの１つまたは複数によって１からｎ回再計算し、例えば、時間ｔ_ｉ＝ｔ_１、ｔ_２…ｔ_ｎで計算することができる。ｎは実行された再計算の回数であり、ｎは少なくとも１とすることができる。ロジック計算は場合によっては、一定の時間間隔をおいて行うことができる。ある場合には、ロジック計算が２分から５分おきに行われてもよい。しかし、大きなエレクトロクロミック・ガラスの着色遷移には、３０分またはそれ以上の時間がかかる可能性がある。これらの大きな窓に関しては、３０分おきなど、頻度を下げて計算を行ってもよい。示される実施形態にはモジュールＡ、Ｂ及びＣが使用されているが、他の実施形態においては、１つまたは複数の他のロジックモジュールを利用することができる。

ステップ６２０において、ロジックモジュールＡ、Ｂ及びＣは計算を実行し、エレクトロクロミック窓５０５ごとの時間ｔ_ｉの一瞬の色合いレベルを決定する。これらの計算は、窓制御装置４５０によって、または窓システムによって行うことができる。特定の実施形態において、制御ロジックは、実際の遷移に先立って、窓がどう遷移すべきかの予測計算を行う。これらの場合、モジュールＡ、Ｂ及びＣにおける計算は、遷移が完了する頃の、またはその後の未来の時間に基づき得る。これらの場合、計算に用いられる未来の時間は、着色命令を受信した後に遷移を完了させるために十分な未来の時間であってもよい。これらの場合、制御装置は実際の遷移に先立って、現在の時間の着色命令を送信することができる。遷移の完了により、窓はその時間に所望される色合いレベルへと遷移している。

ステップ６３０において制御ロジックは、特定のタイプのオーバーライドがモジュールＡ、Ｂ及びＣにおいてアルゴリズムを解放し、いくつかの他の考察に基づいてステップ６４０においてオーバーライド色合いレベルを定義することを可能にする。１つのタイプのオーバーライドは手動オーバーライドである。これは、部屋を占有し、特定の色合いレベル（オーバーライド値）が望ましいことを決定するエンドユーザによって実装されるオーバーライドである。ユーザの手動オーバーライド自体がオーバーライドされている状況が存在する場合がある。オーバーライドの例は、高需要（またはピーク負荷）オーバーライドであり、それはビル内のエネルギー消費が低減されるユーティリティの要件と関連付けられる。例えば、都市部において特に暑い日は、自治体のエネルギー生成及び送達システムに過度な負担をかけないように、自治体全体でエネルギー消費を低減させることが必要となる場合がある。このような場合ビルは、全ての窓が特に高いレベルで着色されるように、制御ロジックから色合いレベルをオーバーライドしてもよい。オーバーライドの別の例は、例えば商業オフィスビルにおいて週末、部屋に占有者がいない場合である。これらの場合にビルは、占有者の快適性に関連する１つまたは複数のモジュールを解放してもよい。別の例において、オーバーライドは、寒い天候時に全ての窓が高い色合いレベルを有してもよいか、または暖かい天候時に全ての窓が低い色合いレベルを有してもよい、という内容であってもよい。

ステップ６５０において、色合いレベルを有する命令が、現場ネットワークを介して、ビル内の１つまたは複数の着色可能な窓５０５におけるエレクトロクロミック・デバイス（複数可）と通信する窓制御装置（複数可）へと送信される。特定の実施形態において、ビルの全ての窓制御装置への色合いレベルの送信が、効率性を考慮して実装されてもよい。例えば、色合いレベルの再計算によって、現在の色合いレベルからの着色の変化がまったく必要ないことが示される場合、更新された色合いレベルを有した命令の送信はその後行われない。別の例として、ビルは窓の大きさに基づいてゾーンに分けられてもよい。制御ロジックは、ゾーンごとに単一の色合いレベルを計算してもよい。制御ロジックは小さい窓を有するゾーンの色合いレベルを、大きい窓を有するゾーンよりも高い頻度で再計算してもよい。

いくつかの実施形態において、現場全体における複数の着色可能な窓５０５の制御方法の実装のための図６におけるロジックは、単一の装置、例えば、単一の主窓制御装置上に置くことができる。この装置は、現場内の窓ひとつひとつのための計算を行い、また、色合いレベルを個別の着色可能な窓５０５における１つまたは複数のエレクトロクロミック・デバイスに送信するためのインターフェースを提供することができる。

また、実施形態の制御ロジックの特定の適応構成要素が存在してもよい。例えば、制御ロジックは、一日の特定の時間においてエンドユーザ（例えば、占有者）がアルゴリズムのオーバーライドを試みる方法を判定し、この情報をより予測的な方法で利用して、所望の色合いレベルを決定してもよい。ある場合では、毎日特定の時間にエンドユーザは予測ロジックによってオーバーライド値に提供された色合いレベルをオーバーライドするための壁面スイッチを利用している可能性がある。制御ロジックは、これらのインスタンスに関する情報を受信し、その時間帯に色合いレベルをオーバーライド値に変化させるために制御ロジックを変化させてもよい。

＜機械式シェード＞
特定の開示により、光学的に切り替え可能な装置（例えば、エレクトロクロミック・デバイス）を制御するためのシステム、方法及びロジックが強調されるが、これらの技術はまた、機械式シェードまたは光学的に切り替え可能な装置及び機械式シェードの組み合わせを制御するために利用することができる。このような機械式シェードは例えば、微小電気機械システム（ＭＥＭＳ）装置または他の電気機械システム（ＥＭＳ）装置の配列を含んでもよい。エレクトロクロミック・デバイスとＥＭＳシステム装置の組み合わせを有する窓が、その全体が参照文献として本明細書に援用される、２０１２年１１月２６日出願の、「ＭＵＬＴＩ－ＰＡＮＥ ＷＩＮＤＯＷＳ ＩＮＣＬＵＤＩＮＧ ＥＬＥＣＴＲＯＣＨＲＯＭＩＣ ＤＥＶＩＣＥＳ ＡＮＤ ＥＬＥＣＴＲＯＭＥＣＨＡＮＩＣＡＬ ＳＹＳＴＥＭＳ」と題する、ＰＣＴ国際出願第ＰＣＴ／ＵＳ２０１３／０７２０８号に記載されている。機械式シェードは通常、エレクトロクロミック・デバイスなどの特定の光学的に切り替え可能な装置とは異なる電力要件を有する。例えば特定のエレクトロクロミック・デバイスは動作に数ボルトしか必要としないが、機械式シェードは場合によっては、機械的機構を物理的に移動させるために十分な電位を確立するために、より大きな電圧を要求してもよい。

マイクロブラインド及びマイクロシャッターは、ＥＭＳ装置のタイプの例である。マイクロブラインド及びマイクロシャッターならびにそれらの作製方法のいくつかの例については、それらの全体が参照文献として本明細書に援用される、米国特許第７，６８４，１０５号及び米国特許第５，５７９，１４９号において説明される。

特定の実施形態において、機械式シェードは、各ＥＭＳ装置が基板への取り付け部（例えば、ヒンジまたはアンカー）及び可動部を含む、ＥＭＳ装置の配列であってもよい。静電力によって駆動される際に、可動部は基板を動かし、目立たなくしてもよい。非駆動状態では、可動部は基板を露出させてもよい。いくつかのマイクロブラインドの例において可動部は、静電力によって駆動される際に湾曲する材料層の張り出し部であってもよい。いくつかのマイクロシャッターの例において、可動部は駆動時に回転するか、または、湾曲する可能性がある。場合によっては、ＥＭＳ装置は静電制御手段によって駆動され、制御されてもよい。マイクロシャッターの例において、静電制御手段は、回転または湾曲の角度を異なる状態に制御してもよい。ＥＭＳ装置の配列を有する基板はまた、導電層を含んでもよい。マイクロブラインドの例において、マイクロブラインドは制御された応力下の薄い層（複数可）を利用して作製される。ＥＭＳ装置の配列を有する実施形態において、各ＥＭＳ装置は、駆動状態及び非駆動状態の、２つの状態を有している。駆動状態はほぼ不明瞭であるＥＭＳ装置配列を行ってもよく、非駆動状態はほぼ透明のＥＭＳ装置の配列を行ってもよいか、またはその逆でもよい。駆動及び非駆動状態はまた、例えば略反射性（または吸収性）とほぼ透明との間で切り替えられてもよい。他の状態はまた、ＥＭＳ装置の配列が駆動または非駆動状態にある時に可能である。例えば、マイクロシャッター、一種のＭＥＭＳ装置が、閉じた状態で着色した枠が提供されるが、開いた状態では着色がほぼ取り除かれる色合い（しかし不明瞭ではない）コーティングによって作製されてもよい。さらに、ＥＭＳ装置のいくつかの配列は、遷移することが可能である、３つ、４つ、またはそれ以上の状態を有してもよい。場合によっては、ＥＭＳ装置は、可視及び／または赤外線送信を修正することができる。場合によっては、ＥＭＳ装置は反射してもよく、吸収性でもよく、それ以外の場合には、また、さらに他の実施形態においては、反射及び吸収の両方の特性を提供してもよい。特定の実施形態において、ＥＭＳ装置は例えば、高送信状態から低送信状態、または無送信状態へと遷移させるために、可変速度で操作されてもよい。特定の場合に、ＥＭＳ装置は、エレクトロクロミック・デバイス（または他の光学的に切り替え可能な装置）と関連付けられ、例えば、関連するエレクトロクロミック・デバイスが低透過率状態または高透過率状態に遷移するまで光を遮蔽する、一時的光遮蔽手段として利用されてもよい。

Claims (23)

1. 窓制御システムであって、
   （ｉ）ビル内の１つまたは複数の光学的に切り替え可能な窓の光学的状態を制御し、
   （ｉｉ）前記ビルのビル管理システムによってではなく、アプリケーションプログラミングインターフェース（ＡＰＩ）により、照明システム、暖房／換気／空調システム（ＨＶＡＣシステム）、セキュリティシステム及び家電機器制御システムの中から選択された前記ビルの少なくとも１つの他のシステムと直接相互作用し、前記少なくとも１つの他のシステムと直接相互作用することは、（ｉ）前記少なくとも１つの他のシステムから第１通信を受信することであって、前記第１通信は、前記窓制御システムと前記少なくとも１つの他のシステムとの間で通信するために前記ＡＰＩによって規定されたフォーマットを有する、前記第１通信を受信すること、および、前記窓制御システムにおいて、前記第１通信に含まれる複数の命令および／またはデータを用いて１または複数の動作を実行すること、および／または、（ｉｉ）前記少なくとも１つの他のシステムに第２通信を送信することであって、前記第２通信は、前記窓制御システムと前記少なくとも１つの他のシステムとの間で通信するために前記ＡＰＩによって規定されたフォーマットを有し、前記少なくとも１つの他のシステムは、前記第２通信に含まれる命令および／またはデータを用いて１または複数の動作を実行する、前記第２通信を送信すること、を含む、窓制御システム。
2. 前記窓制御システムが、前記少なくとも１つの光学的に切り替え可能な窓の遷移を制御するように構成される窓制御装置を含む、請求項１に記載の窓制御システム。
3. 前記窓制御システムが、前記ＡＰＩを介して１つまたは複数の前記窓制御装置によって制御される複数のエレクトロクロミック窓を含む、請求項２に記載の窓制御システム。
4. 前記少なくとも１つの他のシステムとして前記家電機器制御システムが選択された場合、前記家電機器制御システムが、前記１つまたは複数の光学的に切り替え可能な窓の色合いレベルを調整するように構成される、請求項２または３に記載の窓制御システム。
5. 前記少なくとも１つの他のシステムとして前記ＨＶＡＣシステムが選択された場合、前記１つまたは複数の光学的に切り替え可能な窓の色合いレベルに基づいて前記ＨＶＡＣシステムを介して空調レベルを調整するように構成される、請求項２から４のいずれか一項に記載の窓制御システム。
6. 前記少なくとも１つの他のシステムとして前記セキュリティシステムが選択された場合、施錠時に窓が暗くなり、盗難の際に窓が透明になるように前記セキュリティシステムが前記１つまたは複数の光学的に切り替え可能な窓の色合いレベルを調整するように構成される、請求項２から５のいずれか一項に記載の窓制御システム。
7. 前記少なくとも１つの他のシステムとして前記照明システムが選択された場合、前記１つまたは複数の光学的に切り替え可能な窓の色合いレベルに基づいて前記照明システムを介して照明レベルを調整するように構成される、請求項２から６のいずれか一項に記載の窓制御システム。
8. 前記窓制御システムが、前記窓制御システムによって取得されたか、または生成されたデータを、前記少なくとも１つの他のシステムに提供するように構成される、請求項１から７のいずれか一項に記載の窓制御システム。
9. 前記窓制御システムが前記少なくとも１つの他のシステムの１つまたは複数の装置を制御するように、前記窓制御システム及び前記少なくとも１つの他のシステムが構成される、請求項１から８のいずれか一項に記載の窓制御システム。
10. 前記少なくとも１つの他のシステムが前記窓制御システムの１つまたは複数の装置を制御するように、前記窓制御システム及び前記少なくとも１つの他のシステムが構成される、請求項１から９のいずれか一項に記載の窓制御システム。
11. 前記窓制御システムの前記１つまたは複数の装置が、フォトセンサ、光センサ、熱センサ、及び占有センサのうち少なくとも１つを含むセンサ及び／または光学的に切り替え可能な窓を含む、請求項１０に記載の窓制御システム。
12. 窓制御システムにより、ビル内の１つまたは複数の光学的に切り替え可能な窓の光学的状態を制御することと、
    前記窓制御システムにより、前記ビルのビル管理システムによってではなく、アプリケーションプログラミングインターフェース（ＡＰＩ）を用いて、照明システム、暖房／換気／空調システム（ＨＶＡＣシステム）、セキュリティシステム及び家電機器制御システムの中から選択された前記ビルの少なくとも１つの他のシステムと直接相互作用し、前記少なくとも１つの他のシステムと直接相互作用することは、（ｉ）前記少なくとも１つの他のシステムから第１通信を受信することであって、前記第１通信は、前記窓制御システムと前記少なくとも１つの他のシステムとの間で通信するために前記ＡＰＩによって規定されたフォーマットを有する、前記第１通信を受信すること、および、前記窓制御システムにおいて、前記第１通信に含まれる複数の命令および／またはデータを用いて１または複数の動作を実行すること、および／または、（ｉｉ）前記少なくとも１つの他のシステムに第２通信を送信することであって、前記第２通信は、前記窓制御システムと前記少なくとも１つの他のシステムとの間で通信するために前記ＡＰＩによって規定されたフォーマットを有し、前記少なくとも１つの他のシステムは、前記第２通信に含まれる命令および／またはデータを用いて１または複数の動作を実行する、前記第２通信を送信すること、を含む、
    方法。
13. 前記窓制御システムが、前記少なくとも１つの光学的に切り替え可能な窓の遷移を制御するように構成される窓制御装置を含む、請求項１２に記載の方法。
14. 前記窓制御システムが、前記ＡＰＩを介して１つまたは複数の前記窓制御装置によって制御される複数のエレクトロクロミック窓を含む、請求項１３に記載の方法。
15. 前記少なくとも１つの他のシステムとして前記家電機器制御システムが選択された場合、前記家電機器制御システムが、前記１つまたは複数の光学的に切り替え可能な窓の色合いレベルを調整することを含む、請求項１３または１４に記載の方法。
16. 前記少なくとも１つの他のシステムとして前記ＨＶＡＣシステムが選択された場合、前記１つまたは複数の光学的に切り替え可能な窓の色合いレベルに基づいて前記ＨＶＡＣシステムを介して空調レベルを調整することを含む、請求項１３から１５のいずれか一項に記載の方法。
17. 前記少なくとも１つの他のシステムとして前記セキュリティシステムが選択された場合、
    施錠時に窓が暗くなり、盗難の際に窓が透明になるように前記セキュリティシステムが前記１つまたは複数の光学的に切り替え可能な窓の色合いレベルを調整することを含む、請求項１３から１６のいずれか一項に記載の方法。
18. 前記少なくとも１つの他のシステムとして前記照明システムが選択された場合、前記１つまたは複数の光学的に切り替え可能な窓の色合いレベルに基づいて前記照明システムを介して照明レベルを調整することを含む、請求項１３から１７のいずれか一項に記載の方法。
19. 前記ビル管理システムが前記ＨＶＡＣシステムを制御するように構成され、前記ＨＶＡＣシステムが前記窓制御システムから前記ＡＰＩを介して前記第２通信を受信する、請求項１２から１８のいずれか一項に記載の方法。
20. 前記少なくとも１つの他のシステムが前記窓制御システムから前記第２通信を受信し、前記第２通信が前記窓制御システムによって取得されたか、または生成されたデータを提供する、請求項１２から１９のいずれか一項に記載の方法。
21. 前記少なくとも１つの他のシステムが前記窓制御システムから前記第２通信を受信し、前記第２通信が、前記少なくとも１つの他のシステムの１つまたは複数の装置を制御するための、前記窓制御システムからの命令を含む、請求項１２から２０のいずれか一項に記載の方法。
22. 前記窓制御システムが前記少なくとも１つの他のシステムから前記第１通信を受信し、前記第１通信が、前記窓制御システムの１つまたは複数の装置を制御するための、前記少なくとも１つの他のシステムからの命令を含む、請求項１２から２１のいずれか一項に記載の方法。
23. 前記窓制御システムの前記１つまたは複数の装置が、フォトセンサ、光センサ、熱センサ、及び占有センサのうち少なくとも１つを含むセンサ及び／または光学的に切り替え可能な窓を含む、請求項２２に記載の方法。

Images