Difference between revisions of "Recipes"
(Created page with "== Counting area occupancy == One application of the in-room location is to keep track of area occupancy. This can be done with the proximity area field, EPC tags and RFID rea...") |
(→Counting area occupancy) |
||
Line 21: | Line 21: | ||
Also, it is possible to keep track of the number of attendees in a room by using the crud operations of the attendee. | Also, it is possible to keep track of the number of attendees in a room by using the crud operations of the attendee. | ||
− | First, create two observers | + | First, create two observers expecting crud observations with constraints |
− | + | * ''httpMethod'' eq "PUT" | |
− | + | * ''resourceType'' eq "amtech/linkeddata/types/composite/entity/Attendee" | |
− | + | * ''propId'' eq "proximityArea" | |
− | + | and observing rooms with constraints on the uri. The observer tracking '''enter''' events must include also the constraints | |
+ | * observation field ''newValue'' as ''required'' | ||
+ | * room ''uri'' eq observation ''newValue'' | ||
+ | The other observer will track the '''exit''' event and must include | ||
+ | * observation field ''oldValue'' as ''required'' | ||
+ | * room ''uri'' eq observation ''oldValue'' | ||
− | Then create one reasoner | + | Then create one reasoner for each observer to update the observed room resource by [[Reasoner_Increment,_Decrement,_Set|incrementing or decrementing]] the corresponding occupancy field. |
Revision as of 09:59, 10 August 2016
Counting area occupancy
One application of the in-room location is to keep track of area occupancy. This can be done with the proximity area field, EPC tags and RFID reader and antennas.
Let us suppose we have two antennas, one set inside the room whose associated resource has the room id in the proximity area field and the other outside with empty proximity area. Let us assume that they are placed so anyone entering the room is detected only by the antenna inside, and the antenna outside is the last detecting every attendee exiting the room.
The first thing to do is to keep track of each attendee who has entered to the room and is still inside. To do that it is enough to configure the bridge so the LLRPReader plugin send the observations with target thing set to
{
...
"targetthings": "[{
\"thingType\": \"/amtech/linkeddata/types/composite/entity/Attendee\",
\"thingsId\": [\"attendeeUriOrName\"],
\"proximityarea\": \"/uri/of/the/room\"
}]",
...
}
where the attendeeUriOrName must be computed from its EPC tag and the "/uri/of/the/room" is taken from the antenna (see antennaProximity placeholder here).
This configuration will cause that the proximity area of the detected attendee is set to the proximity area of the antenna, this is the room uri if he entered the room or empty if he exit. So, whenever you want to find which attendees are in a given room, it is enough to query the system with an observer, by using the filter on the proximity area.
Also, it is possible to keep track of the number of attendees in a room by using the crud operations of the attendee. First, create two observers expecting crud observations with constraints
- httpMethod eq "PUT"
- resourceType eq "amtech/linkeddata/types/composite/entity/Attendee"
- propId eq "proximityArea"
and observing rooms with constraints on the uri. The observer tracking enter events must include also the constraints
- observation field newValue as required
- room uri eq observation newValue
The other observer will track the exit event and must include
- observation field oldValue as required
- room uri eq observation oldValue
Then create one reasoner for each observer to update the observed room resource by incrementing or decrementing the corresponding occupancy field.