You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a questions regarding the data format of the payload that is send from OPC UA IoT-Agent to the nothbound interface (to Orion-LD in my case).
Issue
In my scenario I am using two OPC UA IoT-Agents for 1) a weather station and 2) process control system. The payload send to the northbound interface from both IoT-Agents is different, so that data for the first data source is stored as numeric values and the data for the second data source is stored as compound values for short-time-history at Orion-LD. Orion-LD just stores the data as it comes in, so I compared the payloads from IoT-Agents and noticed that they are different (see FIWARE/context.Orion-LD#1651). I'd like to store the data of both data sources as numeric values, so I am asking myself why the IoT-Agent sends data as composed values in the second case and not in the same format than the first data source.
Payload from OPC UA Agent
Comparing the payload send from OPC UA agent to Orion-LD we can see that the data is provided as numeric value for the first data source and as compound value for the second data source from OPC UA agent. I got the payload from OPC UA agent logs…
Data send to Orion-LD for the first weather station source:
Comparing the data scheme of both sources I don't see any differences when I check the schema.yaml file (which is the base for generation of the related @context file).
# FROM FIRST DATASOURCE
WeatherObserved:
description: "Weather conditions"
properties:
windSpeed:
description: Intensity of the wind
minimum: 0
type: number
x-ngsi:
model: http//schema.org/Number
type: Property
…
# FROM SECOND DATASOURCE
…
TurbineBearing:
description: "Process management system component 'Turbine bearing'"
properties:
0MAD10CT001_Temp_Lager_P84_1_U:
description: "0MAD10CT001/Temp_Lager_P84_1.U: Turbine bearing Nr. 10 Measuring circuit Temperature Nr. 001 (Analog value measurement)"
type: "number"
x-ngsi:
model: "https://schema.org/Number"
type: "Property"
...
OPC UA Agent configuration
There are some differences regarding agent configuration:
• For the first data source I am using agent version 2.1.4
• For the second data source I am using agent version 2.2.7 (because I need the variable expressLimit for big payloads)
Because of the version change I have some more configuration options for the second data source, but the configuration seems to be almost identical from my point of view. Here is the full configuration file for both sources (with data models shortened because of the sizes).
First datasource:
/*
* Copyright 2022 Engineering Ingegneria Informatica S.p.A.
*
* This file is part of iotagent-opcua
*
* iotagent-opcua is free software: you can redistribute it and/or
* modify it under the terms of the GNU Affero General Public License as
* published by the Free Software Foundation, either version 3 of the License,
* or (at your option) any later version.
*
* iotagent-opcua is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU Affero General Public License for more details.
*
* You should have received a copy of the GNU Affero General Public
* License along with iotagent-opcua.
* If not, see http://www.gnu.org/licenses/.
*
* For those usages not covered by the GNU Affero General Public License
* please contact with::[[email protected], [email protected], [email protected], [email protected]]
*/
var config = {};
config.iota = {
/**
* Configures the log level. Appropriate values are: FATAL, ERROR, INFO, WARN and DEBUG.
*/
logLevel: 'DEBUG',
/**
* When this flag is active, the IoTAgent will add the TimeInstant attribute to every entity created, as well
* as a TimeInstant metadata to each attribute, with the current timestamp.
*/
timestamp: true,
/**
* Context Broker configuration. Defines the connection information to the instance of the Context Broker where
* the IoT Agent will send the device data.
*/
contextBroker: {
/**
* Host where the Context Broker is located.
*/
host: 'orion-ld',
/**
* Port where the Context Broker is listening.
*/
port: '1026',
/**
* Version of the Context Broker (v2 or ld)
*/
ngsiVersion: 'ld',
/**
* JSON LD Context
*/
jsonLdContext: 'http://ld-context/ld-context/datamodels.context-ngsild.jsonld',
/**
* Used as fallbackTenant
*/
service: 'opcua_meteo',
/**
* Used as fallbackPath
*/
subservice: '/weather'
},
/**
* Configuration of the North Port of the IoT Agent.
*/
server: {
/**
* Port where the IoT Agent will be listening for NGSI and Provisioning requests.
*/
port: 4042
},
/**
* Configuration for secured access to instances of the Context Broker secured with a PEP Proxy.
* For the authentication mechanism to work, the authentication attribute in the configuration has to be fully
* configured, and the authentication.enabled subattribute should have the value `true`.
*
* The Username and password should be considered as sensitive data and should not be stored in plaintext.
* Either encrypt the config and decrypt when initializing the instance or use environment variables secured by
* docker secrets.
*/
//authentication: {
//enabled: false,
/**
* Type of the Identity Manager which is used when authenticating the IoT Agent.
*/
//type: 'keystone',
/**
* Name of the additional header passed to hold the identity of the IoT Agent
*/
//header: 'X-Auth-Token',
/**
* Hostname of the Identity Manager.
*/
//host: 'localhost',
/**
* Port of the Identity Manager.
*/
//port: '5000',
/**
* Username for the IoT Agent - Note this should not be stored in plaintext.
*/
//user: 'IOTA_AUTH_USER',
/**
* Password for the IoT Agent - Note this should not be stored in plaintext.
*/
//password: 'IOTA_AUTH_PASSWORD',
/**
* OAuth2 client ID - Note this should not be stored in plaintext.
*/
//clientId: 'IOTA_AUTH_CLIENT_ID',
/**
* OAuth2 client secret - Note this should not be stored in plaintext.
*/
//clientSecret: 'IOTA_AUTH_CLIENT_SECRET'
//},
/**
* Defines the configuration for the Device Registry, where all the information about devices and configuration
* groups will be stored. There are currently just two types of registries allowed:
*
* - 'memory': transient memory-based repository for testing purposes. All the information in the repository is
* wiped out when the process is restarted.
*
* - 'mongodb': persistent MongoDB storage repository. All the details for the MongoDB configuration will be read
* from the 'mongodb' configuration property.
*/
deviceRegistry: {
type: 'mongodb'
},
/**
* Mongo DB configuration section. This section will only be used if the deviceRegistry property has the type
* 'mongodb'.
*/
mongodb: {
/**
* Host where MongoDB is located. If the MongoDB used is a replicaSet, this property will contain a
* comma-separated list of the instance names or IPs.
*/
host: 'iot-mongo-db',
/**
* Port where MongoDB is listening. In the case of a replicaSet, all the instances are supposed to be listening
* in the same port.
*/
port: '27017',
/**
* Name of the Mongo database that will be created to store IoT Agent data.
*/
db: 'iotagent_opcua'
},
/**
* Types array for static configuration of services. Check documentation in the IoT Agent Library for Node.js for
* further details:
*
* https://github.com/Engineering-Research-and-Development/iotagent-opcua/blob/master/docs/quick_start_guide.md
*/
types: {
WeatherObserved: {
active: [
{
name: 'directIrradiation',
type: 'Number'
},
{
name: 'solarRadiation',
type: 'Number'
},
…
],
lazy: [],
commands: []
}
},
contexts: [
{
id: 'urn:ngsi-ld:WeatherObserved:meteostation-01',
type: 'WeatherObserved',
mappings: [
{
ocb_id: 'directIrradiation',
opcua_id: 'ns=5;s=SPS313SC//AI STJ 2',
object_id: 'ns=5;s=SPS313SC//AI STJ 2',
inputArguments: []
},
{
ocb_id: 'diffuseIrradiation',
opcua_id: 'ns=5;s=SPS313SC//AI STJ 3',
object_id: 'ns=5;s=SPS313SC//AI STJ 3',
inputArguments: []
},
…
]
}
],
contextSubscriptions: [
{
id: 'urn:ngsi-ld:Device:STJ-Meteo-01',
type: 'Device',
mappings: [
{
ocb_id: 'directIrradiation',
opcua_id: 'ns=5;s=SPS313SC//AI STJ 2',
object_id: 'ns=5;s=SPS313SC//AI STJ 2',
inputArguments: []
},
{
ocb_id: 'diffuseIrradiation',
opcua_id: 'ns=5;s=SPS313SC//AI STJ 3',
object_id: 'ns=5;s=SPS313SC//AI STJ 3',
inputArguments: []
},
…
]
}
],
events: [],
/**
* Default service, for IoT Agent installations that won't require preregistration.
*/
service: 'opcua_meteo',
/**
* Default subservice, for IoT Agent installations that won't require preregistration.
*/
subservice: '/weather',
/**
* URL Where the IoT Agent Will listen for incoming updateContext and queryContext requests (for commands and
* passive attributes). This URL will be sent in the Context Registration requests.
*/
providerUrl: 'http://localhost:4042/',
/**
* Default maximum expire date for device registrations.
*/
deviceRegistrationDuration: 'P20Y',
/**
* Default type, for IoT Agent installations that won't require preregistration.
*/
defaultType: 'WeatherObserved',
/**
* Default resource of the IoT Agent. This value must be different for every IoT Agent connecting to the IoT
* Manager.
*/
defaultResource: '/iot/opcua_meteo',
/**
* flag indicating whether the incoming measures to the IoTAgent should be processed as per the "attributes" field.
*/
explicitAttrs: false
};
config.opcua = {
/**
* Subscription options for OPC UA connection.
*/
subscription: {
maxNotificationsPerPublish: 1000,
publishingEnabled: true,
// request every second
requestedLifetimeCount: 1000,
requestedMaxKeepAliveCount: 10,
requestedPublishingInterval: 1000,
priority: 128
},
/**
* Endpoint where the IoT Agent will listen for an active OPC UA Server.
*/
endpoint: 'opc.tcp://<ip-address>:48050',
/**
* Security Mode to access OPC UA Server.
*/
securityMode: 'None',
/**
* Security Policy to access OPC UA Server.
*/
securityPolicy: 'None',
/**
* Username to access OPC UA Server.
*/
username: null,
/**
* Password to access OPC UA Server.
*/
password: null,
/**
* Flag indicating whether the OPC uA variables readings should be handled as single subscription.
*/
uniqueSubscription: false
};
config.mappingTool = {
/**
* Boolean property to assess whether enable polling in MappingTool or not
*/
polling: false,
/**
* agentId prefix to be assigned to the newly generated entity from MappingTool execution
*/
agentId: 'age02_',
/**
* Namespaces to ignore when crawling nodes from OPC UA Server
*/
namespaceIgnore: '0,1,2,3,4',
/**
* entityId to be assigned to the newly generated entity from MappingTool execution
*/
entityId: 'age02_Meteostation',
/**
* entityType to be assigned to the newly generated entity from MappingTool execution
*/
entityType: 'WeatherObserved',
/**
* boolean flag to determine whether to store the output of the mapping tool execution or not
*/
storeOutput: true,
/**
* List of characters to be filtered before forwarding any request to Orion.
* Default Orion forbidden characters are filtered by default, see (https://github.com/telefonicaid/fiware-orion/blob/74aaae0c98fb24f082e3b258aa642461eb285e39/doc/manuals/orion-api.md#general-syntax-restrictions)
*/
extendedForbiddenCharacters: []
};
/**
* map {name: function} of extra transformations avaliable at JEXL plugin
* see https://github.com/telefonicaid/iotagent-node-lib/tree/master/doc/expressionLanguage.md#available-functions
*/
config.jexlTransformations = {};
/**
* flag indicating whether the incoming notifications to the IoTAgent should be processed using the bidirectionality
* plugin from the latest versions of the library or the OPCUA-specific configuration retrieval mechanism.
*/
config.configRetrieval = false;
/**
* Default API Key, to use with device that have been provisioned without a Configuration Group.
*/
config.defaultKey = 'iot';
/**
* Default transport protocol when no transport is provisioned through the Device Provisioning API.
*/
config.defaultTransport = 'OPCUA';
/**
* flag indicating whether the node server will be executed in multi-core option (true) or it will be a
* single-thread one (false).
*/
//config.multiCore = false;
/**
* flag indicating whether or not to provision the Group and Device automatically
*/
config.autoprovision = true;
module.exports = config;
Second datasource:
/*
* Copyright 2022 Engineering Ingegneria Informatica S.p.A.
*
* This file is part of iotagent-opcua
*
* iotagent-opcua is free software: you can redistribute it and/or
* modify it under the terms of the GNU Affero General Public License as
* published by the Free Software Foundation, either version 3 of the License,
* or (at your option) any later version.
*
* iotagent-opcua is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* See the GNU Affero General Public License for more details.
*
* You should have received a copy of the GNU Affero General Public
* License along with iotagent-opcua.
* If not, see http://www.gnu.org/licenses/.
*
* For those usages not covered by the GNU Affero General Public License
* please contact with::[[email protected], [email protected], [email protected], [email protected]]
*/
const config = {};
config.iota = {
/**
* Configures the log level. Appropriate values are: FATAL, ERROR, INFO, WARN and DEBUG.
*/
logLevel: 'DEBUG',
/**
* When this flag is active, the IoTAgent will add the TimeInstant attribute to every entity created, as well
* as a TimeInstant metadata to each attribute, with the current timestamp.
*/
timestamp: true,
/**
* Context Broker configuration. Defines the connection information to the instance of the Context Broker where
* the IoT Agent will send the device data.
*/
contextBroker: {
/**
* Host where the Context Broker is located.
*/
host: 'orion-ld',
/**
* Port where the Context Broker is listening.
*/
port: '1026',
/**
* Version of the Context Broker (v2 or ld)
*/
ngsiVersion: 'ld',
/**
* JSON LD Context
*/
jsonLdContext: 'http://ld-context/ld-context/datamodels.context-ngsild.jsonld',
/**
* Used as fallbackTenant
*/
service: 'opcua_pcs',
/**
* Used as fallbackPath
*/
subservice: '/pcs'
},
/**
* Configuration of the North Port of the IoT Agent.
*/
server: {
/**
* Port where the IoT Agent will be listening for NGSI and Provisioning requests.
*/
port: 4043
},
/**
* Configuration for secured access to instances of the Context Broker secured with a PEP Proxy.
* For the authentication mechanism to work, the authentication attribute in the configuration has to be fully
* configured, and the authentication.enabled subattribute should have the value `true`.
*
* The Username and password should be considered as sensitive data and should not be stored in plaintext.
* Either encrypt the config and decrypt when initializing the instance or use environment variables secured by
* docker secrets.
*/
//authentication: {
//enabled: false,
/**
* Type of the Identity Manager which is used when authenticating the IoT Agent.
*/
//type: 'keystone',
/**
* Name of the additional header passed to hold the identity of the IoT Agent
*/
//header: 'X-Auth-Token',
/**
* Hostname of the Identity Manager.
*/
//host: 'localhost',
/**
* Port of the Identity Manager.
*/
//port: '5000',
/**
* Username for the IoT Agent - Note this should not be stored in plaintext.
*/
//user: 'IOTA_AUTH_USER',
/**
* Password for the IoT Agent - Note this should not be stored in plaintext.
*/
//password: 'IOTA_AUTH_PASSWORD',
/**
* OAuth2 client ID - Note this should not be stored in plaintext.
*/
//clientId: 'IOTA_AUTH_CLIENT_ID',
/**
* OAuth2 client secret - Note this should not be stored in plaintext.
*/
//clientSecret: 'IOTA_AUTH_CLIENT_SECRET'
//},
/**
* Defines the configuration for the Device Registry, where all the information about devices and configuration
* groups will be stored. There are currently just two types of registries allowed:
*
* - 'memory': transient memory-based repository for testing purposes. All the information in the repository is
* wiped out when the process is restarted.
*
* - 'mongodb': persistent MongoDB storage repository. All the details for the MongoDB configuration will be read
* from the 'mongodb' configuration property.
*/
deviceRegistry: {
type: 'mongodb'
},
/**
* Mongo DB configuration section. This section will only be used if the deviceRegistry property has the type
* 'mongodb'.
*/
mongodb: {
/**
* Host where MongoDB is located. If the MongoDB used is a replicaSet, this property will contain a
* comma-separated list of the instance names or IPs.
*/
host: 'iot-mongo-db',
/**
* Port where MongoDB is listening. In the case of a replicaSet, all the instances are supposed to be listening
* in the same port.
*/
port: '27017',
/**
* Name of the Mongo database that will be created to store IoT Agent data.
*/
db: 'iotagent_opcua'
},
/**
* Types array for static configuration of services. Check documentation in the IoT Agent Library for Node.js for
* further details:
*
* https://github.com/Engineering-Research-and-Development/iotagent-opcua/blob/master/docs/quick_start_guide.md
*/
types: {
Building: {
active: [
{
name: "0ULX20CT001_TempTmSeWdOst_VSTATUS",
type: "https://schema.org/Number"
},
{
name: "0ULX20CP002_Dr2_Rec_Ost_U",
type: "https://schema.org/Number"
},
...
],
lazy: [],
commands: []
}
},
contexts: [
{
id: "urn:ngsi-ld:PCS-STJ:Building",
type: "Building",
mappings: [
{
ocb_id: "0ULX20CT001_TempTmSeWdOst_VSTATUS",
opcua_id: "ns=5;s=0ULX20CT001//TempTmSeWdOst.VSTATUS",
object_id: "ns=5;s=0ULX20CT001//TempTmSeWdOst.VSTATUS",
inputArguments: []
},
{
ocb_id: "0ULX20CP002_Dr2_Rec_Ost_U",
opcua_id: "ns=5;s=0ULX20CP002//Dr2_Rec_Ost.U",
object_id: "ns=5;s=0ULX20CP002//Dr2_Rec_Ost.U",
inputArguments: []
},
...
]
}
],
contextSubscriptions: [
{
id: "urn:ngsi-ld:PCS-STJ:Building",
type: "Building",
mappings: [
{
ocb_id: "0ULX20CT001_TempTmSeWdOst_VSTATUS",
opcua_id: "ns=5;s=0ULX20CT001//TempTmSeWdOst.VSTATUS",
object_id: "ns=5;s=0ULX20CT001//TempTmSeWdOst.VSTATUS",
inputArguments: []
},
{
ocb_id: "0ULX20CP002_Dr2_Rec_Ost_U",
opcua_id: "ns=5;s=0ULX20CP002//Dr2_Rec_Ost.U",
object_id: "ns=5;s=0ULX20CP002//Dr2_Rec_Ost.U",
inputArguments: []
},
...
]
}
],
events: [],
/**
* Default service, for IoT Agent installations that won't require preregistration.
*/
service: 'opcua_pcs',
/**
* Default subservice, for IoT Agent installations that won't require preregistration.
*/
subservice: '/pcs',
/**
* URL Where the IoT Agent Will listen for incoming updateContext and queryContext requests (for commands and
* passive attributes). This URL will be sent in the Context Registration requests.
*/
providerUrl: 'http://localhost:4043/',
/**
* Default maximum expire date for device registrations.
*/
deviceRegistrationDuration: 'P20Y',
/**
* Default type, for IoT Agent installations that won't require preregistration.
*/
defaultType: 'PCS',
/**
* Default resource of the IoT Agent. This value must be different for every IoT Agent connecting to the IoT
* Manager.
*/
defaultResource: '/iot/opcua_pcs',
/**
* Flag indicating whether the incoming measures to the IoTAgent should be processed as per the "attributes" field.
*/
explicitAttrs: false,
/**
* List of characters to be filtered before forwarding any request to Orion.
* Default Orion forbidden characters are filtered by default, see (https://github.com/telefonicaid/fiware-orion/blob/74aaae0c98fb24f082e3b258aa642461eb285e39/doc/manuals/orion-api.md#general-syntax-restrictions)
*/
extendedForbiddenCharacters: [],
/**
* Flag indicating whether to provision the Group and Device automatically
*/
autoprovision: true,
/**
* Default limit for express router built into iotagent-node-lib module
*/
expressLimit: '1000mb'
};
config.opcua = {
/**
* Subscription options for OPC UA connection.
*/
subscription: {
maxNotificationsPerPublish: 1000,
publishingEnabled: true,
requestedLifetimeCount: 100,
requestedMaxKeepAliveCount: 10,
requestedPublishingInterval: 1000,
priority: 128
},
/**
* Endpoint where the IoT Agent will listen for an active OPC UA Server.
*/
endpoint: 'opc.tcp://<ip-address>:48050',
/**
* Security Mode to access OPC UA Server.
*/
securityMode: 'None',
/**
* Security Policy to access OPC UA Server.
*/
securityPolicy: 'None',
/**
* Username to access OPC UA Server.
*/
username: null,
/**
* Password to access OPC UA Server.
*/
password: null,
/**
* Flag indicating whether the OPC uA variables readings should be handled as single subscription.
*/
uniqueSubscription: false
};
config.mappingTool = {
/**
* Boolean property to assess whether enabling polling in MappingTool or not
*/
polling: false,
/**
* agentId prefix to be assigned to the newly generated entity from MappingTool execution
*/
agentId: 'age03_',
/**
* Namespaces to ignore when crawling nodes from OPC UA Server
*/
namespaceIgnore: '',
/**
* entityId to be assigned to the newly generated entity from MappingTool execution
*/
entityId: 'age03_PCS',
/**
* entityType to be assigned to the newly generated entity from MappingTool execution
*/
entityType: 'PCS',
/**
* boolean flag to determine whether to store the output of the mapping tool execution or not
*/
storeOutput: true
};
/**
* Flag indicating which configuration type to perform. Possible choices are:
* - auto : mappingTool will be run and runtime device mappings will be loaded
* - dynamic : device mappings from config.js will be ignored, REST API Provisioning is mandatory
* - static : device mappings from config.js will be loaded
*/
config.configurationType = 'static';
/**
* map {name: function} of extra transformations avaliable at JEXL plugin
* see https://github.com/telefonicaid/iotagent-node-lib/tree/master/doc/expressionLanguage.md#available-functions
*/
config.jexlTransformations = {};
/**
* Flag indicating whether the incoming notifications to the IoTAgent should be processed using the bidirectionality
* plugin from the latest versions of the library or the OPCUA-specific configuration retrieval mechanism.
*/
config.configRetrieval = false;
/**
* Default API Key, to use with device that have been provisioned without a Configuration Group.
*/
config.defaultKey = 'iot';
/**
* Default transport protocol when no transport is provisioned through the Device Provisioning API.
*/
config.defaultTransport = 'OPCUA';
/**
* Flag indicating whether the node server will be executed in multi-core option (true) or it will be a
* single-thread one (false).
*/
//config.multiCore = false;
module.exports = config;
Question
Can I somehow influence if the data is send as numeric or compound value format in the payload of the request of OPC UA iot agent to the northbound interface? I'd like to change something, so that the data is also send as numeric for the second data source. As the data schema has the same structure and there is no configuration option for compound vs. numeric value format in the agent configuration file, I am not sure how to influence the behavior of the agent.
Greetings and thank you in advance!
The text was updated successfully, but these errors were encountered:
Hi @IngMiad, you should try removing the schema url from type definitions
eg: "https://schema.org/Number" -> "Number"
Could you give it a try? Let us know, best regards!
Remark: In addition to removing the schema url from type definition, I had to remove the earlier devices entries from iot-agent mongo-db otherwise it still uses compound format.
Hi there,
I have a questions regarding the data format of the payload that is send from OPC UA IoT-Agent to the nothbound interface (to Orion-LD in my case).
Issue
In my scenario I am using two OPC UA IoT-Agents for 1) a weather station and 2) process control system. The payload send to the northbound interface from both IoT-Agents is different, so that data for the first data source is stored as numeric values and the data for the second data source is stored as compound values for short-time-history at Orion-LD. Orion-LD just stores the data as it comes in, so I compared the payloads from IoT-Agents and noticed that they are different (see FIWARE/context.Orion-LD#1651). I'd like to store the data of both data sources as numeric values, so I am asking myself why the IoT-Agent sends data as composed values in the second case and not in the same format than the first data source.
Payload from OPC UA Agent
Comparing the payload send from OPC UA agent to Orion-LD we can see that the data is provided as numeric value for the first data source and as compound value for the second data source from OPC UA agent. I got the payload from OPC UA agent logs…
Data send to Orion-LD for the first weather station source:
The data from the second process control station data source is provided to Orion-LD like that:
Data Model for both sources
Comparing the data scheme of both sources I don't see any differences when I check the schema.yaml file (which is the base for generation of the related @context file).
OPC UA Agent configuration
There are some differences regarding agent configuration:
• For the first data source I am using agent version 2.1.4
• For the second data source I am using agent version 2.2.7 (because I need the variable expressLimit for big payloads)
Because of the version change I have some more configuration options for the second data source, but the configuration seems to be almost identical from my point of view. Here is the full configuration file for both sources (with data models shortened because of the sizes).
First datasource:
Second datasource:
Question
Can I somehow influence if the data is send as numeric or compound value format in the payload of the request of OPC UA iot agent to the northbound interface? I'd like to change something, so that the data is also send as numeric for the second data source. As the data schema has the same structure and there is no configuration option for compound vs. numeric value format in the agent configuration file, I am not sure how to influence the behavior of the agent.
Greetings and thank you in advance!
The text was updated successfully, but these errors were encountered: