JP6824875B2 - バルブを制御する無線装置、システム、及び方法 - Google Patents

Description

本発明は、ＷｉＦｉネットワークに接続する制御ユニットと無線通信するように設計され、かつ、インターネットを介してユーザーによってプログラムされるように構成されるバルブユニットを有するＷｉ−Ｆｉ給水システムに関する。

米国特許第７８１０５１５号明細書

無線給水タイマー及びバルブ制御システムは、ルータと無線ＷｉＦｉ通信する制御ユニット、並びに、前記制御ユニットと無線通信してコックと接続するように設計されるバルブユニットを有する。前記バルブユニットは、前記制御ユニットによって受信される信号を介して無線動作するバルブを有する。前記バルブユニットはまた、湿度センサと無線通信し、かつ、前記湿度センサから受信する湿度センサ状態を前記制御ユニットへ中継することで、前記湿度センサ状態に基づいて前記バルブユニットを操作するようにも構成されてよい。前記制御ユニットはまた、少なくともインターネットを介して前記制御ユニットへ送られるスケジュールに基づいて前記バルブユニットを操作するようにも構成されてよい。

本発明について添付図面を参照しながら説明する。

一の実施形態によるインターネット制御スプリンクラーシステムのブロック図である。 図１に表された制御ユニットのブロック図である。 図１に表されたバルブユニットのブロック図である。 図１に表されたシステムのバルブユニットと制御ユニットとの間で周期的に起こる定期的チェックインデータ交換を表す図である。 図１に表されたシステムの（複数の）制御ユニットとインターネットサーバーとの間での通信用アーキテクチャを表す図である。 図１に表された制御ユニットの一例の分解図である。 図１に表されたバルブユニットの一例の分解図である。 図１に表されたバルブユニットの他の例の分解図である。 一の実施形態によるバルブプログラムグリッドのスクリーンショットの例である。

以降では本発明の実施形態について、上述の図面を参照しながら説明する。本願において図示及び説明されるスプリンクラーシステムは、自家所有者の私的Ｗｉ−Ｆｉネットワークを利用するように構成される。

図１に示される一の実施形態では、当該システムは、制御ユニット１０（以降、“ＣＵ”と表記）とバルブユニット３０（以降、“ＶＵ”と表記）の２つのユニットで構成される。（たとえば家の内部、又は、自宅ルータ２０のＷｉ-Ｆｉ範囲内でかつ外に位置するＶＵの範囲内の位置に存在する）ＣＵ１０は、Ｗｉ-Ｆｉインターフェースを内蔵する。（たとえば屋外であってコック付近かつＣＵのＲＦリンク範囲内に位置する）ＶＵ３０は、１つ以上のバルブを内蔵及び制御する。ＣＵ１０は、イーサネット（登録商標）ケーブルではなくＷｉ−Ｆｉ接続を介してルータ２０（たとえばローカルインターネットアクセスポイント）に接続される。イーサネット（登録商標）設定の欠点には、接続の制限（たとえばローカルアクセスポイント又はハブでのポート数が限られていること）、位置の制限（ＣＵを設置できる場所がイーサネット（登録商標）ケーブルの長さによって決定されること）、及び、一般的な消費者が不要なケーブルを嫌がることが含まれる。Ｗｉ-Ｆｉ接続によってＣＵ１０とＶＵ３０との間での接続は改善される。その理由は、後述するように、ＣＵ１０は、ＩＳＭバンドＲＦリンク４０を介したＶＵ３０との通信が可能となるような所望の位置に設置可能となるからである。より好適には、ＣＵ１０は、ＶＵ３０の２００フィート範囲内、及び、強いＷｉ-Ｆｉ信号を有する領域（たとえば壁、電気機器、及び他の材料が信号に影響を及ぼす恐れがある。）内に設置される。

この実施形態ではたとえば、ＣＵ１０とＶＵ３０との間での通信は、ＩＳＭバンド（たとえば米国では９１０ＭＨｚで欧州では８３３ＭＨｚ）ＲＦリンク４０によってなされる。しかし他の既知の通信媒体が用いられてもよい。ＣＵ１０は、複数のＶＵ３０を制御するように構成される。この実施形態では、ＣＵ１０は２つのＶＵ３０を制御し、各ＶＵ３０は内蔵された４つのバルブ５０を有する。しかしＶＵ３０が４つ以外の個数のバルブ５０を内蔵してもよい。各ＶＵ３０は、場合によっては湿度センサ受信器６５（たとえばメルノアの既存の湿度センサのうちの一及び／又は特許文献１に記載された「スマート給水タイマー」）を介して湿度センサ６０と無線通信し、かつ、湿度センサの状態をＣＵ１０へ中継するように構成される。これは、その状態に基づいてＶＵ３０を制御する（たとえばユーザーの設定に基づいて給水／非給水の判断を行う）。ＣＵ１０は、容易に利用可能な「壁コンセント（ｗａｌｌ ｗａｒｔ）」型電源から電力供給され、かつ、ＶＵは標準的な単三型電池によって電力供給されてよい。

上述の給水システムの動作において、ユーザーは、携帯デバイス、タブレット、又はパーソナルコンピュータで、ウエブベースのＧＵＩインターフェースを用いることによって、給水スケジュールをプログラムする。ＣＵ１０は、Ｗｉ-Ｆｉを介してウエブサーバ２０を接続して、スケジュールを（たとえば連続的に、時間間隔をおいて、オンデマンド等で）更新する。サーバ２０は、ＣＵ１０についてのＧＵＩ設定２００から重要な情報を取り出してプログラムされた給水スケジュールを実行し、かつ、その重要な情報をＣＵ１０へ送る。ＣＵ１０は続いて、バルブ操作４００を各ＶＵ４０へ命令することによって（複数の）プログラムされた給水サイクルを実行する。ＣＵ１０は、たとえば７日プログラムを保存し、かつ、ユーザーが修正するまでそのプログラムを連続的に実行するように構成されてよい。よってインターネット接続が何らかの理由で失われた場合、ＣＵ１０は、ダウンロードされた最後のスケジュールに従って給水を続ける。

