本発明の一実施形態(以下、本実施形態)に係る情報報知システムについて、図1〜図14を参照しながら説明する。図1は、本発明に係る情報報知システムが搭載された建物の説明図である。図2は、本発明に係る報知機器の外観図である。図3は、本発明に係るホームサーバ及び外部サーバとの関係の一例を示した図である。図4Aは、本発明に係るホームサーバのハードウェア構成を示すブロック図である。図4Bは、本発明に係るホームサーバの構成を機能面から示した図である。図4Cは、本発明に係るホームサーバの実行環境に関する構成図である。図5は、本発明に係る情報処理端末にて描画される画面の一例を示した図である。図6は、本発明に係る報知機器の構成を示す図である。図7の(A)〜(C)は、報知動作を実行している状態の報知機器を示す模式図であり、(D)は、報知機器にてユーザの操作を受け付けている様子を示す模式図である。図8は、本発明に係る発光動作の内容の一例を示した図である。図9は、本発明に係る音声発生動作の内容の一例を示した図である。図10は、本発明に係る報知機器がユーザの操作を受け付けた際に実行する応答動作の一例を示した図である。図11〜図13は、情報報知処理の流れを示した図である。図14は、機器制御処理の流れを示した図である。
<<本実施形態に係る情報報知システムの概要>>
本実施形態に係る情報報知システム(以下、本システムS)について、図1〜図3を参照しながら概説する。なお、図1中、本システムSを構成する要素間を結ぶ線のうち、実線で記載されたものは、電気配線を示し、破線で記載されたものは、通信回線を示す。
以下では、本システムSが建物の一例としての住宅Hに搭載された構成を例に挙げて説明する。ただし、あくまでも住宅Hは建物の一例に過ぎず、本発明の情報報知システムは、他の建物、例えばオフィスビル、工場内の建屋、店舗等においても利用可能なものである。
<本実施形態に係る情報報知システムの構成>
本システムSは、住宅H内でのエネルギー消費量として、住宅H内での電力消費量を管理するものであり、ユーザ(例えば、住宅Hの居住者)に対して、住宅H内での電力消費に関する情報を報知する。より具体的に説明すると、本システムSは、いわゆるホームエネルギーマネジメントシステム(HEMS)であり、住宅H内における電力消費量を削減する目的から、住宅H内で使用される電力消費機器の電力消費量を視覚化(見える化)して、その視覚化された情報をユーザに報知するものである。
電力消費機器とは、エネルギー消費機器に相当し、具体的には、家電製品、照明、エアコン、給湯器、AV機器、防犯設備等が該当する。また、本実施形態に係る住宅H内では、複数の電力消費機器が使用されている。換言すると、本システムSは、少なくとも1個以上の電力消費機器が使用されている住宅Hに搭載されたものである。
なお、図1では、図示の都合上、電力消費機器としてエアコン7a、照明7bのみを図示している。ただし、図1に図示した電力消費機器の組み合わせはあくまでも一例であり、当然ながら、図1に図示された電力消費機器以上の台数の電力消費機器が住宅H内に設置されていてもよく、また、図1に図示されていない種類の電力消費機器が住宅H内に設置されていることとしてもよい。
また、住宅Hでは、図1に示すように、商用電源4からの電力(以下、系統電力)が受電される一方で、住宅Hに設置された発電ユニット1により、自然エネルギーとしての太陽光エネルギーを利用して発電することが可能である。発電ユニット1が発電した電力(以下、発電電力)及び系統電力は、分電盤2を通じて、住宅H内に設置された電力消費機器の各々に供給される。発電電力は、発電ユニット1と分電盤2との間に設置されたパワーコンディショナ5によって直流電力から交流電力に変換される。
なお、系統電力の単価(すなわち、電気料金)は、時間帯に応じて変化し、例えば、深夜時間帯の単価は、昼間帯の単価よりも幾分安く設定されている。さらに、系統電力の単価は、季節や原油価格の変動等に伴って変動することもある。
また、本実施形態では、発電ユニット1が商用電源4と連系しており、発電電力の余剰分を商用電源4に逆潮流(売電)することが可能である。さらに、本実施形態では、蓄電池3が設けられており、系統電力や発電電力を蓄電池3に蓄電しておくことが可能である。そして、蓄電池3に蓄電された電力(以下、蓄電電力)は、適宜なタイミングで放電され、他の電力と同様、分電盤2を通じて、住宅H内の電力消費機器の各々に供給される。なお、蓄電池3と分電盤2との間には、双方向インバータ6が設置されている。この双方向インバータ6により、系統電力や発電電力は、蓄電池3に蓄電される際に交流電力から直流電力に変換され、蓄電電力は、放電される際に直流電力から交流電力に変換される。
一方、HEMS(すなわち、本システムS)が搭載された住宅Hには、電力を測定するセンサ群が設けられている。具体的に説明すると、分電盤2には、スマートメータからなるセンサ21が取り付けられている。このスマートメータからなるセンサ21は、測定装置に相当し、エネルギー消費量として、住宅H内で消費される電力消費量(正確には、住宅H内で消費される全電力消費量)を測定するものである。特に、本実施形態において、センサ21は、所定の期間における電力消費量の累積値を測定する。ここで、所定の期間とは、本実施形態では1ケ月間の期間が設定されているが、他の期間(例えば、1日間あるいは1週間)に設定されていることとしてもよい。なお、測定開始時から所定の期間が経過すると、センサ21は、測定結果をリセットした上で測定を再開する。
また、エアコン7a及び照明7bの各々には、個別のセンサ22a、22bが取り付けられている。このセンサ22a、22bは、通信機能を有する電力センサであり、対応する機器の電力消費量を測定する。
さらに、発電電力、系統電力、蓄電電力を測定するためのセンサ23a、23b、23cが設けられている。具体的に説明すると、発電電力用のセンサ23aは、パワーコンディショナ5と分電盤2との間に配置され、系統電力用のセンサ23bは、住宅H内に設けられた不図示の受電設備と分電盤2との間に配置され、蓄電電力用のセンサ23cは、蓄電池3の所定位置に取り付けられている。
以上までに説明してきた各センサ21、22a、22b、23a〜23cは、その測定結果に応じた情報を示す測定結果データを出力(送信)する。ここで、測定結果に応じた情報とは、測定結果を数値化したもの(すなわち、測定値)のことであり、測定結果に応じた情報を示す測定結果データとは、数値化した測定結果をデジタル信号に変換したものである。また、センサ21、22a、22b、23a〜23cのうち、住宅H内で消費される電力消費量を測定するセンサ21は、住宅Hにおける瞬間消費電力を常時監視しており、当該瞬間消費電力が所定の大きさ以上になると、かかる状況を報告するための報告データを出力(送信)する。
そして、測定結果データ及び報告データについては、住宅内に設けられたネットワーク(以下、宅内ネットワークTN)を介して取得することが可能である。すなわち、本システムSでは、宅内ネットワークTNを介して、各センサ21、22a、22b、23a〜23cと通信することが可能である。なお、宅内ネットワークTNは、例えば、Ethernet(登録商標)ケーブルを用いた有線、あるいは、IEEE802.1xまたはBluetooth(登録商標)を用いた無線によるIPネットワークにより構成される。
さらに、本システムSでは、宅内ネットワークTNを介して上記の電力消費機器と通信し、当該電力消費機器の運転状態を制御することが可能である。すなわち、本システムSでは、宅内ネットワークTNを通じて、エアコン7aや照明7bをはじめとする電力消費機器の各々の運転状態を遠隔制御することが可能である。
具体的に説明すると、本システムSでは、宅内ネットワークTNを通じて、電力消費機器の運転状態を制御するための信号(制御信号)を電力消費機器に向けて発信する。一方で、宅内ネットワークTNを介して制御信号を受信した電力消費機器側では、当該電力消費機器の運転状態が、制御信号に応じた状態に切り替わるようになる。ここで、運転状態とは、発停(オンオフ)、冷房や暖房等の運転モード、設定温度等の運転管理値など、運転に関してコントロール可能(調整可能)な項目についての現状を示す概念である。
以上のように、本システムSでは、宅内ネットワークTNを介した通信により、各電力消費機器の監視及び制御、並びに、住宅H内での電力需給バランスの視覚化(見える化)を行うことが可能である。そして、以上までに説明してきた本システムSの機能は、住宅Hの内部に設置されたホームサーバ10(ホームゲートウェイ)と、ユーザが電力消費機器の制御や住宅H内での電力需給バランスの監視を行う際のインタフェースとして機能する機器(具体的には、後述の携帯端末30やロボット50)によって実現される。
ホームサーバ10は、本発明の通信装置に相当し、宅内ネットワークTNを通じて、住宅H内に存在する通信対象機器(具体的には、電力消費機器、センサ21、22a、22b、23a〜23c)間でデータや信号を受け渡し、各通信対象機器を一括管理する。すなわち、本実施形態では、各センサ21、22a、22b、23a〜23cからの測定結果データの取得、及び、各電力消費機器への制御信号の発信がホームサーバ10により一元的に行われている。
ところで、電力消費機器の中には、通信方式(通信規格、通信プロトコルと同義)が互いに異なる機器が存在する。一般的に、HEMSが搭載された住宅Hでは、共通の通信方式を採用した電力消費機器を使用することが推奨されており、例えば、ECHONET(エコーネット)コンソーシアムが提唱するECHONET規格を採用した機器に統一されていることが望まれている。一方、ユーザが任意に(通信方式を気にせずに)電力消費機器を購入する等の理由から、住宅H内の電力消費機器の中にECHONET規格外の機器も含まれる場合があり、かかる場合には、住宅Hで使用される電力消費機器の間で通信方式が異なってしまう。
このため、本実施形態に係るホームサーバ10は、通信対象機器に応じて通信方式を切り替え、通信対象機器に対応した通信方式にて通信することが可能な構成になっている。ここで、住宅H内の各通信対象機器が、通信方式の違いによって第1規格機器、第2規格機器及び第3規格機器の3種類に分けられる場合を例に挙げて説明すると、ホームサーバ10は、例えば、第1規格機器と通信する際には、第1規格機器と対応した通信方式を採用し、その後、第2規格機器と通信する際には、通信方式を第2規格機器と対応した通信方式に切り替える。このように機器の種類に応じて通信方式を切り替えるホームサーバ10の機能については、後に詳述する。
一方、本システムSには、宅内ネットワークTNを通じてホームサーバ10と通信する情報処理端末と、USBコネクタ50bによりホームサーバ10に接続された報知機器とが備えられている。これらの機器は、いずれも、ホームサーバ10とユーザとの間に介在し、電力消費機器の制御や住宅H内での電力需給バランスの監視を行う際のインタフェースとして機能する。
報知機器は、ユーザに対して所定の情報を報知する置物型の装置であり、特に、本実施形態に係る報知機器は、図2に図示された外観を有するコミュニケーションロボット(以下、単にロボット50という)である。このロボット50は、ホームサーバ10から送信される実行要求を受信して、所定の報知動作を実行する。なお、本実施形態に係るロボット50は、図2に示すように、長卵形状のマスコットを模した形態となっている。ただし、これに限定されるものではなく、ロボット50の形態については、任意の形態(例えば、動物や人間を模した形態)に設計することが可能である。
また、ロボット50は、上述したように、USBコネクタ50bによってホームサーバ10と接続されており、ホームサーバ10との間でデータの受け渡しを行う。さらに、本実施形態に係るロボット50は、上記のUSBコネクタ50bを介してホームサーバ10と電気的に接続されており、ホームサーバ10が通電状態(オン状態)にある間、ロボット50にホームサーバ10から電力が供給されて通電状態(オン状態)で保持される。つまり、ロボット50に対する電力の供給源(電源)は、ホームサーバ10の電源と連動していることになる。
一方、本実施形態に係るロボット50は、報知動作として、報知する情報に応じた発光形式にて発光する発光動作、報知する情報に応じた音声を発する音声発生動作、報知する情報に応じて振動する振動動作のうち、少なくとも一つ以上の動作を選択して実行することが可能である。なお、ロボット50の構成や動作に関する詳細事項については後述する。
情報処理端末は、ブラウジング機能を有する端末であり、上記の報知機器(具体的には、ロボット50)とは別体をなし、宅内ネットワークTNを介してホームサーバ10と通信可能に接続されている。また、情報処理端末は、情報(具体的には、ホームサーバ10から取得した取得データが示す情報)を表示するためのディスプレイを有しており、本実施形態では、スマートフォンやPDA、ノートパソコン又は所定のアプリケーションソフトが搭載されたデジタルフォトフレーム等、携帯性を有する端末(以下、携帯端末30)によって構成される。
携帯端末30には様々なプログラム(アプリケーション)が搭載されており、その中の一つとして、センサ21、22a、22b、23a〜23cの測定結果が表示される画面(例えば、図5参照。以下、エネルギー管理画面という)を描画するプログラムが存在する。このプログラム(以下、エネルギー管理プログラム)は、携帯端末30に搭載されたタッチパネル31にて、ユーザが所定の操作(例えば、タッチパネル31上に表示されたアイコンをタッチする操作)を行うことにより起動する。
エネルギー管理プログラムが起動すると、携帯端末30は、ホームサーバ10と通信し、ホームサーバ10に対して、センサ21、22a、22b、23a〜23cの測定結果に関するデータの送信を要求する。当該要求を受け付けたホームサーバ10は、センサ21、22a、22b、23a〜23cと通信して上述の測定結果データを取得する。その後、ホームサーバ10は、取得した測定結果データに応じて返答データを生成し、当該返答データを携帯端末30に向けて送信する。携帯端末30は、宅内ネットワークTNを介して上記の返答データを受信(取得)すると、同データを解析して各センサ21、22a、22b、23a〜23cの測定結果を特定する。
以上の処理が実行される結果、ディスプレイとしてのタッチパネル31にエネルギー管理画面が描画されるようになり、エネルギー管理画面上には、上記の返答データが示す情報として、各センサ21、22a、22b、23a〜23cの測定結果が表示されるようになる。このようなエネルギー管理画面を通じて、ユーザは、各電力消費機器の電力消費量や住宅H内での電力需給バランスを視認することが可能になる。なお、上記の返答データは、携帯端末30がホームサーバ10と通信してタッチパネル31に表示する表示用データに相当する。
さらに、タッチパネル31にエネルギー管理画面が描画されている間、ユーザは、同画面に設けられた操作ボタン(例えば、図5中の操作ボタンB1〜B6)を、タッチパネル31を介して押す操作を行うことにより、操作ボタンが押された電力消費機器の運転状態を切り替えることが可能である。
具体的に説明すると、携帯端末30は、タッチパネル31を通じてユーザ操作(具体的には、操作ボタンB1〜B6を押す操作)を受け付けると、ホームサーバ10と通信し、住宅H内で使用されている電力消費機器のうち、上記ユーザ操作の対象となった機器(すなわち、運転状態が制御される機器であり、以下、制御対象機器という)の運転状態を制御する制御処理の実行要求を、ホームサーバ10に対して送信する。ホームサーバ10は、制御処理の実行要求を受け付けると、上記ユーザ操作に応じた制御信号を生成し、当該信号を制御対象機器に向けて発信する。そして、制御対象機器である電力消費機器が上記の制御信号を受信すると、当該制御信号に則って上記制御対象機器の運転状態が切り替わるようになる。
以上までに説明してきたように、ホームサーバ10を中核として、携帯端末30やロボット50を組み込んだ形でHEMS(すなわち、本システムS)が構築されている。
また、本実施形態では、HEMSを搭載した住宅Hが複数集合してコミュニティを形成しており、当該コミュニティ単位でエネルギー管理(電力監視)を行うシステム、すなわち、コミュニティエネルギーマネジメントシステム(CEMS)が構築されている。
そして、各住宅HのHEMSを統括するためのサーバとして、CEMSサーバ40が設けられている。CEMSサーバ40は、住宅H外(例えば、コミュニティの管理施設内)に設置された外部サーバであり、図3に示すように、インターネットからなる宅外ネットワークGNを介して、各住宅Hのホームサーバ10と通信可能に接続されている。また、CEMSサーバ40は、各住宅Hのホームサーバ10と通信して、各ホームサーバ10に対して、各住宅Hのユーザに向けた情報を示すデータを配信する。かかる意味で、CEMSサーバ40は、各住宅H内のユーザに提供する情報を示す提供情報データを送信する情報配信装置に相当するといえる。
CEMSサーバ40から配信する提供情報データとしては、商用電源4からコミュニティ内の各住宅Hに供給される電力の単価の現在値を示す単価データ、コミュニティ内の各住宅Hに対して節電を要求する節電要求データ、コミュニティが属する地域の天気に関する情報を示す天気データ、その他コミュニティに関して各住宅Hのユーザに通知すべき情報を示す通知データとが挙げられる。なお、上記の提供情報データは、あくまでも一例に過ぎず、上述した情報以外の情報を示すデータが含まれていることとしてもよい。
また、CEMSサーバ40からの提供情報データには、上記のデータ以外に、住宅H内で所定の期間中に消費される電力消費量の目標値を示す目標値データが含まれる。ここで、所定の期間とは、例えば、電力使用料金の徴収にあたって電力の総消費量を集計するのに設定された期間であり、通常、各月の所定日から翌月の所定日までの期間である。ただし、上記の期間の設定については、任意に設定することが可能であり、例えば、1日単位の期間であってもよく、あるいは、1年単位の期間であってもよい。
上述の目標値データについて説明すると、CEMSサーバ40が目標値データを送信する上で、予め、所定の期間中に消費される電力消費量の目標値が各住宅Hにて設定されており、当該目標値の設定結果をデータとしてCEMSサーバ40の記憶部(以下、CS側記憶部42という)に記憶しておく必要がある。
CEMSサーバ40側で電力消費量の目標値の設定結果を記憶しておく手順について説明すると、例えば、ホームサーバ10の入力装置12にてCEMSサーバ40のURLを入力する等して、ホームサーバ10のディスプレイ11に、上記の目標値を入力するための入力画面(不図示)を表示し、不図示のキーボード等を通じて目標値の入力を行う。この入力操作を受け付けたホームサーバ10では、入力操作の内容を示すデータを生成し、当該データをCEMSサーバ40に向けて送信する。一方、CEMSサーバ40は、入力操作の内容を示すデータを受信し、当該データに基づいて、ホームサーバ10側で入力された目標値を示すデータ(目標値データ)と、上記データの発信元を特定するために割り当てられた発信元IDを示すデータ(発信元IDデータ)とが生成される。最終的に、これらのデータは、互いに対応付けられた状態でCS側記憶部42に記憶される。
以上のような目標値を設定するために行われる一連の動作は、定期的に繰り返され、例えば、当該目標値が適用される期間の初日から数日前に相当する日に行われる。
なお、本実施形態では、ホームサーバ10側で目標値が設定され、当該目標値を示す目標値データがCEMSサーバ40側で管理(記憶)されることとしたが、目標値の設定がCEMSサーバ40側で行われることとしてもよい。例えば、CEMSサーバ40側で、住宅H内で所定期間(具体的には前年若しくは前月)に実際に消費された電力消費量を示すデータ(以下、実績電力消費量データ)を当該住宅Hのホームサーバ10から受信し、受信した実績電力消費データに基づいて目標値を自動的に設定することとしてもよい。
そして、CEMSサーバ40は、ホームサーバ10側からの目標データ送信要求を受け付けると、発信元IDデータに基づいて、当該要求の発信元であるホームサーバ10を特定した上で、CS側記憶部42に記憶されている目標値データのうち、特定したホームサーバ10に対応する目標値データを読み出して、同ホームサーバ10に向けて目標値データを送信する。
CEMSサーバ40から目標値データが送信されると、そのデータ送信を要求したホームサーバ10が、当該目標値データを受信する。また、ホームサーバ10は、目標値データの受信を契機として、スマートメータからなるセンサ21に対して、電力消費量の測定結果データの送信を要求する。ここで、センサ21から送信される測定結果データは、前述したように、住宅H内で消費された電力消費量の累積値に応じたものであり、より具体的に説明すると、所定の期間の開始時から現時点(厳密には、ホームサーバ10がセンサ21に測定結果データを要求した時点)までに住宅H内で実際に消費された電力消費量の累積値に応じたものである。
ホームサーバ10は、CEMSサーバ40からの目標値データ、及び、センサ21からの測定結果データを受信すると、目標値データから所定の期間における目標値(具体的には、現時点で適用されている目標値)を特定すると共に、測定結果データから上記累積値(具体的には、上記目標値が適用されている期間の開始時から現時点までに住宅H内で実際に消費された電力消費量の累積値)を特定する。その後、ホームサーバ10は、上記の目標値に対する、特定した累積値の割合を算出する。そして、ホームサーバ10は、算出した上記割合に応じた報知動作の実行を、上述したロボット50に対して要求する。
なお、本実施形態では、外部サーバとして、CEMSサーバ40を一例に挙げたが、インターネットに接続されたサーバのうち、CEMSサーバ40以外のサーバ、例えば、住宅Hの管理会社が保有するサーバ、HEMSを構築したシステム開発会社が保有するサーバ、アグリゲータが保有するサーバ、あるいは電力会社が保有するサーバが、上述の提供情報データを送信する外部サーバとして機能することとしてもよい。
<本実施形態に係る情報報知システムの各部の構成>
次に、以上までに説明してきた本システムS各部の構成(報知機器であるロボット50を除く)について、図4A、4B、4C及び図5を参照しながら、より詳細に説明する。
(1)ホームサーバ10について
本システムSの中核をなすホームサーバ10について、そのハードウェア構成を説明すると、図4Aに示すように、CPU10a、メモリ10b、不揮発性記憶装置10c、通信用インタフェース10d(図4A中、通信用I/Fと表記)、ディスプレイ11及び入力装置12を備え、これらの各要素はバス10eを介して接続されている。また、不揮発性記憶装置10cには各種プログラム(例えば、通信用プログラム、USBドライバ等)が格納されている。
一方、ホームサーバ10の構成を機能面から改めて説明すると、図4Bに示すように、外部データ取得部101、測定結果データ取得部102と、返答データ送信部103と、機器制御部104と、ロボット駆動部105とを有している。これらの各部は、前述したホームサーバ10を構成するハードウェア(すなわち、CPU10a、メモリ10b、不揮発性記憶装置10c、通信用インタフェース10d、ディスプレイ11)と、不揮発性記憶装置10cに格納された各種プログラムによって構成される。
外部データ取得部101は、宅外ネットワークGNを通じてCEMSサーバ40と通信することにより、CEMSサーバ40に対してデータ送信を要求し、CEMSサーバ40から送信されてくるデータ(提供情報データ)を受信するものである。受信された提供情報データは、メモリ10bに一時的に格納され、その後、不揮発性記憶装置10cに保存されるようになる。
測定結果データ取得部102は、宅内ネットワークTNを通じて、センサ21、22a、22b、23a〜23cに対して電力消費量の測定及び測定結果データの送信を命令し、当該測定結果データを受信するものである。この測定結果データ取得部102は、例えば、携帯端末30側でエネルギー管理プログラムが起動した際に携帯端末30から発せられるデータ送信要求を受信すると、各センサ21、22a、22b、23a〜23cとの通信を開始して測定結果データを取得する。また、測定結果データ取得部102は、CEMSサーバ40から目標値データを受信すると、これに連動して、スマートメータからなるセンサ21に対して測定結果データの送信を要求し、当該センサ21から、住宅H内で消費された電力消費量の累積値に応じた測定結果データを受信する。
返答データ送信部103は、測定結果データ取得部102が取得した取得した測定結果データに応じて返答データを生成し、当該返答データを携帯端末30に向けて送信するものである。返答データを受信した携帯端末30側では、当該返答データが解析される結果、各センサ21、22a、22b、23a〜23cの測定結果を表示したエネルギー管理画面がタッチパネル31に描画されるようになる。つまり、返答データとは、携帯端末30がホームサーバ10と通信してタッチパネル31に表示する情報を示す表示用データに相当する。そして、返答データが示す情報は、ホームサーバ10が示す情報と同様であり、具体的には、センサ21、22a、22b、23a〜23cの測定結果である。なお、本実施形態において返答データはXML形式のデータである。このため、返答データを受信した携帯端末30は、当該携帯端末30の仕様に応じた形式にて上記測定結果を表示することが可能になる。
機器制御部104は、住宅Hで使用されている電力消費機器のうち、制御対象となる機器と宅内ネットワークTNを通じて通信し、当該制御対象機器に向けて制御信号を発信するものである。この機器制御部104は、制御対象機器となる電力消費機器の運転状態を制御するためにユーザが行う操作に基づいて、制御信号を生成し、当該制御信号を制御対象機器に向けて発信するものである。ここで、制御対象機器の運転状態を制御するために行われるユーザ操作は、前述したように、携帯端末30がタッチパネル31を通じて受け付ける。ユーザ操作を受け付けた携帯端末30は、機器制御部104に対して、当該ユーザ操作の対象となった機器(すなわち、制御対象機器)について運転状態を制御する処理(制御処理)の実行を要求する。
そして、機器制御部104は、携帯端末30から送られた制御処理の実行要求を受信すると、上記ユーザ操作に応じた制御信号を生成し、制御対象機器に向けて制御信号を発信する。
また、本実施形態では、制御対象機器の運転状態を制御するために行われるユーザ操作がロボット50でも受け付けられる。すなわち、ユーザがロボット50に対して所定の動作(具体的には、後述する3回の握持操作)を行うと、ロボット50がホームサーバ10(具体的には、機器制御部104)に制御処理の実行要求を伝送する。そして、機器制御部104は、ロボット50から送られた制御処理の実行要求を受信すると、所定の制御対象機器に向けて制御信号を発信する。なお、上記のユーザ操作を受け付けるためにロボット50に備えられた機構(具体的には、操作受付機構55)については後述する。
さらに、機器制御部104は、制御信号を受信した制御対象機器において運転状態の制御が完了すると、当該制御対象機器から送信される信号(具体的には、制御対象機器側で運転状態の制御が完了したことを示す信号であり、以下、制御完了信号)を受信する。
ロボット駆動部105は、USBコネクタ50bを介してロボット50に電源を供給するとともに、ロボット50に対して、報知動作の実行要求を発信するものである。具体的に説明すると、このロボット駆動部105は、ホームサーバ10のCPU10a、メモリ10b、不揮発性記憶装置10c及びUSBポート(不図示)と、不揮発性記憶装置10cに格納されたロボット用ドライバ205及びUSBドライバ206(例えば、図4C参照)との協働によって構成される。
そして、本実施形態に係るロボット駆動部105は、外部データ取得部101がCEMSサーバ40からのデータ(提供情報データ)を受信すると、USB回路を通じて、そのデータに応じた報知動作の実行要求をロボット50に対して送信する。
また、本実施形態では、外部データ取得部101がCEMSサーバ40から目標値データを取得し、測定結果データ取得部102がセンサ21から測定結果データを受信すると、ロボット駆動部105が、これらのデータに基づいて、所定の期間における目標値と、所定の期間中に住宅H内で実際に消費された電力消費量の累積値を特定する。そして、ロボット駆動部105は、上記目標値に対する上記累積値の割合を算出した上で、算出した当該割合に応じた報知動作の実行要求を、ロボット50に対してUSB回路を通じて送信する。
以上のように、ロボット駆動部105は、測定結果データ及び提供情報データ等、ホームサーバ10が通信先から受信した受信データに基づいて、報知動作の実行要求をロボット50に対して送信する。
また、本実施形態では、機器制御部104が上記の制御完了信号を受信すると、ロボット駆動部105が、制御完了信号に則った報知動作の実行要求をロボット50に対して送信する。さらに、本実施形態では、住宅H内で消費される電力消費量を測定するセンサ21が、住宅Hにおける瞬間消費電力が所定の大きさ以上になったことを知らせるための報告データを送信する。この報告データがホームサーバ10側(例えば、測定結果データ取得部102)に受信されると、ロボット駆動部105が、報告データに則った報知動作の実行要求をロボット50に対して送信する。
以上までに説明してきた機能を搭載したホームサーバ10は、さらに、宅内ネットワークTNを通じて通信することが可能な機器(通信対象機器)の種類に応じて通信方式を切り替え、各通信対象機器に対応した通信方式にて通信する機能を実装している。例えば、上述した機器制御部104が、住宅H内の電力消費機器のうち、第1規格機器に属する機器を制御する際には、第1規格機器に対応した通信方式を採用し、その後に、第2規格機器に属する機器を制御する際には、第2規格機器に対応した通信方式に切り替える。
上述したホームサーバ10の機能、すなわち通信対象機器に対応した通信方式にて通信する機能は、図4Cに図示されたホームサーバ10の実行環境によって実現される。具体的に説明すると、ホームサーバ10は、OS201と、JAVA(登録商標)仮想マシン(以下、JVM)202と、OSGi(Open Services Gataway initiative)フレームワーク203と、OSGiフレームワーク203上で動作するソフトウェア(以下、バンドルとも言う)とを備える。
OSGiフレームワーク203は、JVM202上に構築され、OSGiフレームワーク203上で動作するバンドルのダウンロード、インストール、起動、停止などのライフサイクルを管理する。そして、OSGiフレームワーク203上で動作するバンドルについては、動的に入れ替えることが可能であり、また、複数のバンドルを並列的に実行することが可能である。
OSGiフレームワーク203上で動作するバンドルには、標準バンドルと、アプリケーションバンドルとがある。標準バンドルとは、HTTP(Hypertext Transfer Protocol)やUPnP(Universal Plug and Play)等の基本的なプロトコルをバンドル化したものである。アプリケーションバンドルとは、OSGiフレームワーク203に登録されたアプリケーションソフトであり、このアプリケーションバンドルの中には、第1規格機器用通信バンドル204a、第2規格機器用通信バンドル204b、第3規格機器用通信バンドル204cが含まれている。第1規格機器用通信バンドル204aとは、第1規格機器に対応した通信方式にて第1規格機器と通信するためのアプリケーションである。同様に、第2規格機器用通信バンドル204bとは、第2規格機器に対応した通信方式にて第2規格機器と通信するためのアプリケーションであり、第3規格機器用通信バンドル204cとは、第3規格機器に対応した通信方式にて第3規格機器と通信するためのアプリケーションである。
そして、上記3つの通信バンドル204a、204b、204cがCPU10aによって実行されることにより、ホームサーバ10は、通信対象機器と対応した通信方式にて通信する。なお、新たな通信方式を採用した機器が住宅H内に導入された場合、当該導入機器に対応した通信方式にて当該導入機器と通信するためのアプリケーションソフトをOSGiフレームワーク203に登録すればよい。これにより、新たな通信方式を採用した機器が住宅H内に導入された場合であっても、ホームサーバ10は、当該新たな通信方式にて通信するためのバンドル(具体的には、登録したアプリケーションソフト)を選択することにより、上記の機器と通信することが可能になる。
なお、OSGiフレームワーク203上で動作するバンドルの中には、前述したロボット用ドライバ205が含まれている(図4C参照)。
また、OSGiフレームワーク203の、動的にバンドルを入れ替える機能により、ホームサーバ10と通信する通信対象機器に応じて、実行される通信バンドルが入れ替われるようになる。換言すると、通信バンドルの入れ替えにより、ホームサーバ10が採用する通信方式が切り替わるようになる。さらに、OSGiフレームワーク203に各通信バンドルが登録されると、各通信バンドルの機能を利用するためのインタフェースが、レジストリ(サービスレジストリ)に登録される。その上で、OSGiフレームワーク203は、これらのインタフェースを統合したものを、Application Program Interface(以下、汎用APIという)として提供する。
汎用APIは、ホームサーバ10以外の機器で実行されるプログラム(例えば、携帯端末30で実行されるプログラム)で利用され、当該プログラムの実行中に、上述の通信バンドル204a、204b、204cの起動や入れ替えを実施するための関数である。また、汎用APIは、公開され、ホームサーバ10以外の機器で実行されるプログラム(例えば、携帯端末30で実行されるプログラム)の開発に供される。つまり、プログラムを開発する際に汎用APIを利用すれば、プログラム開発者側で通信対象機器間の通信方式の違いを意識する必要はなく、ホームサーバ10のURI等、汎用APIを利用(リクエスト)するための情報(コード)を用いることで、ホームサーバ10に、通信対象機器に対応した通信方式にて通信を行わせることが可能になる。
以上のように、本実施形態では、通信バンドルの違い(通信対象機器が採用する通信方式の違い)を吸収する仕組みとして、上記の汎用APIがホームサーバ10に実装されている。また、汎用APIは、公開されており、例えば、住宅H内の電力消費機器の運転状態を制御するために携帯端末30に搭載するプログラムを開発する際に、当該プログラム中に汎用APIを利用するための情報が組み込まれる。このように汎用APIを利用するための情報を組み込むだけで、ホームサーバ10に対して、通信対象機器に対応した通信方式による通信の実行を要求することができるプログラムを開発することができる結果、プログラム開発が容易になる。このため、プログラム開発者にとって、プログラム開発の自由度が向上し、ユーザのニーズに応え得るプログラムをより容易に開発することができるようになる。
なお、汎用APIを利用するための情報とは、REST(Representational State Transfer)に則ってホームサーバ10と通信対象機器との間の通信の実行を要求するための情報(コード)である。ここで、通信実行を要求する側の機器(具体的には、例えば携帯端末30)からホームサーバ10に対して、通信実行要求を送信する際に適用される通信プロトコルは、HTTPである。よって、ホームサーバ10に対して送信する通信実行要求の中には、ホームサーバ10のURI(アドレス)等が含まれることになる。
(2)携帯端末30について
携帯端末30は、上述したように、宅内ネットワークTNを介してホームサーバ10と通信可能に接続された情報処理端末であり、不図示のCPU、メモリ、通信用インタフェース等により構成され、エネルギー管理プログラムと機器制御プログラムが搭載されている。エネルギー管理プログラムは、ホームサーバ10に対して、センサ21、22a、22b、23a〜23cの測定結果に関するデータ送信を要求するとともに、ホームサーバ10から送信される返答データを受信して当該返答データを解析し、展開するためのプログラムである。
そして、上記のエネルギー管理プログラムが実行されることにより、図5に図示されたエネルギー管理画面がタッチパネル31に描画されるようになり、エネルギー管理画面上には、各センサ21、22a、22b、23a〜23cの測定結果が表示されるようになる。このようなエネルギー管理画面を通じて、ユーザは、各電力消費機器の電力消費量や住宅H内での電力需給バランスを視認することが可能になる。
機器制御プログラムは、ユーザが上記エネルギー管理画面を通じて行う電力消費機器の運転状態を制御するための操作(具体的には、エネルギー管理画面の操作ボタンB1〜B6を押す操作)に基づき、制御対象機器の運転状態を制御する制御処理の実行要求を、ホームサーバ10に対して送信するためのプログラムである。この機器制御プログラムは、前述したように、汎用APIを利用するための情報を組み込んでおり、機器制御プログラムが制御処理の実行を要求するために生成し送信するデータの中には、通信対象機器に対応した通信方式による通信の実行をホームサーバ10に対して要求するためのデータが含まれるようになる。なお、本実施形態において、機器制御プログラムはエネルギー管理プログラムの起動に連動して起動し、その後、上記のユーザ操作が行われるまでの間は待受状態となる。
ここで、エネルギー管理画面について説明すると、図5に示すように、住宅H内における電力需給バランスを示す項目を表示したものである。具体的に説明すると、エネルギー管理画面上には、複数(図5に示す例では6つ)の表示領域Ar1〜Ar6が設けられており、表示領域Ar1には発電ユニット1による発電量を示す値が、表示領域Ar2には商用電源4からの受電量(買電量)を示す値が、表示領域Ar3には蓄電池3の蓄電量を示す値が、それぞれ表示されている。
また、表示領域Ar4には、住宅H内における電力の総消費量を示す値が表示されており、具体的には、所定期間(より具体的には、今月)の開始時から現時点までに住宅H内で実際に消費された電力消費量の累積値が表示される。なお、表示領域Ar4には、所定期間(より具体的には、今月)において住宅H内で消費される電力消費量の目標値が併せて表示される。
また、表示領域Ar5,Ar6については、住宅H内で使用される電力消費機器のうち、主要な機器(例えば、使用頻度の高い機器)に対して割り当てられており、図5に示す例では、エアコン7aに対して表示領域Ar5が、照明7bに対して表示領域Ar6が、それぞれ割り当てられている。
電力消費機器に対して割り当てられた表示領域Ar5,Ar6には、それぞれ、当該電力消費機器の消費電力を示す値のほか、操作ボタンB1〜B6が表示されている。操作ボタンB1〜B6について説明すると、操作ボタンB1,B2,B4,B5は、対応する機器の発停(オンオフ)を切り替えるためのボタンであり、中に「ON」と表記された操作ボタンB1,B4は、対応する機器を作動状態(オン状態)にするためのボタンであり、中に「OFF」と表記された操作ボタンB2,B5は、対応する機器を停止状態(オフ状態)にするためのボタンである。
なお、各機器の発停(オンオフ)状態については、それぞれに対応している表示領域Ar5、Ar6にて確認可能となっている。具体的に説明すると、作動状態の機器については、「ON」と表記された操作ボタンB1,B4が点灯し、停止状態の機器については、「OFF」と表記された操作ボタンB2,B5が点灯する。例えば、図5に図示されたケースにおいては、エアコン7a及び照明7bが作動状態にあることが確認できる。
操作ボタンB3,B6は、対応する機器の運転状態の詳細設定を行うためのボタンであり、当該操作ボタンB3,B6を押すと、不図示の詳細設定画面がポップアップ形式でエネルギー管理画面上に重ねて描画されるようになる。そして、この詳細設定画面を通じて、ユーザは、例えば、冷房や暖房等の運転モード、設定温度などの運転管理値を設定し、制御対象機器の運転状態を制御することが可能になる。
以上のような操作ボタンB1〜B6が設けられていることにより、ユーザは、制御対象機器の運転状態を制御するための操作をすることが可能である。つまり、ユーザが操作ボタンB1〜B6を押すことにより、当該操作の対象となった電力消費機器を制御対象機器として制御処理を実行するように、携帯端末30からホームサーバ10に向けて制御処理の実行要求が送信される。当該実行要求を受信したホームサーバ10側では、上記の操作(より具体的には、操作ボタンB1〜B6のうち、ユーザにより押されたボタン)に基づいて、当該操作に応じた制御信号を生成して制御対象機器に向けて発信するようになる。
なお、当然ながら、タッチパネル31上にエネルギー管理画面を描画する際、携帯端末30の状態は、通電状態になっている。すなわち、携帯端末30は、ディスプレイとしてのタッチパネル31に、ホームサーバ10からの返答データが示す情報(より具体的には、エネルギー表示画面に表示される各センサ21、22a、22b、23a〜23cの測定結果)を表示する際に、通電状態となって電力を消費するようになる。
(3)CEMSサーバ40について
CEMSサーバ40は、不図示のCPU、メモリ、通信用インタフェース等により構成され、宅外ネットワークGNを通じてホームサーバ10(具体的には、外部データ取得部101)からのデータ送信要求を受け付けて、ホームサーバ10に向けてデータ(提供情報データ)を送信する。
提供情報データには、前述したように、商用電源4からの供給電力の単価の現在値を示す単価データ、各住宅Hに対して節電を要求する節電要求データ、コミュニティが属する地域の天気に関する情報を示す天気データ、各住宅Hのユーザに通知すべき情報を示す通知データ、及び、住宅H内で所定の期間中に消費される電力消費量の目標値を示す目標値データが含まれている。なお、各住宅Hのユーザに通知すべき情報を示す通知データとしては、例えば、上記の目標値が未だ設定されていないことを知らせる情報や、各住宅Hでの電力消費量の削減量についてコミュニティ内で順位付けした情報(以下、省エネランキング)が挙げられる。
これらの提供情報データは、HDD等の補助記憶装置からなるCS側記憶部42に格納されており、ホームサーバ10からのデータ送信要求の内容に応じて送信すべきデータが読み出され、その後、ホームサーバ10に向けて送信される。
<<本実施形態のエネルギー管理システムの特徴>>
本システムSでは、宅内ネットワークTNを介してホームサーバ10が各電力消費機器やセンサ21、22a、22b、23a〜23cと通信することにより、各電力消費機器の監視及び制御が一元的に行われる。また、ホームサーバ10から送信されるデータ(具体的には、上述の返答データ)に基づいて、携帯端末30のタッチパネル31にエネルギー管理画面を描画して、当該画面上に各センサ21、22a、22b、23a〜23cの測定結果が表示される。これにより、住宅H内での電力需給バランスを視覚化(見える化)することが可能となり、ユーザは、上記のエネルギー管理画面を見て、住宅H内での電力需給バランスを視認することが可能になる。
しかしながら、発明が解決しようとする課題の項で説明したように、ユーザが上記のエネルギー管理画面を見る上で、携帯端末30を起動させるための操作を行う等の手間を要することになる。かかる手間を要する結果、住宅H内での電力需給の状況を確認することがユーザにとって面倒なものとなり、省エネルギー行動を促し難くなってしまう。一方で、携帯端末30を起動させたままで常時通電状態とすると、携帯端末30において無駄に電力を消費してしまうことになる。
以上の事態に鑑みて、本システムSでは、電力消費機器の制御や住宅H内での電力需給状況の監視を行う際のインタフェースとして、携帯端末30の他に、報知機器であるロボット50が設けられている。このロボット50により、ユーザは、住宅H内での電力需給バランスに関する情報をはじめ、諸処の情報をより簡易的な方法により入手することが可能になる。そして、本実施形態に係るロボット50は、報知する情報が複数種類ある場合(すなわち、報知する情報が多様化した場合)にも対応することが可能なものである。
以下、図6〜図14を参照しながら、本実施形態に係るロボット50の構成例及び動作例について説明する。
<ロボット50の構成例について>
以下では、本実施形態に係るロボット50の構成例について説明する。
ロボット50の構成例について説明するにあたり、ロボット50が備える機能について概説すると、ロボット50は、ホームサーバ10(具体的には、ロボット駆動部105)から送信される実行要求を受信して、所定の報知動作を実行する。報知動作の実行を要求するためにロボット50に送信される信号は、ホームサーバ10がセンサ21、22a、22b、23a〜23cやCEMSサーバ40と通信してデータを受信すると、その受信データに基づいてロボット駆動部105により生成される。
一方で、ロボット50は、報知動作の実行要求を受信すると、当該要求を解析し、その解析結果に応じた情報をユーザに知らせるべく報知動作を実行する。ここで、報知動作の実行要求は、上述したように、ホームサーバ10がセンサ21、22a、22b、23a〜23cやCEMSサーバ40から受信した受信データに基づいてなされ、ユーザに報知すべき情報も上記受信データが示す内容となる。したがって、ロボット50は、ホームサーバ10の受信データに基づき、受信データに応じた報知動作を実行することになる。
そして、本実施形態に係るロボット50は、前述したように、報知動作として、報知する情報(換言すると、上記の受信データ。以下、同じ)に応じた発光形式にて発光する発光動作、報知する情報に応じた音声を発する音声発生動作、報知する情報に応じて振動する振動動作を選択して実行する。
上記3種類の報知動作を実行するために、ロボット50は、図6に示すように、発光機構51、音声発生機構52と、振動機構53とを有している。さらに、ロボット50は、これらの機構51,52,53を制御する制御部としてのコントローラ54を有している。なお、上述したロボット50の各部(すなわち、発光機構51、音声発生機構52、振動機構53及びコントローラ54)は、ロボット50内部、具体的には不図示のフレームに取り付けられ、さらに当該フレームは、透光性を有するゴム製のカバー部材50aに覆われている。このカバー部材50aは、ロボット50の外観形状を規定しており、ユーザが握持すると押し潰れるように弾性変形する(図7の(D)参照)。
発光機構51は、報知する情報(受信データ)に応じた発光形式にて発光する発光動作を実行するものである。この発光機構51は、LED素子等の公知の発光機器(光源)により構成されている。そして、発光機構51が発光動作を行うと、その光がカバー部材50aを透過する結果、図7の(A)に示すようにロボット50全体が発行するようになる。
ここで、発光機構51が発行動作を行う際の発光形式とは、発光動作の実行条件を示す概念であり、具体的には、発光色、発光強度(照度)、発光モード(点灯又は点滅の選択)、点滅速度等が挙げられる。そして、発光機構51は、報知する情報のカテゴリや内容に応じて、発光形式を切り替え、本実施形態では、発光色、発光モード、点滅速度を切り替えることとしている。
音声発生機構52は、報知する情報(受信データ)に応じた音声を発する音声発生動作を実行するものである。この音声発生機構52は、小型デジタルオーディオプレイヤー等の公知の音声再生装置により構成されており、複数の音声ファイルが記憶されたメモリ(不図示)が内蔵されている。そして、音声発生機構52は、上記のメモリに記憶された複数の音声ファイルの中から、報知する情報に対応した音声ファイルを再生する。これにより、図7の(B)に示すように、スピーカ(不図示)から上記音声ファイルに収録された音声が発せられるようになる。なお、本実施形態に係る音声発生機構52は、電子データからなる音声ファイルを再生するものであるが、これに限定されるものではなく、例えば、テープやコンパクトディスク等に収録された音声を再生するものであることとしてもよい。
振動機構53は、報知する情報(受信データ)に応じて振動する振動動作を実行するものである。この振動機構53は、バイブレータ等の公知の振動付与機器により構成されており、振動動作を実行すると図7の(C)に示すようにロボット50全体が振動するようになる。なお、振動動作は、ロボット50により所定の情報が報知されているのをユーザに気付かせるために実行され、本実施形態では、ロボット50が報知するすべての情報に対して振動動作が実行される。つまり、本実施形態に係るロボット50は、ユーザに情報を報知するにあたって、ユーザの注意を引くために先ず振動動作を実行することになる。
コントローラ54は、図6に示すように、CPU54a、メモリ54b、通信用インタフェース54c、制御回路54d等により構成されており、USBコネクタ50bがホームサーバ10のUSBポートに接続された状態でUSB回路を介してホームサーバ10(具体的には、ロボット駆動部105)との間でデータの送受信を行う。
なお、本実施形態では、上述したように、ロボット50用の電源がホームサーバ10の電源と連動しており、ホームサーバ10が通電状態でいる間、USB回路を介してホームサーバ10側からロボット50に電力が供給される。ホームサーバ10は、住宅H内の電力需給状況の監視及び制御を行う観点から常時通電状態となっているので、ロボット50についても常時通電状態となっている。一方、ロボット50が報知動作を実行する際、ロボット50の状態は通電状態となっている。つまり、本実施形態においてロボット50は、常時、報知動作を実行することが可能な状態にあり、ホームサーバ10から報知動作の実行要求があった際には直ちに応答して報知動作を実行する。ただし、上記の構成に限定されるものではなく、ロボット50の状態をタイマー制御により切り替え、通常は通電状態とする一方で、所定の時間帯(例えば、夜間)には非通電状態(電源オフ状態)とすることとしてもよい。
また、本実施形態では、通電状態にあるロボット50が消費する電力(単位時間あたりに消費する電力であり、以下に同じ。)は、通電状態にある携帯端末30が消費する電力と比較して小さくなっている。つまり、携帯端末30を常時通電状態とする場合の電力消費量に比して、ロボット50を常時通電状態とする場合の電力消費量の方が幾分小さい。
コントローラ54は、ホームサーバ10から報知動作の実行要求を受信すると、当該実行要求に応じて、発光機構51による発光動作、音声発生機構52による音声発生動作、及び振動機構53による振動動作のうち、少なくとも一つ以上の動作を報知動作として実行させる。
より具体的に説明すると、コントローラ54は、ホームサーバ10から報知動作の実行要求を受信すると、当該実行要求を解析して、報知すべき情報(すなわち、報知動作を通じてユーザを知らせる情報)のカテゴリを特定する。換言すると、ホームサーバ10から送信される実行要求には、報知すべき情報のカテゴリを示すデータが埋め込まれており、当該データによりコントローラ54はカテゴリを特定する。報知すべき情報のカテゴリを特定した後、コントローラ54は、発光動作、音声発生動作及び振動動作の中から、上記のカテゴリに対応した動作を選択し、選択した動作を報知動作として実行させる。
本実施形態において、報知すべき情報のカテゴリとしては、「系統電力の単価の現在値」、「節電要求」、「コミュニティが属する地域の天気」、「目標値未設定」、「省エネランキング」が挙げられる。
さらに、報知すべき情報のカテゴリの中には、上述したカテゴリの他に、所定の期間における目標値に対する、同期間中に住宅H内で実際に消費された電力消費量の累積値の割合を算出した際の算出結果(以下、「割合の算出結果」という)、制御対象機器となった電力消費機器の運転状態の制御が完了したことを知らせる情報(以下、「制御完了」という)、及び、住宅Hにおける瞬間消費電力が所定の大きさ以上になるまで増大したことを報告する情報(以下、「瞬間消費電力増大」という)が含まれる。
そして、報知すべき情報のカテゴリと報知動作として実行される動作との対応関係については、テーブル化されてメモリ54bに記憶されている。コントローラ54(より具体的には、CPU54a)は、当該テーブルを参照することにより、報知すべき情報のカテゴリに対応した動作を特定し、特定した動作を報知動作として実行させる。なお、本実施形態では、報知すべき情報のカテゴリと報知動作として実行される動作との対応関係が下記の通りになっている。
・カテゴリ「系統電力の単価の現在値」:発光動作、音声発生動作、振動動作
・カテゴリ「節電要求」:音声発生動作、振動動作
・カテゴリ「地域の天気」:音声発生動作、振動動作
・カテゴリ「目標値未設定」:音声発生動作、振動動作
・カテゴリ「省エネランキング」:音声発生動作、振動動作
・カテゴリ「割合の算出結果」:発光動作、振動動作
・カテゴリ「制御完了」:音声発生動作、振動動作
・カテゴリ「瞬間消費電力増大」:発光動作、振動動作
さらに、コントローラ54は、ホームサーバ10から受信した報知動作の実行要求を解析して、報知すべき情報の内容を特定する。換言すると、ホームサーバ10から送信される実行要求には、報知すべき情報の内容を示すデータが組み込まれており、当該データによりコントローラ54は情報の内容を特定する。ここで、報知すべき情報の内容とは、上述したカテゴリの各々について現在の状態を示す概念であり、例えば、「地域の天気」というカテゴリの情報の場合、「晴れ」、「曇り」、「雨」が内容に相当する。報知すべき情報の内容を特定した後、コントローラ54は、発光動作、音声発生動作及び振動動作のうち、上述したカテゴリに対応した動作を、特定した情報の内容に対応した形式で実行する。
具体的に説明すると、報知動作として発光動作が実行される場合、特定した情報の内容に対応した発光形式にて発光動作が実行される。ここで、情報内容と発光形式との対応関係は、図8に示すようにテーブル化されてメモリ54bに記憶されており、コントローラ54は、当該テーブルを参照することにより、特定した情報の内容に対応した発光形式にて発光動作を実行させる。
より具体的に説明すると、例えば、報知すべき情報のカテゴリが「割合の算出結果」である場合、発光機構51は、所定の発光色にて発光動作を実行することになり、その発光色は、図8中、番号(1)のテーブルに記載された対応関係に基づいて定められる。例えば、上記の割合が50%未満の場合は、発光色が水色となり、51〜70%の範囲にある場合は、発光色が青色となる。
また、報知すべき情報のカテゴリが「瞬間消費電力増大」である場合、発光機構51は、図8中、番号(2)のテーブルに示すように、発光色を変化させながら発光動作を実行することになる。
さらに、報知すべき情報のカテゴリが「系統電力の単価の現在値」である場合、発光機構51は、点滅モードで発光動作を実行することになり、その点滅速度(点滅間隔)は、図8中、番号(3)のテーブルに記載された対応関係に基づいて定められる。例えば、単価の現在値が標準料金の0.5倍以下である場合は、10sec間隔で点滅し、0.6倍〜0.8倍の範囲にある場合には、8sec間隔で点滅する。
一方、報知動作として音声発生動作が実行される場合、特定した情報内容に対応した音声ファイルが再生されて、当該ファイルに収録された音声が発せられる。ここで、情報内容と音声(換言すると、音声ファイル)との対応関係については、図9に示すようにテーブル化されてメモリ54bに記憶されており、コントローラ54は、当該テーブルを参照することにより、特定した情報内容に対応した音声を発する音声発生動作を実行させる。
より具体的に説明すると、例えば、報知すべき情報のカテゴリが「節電要求」である場合、コントローラ54は、音声発生機構52に、「セツデンセツデン」という音声が収録された音声ファイルを再生させる。
また、報知すべき情報のカテゴリが「系統電力の単価の現在値」である場合、コントローラ54は、同カテゴリについて前回報知動作を行った際の単価と比較して、単価の現在値が下がっている場合には、音声発生機構52に、「リョウキンガヤスクナッタヨ」という音声が収録された音声ファイルを再生させ、上がった場合には、「リョウキンガタカクナッタヨ」という音声が収録された音声ファイルを再生させる。
また、報知すべき情報のカテゴリが「制御完了」である場合には、コントローラ54は音声発生機構52に、「セイギョシタヨ」という音声が収録された音声ファイルを再生させ、報知すべき情報のカテゴリが「目標値未設定」である場合には、「モクヒョウヲイレテネ」という音声が収録された音声ファイルを再生させる。
さらに、報知すべき情報のカテゴリが「省エネランキング」である場合、コントローラ54は、同カテゴリについて前回報知動作を行った際の順位と比較して順位が上がった場合には、音声発生機構52に、「ランクアップ」という音声が収録された音声ファイルを再生させ、順位が下がった場合には「ランクダウン」という音声が収録された音声ファイルを再生させ、順位に変動がない場合には「ランクカワラズ」という音声が収録された音声ファイルを再生させる。
また、報知すべき情報のカテゴリが「地域の天気」である場合には、コントローラ54は、当該地域における当日の天気が晴れの場合には、「キョウハハレルヨ」という音声が収録された音声ファイルを再生させ、曇りの場合には、「キョウハクモリダヨ」という音声が収録された音声ファイルを再生させ、雨の場合には、「キョウハアメガフルカモ」という音声が収録された音声ファイルを再生させる。
ところで、本実施形態において、振動動作は、報知すべき情報のカテゴリ及び内容にかかわらず同一の形式(例えば、同一の振動時間)で実行されることになっている。ただし、これに限定されるものではなく、報知すべき情報のカテゴリ及び内容に応じて、振動動作の実行形式を変えることとしてもよい。
以上までに説明してきたように、本実施形態に係るロボット50は、ホームサーバ10からの実行要求を受信すると自動的に報知動作を実行する。これにより、ロボット50は、ユーザに対して、住宅H内の電力需給状況に関する情報を含む諸処の情報を報知する。ユーザの立場から考えると、ロボット50の報知動作によって、多様な情報が特に操作を要することなく自動的に報知されるので、ユーザは、手軽に情報を入手することが可能となる。すなわち、本実施形態に係るロボット50により、ユーザに対して特に操作を要することなく、簡易的な方法にて情報を報知することが可能となる。
このように本実施形態ではユーザに対して特に操作を要することなく情報が報知されるので、ユーザに対して「気付き」をより容易に与えることができ、ユーザが自己のエネルギー消費行動を見直すきっかけを提供し易くなる。
また、本実施形態に係るロボット50は、上述した3種類の報知動作を実行し、更に発光動作及び音声発生動作については、報知すべき情報のカテゴリや内容に応じて複数の実行パターンが用意されている。実行パターンとは、発光動作時の発光形式(本実施形態では、発光色、発光モード、点滅速度)や、音声発生動作時に発生される音声の内容のことである。
そして、報知すべき情報に応じて、実行する報知動作の種類や実行パターンを切り替えれば、報知すべき情報が多様化したとしても(換言すると、報知する情報の種類が複数種となったであっても)、十分に対応することが可能となる。
さらに、例えば、発光動作時の発光色、発光モード、点滅速度等を切り替えることで、同時に複数の情報を報知することも可能となり、具体的に説明すると、発光色と点滅速度を切り替えることで、カテゴリ「割合の算出結果」に関する情報と、カテゴリ「系統電力の単価の現在値」に関する情報を同時に報知することが可能となる。
また、本システムSでは、ユーザが住宅H内の電力需給状況に関する情報を確認するための機器として、携帯端末30とロボット50とが併用されている。これにより、ロボット50を設けたことによる効果(有効性)がより一層高まることになる。
具体的に説明すると、携帯端末30は、ロボット50と比較してより多くの情報を提供することができるものの、ユーザに対して起動操作等の手間を要する。これに対し、ロボット50は、起動操作等を要さずに簡易的にユーザに対して情報を報知することが可能であるので、ユーザにとって有用なものとなり、その効果は、ロボット50が単独で設けられている場合(すなわち、携帯端末30が併用されていない場合)に比べて、より有意義なものとなる。
さらに、上述したように、通電状態にあるロボット50が消費する電力は、通電状態にある携帯端末30が消費する電力と比較して小さくなっているので、携帯端末30を常時通電状態とする場合の電力消費量に比して、ロボット50を常時通電状態とする場合の電力消費量の方が幾分小さくなる。すなわち、ユーザが住宅H内の電力需給状況に関する情報として簡単な内容の情報を希望するのであれば、携帯端末30を常時通電状態とするよりも、ロボット50を常時通電状態としていた方が幾分経済的で、電力消費量をより少なくすることができる。したがって、ユーザが住宅H内の電力需給状況に関して情報を入手する上で、ロボット50を常時通電状態としておき、ロボット50の報知動作を通じて簡易的な情報を得た上で、更に詳細な情報を確認したい場合に携帯端末30を起動することとすれば、電力消費量を考慮して好適なエネルギー管理行動を実現することが可能になる。
ところで、本実施形態に係るロボット50は、以上までに説明してきた報知動作を実行するための構成を備えている一方で、ユーザが電力消費機器の運転状態を制御する際に行う操作を受け付ける機能を搭載している。すなわち、本実施形態において、ユーザは、電力消費機器の運転状態を制御する際に行う操作を、携帯端末30のタッチパネル31に描画されたエネルギー管理画面を通じて行うことができる他、ロボット50を通じて行うことが可能である。
電力消費機器の運転状態を制御する際に行われるユーザ操作を受け付けるためにロボット50に備えられた構成について説明すると、ロボット50には、図6に示すように、操作受付機構55が備えられている。この操作受付機構55は、ユーザが電力消費機器の運転状態を制御する際に行う操作を受け付けるものであり、本実施形態では、ロボット50内部に存するフレームとこれを覆うカバー部材50aとの間に配置された圧力センサ等の公知の操作受付機構により構成される。
操作受付機構55についてより詳しく説明すると、ユーザが図7の(D)に示すようにロボット50(厳密には、操作受付機構55が設置された箇所の近傍)を押し潰すように握持する動作(以下、握持操作という)を行うと、圧力センサからなる操作受付機構55は、その握持操作を受け付ける。かかる握持操作は、ユーザが電力消費機器の運転状態を制御する際に行う操作に相当する。
そして、操作受付機構55は、握持操作を受け付けると信号を生成し、当該信号をコントローラ54に伝送する。コントローラ54は、操作受付機構55から送られた信号を受信すると、当該信号に基づき(換言すると、操作受付機構55が受け付けた握持操作に基づき)、電力消費機器の運転状態を制御する制御処理の実行要求をホームサーバ10に対して送信する。ホームサーバ10(より具体的には、前述の機器制御部104)は、ロボット50側から制御処理の実行要求を受信すると、制御信号を生成し、住宅H内の電力消費機器のうち、制御対象機器である電力消費機器に向けて制御信号を発信する。
以上のように、本実施形態に係るロボット50は、上述の報知動作を実行する機能の他、制御対象機器である電力消費機器の運転状態を遠隔制御する機能(リモコン機能)をも備えている。この結果、情報の報知機器であるロボット50がユーザにとって使い勝手の良いものとなり、ロボット50の利便性が向上することになる。
なお、本実施形態では、ホームサーバ10がロボット50側から制御処理の実行要求を受信した場合、ホームサーバ10の機器制御部104は、住宅H内の電力消費機器のうち、常時運転させる必要がある機器(例えば、ホームサーバ10や冷蔵庫等)を除き、全てを制御対象機器として、制御信号を生成し発信することとし、具体的には、各制御対象機器の電源をオフ状態とするような制御信号を生成し発信する。ただし、これに限定されるものではなく、住宅H内の電力消費機器のうち、特にユーザが指定した機器のみを制御対象機器として制御信号を生成し送信することとしてもよい。
また、本実施形態では、操作受付機構55が握持操作を複数回繰り返して受け付けたとき(正確には、所定の時間内に複数回の握持操作を受け付けた場合)に、コントローラ54がホームサーバ10に対して制御処理の実行要求を送信することとしている。
具体的に説明すると、図10に示すように、握持操作の実施回数(換言すると、操作受付機構55が握持操作を受け付けた回数)に応じて、ロボット50における応答動作が異なり、握持操作の実施回数が3回である場合に限り、コントローラ54が、制御処理の実行要求をホームサーバ10に対して送信することとしている。これにより、ロボット50を用いた電力消費機器の遠隔制御が誤って行われてしまうこと(誤操作)を防止することが可能になる。
つまり、ユーザ等が意図せずに握持操作を行った場合に、コントローラ54がその握持操作に基づいて制御処理の実行要求をホームサーバ10に対して送信してしまうと、ユーザの意に反して電力消費機器の運転状態が切り替わってしまう。これに対して、本実施形態では、制御処理の実行要求が送信されるための握持操作の実施回数が3回に設定されているので、ユーザ等が誤って握持操作を1、2回行ったとしても、ユーザの意に反して制御処理の実行要求がロボット50から送信されるのを回避することが可能になる。
以下、握持操作の実施回数とロボット50における応答動作との対応関係について、より具体的に説明する。
先ず、所定時間内に1回のみ握持操作を受け付けた場合には、操作受付機構55が1回の握持操作を受け付けたことを示す信号を生成し、コントローラ54に伝送する。当該信号を受信したコントローラ54は、ホームサーバ10の外部データ取得部101に対して、CEMSサーバ40との通信の実行を要求し、これにより、外部データ取得部101が、CEMSサーバ40に対してデータ送信を要求して、CEMSサーバ40から提供情報データを取得する。そして、ホームサーバ10のロボット駆動部105が、取得した提供情報データに応じた報知動作の実行要求をロボット50に対して送信すると、ロボット50側では、コントローラ54が発光動作、音声発生動作及び振動動作の中から、上記提供情報データに対応した動作を報知動作として実行させる。
なお、本実施形態では、1回のみの握持操作を受け付けた場合にロボット50が実行する報知動作として、所定の音声(例えば、地域の天気に応じた音声)を発する音声発生動作が実行されることとする。
次に、所定時間内に2回の握持操作を受け付けた場合には、操作受付機構55が2回の握持操作を受け付けたことを示す信号を生成し、コントローラ54に伝送する。当該信号を受信したコントローラ54は、音声発生機構52を制御し、前回実行した音声発生動作の際に再生した音声ファイルを再度再生させて、前回の音声発生動作と同様の音声が発せられるように、音声発生動作を実行させる。このように前回の音声発生動作で再生された音声ファイルを再度再生させることが可能であるので、ユーザは、例えば住宅Hを不在にしている間に報知動作としての音声発生動作が実行された場合であっても、当該音声発生動作の内容(すなわち、ユーザが聞き逃した音声発生動作の内容)を帰宅後に確認することが可能になる。
さらに、所定時間内に3回の握持操作を受け付けた場合には、操作受付機構55が3回以上の握持操作を受け付けたことを示す信号を生成し、コントローラ54に伝送する。当該信号を受信したコントローラ54は、前述したように、ホームサーバ10に対して制御処理の実行要求を送信するとともに、音声発生機構52を制御し、所定の音声(例えば、制御処理の実行要求を送信した旨を示す音声)を発する音声発生動作を実行させる。
以上のような対応関係に則って、ロボット50(厳密にはコントローラ54)からホームサーバ10に対して制御処理の実行要求が送信される。なお、本実施形態では、制御処理の実行要求を送信するための握持操作の実行回数を3回としたが、これに限定されるものではなく、少なくとも2回以上であればよく、任意の回数に設定することが可能である。
<ロボット50の動作例>
次に、以上までに説明してきた構成を有するロボット50の動作例を説明する。なお、ロボット50の動作例を説明するにあたり、以下では、ロボット50に報知動作を実行させるまでに行われる一連の動作(以下、情報報知工程)、及び、ユーザが電力消費機器の運転状態を制御する際に行う握持操作をロボット50が受け付けた以降の一連の動作(以下、機器制御工程)について説明する。
(1)情報報知工程について
以下、情報報知工程の手順について説明する。先ず、報知すべき情報のカテゴリが「割合の算出結果」である場合の情報報知工程を例に挙げて、図11を参照しながら説明する。
「割合の算出結果」に関する情報について情報報知処理を開始するにあたり、ユーザが所定の期間中に住宅Hで消費される電力消費量の目標値を入力しており、当該目標値を示す目標値データがCEMSサーバ40のCS側記憶部42に記憶されている。
上記の状態において、ホームサーバ10の外部データ取得部101は、宅外ネットワークGNを通じてCEMSサーバ40と通信し、CEMSサーバ40に対して目標値データの送信を要求する(S001)。このデータ送信の要求を以て情報報知工程が開始される。なお、本実施形態において、上記のデータ送信要求は、約30分間隔で行われる。このため、本実施形態では約30分間隔で、「割合の算出結果」に関する情報についての情報報知工程が実施される。ただし、これに限定されるものではなく、「割合の算出結果」に関する情報についての情報報知工程が実施される間隔は、任意に設定することが可能である。
次に、CEMSサーバ40は、ホームサーバ10からのデータ送信要求を受け付けると(S002)、当該要求の発信元であるホームサーバ10を特定した上で、特定したホームサーバ10に対応する目標値データをCS側記憶部42から読み出して、同ホームサーバ10に向けて目標値データを送信する(S003)。
その後、ホームサーバ10では、外部データ取得部101が宅外ネットワークGNを通じて、CEMSサーバ40から送信された目標値データを受信する(S004)。また、本実施形態では、目標値データの受信と連動して、測定結果データ取得部102が、スマートメータからなるセンサ21に対して測定結果データの送信を要求し、当該センサ21から測定結果データを受信する(S005)。かかる測定結果データは、上記目標値が適用される期間の開始時から現時点までの間に住宅H内で実際に消費された電力消費量の累積値を測定した際の測定値(測定結果に応じた情報)を示すデータである。
そして、ホームサーバ10が上記の測定結果データ及び目標値データを受信すると、これらのデータに基づいて、ロボット駆動部105が、所定の期間における目標値と、所定の期間中に住宅H内で実際に消費された電力消費量の累積値とを特定し、さらに、上記目標値に対する上記累積値の割合を算出する(S006)。その後、ロボット駆動部105は、算出した割合に応じた報知動作の実行要求をロボット50に対して送信する(S007)。
ロボット50側では、コントローラ54が、ロボット駆動部105からUSB回路を通じて報知動作の実行要求を受信し(S008)、当該実行要求を解析して、報知すべき情報のカテゴリを特定した上で、発光動作、音声発生動作及び振動動作の中から、特定したカテゴリに対応した動作を、実行する報知動作に決定する(S009)。実行する報知動作のカテゴリが決定した後には、コントローラ54が、発光機構51、音声発生機構52及び振動機構53を制御して、決定した報知動作を実行させる(S0010)。本具体例の場合、報知すべき情報のカテゴリは「割合の算出結果」であるため、ロボット50では、報知動作として発光動作と振動動作が実行されることになる。
なお、報知動作として発光動作を実行する場合、ロボット50のコントローラ54は、報知すべき情報のカテゴリとともに内容を特定し、特定した内容に対応した発光形式にて発光動作を発光機構51に実行させる。
以上までに説明してきた一連の手順により、ロボット50が報知動作として発光動作及び振動動作を実行するようになり、ユーザに対して、目標電力消費量に対する実際の消費量の累積値の割合が報知されることになる。この結果、ユーザに対して、住宅H内での電力需給状況や自己のエネルギー消費行動を見直すきっかけを与えることが可能になる。つまり、ユーザは、ロボット50の報知動作を通じて、目標電力消費量に対してこれまで実際にどれだけの電力を消費してきたのかを簡単に確認することができるので、その後のエネルギー消費行動を見直すきっかけを持ち易くなる。
なお、上記の例では、目標電力消費量に対する実際の消費量の累積値の割合を報知するための報知動作として、発光動作及び振動動作が実行されることとしたが、これに限定されるものではなく、発光動作、音声発生動作及び振動動作のうち、少なくとも一つ以上の動作が報知動作として実行されればよい。
また、上記の例では、電力消費量の目標値を示す目標値データがCEMSサーバ40のCS側記憶部42に記憶されており、目標電力消費量に対する実際の消費量の累積値の割合を算出するにあたり、宅外ネットワークGNを通じてCEMSサーバ40と通信して目標値データを取得することとしたが、これに限定されるものではない。例えば、ホームサーバ10(具体的には、メモリ10bや不揮発性記憶装置10c)に目標値データを記憶しておくこととしてもよい。かかる構成の場合、図12に示すように、目標電力消費量に対する実際の消費量の累積値の割合を算出するにあたり、ホームサーバ10に記憶された目標値データを読み出すことになる(S011)。目標値データを読み出した後の手順S012〜S017については、上記の例で説明した手順S005〜S010と同様であるので、説明は省略する。
次に、報知すべき情報のカテゴリが「系統電力の単価の現在値」である場合の情報報知工程を例に挙げて、図13に参照しながら説明する。
系統電力の単価(すなわち、電気料金)は、前述したように時間帯に応じて変化し、当該単価が変化した場合には、CEMSサーバ40がコミュニティ内の各住宅Hに設置されたホームサーバ10に向けて、変更後の単価(すなわち、系統電力の単価の現在値)を示す単価データが配信される(S021)。この単価データは、CEMSサーバ40が配信する提供情報データであり、例えば、電力会社が設定した電気料金の料金体系に基づいて予め生成しており、系統電力の単価が変更する時刻になると自動的に配信される。
その後、ホームサーバ10では、外部データ取得部101が宅外ネットワークGNを通じて、CEMSサーバ40から送信された単価データを受信する(S022)。そして、ホームサーバ10側で単価データが取得されると、ロボット駆動部105が、その単価データに基づいて系統電力の単価の現在値を特定した上で、特定した系統電力の単価の現在値に応じた報知動作の実行要求をロボット50に対して送信する(S023)。
ロボット50側では、コントローラ54が、ロボット駆動部105からUSB回路を通じて報知動作の実行要求を受信し(S024)、当該実行要求を解析して、報知すべき情報のカテゴリを特定した上で、発光動作、音声発生動作及び振動動作の中から、特定したカテゴリに対応した動作を、実行する報知動作に決定する(S025)。実行する報知動作のカテゴリが決定した後には、コントローラ54が、発光機構51、音声発生機構52及び振動機構53を制御して、決定した報知動作を実行させる(S026)。本具体例の場合、報知すべき情報のカテゴリは「系統電力の単価の現在値」であるため、ロボット50では、報知動作として発光動作と振動動作が実行されることになる。具体的に説明すると、ロボット50は、例えば系統電力の単価の現在値が更新されたことをユーザに気付かせるために振動発生機構53による振動動作を実行し、更新後の単価の現在値に応じた発光形式(より具体的には、更新後の単価の現在値に対応した発光色)にて発光機構51による発光動作を実行する。
以上までに説明してきた一連の手順により、ロボット50が報知動作として発光動作よび振動動作を実行する結果、ユーザに対して系統電力の単価の現在値を報知することが可能となる。これにより、ユーザに対して、自己のエネルギー消費行動を見直すきっかけが与えられ、ユーザの省エネルギー意識を喚起することが可能になる。
なお、上記の例では、系統電力の単価の現在値を報知するための報知動作として、発光動作及び振動動作が実行されることとしたが、これに限定されるものではなく、発光動作、音声発生動作及び振動動作のうち、少なくとも一つ以上の動作が報知動作として実行されればよい。
また、上記の例では、CEMSサーバ40が配信する提供情報データのうち、系統電力の単価の現在値を示す単価データがホームサーバ10に受信されたケースについて説明したが、他の提供情報データ、例えば、上述した節電要求データ、天気データ等を受信した場合についても、上記と同様の手順に従って、当該データに応じた報知動作が実行されることとすればよい。
さらに、センサ21が前述の報告データ(住宅Hにおける瞬間消費電力が所定の大きさ以上になったことを知らせるためのデータ)を送信し、ホームサーバ10側で報告データを受信した場合には、ロボット駆動部105が、ロボット50に対して、瞬間消費電力が増大したことを知らせるための報知動作の実行を要求する。その後、上記と同様の手順(S024〜026)により、ロボット50側で、カテゴリ「瞬間消費電力増大」に対応した報知動作として発光動作及び振動動作が実行される。なお、上記カテゴリ「瞬間消費電力増大」に対応して実行される発光動作は、前述したように、発光色を変化させながら実行される。
また、運転状態が制御されている電力消費機器(制御対象機器)について制御が完了した際に送信される制御完了信号を、ホームサーバ10の機器制御部104が受信した場合には、ロボット駆動部105が、ロボット50に対して、制御完了を知らせるための報知動作の実行を要求する。その後、上記と同様の手順(S024〜026)により、ロボット50側で、カテゴリ「制御完了」に対応した報知動作として音声発生動作及び振動動作が実行される。
(2)機器制御工程について
以下、機器制御工程について図14を参照しながら説明する。
先ず、ユーザがロボット50を握持する操作(握持操作)を行うと、ロボット50側では操作受付機構55が当該握持操作を受け付ける(S031)。ここで、操作受付機構55が所定時間内に受け付けた握持操作の回数が1回であった場合には(S032で「1回」)、ロボット50のコントローラ54が、ホームサーバ10の外部データ取得部101に対して、CEMSサーバ40との通信の実行を要求する(S033)。これにより、外部データ取得部101が、CEMSサーバ40に対してデータ送信を要求し(S034)、当該要求に応じて、CEMSサーバ40が提供情報データ(具体的には、天気データ)を配信する(S035)。
そして、外部データ取得部101がCEMSサーバ40からの提供情報データを受信すると(S036)、ロボット駆動部105が、当該提供情報データに応じた報知動作の実行要求をロボット50に対して送信する(S037)。ロボット50側では、コントローラ54が、ホームサーバ10側から報知動作の実行要求を受け付けると(S038)、上記の提供情報データに対応した動作を報知動作として実行する(S039)。本実施形態では、CEMSサーバ40からの提供情報データが天気データであるので、ロボット50は、地域の天気に応じた音声を発する音声発生動作を報知動作として実行することになる。
次に、操作受付機構55が所定時間内に受け付けた握持操作の回数が2回であった場合(S032で「2回」)について説明すると、ロボット50のコントローラ54が、音声発生機構52が前回の音声発生動作の際に再生した音声ファイルを特定する(S040)。かかる音声ファイルの特定処理は、メモリ54bに記憶された音声ファイルの再生履歴をCPU54aが参照することによって行われる。そして、音声ファイルの特定が完了した後に、コントローラ54は、音声発生機構52を制御し、前回再生した音声ファイルを再生して、前回と同様の音声を発する音声発生動作を実行させる(S041)。
次に、操作受付機構55が所定時間内に受け付けた握持操作の回数が3回であった場合(S032で「3回」)について説明すると、本場合において機器制御工程が行われ、住宅H内の電力消費機器の運転状態がホームサーバ10の機器制御部104により制御されるようになる。
すなわち、本実施形態では、操作受付機構55が所定時間内にユーザの握持操作を3回受け付けた段階で、はじめてコントローラ54が、電力消費機器の運転状態を制御する制御処理の実行要求をホームサーバ10に対して送信する(S042)。なお、前述したように、コントローラ54は、ホームサーバ10に対して制御処理の実行要求を送信するとともに、音声発生機構52を制御し、所定の音声(例えば、制御処理の実行要求を送信した旨を示す音声)を発する音声発生動作を実行させる(S042)。
制御処理の実行要求を受け付けたホームサーバ10側では、機器制御部104が制御処理を実行する(S043)。すなわち、住宅Hで使用されている電力消費機器のうち、制御対象となる機器に向けて制御信号が発信される。なお、前述したように、本実施形態では、ホームサーバ10がロボット50側から制御処理の実行要求を受信すると、住宅H内の電力消費機器のうち、常時運転させる必要がある機器(例えば、ホームサーバ10や冷蔵庫等)を除く全ての機器に向けて、電源をオフにする制御信号が発信される。
そして、制御対象機器の運転状態の制御が完了した段階で、機器制御部104が制御対象機器から制御完了信号を受信するようになり(S044)、当該制御完了信号の受信後、ロボット駆動部105が、制御完了信号に則った報知動作の実行要求をロボット50に対して送信する(S045)。コントローラ54は、上記の実行要求を受信すると(S046)、当該実行要求を解析して、報知すべき情報のカテゴリを特定し、発光動作、音声発生動作及び振動動作の中から、特定したカテゴリに対応した動作を、実行する報知動作に決定する(S047)。実行する報知動作のカテゴリが決定した後には、コントローラ54が、発光機構51、音声発生機構52及び振動機構53を制御して、決定した報知動作を実行させる(S048)。
具体的に説明すると、報知すべき情報のカテゴリが「制御完了」と特定され、報知動作として、制御処理の完了を示す音声を発生する音声発生動作と、振動動作が実行される。なお、本実施形態では、カテゴリ「制御完了」の情報を報知するにあたり、音声発生動作と振動動作とが実行されることになっているが、これに限定されるものではなく、発光動作、音声発生動作及び振動動作のうち、少なくとも1つ以上の動作が実行されればよい。
<<その他の実施形態>>
上記の実施形態では、主として本発明の情報報知システムについて説明した。しかし、上記の実施形態は、本発明の理解を容易にするためのものであり、本発明を限定するものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物が含まれることは勿論である。
また、上記の実施形態では、住宅H内でのエネルギー消費量を測定して測定結果データを送信する測定装置としてのセンサ21、及び、提供情報データを送信する情報配信装置としてのCEMSサーバ40の双方と通信するホームサーバ10を通信装置の一例として挙げたが、これに限定されるものではない。上記の測定装置と上記の情報配信装置のうち、少なくとも一方の装置と通信する通信装置であればよい。そして、報知動作を実行する報知機器(上記の実施形態では、ロボット50に相当する)については、測定結果データ及び提供情報データのうち、上記の少なくとも一方の装置と通信した際に受信した受信データに基づき、当該受信データに応じた報知動作を実行するものであればよく、例えば、測定結果データ(あるいは提供情報データ)をホームサーバ10が受信したときに限り、当該受信データに応じた報知動作を実行する報知機器であってもよい。
また、上記の実施形態では、報知動作を実行する報知動作の一例としてマスコット形状のコミュニケーションロボット(ロボット50)を挙げたが、これに限定されるものではなく、例えば、球体や個性的な形状を有する置物であってもよい。つまり、比較的容易に配置を変えることが可能であり、ユーザに対して情報を簡易に報知することができる置物型の報知機器である限り、制限なく利用することが可能である。
また、上記の実施形態では、通信対象機器に応じて通信バンドルを切り替えて実行すると共に、各通信バンドルの機能を利用するためのインタフェースを統合してAPI(汎用API)として提供するための機構として、OSGiフレームワーク203を例に挙げて説明したが、上記の機能を有するものである限り、OSGiフレームワーク203以外の既存の技術を利用することとしてもよい。
また、上記の実施形態では、センサ21、22a、22b、23a〜23cの測定結果が表示されるエネルギー管理画面が、携帯端末30に搭載されたタッチパネル31に描画されることとした。ただし、これに限定されるものではなく、ホームサーバ10のディスプレイ11に描画されることとしてもよい。
また、上記の実施形態では、ホームサーバ10にUSBにて接続するロボット50を例に挙げて説明し、ホームサーバ10の電源に連動して電力が供給されることとした。ただし、これに限定されるものではなく、充電式の内部電源を有し、ホームサーバ10とワイヤレス通信を行う報知機器であってもよい。かかる報知機器であれば、USB等の配線が不要になるので、置き場所を自由に決定することが可能となる。なお、内部電源の充電についてはワイヤレス充電、すなわち、充電器と接触させずに充電する方式を採用すると、置き場所を自由に決定する上で好適である。
また、上記の実施形態では、電力をエネルギーの一例として挙げ、住宅H内での電力消費量を管理するエネルギー管理システムについて説明した。ただし、これに限定されるものではなく、他のエネルギー消費量(ガス使用量や水道使用量)を管理対象として含むシステムであってもよい。