index.md

This example shows the use of metadata mapping within Cepheus-CEP.

It is completely based on the Rooms and Floors example.

It illustrates how to propagate the unit metadata of a temperature attribute.

Setup

The Context Entities generated by the sensors now contain a unit metadata:

 {
     "id": "Room31", // Room 1 on floor 3 (could be anything else)
     "type":"Room",  // all sensors must use the same "Room" type
     "attributes": [
        {
            "name":"temperature",
            "type":"double",
            "value":"21",
            "metadatas": [
                { "name":"unit", "type":"string", "value":"celsius" }
            ]
        },
        { "name":"floor", "type":"string", "value":"3" } // the room is on the third foor
     ]
 }

and we expect the CEP to output values as:

{
    "id": "Floor1", // uniquely identifies a floor (coud be anything else)
    "type":"Floor", // all floor must use the same "Floor" type
    "attributes": [
        {
            "name":"temperature",
            "type":"double",
            "value":"23.3",
            "metadatas": [
                { "name":"unit", "type":"string", "value":"celsius" }
            ]
        }
    ]
}

Configuring the CEP

Translated to the configuration format of the Cepheus-CEP, we get the following "in" section for accepting Room temperature as input :

"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
        "providers": [ "http://localhost:8081" ],  # The URL of the source of the input
        "attributes":[
            {
                "name":"temperature",
                "type":"double",
                "metadata": [
                   { "name":"unit", "type":"string" }
                ]
            },
            { "name":"floor", "type":"string" }
        ]
    }
]

The "out" section is also similar to the NGSI Context Entity of a Floor:

"out":[
    {
        "id":"Floor1",
        "type":"Floor",
        "attributes":[
            {
                "name":"temperature",
                "type":"double",
                "metadata": [
                    { "name":"unit", "type":"string" }
                ]
            }
        ]
    }
]

To transmit the unit metadata of the temperature, we need to tell the EPL rule to transmit temperature_unit "as is" :

INSERT INTO Floor
SELECT floor as id, avg(temperature) as temperature, temperature_unit
FROM Room.win:time(10 minutes)
GROUP BY floor
OUTPUT LAST EVERY 1 min

See more information about metadata naming in EPL in the CEP/Mapping section.

The config.json has the complete configuration setup.

Testing the setup

You can run the run.sh file in a terminal while checking the logs of Cepheus CEP to see the Rooms temperature sent to the CEP and the CEP reacting to the events.

In a first terminal, launch Cepheus-CEP:

cd cepheus-cep
mvn spring-boot:run

Default configuration should launch it on port :8080 on your machine.

Now in another terminal, trigger the run.sh script:

cd doc/examples/7_Metadata
sh run.sh

The script first sends the config.json file to Cepheus-CEP, then it starts sending temperatures updates.

Go back to the terminal where you launched the CEP. You should see temperatures as "EventIn" being logged.

After a few seconds, the "EventOut" logs will show the CEP triggering the average temperature for each floor.