ＣＵ１０は、現時点でのバルブの状態４１０、及び、利用可能な場合には、ユーザーが単純な状態表示装置を介して何が起こっているのかを知ることができるように湿度センサ状態の状態４２０を更新するように構成されてよい。ＣＵ１０は、ＣＵ１０がサーバ２０に接続するたびごとに、又は、他の所望の時間間隔でこの情報を更新するように構成されてよい。

動作中、ＶＵ３０は、（たとえばＩＳＭ無線通信を用いることによって）ＣＵ１０と接続することで、ＶＵ３０の各バルブ５０についての最新の設定を受信するように構成される。ＶＵ３０は、スケジュール設定を保存せず、ダム端末（ｄｕｍｂ）である（たとえばその瞬間に命令されたようにバルブをオン又はオフに切り換える）。ＶＵ３０がＣＵ１０との接続を失った場合、ある回数（たとえば５回）の試行後又はある期間（たとえば５分）後、ＶＵ３０は、安全対策としてバルブ５０を閉じる。

ＣＵ１０からの命令の際、ＶＵ３０は、湿度センサ６０がシステム１に接続されているか否かを判断し、接続されている場合には、ＶＵ３０は、受信されたセンサ情報をＣＵ１０へ中継する。湿度センサ６０の制御（たとえば湿度センサのオンとオフを切り替えて信号を待つこと）はＣＵ１０の制御下にある。ＣＵ１０が給水サイクル前及びその間に湿度センサ６０を利用するようにユーザーがプログラムした場合には、ＣＵ１０はそのようにする。

一の実施形態では、たとえば同様のシステムを備える隣人が、その隣人のシステムの一部ではない構成要素にアクセスできないようにＣＵ１０と付随するＶＵ３０を守るため、ＣＵ１０とＶＵ３０の各々は、たとえばシリアル番号のような識別子を有する。たとえば、ＣＵ１０の識別子は（たとえばインターネットへ接続可能なすべてのデバイスによって要求される）固有のＭＡＣアドレスに基づき、かつ、ＶＵ３０は１６ビットの数によって識別されてよい。これにより、固有のシリアル番号を有する６４ｋのバルブユニットの製造が可能となる。他の既知の識別子が、これらのデバイスの各々を固有に識別するのに用いられてよい。

ＣＵ１０の一の実施形態を図２と図６に示して後述する。

図６に表された実施形態に示されているように、ＣＵ１０の組立体は、前方筐体１００、後方筐体１１０、前方筐体と後方筐体との間に供された空間内に配置されるＰＣＢ組立体１２０を有する。前方筐体は、前方ラベル部１０５、及び、たとえばＬＥＤによって生成される光を放出するように構成された１つ以上の開口部を有する。ＰＣＢ組立体１２０は、（複数の）ＬＥＤ１２２（たとえば表示器／ステータスライト）、電力アダプタ１２６を収容するように構成されるパワーコネクタ１２４、及び、（複数の）ＬＥＤスペーサ１２８を有する。前方筐体は、後方筐体に取り付けられ、かつ、前方筐体と後方筐体との間でＰＣＢ組立体を固定するように設計されている。

図２に表された実施形態において示されているように、ＣＵ１０は、ホームルータ又はサーバ２０と通信する無線モジュール１５０、マイクロコントローラ１６０、及び、ＶＵ３０と通信する通信手段１７０（たとえばＩＳＭバンド無線）を有する。

この実施形態では、ＳＰＩベースのインターフェースへ無線メッセージを送信するマイクロコントローラ１６０は、無線モジュールがどのようなインターフェースを有するのかをマイクロコントローラ１６０に知らせる情報を有する。これはハードウエアにより実現されたＩ／Ｏビットのように単純であり得る。異なる無線モジュールが検出されたとき、マイクロコントローラは、その無線フォーマットをサポートする適切なソフトウエアを実行する。

リアルタイムクロック（ＲＴＣ）は、時刻を記録し、かつ、所定のユーザーインターフェースの設定に従って給水動作を予定する。ＲＴＣは、ＣＵ１０がサーバ２０へチェックインするたびごとに更新／同期される。

この実施形態では、ＣＵ１０の機能には少なくとも、すべてのＷｉ-Ｆｉ通信をサポートすること、外部ユーザー／ウエブページ入力に基づいてタイミング機能を実行すること、要求があるときに手動バルブ制御命令を（複数の）外部ＶＵ３０へ中継すること、要求があったときにバルブの状態４１０をウエブのＧＵＩへ送信すること、適切なものとして／適切なときに局所状態表示器を更新することが含まれる。他の実施形態では、ＣＵ１０は、要求されるときには、すべての要求されるＺ-Ｗａｖｅ又はＺｉｇｂｅｅデバイスおよび命令をサポートし、かつ、ホームオートメーションネットワークに含まれることが求められるすべてのＺ-Ｗａｖｅ、Ｚｉｇｂｅｅ機能をサポートするように機能する。

この実施形態では、ＣＵ１０のハードウエアは、電源アダプタ型直流電源１８０からの入力電力フィルタリング／調節（制御）、マイクロコントローラ１６０（たとえばテキサスインスツルメンツＰＮ ＭＳＰ４３０Ｇ２９５５）、Ｗｉ-Ｆｉモジュール（たとえばテキサスインスツルメンツＰＮ ＣＣ３３００）、ＩＳＭ無線チップ（たとえばシリコンラボＳｉ４４５５）、（複数の）既知の局所状態表示器、及び、ＰＣＢ（ＰＣＢトレースにおいて２．５ＧＨｚ及び９１０ＭＨｚアンテナを内蔵する４層ＰＣＢ）を有してよい。

選択されたマイクロコントローラは、フラッシュンメモリ、ＲＡＭ、及び、すべての必要なサポート機能（たとえばＣＰＵクロック、パワーオンリセット回路等）を有してよい。そのため、前記マイクロコントローラは自己充足であり、追加のサポートデバイスを必要としない。選択されたマイクロコントローラはまた、複数のシリアルインターフェースを含む広範にわたる周辺機器をも有して良い。前記広範にわたる周辺機器のうちの２つはＳＰＩである（たとえば、これらのうちの一はＣＣ３０００に対するインターフェースとなることが求められ、他はＩＳＭバンド無線に対するインターフェースとなることが求められる。）。

