Difference between revisions of "Recipes"

Revision as of 13:31, 10 April 2018

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.

Execute action at a specific time

Use case: reset values in thing at midnight every day