Difference between revisions of "Sample configuration for beacons"

Latest revision as of 12:12, 20 September 2017

Requirements and required steps

Required thing types

• amtechM2mBridge
• BLEbeaconsScanner

As a creator define a service with actor(s)

• Define and actor and name it.
• Add to the actor policies to GET (read), POST (create) and/or PUT (edit) entities of the required types. In this case amtechM2mBridge and BLEbeaconsScanner.
• Create an activity and name it.
• Add the previously created actor to the activity.
• Optionally add logic to the activity through new observers/reasoners/etc.
• Publish the activity and in the process, share it with at least one follower tenant by using the property guesttenants. Now the admin of these tenants will have the possibility to subscribe to the generated service and invite new users to its own tenant using the actors defined by the service or a subset of them.

As follower admin

• Subscribe to the service that the creator is offering.
• Figure out the accesses you want to give to the bridge or bridges that will be configured based on this service and design a serie of invited followers (one for each bridge). Invite these new users (bridge users) to the tenant with the actors defined by the creator or a subset of them.

Design the bridges

Still as follower admin (although this can also be done by the creator), start designing the bridge templates:

• Create a new BLEbeaconsScanner instance and configure all its required properties.
• Create an amtechM2mBridge instance.
• Configure required properties and useful properties as:
  • Add the BLEbeaconsScanner instance to the bridge instances
  • Configure bridge error observation config:
    • Topic should be configured as an existing root topic or a subtopic (at any level) of an existing root topic (creators can create new root topics if needed). For instance: /m2mBridge/example/errors where /m2mBridge is an existing topic.
    • Configure producer. A placeholder substitution like #{thingId} may be useful as value for the producer.
  • Might be useful to configure the logger level to "debug" instead of the default value "error".
  • Do the observation production configuration part.
    • Add BLEbeaconsScanner to the list of things
    • Go to its list of produced observations
    • Add required observations like eddystoneScan, ibeaconScan, etc
    • Configure topic and producer for this produced observations. Similar to the bridge error observation config:
      • Add topic as root topic or subtopic of an existing root topic (creators can create new root topics if needed). Ex. /m2mBridge/example/eddystoneScannings or /m2mBridge/example/ibeaconScannings
      • Configure the producer. Again, some placeholder substitution may be useful.
  • If configured as creator, share this bridge instance with the follower tenant so that invited users belonging to the list can clone it.
• Validate the bridge (it should validate or otherwise you should have overlooked some of these steps)

Observation production graph view

Graph view

As invited user to the follower tenant

• Accept the invitation sent by the follower admin.
• Configure the bridge with the DAP URL and your credentials in bridgeConfig.json
• Set the configured bridge as the template.
• Configure all the other required properties as templateId, bridgeIdPrefix, etc.
• Run the bridge.