状態表示器１６２は、ＣＵ１０における様々な通信機能の状態−たとえばパワーインジケータ（たとえば赤色光）、ウエブインターフェースの状態（たとえばユーザーのホームルータ２０への接続の確立を試みようとするときに赤色光が明滅する）、及び、ウエブサービスの状態（たとえば登録されていないときには緑色光が明滅してそれ以外では点灯する）−を示すように設計される。

瞬間的な接触スイッチはたとえば、リセットスイッチ１６４及び設定スイッチ１６６を含む。リセットスイッチ１６４は、マイクロコントローラ１６０のハードリセットによって、ＣＵ１０を初期条件に回復するように構成される。この状態ではたとえば、すべてのルータ設定情報が失われ、かつ、ユーザーは、最初の利用毎にサーバによってＣＵ１０を再登録することが要求され得る。リセットスイッチ１６４は、アクセスが困難（たとえば前方パネル内の小さな穴を介してアクセス可能）で、かつ、ペーパークリップ等によってしか起動できないように配置されてよい。設定スイッチ１６６は、「スマート設定（Ｓｍａｒｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）」プロセスを初期化するように構成される。ユーザーは、ＣＵ１０がホームルータ２０とインターネットへのアクセスを得るようにスマート設定（たとえばスマートフォン又はＰＣ上でテキサスインスツルメンツのＳｍａｒｔ Ｃｏｎｆｉｇアプリを用いることによってＣＣ３３００モジュールを接続する設定プロセス）を実行することが要求され得る。一の実施形態では、設定スイッチ１６６は、押されたときに導電性エラストマー製パッドによって短絡されたＰＣＢコンタクトで構成される（メルノアモデル３０１２タイマーで用いられたものと同様のもの）。

ＶＵ３０の各異なる実施形態が、以降で説明され、かつ、図７と図８の分解図で表される。

図７は、前方筐体３１０、後方筐体３２０、及び、前方筐体と後方筐体によって画定される空間内に配置されるＰＣＢ組立体３４０とバルブ組立体３５０を有するＶＵ３０の組立体の一実施形態を表している。側部カバー３３０もまた空間を画定するように含まれてよい。この実施形態では、バルブ組立体３５０は、ＶＵ内部で図中の各部材が並ぶ方向に平行に列をなして配置される４つのソレノイドバルブを有する。バルブ組立体３５０は、コックと（直接的又は簡略な接続を介して）接続して、そのコックからバルブ５０の各々へ水を送る。この実施形態では、ＰＣＢ組立体３４０は、ＶＵ３０内で長手方向に列をなして配置される４つのＰＣＢタッチパッド３４２を有する。たとえば１つのタッチパッド３４２はバルブ組立体３５０の各バルブに対応する。ＰＣＢロケータブラケット３６０は、ＰＣＢ組立体３４０とバルブ組立体３５０との間に挟まれ、かつ、ＶＵ３０内で長手方向に延びる。前方筐体３１０は長手方向に延びる前面を有する。この実施形態では、前面は４つのオン／オフタッチパッド３４２を有する。４つのオン／オフタッチパッド３４２は、バルブユニット３０中のバルブ５０の個数に対応する。タッチパッド３４２の各々は、ユーザーが領域Ａに触れる場合に、対応するタッチパッドＡ−バルブユニットＡをオン／オフ状態にする−とのコンタクトがなされるように配置される。後方筐体３２０は、バッテリー端子３７０とバッテリー（たとえばこの実施形態では４つの単三電池）を固定するように構成される。後方筐体はまた、湿度センサソケット３８０を収容するようにも構成される（たとえばソケットはＶＵの他の部分上に配置されてもよい。）。

この実施形態では、ＶＵ３０は、バッテリーで動作し、かつ、ＶＵ３０内部で各バルブ５０に係る（たとえばバルブを手動で起動するための）少なくとも１つの容量スイッチ４０２を有する。２つ（以上の）容量スイッチ４０２が、誤作動を防止するのに用いられ得るさらなる検知を供するため、各バルブ５０用に用いられてよい（たとえば４つのバルブと８つの容量スイッチ）。ＶＵ３０が周期的に「目を覚ます」−たとえば１００ｍｓ毎にスイッチを走査し、かつ、１分毎に通信手段４１０（たとえばＩＳＭバンド無線）がＣＵ１０からバルブ状態４１０を得ることを可能にすることで１分のタイミング分解能を維持する。「目を覚ます」周期は、様々な周期に設定されてよい。動作中、図３に示された実施形態に表されたバルブ５０のスイッチがオン又はオフに切り替えられる必要がある場合、バルブ５０は、電圧ブースター４０４を起動し、かつ、電圧が十分に高くなるか、又は、所定の閾値に到達するときにバルブ駆動装置４０６を稼働させる。この実施形態では、バルブのスイッチが−（上述の）プログラム制御下又は手動（たとえば容量スイッチ）制御下で−オンに切り替えられたとき、適切なＬＥＤ状態表示器光４０８が点灯する。

この実施形態によると、ＣＵ１０がバルブの開閉を命令するとき、又は、ユーザーが複数の容量スイッチ４０２のうちの１つを「押す」又は「触る」とき、ＶＵ３０はバルブの開閉のみを行うように構成される。この構成（たとえば「ダム端末」）に必要とされるマイクロコントローラは、この構成より賢い構成に必要とされるマイクロコントローラよりも小さくて安価である。

このＰＣＢに基づく容量接触スイッチ設計の一の利点は、ＶＵ３０で通常みられる、使用及び他の素子によって破断又は損傷する恐れがある外付け部品の数を減らすことである。他の利点は制御の容易さである。ユーザーは単純に、スイッチを触ることでバルブを開き、再度スイッチを触ることでバルブを閉じる。他の利点は美学、具体的には−外観設計の相対的な単純さ−に関する。

