Page History

...

The Azure IoT Hubs tab has two parts - Settings and CertificatesImage RemovedImage Added

Anchor
azureiothubssettings azureiothubssettings

Azure IoT Hubs - Settings

...

• Enable Certificate Based Authentication
  • Whether or not to use certificate based authentication.
  • This determines the authentication fields available for use.
• Password
  
  • Available if not using certificate based authentication
  • This is the Azure IoT Hub device connection string used to connect in the following format:
  • HostName=<Host Name>;DeviceId=<Device Name>;SharedAccessKey=<Device Key>
• MQTT Hostname
  • Available if using certificate based authentication 
  • This is the DNS endpoint name of your IoT Hub
• Device ID
  • Available if using certificate based authentication 
  • The Device ID to connect to as provisioned in the IoT Hub
• CA Certificate File
  • Available if using certificate based authentication
  • The CA certificate that signed the SSL certificate being used in the IoT Hub server. See this document for more information.
  • The drop down is populated from a list of files that have been uploaded to the IoT Hub/Certificates tab.
• Client Certificate File
  • Available if using certificate based authentication
  • The client certificate file as provisioned for the Device ID specified above.  See this See this Connecting to Azure IoT Hub with Certificate Based Authentication for details on creating the client certificate
  • The drop down is populated from a list of files that have been uploaded to the IoT Hub/Certificates tab.
• Client Private Key File
  • Available if using certificate based authentication
  • The client private key file that was used in generating the certificate for the Device ID specified above. See this Connecting to Azure IoT Hub with Certificate Based Authentication for details on creating the client private key 
  • The drop down is populated from a list of files that have been uploaded to the IoT Hub/Certificates tab.
• Private key password
  • Available if using certification based authentication
  • The password used for the private key if one was specified for the Client Private Key File

...

Image RemovedImage Added

• Store & Forward Enabled
  • Whether to enable Store & Forward capabilities for this endpoint
• Store & Forward Type
  • The type of the Store & Forward mechanism options: In_Memory and Disk_Backed (available in release 4.0.17 and higher)
  • Data stored with an In_Memory Store & Forward will not be persisted across a module configuration change, module disable/enable, module restart or power loss. 
  • Data stored with a Disk_Backed Store & Forward will persist across a module configuration change, module disable/enable, module restart or power loss
• Message Capacity - deprecated in 4.0.19
  • The maximum number of messages to store before dropping the oldest historical messages
• History Max Size
  • Maximum number of megabytes history can use before dropping the data
  • An In_Memory History store will use the Ignition Java Heap memory
• History Max Age
  • The maximum number of minutes to store history before dropping the data
• Flush Period
  • The period of time to wait (in milliseconds) between sending when flushing messages

...

• Keep Alive
  • The MQTT keep alive timeout in seconds
• Max Message Size
  • The maximum message size in bytes that any message can be when pushing to IoT Hub. Generally, this should match the max message size allowed by IoTHub.
• Session Expiration
  • How long in seconds to specify for session token timeouts when not using certificate based authentication
• Content Type

  • The content type to include in the topic to Azure IoT Hub

    • NONE (default) - No content type header will be included with the message
    • APPLICATION_JSON - The application/json header will be included with the message and make the body of the message available for routing if content encoding is also not 'NONE'
  • See Using IoT Hub Message Based Routing tutorial for more details
• Content Encoding
  • The content encoding to include in the topic to Azure IoT Hub
    • NONE (default) - No content encoding header will be included with the message
    • UTF_8 - The 'utf-8' header will be included with the message and make the body of the message available for routing if the content type is also set to APPLICATION_JSON
    • UTF_16 - The 'utf-16' header will be included with the message and make the body of the message available for routing if the content type is also set to APPLICATION_JSON
    • UTF_32 - The 'utf-32' header will be included with the message and make the body of the message available for routing if the content type is also set to APPLICATION_JSON
  • See Using IoT Hub Message Based Routing tutorial for more details
• Azure Date/Time Format
  • The date/time format to use when pushing messages to IoT Hub
    • LONG_MS_SINCE_EPOCH (default) - The timestamp values will all be as numbers in milliseconds since epoch (Jan 1, 1970) in UTC
    • STRING_AZURE_COMPAT - The timestamp will be pushed as described here. This is useful when wanting to use 'edge' timestamps in Azure Time Series insights.
  • See Pushing Data to Azure Time Series Insights tutorial for more details

