この例は、より複雑なイベント処理を示しています。
以下の状況を考えてみましょう :
- 各部屋の NGSI 対応温度センサ
- 部屋を冷やしたり暖めたりするために開閉する各部屋の NGSI 制御シャッター
部屋を温める強い日差しがあると、シャッターを閉めることにします。室内温度が26°C以上になるとシャッターが閉じ、224°C以下になるとシャッターが開きます。
セットアップ¶
以下のコンテキスト・エンティティとしてそれらの値を出力するように NGSI 互換センサを設定します :
{
"id": "Room1", # Room 1 (could be anything else)
"type":"Room", # all sensors must use the same "Room" type
"attributes": [
{ "name":"temperature", "type":"double", "value":"21" }, # this is the value of the sensors
{ "name":"shutter", "type":"string", "value":"shutter1" } # the shutter associted to the room
]
}
これらの更新を受け入れるように CEP を設定し、次にシャッターに基づくコンテキスト・エンティティの更新をトリガーすることができます :
{
"id": "Shutter1", # uniquely identifies a shutter (coud be anything else)
"type":"Shutter", # all shutters must use the same "Shutter" type
"attributes": [
{ "name":"status", "type":"string", "value":"closed" }, # this will trigger the close command
]
}
status
属性は、opened
か closed
になります。
上のモデルに基づいてシャッターコマンドをトリガーする EPL ルールは次のとおりです :
INSERT INTO Shutter
SELECT R.r.shutter as id, 'closed' as status
FROM pattern [ every r=Room(temperature > 26.0) -> (timer:interval(10 sec) and not Room(temperature < 26.0 and id=r.id))] as R unidirectional
LEFT OUTER JOIN Shutter.std:groupwin(id).std:lastevent() as S
ON R.r.shutter = S.id
WHERE S is null OR S.status = 'opened'
そして
INSERT INTO Shutter
SELECT R.r.shutter as id, 'opened' as status
FROM pattern [ every r=Room(temperature < 24.0) -> (timer:interval(10 sec) and not Room(temperature > 24.0 and id=r.id))] as R unidirectional
LEFT OUTER JOIN Shutter.std:groupwin(id).std:lastevent() as S
ON R.r.shutter = S.id
WHERE S is null OR S.status = 'closed'
これらのルールの構文の詳細については、Esper EPL マニュアルを参照してください。
ルームの shutter
属性をシャッターの id
として使用しています。パターンが一致する場合、シャッターの status
は close
または oepn
に設定されます。温度が26秒以上または24秒未満で10秒間連続して維持された場合、パターンがトリガされます。現在のステータスが不明または反対の場合にのみ、シャッターウィンドウの左外部結合によりコマンドをトリガーすることができます。単方向命令は、パターンが一致しているとき、またはシャッターウィンドウが更新されていないときにのみ結合を評価するように制限します。
注 : 最適化は、"named window" を使用して、2つのフィルタリングされたシャッターウィンドウ Shutter.std:groupwin(id).std:lastevent()
を防ぐことができます。これは練習として残されています。
CEPの設定¶
Cepheus-CEP の設定フォーマットに変換されているので、入力として室温を受け入れるための "in" セクションがあります :
"in": [
{
"id":"Room.*", # Pattern is used to subscribe to provider to all Room1, Room2, ..., RoomN
"type":"Room", # The type to subscribe
"isPattern":true, # Pattern match the id
"attributes":[
{ "name":"temperature", "type":"double" },
{ "name":"shutter", "type":"string" } # Id of the Shutter associated to the Room
]
}
]
"out" セクションは、シャッターの NGSI コンテキスト・エンティティにも似ています :
"out":[
{
"id":"ShutterX",
"type":"Shutter",
"attributes":[
{ "name":"status", "type":"string" }
]
}
]
config.json は、完全な設定のセットアップを持っています。
セットアップのテスト¶
run.sh ファイルを端末で実行し、Cepheus CEP のログをチェックすることで、CEP に送信されたルームの温度と CEP がイベントに反応することを確認できます。
最初の端末で、Cepheus-CEP を起動します :
cd cepheus-cep
mvn spring-boot:run
デフォルト設定では、マシン上の port :8080 で起動する必要があります。
今度は別のターミナルで、run.sh スクリプトを起動します :
cd doc/examples/2_CloseShutters
sh run.sh
スクリプトは最初に config.json ファイルを Cepheus-CEP に送信し、温度の更新を送信します。
CEP を開始した最初の端末に戻ります。"EventIn" というログが記録されているはずです。
数秒後、"EventOut" ログには、各シャッターの状態をトリガする CEP が表示されます。
次のステップ¶
次の例で、Cepheus-CEP を Cepheus-Broker と連携させる方法を学びます。