図８は、上で説明して図３と図７で表された容量タッチスイッチ４０２又はタッチパッド３４２の代わりに複数の接触押しボタン３４２を有するＶＵ３０の組立体の他の実施形態を表している。この実施形態によると、ＶＵ３０は、ＣＵ１０がバルブの開閉を命令するとき、又は、ユーザーが複数の押しボタンのうちの１つを「押す」ときに、バルブを開閉するように構成される。

ＶＵ３０は、ＲＦリンクの不具合を検出し、かつ、そのような不具合が生じた場合にはすべてのプログラムされたオン状態のバルブを閉じるように構成される。この条件ではたとえば、ユーザーだけが、容量スイッチ３４２又は押しボタン３４２０を介した局所制御を利用してバルブをオン状態に設定し得る。ＶＵ３０が所定の期間中（たとえば複数の１分チェックイン通信試行中）ＣＵ１０とのやり取りができなくなったときに、ＲＦリンクの不具合が起こり、かつ、バルブが閉じられる。

この実施形態では、ＣＵ１０の機能には少なくとも、すべてのシステム設定及び初期化要求をサポートすること、任意の湿度センサ受信器６５から現在の湿度センサデータを受信すること、ＣＵ１０からバルブ制御データを受信すること、容量スイッチ３４２又は押しボタン３４２０を走査して局所的な手動操作を行うこと、ＣＵ１０による要求として又はユーザーによって局所的にバルブ５を作動すること、湿度条件と、バッテリーとバルブの状態４１０をＣＵ１０へ送信すること、電圧ブースター回路４０４を制御してバルブソレノイドを作動すること、バルブ駆動装置４０６を制御してバルブ５０を開閉すること、局所バルブ状態表示器を更新すること、並びに、（たとえば停電、ＲＦリンクの断線、又はハードウエアの不具合による）ＣＵ１０の通信不具合を検出することが含まれる。

この実施形態では、ＶＵ用のハードウエアは、マイクロコントローラ４００（たとえばテキサスインスツルメンツＰＮ ＭＳＰ４３０Ｇ２７５５）、バッテリー又はバッテリーパック、ＩＳＭバンドＲＦトランシーバチップ４１０（たとえばシリコンラボＳｉ４４５５）、アンテナ（たとえば場合によってはＰＣＢエッチングによって実装されるヘリカルコイルアンテナ）、電圧ブースター回路部品４０４、バルブ駆動装置部品４０６、手動バルブ制御用容量スイッチ４０２、バルブ状態表示器４０８、湿度センサ受信器コネクタ４１０（たとえば３ピンコネクタ）、及びＰＣＢ（たとえば２又は４層ＰＣＢ）を有する。

本願で説明したスプリンクラーシステムのシステム設定及び動作中、データが、サーバ２０、ＣＵ１０、及びＶＵ３０との間で交換される。以下はシステムの部品間で転送されるデータについての簡単な説明である。

最初に、サーバ２０とＣＵ１０との間で転送されるデータについて説明する。このデータは設定データとスケジュールデータを含む。

一例では、設定プロセス開始の間、ユーザーは、ウエブベースのＧＵＩインターフェースのアクセスが可能になる前に、ＣＵシリアル番号又はＩＤコードを登録する。登録は、ユーザーのＣＵ１０に係るＣＵシリアル番号（たとえば筐体に記されてよい）を用いることによってＧＵＩインターフェースをサポートするウエブサイトにログインすることを要求してよい。シリアル番号が有効な場合、ユーザーは、ＣＵ１０と併用されるＶＵ３０のシリアル番号若しくはＩＤコード（たとえばＶＵの筐体に同様に記されてよい）を入力又は登録する予定のＧＵＩインターフェースへアクセスする。次にＧＵＩインターフェースでは、ユーザーは、各ＶＵ３０の（複数の）バルブ５０の所望の給水スケジュールの詳細（たとえばスケジュールデータ）を入力することができる。追加のＶＵ３０が、ＣＵ１０と同時に登録されてよいし、あるいは、ＣＵ１０と同時に取得できない場合には後で登録されてよい。ＧＵＩインターフェース自体については後述する。ＣＵ１０は（複数の）ＶＵのＩＤコードを保存しなくてよい。その代わりに、サーバ２０がスケジュールデータをダウンロードするたびに、ユーザーが目的のＶＵ用に入力したＶＵのＩＤコードでスケジュールデータが開始される。ＣＵ１０は、ＶＵ３０からのリスエストに対してこれをチェックすることで、それらが同一のコードであることを確認する。同一でない場合（たとえばＣＵ１０が隣人のＶＵからのリクエストを受信した場合）には、ＣＵ１０はそのリクエストを無視する。ＣＵ１０が一致するＩＤコードを有するＶＵ３０からのリクエストを受信するとき、ＣＵ１０は、バルブ又は領域命令をＶＵ３０へ送る。他の実施形態によると、ＧＵＩインターフェースは、ＣＵとＶＵの製造者によって割り当てられる許容可能なＩＤコードのデータベースを管理する。

ＣＵ１０が給電されるとき、ユーザーは、スマートフォン、ＰＣ、又はタブレットを用いて「スマート設定」操作を実行してよい。その後ＣＵ１０はたとえば、ユーザーのホームＷｉ-Ｆｉルータ２０に接続される。続いてＣＵ１０は、ＧＵＩサーバへ自動的に接続して、識別用のＣＵのＩＤコードを用いてスケジュールデータを取得する。ＣＵ１０が上述したように登録された場合、ＧＵＩインターフェースは、ＣＵ１０に係る（複数の）ＶＵ３０用のスケジュールデータをダウンロードする。次にスケジュールデータについて説明する。

