Difference between revisions of "Recipes"

Revision as of 00:53, 8 February 2019

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
• include the thing id in the observation fields so that it can be used to retrieve the thing for updating it in the reasoner
  

Reasoner to update the thing

• Reasoner that runs with the execution of an observer that receives the type of observation sent with the previous schedule
• Observe things with the thing id included in the observation fields
• Update thing, resetting values

Execute action every 30 min

Use case: check if a thing keeps the same value in a field for more than 30 min and send a notification

Solution: Configure scheduled observation to be sent 30 min after the value is updated in the thing, and configure a reasoner that upon the arrival of that observation, checks if the thing still has the same value in the field to send the notification.

Scheduled Observation Configuration Details :

• action sendScheduledObservation
• set property StartDate to the current date plus 30 min
• set property Occurrence to 1 so that the observation is only sent once
• include in the observation fields, the thing id and the value of the field being analyzed so that it can be used to retrieve the thing in the reasoner that will consume the observation when it arrives, 30 min after
  

Reasoner to check if the thing has the same value in the field when the scheduled observation arrives

• Reasoner that runs with the execution of an observer that receives the type of observation sent with the previous schedule and filters the thing that has the same id, and the field with the same value it had 30 min before (value included in the scheduled observation). Also, filter thing using the date field that indicates the time when that value was updated in the thing. This will avoid retrieving a thing that has the same value in the field, but that has been changed in the last 30 min
• If the observer returns at least one thing (it should return only one at most), send the notification with the info that the thing has had the same value in the field for 30 minutes

Send notifications to emails/phone numbers defined in the thing instances

Use case: Send notification to emails/phone numbers that can be changed without changing the activity configuration

Solution: Define recipients on the thing instance involved in the reasoner that sends the notification, using the fields "Emails" and "Phones" found in all thing instances. Notifications will be sent to the list of emails defined in the thing instance, and also to the list of recipients defined in the reasoner action. See Action Send Notification

Bridge and instances Crud

Restart instance when supported properties change by calling stop and star plugin interface