Azure IoT Hub Settings - Advanced Store & ForwardImage Added

• H2 Database Port
  • TCP Port to connect to H2 Database for Disk_Backed History Store

Anchor
azureiothubscertificates azureiothubscertificates

Azure IoT Hubs - Certificates

This tab provides a list of the certificate or private keys if loaded and available for certificate based authentication.

This should generally will include the root CA for your IoT Hub, the client certificate file, and the client private key file CA Certificate that signed the SSL cert being used on the IoTHub server along with any device(s) certificate and private key files.

...

This tab provides a list of Azure IoT Edge endpoints that the module should connect to to push tag data. One or more Azure IoT Edge endpoints can be configured on this tab.Image RemovedImage Added

Clicking on the 'Create new Azure IoT Edge..." link will bring up the following form to add a new Azure IoT Edge. The configuration sections available are Main, Connectivity, Authentication, Store & Forward and Advanced. 

...

Image RemovedImage Added

• Store & Forward Enabled
  • Whether to enable Store & Forward capabilities for this endpoint
• Store & Forward Type
  • The type of the Store & Forward mechanism options: In_Memory and Disk_Backed (available in release 4.0.17 and higher)
  • Data stored with an In_Memory Store & Forward will not be persisted across a module configuration change, module disable/enable, module restart or power loss. 
  • Data stored with a Disk_Backed Store & Forward will persist across a module configuration change, module disable/enable, module restart or power loss
• Message Capacity - deprecated in 4.0.19
  • The maximum number of messages to store before dropping the oldest historical messages
• History Max Size
  • Maximum number of megabytes history can use before dropping the data
  • An In_Memory History store will use the Ignition Java Heap memory
• History Max Age
  • The maximum number of minutes to store history before dropping the data
• Flush Period
  • The period of time to wait (in milliseconds) between sending when flushing messages

...

• Keep Alive
  • The MQTT keep alive in seconds
• Max Message Size
  • The maximum message size in bytes that any message can be when publishing to IoT Edge. Generally, this should match the max message size allowed by IoT Edge.
• Session expiration
  • How long in seconds to specify for token timeouts when not using certificate based authentication
• Content Type
  • The content type to include in the topic to Azure IoT Edge
    • NONE (default) - No content type header will be included with the message
    • APPLICATION_JSON - The application/json header will be included with the message and make the body of the message available for routing if content encoding is also not 'NONE'
• Content encoding
  • The content encoding to include in the topic to Azure IoT Edge
    • NONE (default) - No content encoding header will be included with the message
    • UTF_8 - The 'utf-8' header will be included with the message and make the body of the message available for routing if the content type is also set to APPLICATION_JSON
    • UTF_16 - The 'utf-16' header will be included with the message and make the body of the message available for routing if the content type is also set to APPLICATION_JSON
    • UTF__32 - The 'utf-32' header will be included with the message and make the body of the message available for routing if the content type is also set to APPLICATION_JSON 
• Azure Date/Time Format
  • The date/time for mat to use when pushing messages to IoT Edge
    • LONG_MS_SINCE_EPOCH (default) - The timestamp values will all be as numbers in milliseconds since epoch (Jan 1, 1970) in UTC
    • STRING_AZURE_COMPAT - The timestamp will be pushed as described here. This is useful when wanting to use 'edge' timestamps in Azure Time Series Insights. 
• Custom Topic Extension
  • The Custom Topic Extension to append to the topic string for things like Application Properties

...

...

Azure IoT Edges

...

Settings - Advanced Store & ForwardImage Added

• H2 Database Port
  • TCP Port to connect to H2 Database for Disk_Backed Store & Forward

Anchor
azureiotedgecertificates azureiotedgecertificates

Azure IoT Edges - Certificates

This tab provides a list of the certificate or private keys loaded and available for certificate based authentication. This should generally include the root CA for your IoT Edge, the client certification file and the client private key file.

...

This tab provides a list of Azure Event Hub endpoints that the module should connect to to push tag data. One or more Azure Event Hub endpoints can be configured on this tab. Image RemovedImage Added

Clicking on the 'Create new Azure Event Hub ..' link will bring up the following form to add a new Azure Event Hub. The configuration sections available are Main, Store & Forward and Advanced