動作中、ＣＵ１０は、周期的にＧＵＩサーバとコンタクトして、たとえばスケジュールに変更があったのか否かを問い合わせるように構成される。ＧＵＩサーバは、必要な場合には新たなスケジュールをダウンロードする。それに加えて、ＣＵ１０は、現在のバルブと（存在する場合には）湿度センサ６０の状態をアップロードする。ＣＵ１０へダウンロードされるデータは以下を含んでよい。
− ＣＵのＩＤコード
− （複数の）ＶＵのＩＤコード
− ＶＵ１、領域（又はバルブ）１、領域２等についての６サイクルでの日曜日（曜日０）のスケジュールと設定
− ＶＵ１、領域（又はバルブ）１、領域２等についての６サイクルでの月曜日（曜日１）のスケジュールと設定
− ＶＵ１についてのその週の残りの日での他の事項
− ＶＵ２、領域（又はバルブ）１、領域２等についての６サイクルでの日曜日（曜日０）のスケジュールと設定
他

よってその週の各日の各サイクルについての各領域に係るデータのブロックが存在する。

サイクルの開始時間と停止時間が同一である場合、そのサイクルは不稼働となる。この例は、６バイト／サイクル／領域、すなわち領域あたり６×６×４＝１４４バイト/日を含む。それに加えて、各領域についての各日に係る（しかしサイクルには関係ない）雨による遅延又はセンサ使用のデータが存在してよい。

これは、雨による遅延が、ユーザーが「呼び出した」後の深夜に始まり、かつ、２４時間単位で延長する例である。従って、各日で、その日のスケジュールによらず雨による遅延フラグがＣＵ１０に対して示されると、給水は行われない。取り付けられたセンサがその領域で用いられるのか否かを示す追加のバイトも存在する。

これは、追加で２バイト／領域／日すなわち合計で８バイト／日である。この例では、１日での４バルブ（１ＶＵ）についての合計のスケジュールの要件は１５２（＝１４４+８）バイトで、１週間では１０６４（＝７×１５２）バイトである。従って２つのバルブユニットについての１週間のスケジュールデータの合計は２１２８バイトである。

次にＣＵ１０からＧＵＩサーバへ転送されるデータについて説明する。このデータは設定データとスケジュールデータを含む。

一例では、ユーザーが、ＣＵ及び／又はＶＵのＩＤコードを有するダウンロードデータを初期化した後、ＣＵ１０は「受信確認通知」で応答する。この例では、スケジュールデータの受信が成功した後、ＣＵは、ＧＵＩを提供するウエブサービスへ現在の状態を直接送ることによって応答する。ＣＵがｐｕｓｈｅｒサービスとの定期的な「ハートビート」コンタクトを実行するといつも、ｐｕｓｈｅｒサービスはスケジュールで応答する。一の実施形態によると、ＣＵは、以下のような現在のシステムの状態をＧＵＩウエブサーバへアップロードする。

次にＣＵからＶＵへ転送されるデータについて説明する。このデータはコマンドデータを含む。

ＶＵは、ＣＵからの命令に応答し、かつ、ＶＵのバッテリー状態に関するデータを送信し、かつ、センサ状態を中継するように構成される。ＶＵは、独自のＩＤを含む命令パケットを受信するとすぐに応答する。一の実施形態によると、利用可能な命令は以下である。

次にＶＵからＣＵへ転送されるデータについて説明する。このデータはＶＵの状態データを含む。

一の実施形態によると、ＶＵは周期的に（たとえば毎分）起動してＣＵへチェックインする。ＣＵは、バルブと湿度センサ命令をＶＵへ送ることによって応答する。ＶＵは、命令を繰り返し、かつ、ＶＵのバッテリーと湿度センサの状態を追加することによって、命令の受信を通知する。このデータは以下を含む。

センサフラグの状態は、センサ受信器が接続されたのか否か、並びに、センサの給水及びバッテリーのフラグと一致するセンサ受信器の機能の状態を示すビットをも有してよい。

次にＧＵＩからＣＵへのパケット表現について説明する。

上述したように、１週間での１つのＶＵのスケジュールデータは、１０６４バイトすなわち１日あたり１５２バイトを必要とする。データは１日のパケット数でダウンロードされてよい。たとえば２つのバルブユニットを備えるシステムでは１週間で１４のパケットが必要となる。ＧＵＩからＣＵへ送られるパケットの種類は２種類以上存在するが、大体はスケジュールの更新である。他の考えられ得るパケットの種類には、ＣＵソフトウエアコードを更新する命令、及び、送信される新たなコード等が含まれてよい。スケジュール更新型パケットは、バルブユニットのＩＤ番号と日の番号を含む。ＧＵＩとＰｕｓｈｅｒとの間でのプロトコルとデータの流れの例について以降で説明する。

次にＣＵからＶＵへのパケット表現及びＶＵからＣＵへのパケット表現について説明する。一の実施形態が図４に示されている。

ＣＵからＶＵへのパケット型は、ＶＵからの「チェックイン」パケットに応じた定期的なバルブ動作を含む。ＶＵからＣＵへのパケット型は、定期的なチェックインパケットとチェックインパケットの「受信完了」通知を含む。

一の実施形態によると、ＶＵ３０は、必要に応じて給水スケジュールを修正できるように接続された湿度センサ６０を有しているか否かをＣＵ１０に知らせる。伝送される必要のある追加のデータにはたとえば以下が含まれる。
（１）ＶＵ３０に湿度センサ受信器６５が取り付けられていること
（２）ＣＵ１０がＶＵ３０をオン状態にしてセンサデータを受信させる必要があること
（３）ＶＵ３０は湿度センサフラグが何であるのかをＣＵ１０に知らせる必要があること、及び、
（４）ＣＵ１０はＶＵ３０に受信器６５をオフ状態にさせる必要があること

ＣＵ１０からＶＵ３０へのコマンドパケット長は、ＶＵ３０が他のＶＵ３０の伝送情報をＣＵ１０に由来するものとして誤って読み取ろうとしないように、ＶＵ３０からＣＵ１０へのコマンドパケット長とは異なり得る（たとえばＶＵのＩＤ番号はどうしても一致しない）。

