Difference between revisions of "Recipes"

Revision as of 12:45, 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 Solution: configure scheduled observation to be sent every day at midnight, and configure reasoner that upon the arrival of that observation, updates the thing Scheduled Observation Configuration Details :

• action sendScheduledObservation in the same reasoner that creates the thing, to make sure that the observation is generated once when the thing is created.
• set property Days to 1 so that it is re-sent every day
• set property Occurrence to 0 so that the action of re-sending it every day is repeated always
• set property StartDate to midnight via a javascript binding. Take into account that server hours are in UTC