Difference between revisions of "Observation production config"
(→Thing type without observation production configuration) |
(→Thing type without observation production configuration) |
||
Line 54: | Line 54: | ||
=== Thing type without observation production configuration === | === Thing type without observation production configuration === | ||
− | A use case could require that an instance of thing type is needed just to receive [Actions#Send_command|commands], in that case the bridge configuration allows to set a thing instance without observation production configuration. '''Remark this thing type instance will not produce observations.''' | + | A use case could require that an instance of thing type is needed just to receive [[Actions#Send_command|commands]], in that case the bridge configuration allows to set a thing instance without observation production configuration. '''Remark this thing type instance will not produce observations.''' |
Revision as of 12:24, 24 November 2016
Contents
Configuration options
The goal of this configuration is to identify the observation types that a thing of a given type produces behind a bridge.
- When you access this configuration, you're presented with a list of thing types (initially empty).
- You can add new thing types as a way of expressing a production for all the bridge thing instances belonging to that type. Therefore only those types associated to the things that are already configured as bridge instances are shown (things in the bridgeInstances property).
- Once the type is added to the observation production configuration you can navigate to the produced observations and add new observation types. This allows you to express that those bridge instances that belong to the selected type can produce the observation that you're about to add/modify.
- So you select an observation type. It has got to be an observation type listed in the observation types that this thing type can produce. See the definition of the corresponding thing type, observationproductionconfig property
- Once selected you should configure the following properties:
Remarks: The Amtech M2M bridge uses this configuration to automatically fill this fields in the observations it sends. The follower must have a role with access polices to the thing type in order to get this information
Example
Let's show some more configuration details through an example:
- As we can appreciate from the previous explanation, the configuration involves thing types and the observation types they produce. The first step is to open the bridge and go to observation production configuration setting:
- When you navigate into it you're presented with a list of already configured thing types (initially empty):
- Then you can add or navigate to an existing entity type. Let's choose LLRPReader for the example:
- Then you can browse the list of observation types that it produces:
- Again you can add or delete existing entries: observation types in this case. Let's go to graiEPC config:
- The example shows a LLRPReader that is configured to produce observations of type graiEPC. Then you configure the observation properties required to produce this observation and enforce security including fixed settings for topic, targetthings, producer, guestusers and guesttenants (See Observations and observation types). In the example we set:
- topic to /thingsInBoardroom/LLRPReader/#{smoothingResult}. #{smoothingResult} placeholder evaluated to new or lost so it allows us to group observations in corresponding child topics.
- producer to #{thingId}. #{thingId} placeholder is replaced but the thing ID of the thing sending the observation.
- targetthings through a new page where you can add or edit existing target types:
- For the example let's add/modify the type thingInBoardroom so we're presented with the targetthings properties:
- So you can configure the resource Id to #{thingId}:#{serialNumber} for instance. #{thingId} and #{serialNumber} placeholders are replaced with the thing ID of the thing sending the observation and the serial number from the graiEPC observation to uniquely identify the target thing.
Placeholders
Allows to set identifiers that will be substituted by real values at different intelligence layers. See placeholders.
Let's see some examples:
- guesttenants set to #{companyPrefix} - In this case we use the placeholder to set guesttenants from graiEPC value companyPrefix. It allows you to control the access to observations and things from the intelligence in the edge.
- topic set to /thingsInBoardroom/LLRPReader/#{smoothingResult}/#{country} - placeholder is used to group observations by new or lost and then by country.
Relation between thing types and the observation types allowed in the observation production configuration
For the relation among thing types and observation production configuration (See Thing types)
In the definition of a thing type you express the list of observation types it produces. It constrains the list of observation types that can be selected in the observation production configuration for that thing type. For instance, you're presented with a screen like this when you try to add new observations for the LLRPReader type.
Thing type without observation production configuration
A use case could require that an instance of thing type is needed just to receive commands, in that case the bridge configuration allows to set a thing instance without observation production configuration. Remark this thing type instance will not produce observations.