このシステムでは、複数のデバイスがＣＵからＶＵへのＲＦリンクと同一の周波数を用いてよく、かつ、互いに近接していることはわかっていないので、一の実施形態によると、すべての受信器はすべての送信器の送信情報を受信できると推定される。以下の例によると、２つのＶＵ３０（たとえば各々は１分の更新リクエストを送信する）、２つの湿度センサ（たとえば各々は約１５秒ごとに状態を送信する）、１つのＣＵ（たとえばＶＵによる情報のリクエストがあたっときにのみ送信する）が存在する。この例では、湿度センサ６０は、ＩＤが一致する受信器以外の任意の受信器６５と直接やり取りしない。しかし湿度センサ６０は、他の受信器によって拾われ得ないＲＦ信号を生成する。このため、フォーマットとＩＤが適合しない信号は拒絶される。とはいえ、その周波数での任意の１つの送信器が送信する一方で、他のＲＦ通信は行うことができない。これはコリジョンとして知られ、以下のようにして適応される。

一の実施形態によると、受信器チップは、いつ他の送信器がアクティブになるのかを検出するように構成されるので、コリジョンの回避は、既存の送信をチェックし、かつ、コリジョンが検出される場合、他の送信が試行される前に遅延させることによって実装されてよい。たとえば複数回−場合によっては最大１０回−の送信試行がなされ、その後ＶＵ３０は（たとえば次の分又は設定時間まで）待って再度試行する。

一のコリジョンの可能性は、２つ以上のＶＵ３０の送信を同時に行うことを含んでよい。２つ以上のＶＵ３０の両方が同時に送信の試行を開始する場合、又は、ＣＵ１０が早いリクエストに応答しているときにもう一方が試行する場合、又は、隣人が同様のシステムを設置し、かつ、それらのＶＵ３０のうちの１つが「自宅の」ＶＵ３０の範囲内で偶々同時に送信する場合に、このようなことは起こり得る。

他のコリジョンの可能性は、１つ以上のセンサ６０が同時に送信することを含んでよい。センサは、コリジョンを検出できないので、待つことができない（しかしたとえば、１５秒の遅延後に同一のデータを再送信するように設計することは可能である）。

コリジョンの可能性は、送信器の個数と送信期間に部分的に依存する。同時に通信しようとする可能性のあるデバイスの数はそれほど多くはなく、かつ、やり取りされるデータは非常に小さいので、このシステムでのコリジョンは、めったに起こらないはずであり、データのスループットは特に影響を受けない。

図５は、ＣＵ１０からウエブサーバ２０への通信及びウエブサーバ２０からＣＵ１０への通信のアーキテクチャを表す図である。

この実施形態では、Ｐｕｓｈｅｒは、ウエブソケットを用いて、クライアントとやり取りし、かつ、サーバからクライアントへデータを送るためにＲＥＳＴ ＡＰＩを用いるＨＴＴＰ ＰＯＳＴを管理する双方向通信チャネルである。すべてのメッセージはＰｕｓｈｅｒのサービスを介して送られる。Ｐｕｓｈｅｒは、データがアプリケーションと呼ばれる入れ物の中に含まれるように通信チャネルを区分化するように構成される。メッセージを送受信するため、Ｒｅｃｅｉｖｅｒ／Ｓｅｎｄｅｒはアプリケーションに申し込む必要がある。

アプリケーションは、Ｐｕｓｈｅｒのウエブフロントから生成される。アプリケーションを生成することで、特定の信用情報−たとえばアプリケーションＩＤ、鍵、及び秘密鍵−が生成される。信用情報は、特定のアプリケーションにおいてＲｅｃｅｉｖｅｒ／Ｓｅｎｄｅｒの両方によってメッセージを送るのに用いられる。

各アプリケーションはチャネルをさらに有してよい。チャネルはユーザーによってオンデマンドで生成されてよい。Ｒｅｃｅｉｖｅｒはチャネルに申し込んで良い。Ｓｅｎｄｅｒはこれらのチャネル上でメッセージを発行してよい。チャネルに申し込むＲｅｃｅｉｖｅｒのみが、そのチャネルのためのメッセージを受信できる。各チャネルは複数のＲｅｃｅｉｖｅｒを有してよい。複数のＳｅｎｄｅｒは各チャネルへメッセージを送信してよい。

各チャネルは、Ｓｅｎｄｅｒがメッセージを送信することが可能な格異なるイベント名−たとえばＣＯＮＴＲＯＬイベント、ＤＡＴＡイベント、ＭＳＧイベント−を有して良い。これらのイベントはユーザー定義可能であってよい。各イベントはそのイベントに係るメッセージを有してよい。それに加えて、エンドユニットが時々サービスを行う必要があると考えられるＰｕｓｈｅｒの内部で処理されるべきイベント−たとえばｐｕｓｈｅｒの申し込みメッセージ、ｐｕｓｈｅｒの接続が有効であるというメッセージ等−が存在する。

Ｐｕｓｈｅｒの各エンドユニットは、アプリケーションにログインし、かつ、メッセージを受信するためにチャネルに申し込む必要があると考えられる。

次に、ＣＵからウエブへ及びウエブからＣＵへのデータの流れについて説明する（たとえばサーバが動いていると仮定すると、Ｐｕｓｈｅｒアカウントがアプリケーションによって生成され、Ｗｅｂｈｏｏｋは、Ｐｕｓｈｅｒ内において、チャネルがＰｕｓｈｅｒアプリケーション内に書き込まれるときはいつもサーバに報告するように、構成される。）。

最初にＣＵ１０がルータ２０に接続する。次にＣＵ１０は、Ｐｕｓｈｅｒに接続し、かつ、ＩＤと同じ名前のチャネル名に申し込む。チャネルが書き込まれたＣＵ１０によって占められるので、Ｐｕｓｈｅｒは、チャネルが占められているというメッセージを発しているサーバへＷｅｂｈｏｏｋを送る。続いてサーバはたとえば、チャネル用のハッシュ鍵を生成し、そのハッシュ鍵をデータベース内に格納し、かつ、Ｐｕｓｈｅｒを介してそのハッシュ鍵をＣＵ１０へ送る。

