Difference between revisions of "Observation production config"

From AMTech WikiDocs
Jump to: navigation, search
(Configuration options)
(Configuration options)
 
(2 intermediate revisions by the same user not shown)
Line 12: Line 12:
 
* 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
 
* 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:
 
* Once selected you should configure the following properties:
**; topic : This is the topic or topics where this observation will be addressed to. Unless the simple definition of a [[Sensor's_network#Topics|topic]] in an observation, this allows you to specify several destinations. It consist of vertical bar (|) separated list of single destinations, each one consisting in a destination protocol and an address. Currently there is support for the following destination protocols:
+
*; topic : This is the topic or topics where this observation will be addressed to. Unless the simple definition of a [[Sensor's_network#Topics|topic]] in an observation, this allows you to specify several destinations. It consist of vertical bar (|) separated list of single destinations, each one consisting in a destination protocol and an address. Currently there is support for the following destination protocols:
*:; amtech: Topic in amtech cloud. In this case the address follows the same rules explained [[Sensor's_network#Topics|here]]. Example: <code>amtech:/thingsInBoardroom/llrpReasoner/#{smoothingResult}.
+
*:; amtech: Topic in amtech cloud. In this case the address follows the same rules explained [[Sensor's_network#Topics|here]]. Example: <code>amtech:/thingsInBoardroom/llrpReasoner/#{smoothingResult}</code>.
 
*:; edge: The observation will be produced for it to be consumed by edge reasoners. No address is allowed for this destination.
 
*:; edge: The observation will be produced for it to be consumed by edge reasoners. No address is allowed for this destination.
 
*:; mqtt or mqtts: The observation will be directed to a MQTT broker. The address must express the host and port of the MQTT broker but it might also contain authentication information, certificates for SSL protocol and other options. Example: <code>mqtt://user:pass@mqtthost.example.com:1883</code>.
 
*:; mqtt or mqtts: The observation will be directed to a MQTT broker. The address must express the host and port of the MQTT broker but it might also contain authentication information, certificates for SSL protocol and other options. Example: <code>mqtt://user:pass@mqtthost.example.com:1883</code>.
**; producer: This is the definition of the [[Sensor's_network|producer]] when this observation will be sent in the bridge.
+
*; producer: This is the definition of the [[Sensor's_network|producer]] when this observation will be sent in the bridge.
**; targetthings: This is the definition of the [[Sensor's_network#targetthings|targetthings]] when this observation will be sent in the bridge.
+
*; targetthings: This is the definition of the [[Sensor's_network#targetthings|targetthings]] when this observation will be sent in the bridge.
  
 
Remarks: The Amtech M2MBridge uses this configuration to automatically fill this fields in the observations it sends. The follower must have a role with access polices to the [[Activities#Thing types|thing type]] in order to get this information
 
Remarks: The Amtech M2MBridge uses this configuration to automatically fill this fields in the observations it sends. The follower must have a role with access polices to the [[Activities#Thing types|thing type]] in order to get this information

Latest revision as of 23:26, 18 August 2019

What is it

  • Configuration of the observation types produced by the bridge instances
  • It is configured for each bridge instance type
  • It is automatically updated when bridge instances are deleted (if it is the last instances of its type in the bridge instance list, the observation production config for that thing type is deleted)

Configuration options

  • 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:
    topic 
    This is the topic or topics where this observation will be addressed to. Unless the simple definition of a topic in an observation, this allows you to specify several destinations. It consist of vertical bar (|) separated list of single destinations, each one consisting in a destination protocol and an address. Currently there is support for the following destination protocols:
    amtech
    Topic in amtech cloud. In this case the address follows the same rules explained here. Example: amtech:/thingsInBoardroom/llrpReasoner/#{smoothingResult}.
    edge
    The observation will be produced for it to be consumed by edge reasoners. No address is allowed for this destination.
    mqtt or mqtts
    The observation will be directed to a MQTT broker. The address must express the host and port of the MQTT broker but it might also contain authentication information, certificates for SSL protocol and other options. Example: mqtt://user:pass@mqtthost.example.com:1883.
    producer
    This is the definition of the producer when this observation will be sent in the bridge.
    targetthings
    This is the definition of the targetthings when this observation will be sent in the bridge.

Remarks: The Amtech M2MBridge 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:
    Open bridge and go to observation production configuration settings
  • When you navigate into it you're presented with a list of already configured thing types (initially empty):
    Thing type list for observation production configuration
  • Then you can add or navigate to an existing entity type. Let's choose LLRPReader for the example:
    Specific thing type configuration
  • Then you can browse the list of observation types that it produces:
    Observation type list for a give thing type
  • Again you can add or delete existing entries: observation types in this case. Let's go to graiEPC config:
    Specific observation type configuration
  • 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 by the thing ID of the thing sending the observation.
    • targetthings through a new page where you can add or edit existing target types:
      List of target types for the targetthings
      For the example let's add/modify the type thingInBoardroom so we're presented with the targetthings properties:
      Configuration of instances for the selected type in targetthings
      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.
      targetthings

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.
placeholder

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.

Select observation 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.