...

Image RemovedImage Added

• Store & Forward Enabled
  • Whether to enable Store & Forward capabilities for this endpoint
• Store & Forward Type
  • The type of the Store & Forward mechanism options: In_Memory and Disk_Backed (available in release 4.0.17 and higher)
  • Data stored with an In_Memory Store & Forward will not be persisted across a module configuration change, module disable/enable, module restart or power loss. 
  • Data stored with a Disk_Backed Store & Forward will persist across a module configuration change, module disable/enable, module restart or power loss
• Message Capacity - deprecated in 4.0.19
  • The maximum number of messages to store before dropping the oldest historical messages
• History Max Size
  • The maximum number of megabytes history can use before dropping the data
  • In_Memory Store & Forward will use the Ignition Java Heap memory
• History Max Age
  • The maximum number of minutes to store history before dropping the data
• Flush Period
  • The period of time to wait (in milliseconds) between sending when flushing messages

...

• Max Message Size
  • The maximum message size for the Azure Event Hub. Default is 262144 bytes (256KB). Generally, this should match the max message size allowed by the Event Hub.
    • EventHub Basic: 262144 bytes (256KB)
    • EventHub Standard or better: 1048576 bytes (1MB)
• Content Encoding
  • The content encoding of the data to push to Event Hub.
  • Current options are UTF_8, UTF_16 and UTF_32
• Azure Date/Time Format
  • The date/time format to use when pushing messages to IoT Hub
    • LONG_MS_SINCE_EPOCH (default) - The timestamp values will all be as numbers in milliseconds since epoch (Jan 1, 1970) in UTC
    • STRING_AZURE_COMPAT - The timestamp will be pushed as described here. This is useful when wanting to use 'edge' timestamps in Azure Time Series insights.
  • See Pushing Data to Azure Time Series Insights tutorial for more detail

Azure Event Hub Settings - Advanced Store & ForwardImage Added

• H2 Database Port
  • TCP Port to connect to H2 Database for Disk_Backed Store & Forward

Anchor
azureiotcentral azureiotcentral

Azure AnchorazureiotcentralazureiotcentralAzure IoT Central

This tab provides a list of Azure IoT Central endpoints that the module should connect to to push tag data. One or more Azure IoT Central endpoints can be configured on this tab.Image RemovedImage Added

Clicking on the 'Create new Azure IoT Central Setting.." link will bring up the following form to add a new Azure IoT Central. The configuration sections available are Main, Store & Forward and Advanced.

...

Image RemovedImage Added

• Store & Forward Enabled
  • Whether to enable Store & Forward capabilities for this endpoint
• Store & Forward Type
  • The type of the Store & Forward mechanism options: In_Memory and Disk_Backed (available in release 4.0.17 and higher)
  • Data stored with an In_Memory Store & Forward will not be persisted across a module configuration change, module disable/enable, module restart or power loss. 
  • Data stored with a Disk_Backed Store & Forward will persist across a module configuration change, module disable/enable, module restart or power loss
• Message Capacity - deprecated in 4.0.19
  • The maximum number of messages to store before dropping the oldest historical messages
• History Max Size
  • The maximum number of megabytes history can use before dropping the data
  • In_Memory Store & Forward will use the Ignition Java Heap memory
• History Max Age
  • The maximum number of minutes to store history before dropping the data
• Flush Period
  • The period of time to wait (in milliseconds) between sending when flushing messages

...

• Max Message Size
  • The maximum message size in bytes that any message can be when pushing to IoT Central.
• Azure Date/Time Format
  • The date/time format to use when pushing messages to IoT Hub
    • LONG_MS_SINCE_EPOCH (default) - The timestamp values will all be as numbers in milliseconds since epoch (Jan 1, 1970) in UTC
    • STRING_AZURE_COMPAT - The timestamp will be pushed as described here. This is useful when wanting to use 'edge' timestamps in Azure Time Series insights.
  • See Pushing Data to Azure Time Series Insights tutorial for more details

Azure IoT Central - Advanced Store & ForwardImage Added

• H2 Database Port
  • TCP Port to connect to H2 Database for Disk_Backed Store & Forward

Anchor
Anchor
sets sets

Sets

This tab contains a list of Azure Sets.  Each set represents a grouping of Azure IoT/Event Hub endpoints.  When a set is referenced by a Tag Agent, the Agent will push Tag data to all Azure IoT/Event Hub endpoints contained within that Set.