一旦ＣＵ１０がハッシュ鍵を得ると、ＣＵ１０は、（ａ）現在のセッションのハッシュ鍵を格納し、（ｂ）状態のメッセージを生成し、（ｃ）ＣＵのＩＤコードをメッセージに加え、（ｄ）送信用のメッセージ全体を符号化し、かつ、（ｅ）ＧＥＴメッセージを生成してサーバへ配置してメッセージを送る。

一旦サーバがメッセージを受け入れると、サーバは、（ａ）ハッシュ鍵をチェックして、メッセージがどのＣＵからのであるのかを判断し、（ｂ）符号化されたメッセージを復号化してＣＵのＩＤとメッセージを取得し、かつ、（ｃ）ＣＵのＩＤとハッシュ鍵の所有者とを結びつける。ハッシュ鍵の所有者とＣＵのＩＤコードが一致する場合、メッセージは有効であり、さらなる処理のために待ち行列に加えられる。ハッシュ鍵が一致しない場合、メッセージは無視される。

サーバが特定のＣＵ１０へメッセージを送るとき、サーバは、バイナリデータからメッセージを符号化し、かつ、定められたアプリケーションとＣＵのＩＤコードをチャネル名として用いることによってＰｕｓｈｅｒのメッセージを送る。ＣＵ１０では、Ｐｕｓｈｅｒはメッセージを配信する。ＣＵ１０は、バッファ内のメッセージを読み、そのバッファを復号化し、バイナリデータを構造体に読み込み、かつ、Ｓｃｈｅｄｕｌｅｒを更新する。

次に、携帯デバイスを用いてＣＵ１０をＷｉ-Ｆｉネットワークへ接続する方法の一例について説明する。初期設定後、システムは、携帯デバイス又はコンピュータからプログラムされるように設計される。

ユーザーは、パワーアダプタ１２６を介してＣＵ１０を電力の出力部に接続する。強いＷｉ-Ｆｉ信号を有し、かつ、ＶＵ３０の２００フィート範囲内の領域内にＣＵ１０を設置することが好ましい。

ユーザーは、無線給水タイマーとスプリンクラーシステムの携帯アプリケーション（“Ｗｉ-Ｆｉ ＣＵ Ａｐｐ”）を（たとえばＡｐｐ Ｓｔｏｒｅ又はＧｏｏｇｌｅ Ｐｌａｙから）ダウンロード及びインストールする前に、自分の携帯デバイス（たとえばスマートフォン又はタブレット）が所望のＷｉ-Ｆｉネットワークに接続されることを確認する。

ユーザーは、ダウンロードしたＷｉ-Ｆｉ ＣＵ Ａｐｐを起動し、かつ、システム１をネットワークに接続する前に、ダウンロードしたＷｉ-Ｆｉ ＣＵ Ａｐｐが所望のＷｉ-Ｆｉネットワーク（たとえば自宅ネットワーク）に接続されることを確認する。

ユーザーは、ＧＵＩウエブサイトにアクセスし、個人アカウントを作成し、かつ、たとえばＣＵ１０のシリアル番号（たとえばＣＵ１０の後部カバー又はシステムに備えられたパッケージング材料に記されている）を入力することによってシステムを登録する。ユーザーはまた、位置に固有の情報（たとえば領域コード、ＺＩＰコード、市／州等）を入力してその位置での天候情報を得ることをも可能となる。ユーザーはまた、この登録の一部としてＣＵ１０に接続される各ＶＵ３０のシリアル番号を入力してもよい。

ユーザーは、（複数の）ＶＵ３０を外部に存在する（複数の）コックに接続し、かつ、その（複数の）コックをオンにする。

ユーザーは、ホースの第１端部をＶＵ３０の所望の出力部に接続し、かつ、ホースの第２端部をスプリンクラー装置に接続する。

ユーザーは、スプリンクラー装置近傍の領域内に湿度センサ６０を設置し、かつ、システム１とやり取りするように湿度センサ６０を設定する。

ユーザーはまた、コンピュータまたは携帯デバイスを介して、ＧＵＩインターフェース（ウエブページ）上でシステムに係るユーザーの個人アカウントにアクセスことによって制御装置をプログラムしてもよい。システムに係るウエブページの一例は、バルブプログラムグリッドのスクリーンショットである図９に示されている。グリッドは、ユーザーがバルブに固有のプログラム情報を入力できるように構成される。バルブに固有のプログラム情報とはたとえば、第１給水サイクルの開始時間、給水時間（分）、給水サイクル（たとえば４，６，８又は１２時間ごとに一度の給水又は１，２，３，４，５，６又は７日に一度の給水）とエコノミーモードとの間の時間（たとえば給水サイクル中にバルブを繰り返し開閉することで水を節約して、より少ない水の流出でより多くの水を吸い込ませることを可能にする）である。各バルブは独自の給水プログラムを有してよい。

上記の観点で、本発明の複数の目的が実現され、かつ、他の有利な結果が得られることがわかる。本発明の技術的範囲から逸脱することなく、様々な変更が上記の構成においてなされてよいので、上記の説明に含まれ、又は、添付図面に示されたすべての事項は、例示と解されるべきであり限定ではない。

Claims (15)

1. 無線給水タイマー及びバルブ制御システムであって、
   ルータと無線ＷｉＦｉ通信する制御ユニット、
   前記制御ユニットと無線通信してコックと接続するように設計されるバルブユニット、
   を有し、
   前記バルブユニットは、前記制御ユニットによって受信される信号を介して無線動作するバルブを有し、
   前記制御ユニットは、前記ルータを介して前記ルータのネットワーク外部のサーバへインターネットで通信するように構成され、
   前記サーバは、ユーザーから、ユーザーのデバイスを介して前記バルブを操作する命令を含むユーザー入力を受信するように構成され、
   前記サーバは、前記バルブを操作する前記ユーザー入力に基づいて前記制御ユニットへメッセージを送信するように構成され、
   前記制御ユニットは、前記サーバから受信したメッセージに基づいて、前記バルブユニットへバルブ操作命令信号を送信するように構成され、
   前記サーバは、各々が異なるユーザーによって所有されている複数の制御ユニットと通信し、ａ）前記複数の制御ユニットから受信した複数のメッセージをチェックして受信されたメッセージを送信した特定のユーザーの特定の制御ユニットを識別し、ｂ）前記特定の制御ユニットの識別を含む前記特定のユーザーの前記特定の制御ユニット向けのメッセージを生成する、ように構成され、
   前記サーバは、前記制御ユニットから受信した複数のメッセージをチェックし、受信されたメッセージの送信元である特定の制御ユニットを特定し、
   前記ユーザーのデバイスがユーザーの携帯デバイスで、
   前記ユーザーのデバイスが、無線給水タイマー及びスプリンクラーシステムの携帯ソフトウエアアプリケーションを有し、
   前記サーバは、前記ユーザーのデバイス上に前記無線給水タイマー及びスプリンクラーシステムの携帯ソフトウエアアプリケーションをダウンロード並びにインストールしたユーザーによって前記ユーザーのデバイスを介して前記ユーザーからのユーザー入力を受信するように構成され、
   前記ユーザーは、前記ユーザーのデバイスを介して、ａ）個人のアカウントを生成し、設定プロセス中に、ｂ）前記システムに供される前記制御ユニット及びバルブユニットのシリアル番号又はｉｄコードを入力することによって、ｉ）前記制御ユニット及びｉｉ）前記バルブを登録し、
   前記システムの構成は、
   前記ユーザーが、前記ユーザーのデバイスの前記無線給水タイマー及びスプリンクラーシステムの携帯ソフトウエアアプリケーションを介して、前記サーバによって受信される前記バルブユニットのバルブの給水スケジュールを入力し、
   前記サーバは、前記給水スケジュールを前記ユーザーの制御ユニットへ送る、
   ようになされる、
   無線給水タイマー及びバルブ制御システム。
2. 請求項１に記載の無線給水タイマー及びバルブ制御システムであって、前記制御ユニットが、複数のバルブユニットを操作するように構成される、無線給水タイマー及びバルブ制御システム。
3. 請求項１に記載の無線給水タイマー及びバルブ制御システムであって、前記バルブユニットと前記制御ユニットとの間での無線通信が、ＩＳＭバンドとＲＦリンクによってなされる、無線給水タイマーシステム。
4. 請求項１に記載の無線給水タイマー及びバルブ制御システムであって、前記バルブユニットは、各々が前記制御ユニットによって無線操作される複数のバルブを有する、無線給水タイマー及びバルブ制御システム。
5. 請求項１に記載の無線給水タイマー及びバルブ制御システムであって、
   前記バルブユニットが、湿度センサと無線通信し、かつ、前記湿度センサから受信した湿度センサ状態を前記制御ユニットへ中継するように構成され、
   前記制御ユニットは、前記湿度センサ状態に基づいて前記バルブユニットを操作するように構成される、
   無線給水タイマー及びバルブ制御システム。
6. 請求項１に記載の無線給水タイマー及びバルブ制御システムであって、前記制御ユニットが、インターネットサーバーによって前記制御ユニットへ送られる前記スケジュールに少なくとも基づいて前記バルブユニットを操作するように構成される、無線給水タイマー及びバルブ制御システム。
7. 請求項６に記載の無線給水タイマー及びバルブ制御システムであって、前記制御ユニットが、前記スケジュールを管理し、かつ、前記スケジュールが、前記ユーザーの携帯デバイスの前記無線給水タイマー及びスプリンクラーシステムの携帯ソフトウエアアプリケーションを介して、ユーザーによって修正されるまで前記スケジュールに従って前記バルブユニットを操作するように構成される、無線給水タイマー及びバルブ制御システム。
8. 請求項１に記載の無線給水タイマー及びバルブ制御システムであって、前記制御ユニットが、所定の時間にバルブ状態をインターネットサーバーへアップロードするように構成される、無線給水タイマーシステム。
9. 請求項８に記載の無線給水タイマー及びバルブ制御システムであって、前記所定の時間は、前記制御ユニットが前記サーバとコンタクトする度毎である、無線給水タイマー及びバルブ制御システム。
10. 請求項１に記載の無線給水タイマー及びバルブ制御システムであって、前記バルブユニットは、所定の期間中に前記制御ユニットとのコンタクトを失った場合にすべてのバルブを閉じるように構成される、無線給水タイマー及びバルブ制御システム。
11. 請求項１に記載の無線給水タイマー及びバルブ制御システムであって、
    当該システムと無線通信する湿度センサをさらに有し、
    前記バルブユニットは、前記湿度センサから受信されたセンサ情報を前記制御ユニットへ中継するように構成される、
    無線給水タイマー及びバルブ制御システム。
12. 請求項１に記載の無線給水タイマー及びバルブ制御システムであって、前記バルブユニットが、前記バルブユニット上のバルブの各々を手動で開閉するように構成される容量タッチスイッチを有する、無線給水タイマー及びバルブ制御システム。
13. 請求項６に記載の無線給水タイマー及びバルブ制御システムであって、前記インターネットサーバーによって前記制御ユニットへ送られる前記スケジュールが、局所的な天候情報に基づいて修正可能である、無線給水タイマー及びバルブ制御システム。
14. 請求項１に記載の無線給水システムを使用する方法であって、
    Ｗｉ−Ｆｉ通信を介して制御ユニットをルータへ接続する段階、
    無線通信を介してバルブユニットを前記制御ユニットへ接続する段階、及び、
    前記制御ユニットから前記バルブユニットへ、前記バルブユニット上のバルブを開閉するバルブ動作命令信号を送る段階、
    を有する方法。
15. 請求項１に記載の無線給水タイマー及びバルブ制御システムであって、前記サーバは、（ａ）ハッシュキーをチェックしてどの制御ユニットに起因する暗号化メッセージなのかを判断し、（ｂ）前記暗号化メッセージを復号化して制御ユニットＩＤを取得し、（ｃ）前記制御ユニットＩＤと前記ハッシュキーの持ち主とを一致させることによって、前記複数の制御ユニットから受信した複数のメッセージをチェックして受信されたメッセージを送信した特定のユーザーの特定の制御ユニットを識別するように構成される、無線給水タイマー及びバルブ制御システム。

Images