...

Anchor
tagagents tagagents

Tag Agents

Tag Agents are the workers within Azure Injector that monitor tag events, convert them define which tags will be picked up from the Ignition tag tree, converted to a JSON representation , and push them pushed to one or more Azure IoT Hub endpoints. Out of the box the Azure Injector module will have one "default" Tag Agent defined.

Tag Agents are configured to point to a single folder.  All Tags within that folder will be monitored by the Tag Agent. 

Image Removed

Tag Agents will monitor tags from a specific Tag Provider and, optionally, a specific Tag Path. If the tag folder hierarchy has been constructed as Group ID, Edge Node ID, and Device ID, then these will automatically be used when building up the JSON message payload which includes these in the topic.

If your tag folder hierarchy does not conform to this structure, you can explicitly define these required elements under the SparkPlug Settings section to be included when building the message topic.

Image Added

Clicking on the 'Create new Tag Agent Settings..Clicking on the 'Create new Tag Agent Settings..' link will bring up the following form to add a new Tag Agent. The configuration sections available are Agent Settings, Sparkplug Settings and Advanced

...

• Name
  • A unique name for the tag agent.
• Enabled
  • Sets whether the Tag Agent is enabled or disabled.  If disabled, the Tag Agent will not run and no data will be pushed to any configured endpoints.
• Tag Provider Name
  
  • The name of the Tag provider containing the tags.
• Tag Path
  • An optional folder path under the Tag provider where to the root folder of the Tags can be foundwhere the tag tree starts.
• Push Trigger
  • Defines what triggers a push to the cloud endpoint
    • EVENT_DRIVEN (default) - when a tag change event (value or quality) occurs, and no pending push exists, tag events will be aggregated for the 'Tag Pacing Period' before being pushed.  
    • PERIODIC - will push the latest data for all tags associated with the Agent every 'Tag Pacing Period'. With this option, only one event per tag will be sent and tag change events will not be captured.
• Tag Pacing Period
  • The buffer period, in milliseconds, that Tag events will be aggregated into a single payload before pushing.
•  Convert UDTs
  • Whether to convert UDT members to normal Tags before publishing.  If enabled the Tags representing the UDT member will retain their member path prefixed by the UDT Instance name.
• Publish UDT Definitions
  • This will only be used if 'Convert UDTs' is false  
  • Whether or not to push the UDT Definitions in the the NBIRTH messages
• Optimize UDTs
  • This will only be used if 'Convert UDTs' is false
  • Whether or not to 'convert UDTs' only for DATA messages.
• Set
  • The Set of Azure IoT Hub endpoints that the Tag Agent will push to.

...

Anchor
tagagentssparkplugsettings tagagentssparkplugsettings

Tag Agents - Sparkplug Settings

Image Modified

• Group ID
  • An ID representing a logical grouping of MQTT Edge Of Network (EoN) Nodes and Devices into the infrastructure.
• Edge Node ID
  • An ID that uniquely identifies the MQTT Edge Of Network (EoN) Node within the infrastructure.
• Device ID
  • An optional ID that uniquely identifies a Device within the infrastructure.

The Sparkplug settings are optional and allow for an additional customization of how the Tag Agent scans and discovers tag within the specified Tag Path.  Here is a brief description of how the Agent scans/discovers folders based on the different combinations of potential Sparkplug Settings.

• If all three IDs are left blank the Agent will assume the following folder structures follow the Tag Path:
  • <groupFolder>/<edgeNodeFolder>/<deviceFolder>/<tags>
  • <groupFolder>/<edgeNodeFolder>/<tags>
    
• If only the Group ID is specified the Agent will assume the following folder structure follows the Tag Path:
  • <edgeNodeFolder>/<deviceFolder>/<tags>
  • <edgeNodeFolder>/<tags>
    
• If the Group ID and the Edge Node ID are specified the Agent will assume the following folder structure follows the Tag Path:
  
  • <deviceFolder>/<tags>
  • <tags>
• If the Group ID, Edge Node ID, and the Device ID are specified the Agent will assume the following folder structure follows the Tag Path:
  
  • <tags>

...

• • .

Anchor
tagagentsadvanced tagagentsadvanced

Tag Agents - Advanced

...