i4connected Knowledgebase 5.6

i4connected Import Service JSON examples

Abstract

Check out this article and learn more details about the newly introduced i4connected addon, the import Service.

As indicated by the dedicated article, the Import Configuration function allows you to create or update multiple entities, by providing the following parameters:

Entity

Parameters

Example

Roles

In order to create or update Roles, the following parameters need to be defined:

  • name - role name.

  • isPrivileged - boolean.

  • isDefault - boolean.

  • isFrontEnd - boolean.

  • manageConfiguration - boolean.

  • manageSharedFilters - boolean.

  • manageSharedTiles - boolean.

  • managePersonalTiles - boolean.

  • importAppend - boolean.

  • importOverwrite - boolean.

  • configureSecurity - boolean.

  • configurePrivilegedSecurity - boolean.

  • viewUsers - boolean.

  • viewAllUsers - boolean.

  • manageUsers - boolean.

  • changePassword - boolean.

  • viewSitesAreas - boolean.

  • viewOrgUnits - boolean.

  • manageOrgUnits - boolean.

  • viewDevices - boolean.

  • manageDevices - boolean.

  • viewAdapters - boolean.

  • manageAdapters - boolean.

  • readSignals - boolean.

  • writeSignals - boolean.

  • viewEvents - boolean.

  • manageEvents - boolean.

  • closeEventOccurrences - boolean.

  • acknowledgeEventOccurrences - boolean.

  • takeEventOccurenceOwnership - boolean.

  • assignEventOccurrenceOwnership - boolean.

  • changeEventOccurrencePriority - boolean.

  • commentEventOccurrences - boolean.

  • viewEventOccurrenceComments - boolean.

  • viewEventOccurrenceHistory - boolean.

  • viewEventLogbook - boolean.

  • viewAuditLog - boolean.

  • manageMessenger - boolean.

  • manageReportDefinitions - boolean.

  • scheduleReports - boolean.

  • useDistributionLists - boolean.

  • reportArchive - boolean.

  • manageMeasureAction - boolean.

  • importMeasureAction - boolean.

  • viewMeasureAction - boolean.

  • manageManualCounter - boolean.

  • requisitionNoteHallManager - boolean.

  • requisitionNotePowerPlantUser - boolean.

  • viewAllAdapters - boolean.

  • viewAllUserInvitations - boolean.

  • viewAllSitesAreas - boolean.

  • viewAllOrgUnits - boolean.

  • viewApplications - boolean.

  • manageApplications - boolean.

  • viewAllApplications - boolean.

  • editMeasurementHistory - boolean.

  • viewReportDefinitions - boolean.

  • viewAllReportDefinitions - boolean.

  • manage Personal Panels - boolean.

  • pinSharedPanels - boolean.

  • unpinSharedPanels - boolean.

  • manageEventScripts - boolean.

  • manageVirtualSignals - boolean.

  • manageUserAccounts - boolean.

  • manageEmailEventScripts - boolean.

  • viewResponseTeams - boolean.

  • manageResponseTeams - boolean.

  • viewAllResponseTeams - boolean.

  • viewNotificationProfiles - boolean.

  • manageNotificationProfiles - boolean.

  • viewAllNotificationProfiles - boolean.

  • manageRolePackages - boolean.

  • manageSiteUsers - boolean.

  • manageSiteApplications - boolean.

  • manageSiteMeasureAggregations

  • manageSitePublicHolidays - boolean.

  • manageSiteResponseTeams - boolean.

  • publishSiteEvents - boolean.

  • manageAreaUsers - boolean.

  • manageAreaApplications - boolean.

  • manageAreaMeasureAggregations - boolean.

  • manageAreaResponseTeams - boolean.

  • publishAreaEvents - boolean.

  • manageOrgUnitUsers boolean.

  • manageOrgUnitApplications - boolean.

  • manageOrgUnitMeasureAggregations - boolean.

  • manageOrgUnitResponseTeams - boolean.

  • publishOrgUnit Events - boolean.

  • manageDeviceUsers - boolean.

  • manageDeviceApplications - boolean.

  • manageDeviceResponseTeams - boolean.

  • publishDeviceEvents - boolean.

  • viewServerEvents - boolean.

  • manageOwnComponentConfiguration - boolean.

  • manageSharedComponentConfiguration - boolean.

  • viewEventOccurrences - boolean.

  • linkedRoleNames - string, [roleNames].

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{   
 "roles": [{
        "name": "",
        "isPrivileged": ,
        "isDefault": ,
        "isFrontEnd": ,
        "manageConfiguration": ,
        "manageSharedFilters": ,
        "manageSharedTiles": ,
        "managePersonalTiles": ,
        "importAppend": ,
        "importOverwrite": ,
        "configureSecurity": ,
        "configurePrivilegedSecurity": ,
        "viewUsers": ,
        "viewAllUsers": ,
        "manageUsers": ,
        "changePassword": ,
        "viewSitesAreas": ,
        "manageSitesAreas": ,
        "viewOrgUnits": ,
        "manageOrgUnits": ,
        "viewDevices": ,
        "manageDevices": ,
        "viewAdapters": ,
        "manageAdapters": ,
        "readSignals": ,
        "writeSignals": ,
        "viewEvents": ,
        "manageEvents": ,
        "closeEventOccurrences": ,
        "acknowledgeEventOccurrences": ,
        "takeEventOccurrenceOwnership": ,
        "assignEventOccurrenceOwnership": ,
        "changeEventOccurrencePriority": ,
        "commentEventOccurrences": ,
        "viewEventOccurrenceComments": ,
        "viewEventOccurrenceHistory": ,
        "viewEventLogbook": ,
        "viewAuditLog": ,
        "manageMessenger": ,
        "manageReportDefinitions": ,
        "scheduleReports": ,
        "useDistributionLists": ,
        "reportArchive": ,
        "manageMeasureAction": ,
        "importMeasureAction": ,
        "viewMeasureAction": ,
        "manageManualCounter": ,
        "requisitionNoteHallManager": ,
        "requisitionNotePowerPlantUser": ,
        "viewAllAdapters" : ,
        "viewAllUserInvitations" : ,
        "viewAllSitesAreas" : ,
        "viewAllOrgUnits" : ,
        "viewApplications" : ,
        "manageApplications" : ,
        "viewAllApplications" : ,
        "editMeasurementHistory" : ,
        "viewReportDefinitions" : ,
        "viewAllReportDefinitions" : ,
        "managePersonalPanels" : ,
        "pinSharedPanels" : ,
        "unpinSharedPanels" : ,
        "manageEventScripts" : ,
        "manageVirtualSignals" : ,
        "manageUserAccounts" : ,
        "manageEmailEventScripts" : ,
        "viewResponseTeams" : ,
        "manageResponseTeams" : ,
        "viewAllResponseTeams" : ,
        "viewNotificationProfiles" : ,
        "manageNotificationProfiles" : ,
        "viewAllNotificationProfiles" : ,
        "manageRolePackages" : ,
        "manageSiteUsers" : ,
        "manageSiteApplications" : ,
        "manageSiteMeasureAggregations" : ,
        "manageSitePublicHolidays" : ,
        "manageSiteResponseTeams" : ,
        "publishSiteEvents" : ,
        "manageAreaUsers" : ,
        "manageAreaApplications" : ,
        "manageAreaMeasureAggregations" : ,
        "manageAreaResponseTeams" : ,
        "publishAreaEvents" : ,
        "manageOrgUnitUsers" : ,
        "manageOrgUnitApplications" : ,
        "manageOrgUnitMeasureAggregations" : ,
        "manageOrgUnitResponseTeams" : ,
        "publishOrgUnitEvents" : ,
        "manageDeviceUsers" : ,
        "manageDeviceApplications" : ,
        "manageDeviceResponseTeams" : ,
        "publishDeviceEvents" : ,
        "viewServerEvents" : ,
        "manageOwnComponentConfigurations" : ,
        "manageSharedComponentConfigurations" : ,
        "viewEventOccurrences" : ,
        "linkedRoleNames": [""]
    }]
}

Role packages

In order to create or update Role packages, the following parameters need to be defined:

  • name - name of the role package.

  • description - string.

  • globalRoleNames - array of strings.

  • entityRoleNames - array of string.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{    
"rolePackages": [{
        "name": "",
        "description": "",
        "globalRoleNames": [""],
        "entityRoleNames": [""]
    }]
}

Sites

In order to create or update Sites, the following parameters need to be defined:

Important

When creating new entities, the parameters marked with an asterisk (*) are mandatory. When updating an entity, the parameters marked with an asterisk (*) need to be an exact match with the existing entity.

  • name* - unique in the system.

  • addressLine - e.g. "Nicolaus Olahus 3"

  • postalCode - e.g. "123456".

  • city - e.g. "Sibiu", "Buchen".

  • country * - e.g. "Germany", "United States".

  • latitude - float.

  • longitude - float.

  • siteType - name of the site type, should be in the system.

    Note: If the siteType is not in the sytem, it will be created with default values.

  • subpage - link fragment of the page, the page should be in the system.

  • measureAggregations - aggregation for measureGroup/ measureType pair should be in the system.

    • measureGroup * - name of the measure group.

    • measureType * - name of the measure type.

  • userAssignments

    • userName - string.

    • roleNames - array of strings.

    • rolePackageName - string, collection of user/roles which should be directly assigned.

      Note: If the rolePackageName exists, roleNames should be ignored.

Note

Please note that the Import Configuration function does not support Custom Fields Definitions (metadata) imports. Therefore, when updating via import an entity that already has metadata defined, the metadata will not be affected.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{   
 "sites":[{
        "name": "", 
        "addressLine": "",
        "postalCode": "",
        "city": "",
        "country": "",
        "latitude": , 
        "longitude": , 
        "siteType": "", 
        "subpage": "",
        "measureAggregations": [
            {
                "measureGroup": "", 
                "measureType": ""
            }
        ],
        "userAssignments": [{
            "userName": "",
            "roleNames": [""],    
            "rolePackageName": ""
        }], 
    }]
}

Areas

In order to create or update Areas, the following parameters need to be defined:

Note

When creating new entities, the parameters marked with an asterisk (*) are mandatory. When updating an entity, the parameters marked with an asterisk (*) need to be an exact match with the existing entity.

  • siteName * - name of the site

  • path * - specifies the Site parent names distributed between square brackets, as an array of strings, where each string should be placed between quotation marks. Listed Sites should be in the system/JSON.

    Because root area name should be unique in site scope, child area should be unique in parent area scope.

  • page - name of the page.

  • measureAggregations - aggregation for measureGroup/ measureType pair should be in the system / JSON file.

    • measureGroup* - name of the measure group.

    • measureType* - name of the measure type.

  • userAssignments

    • userName - string.

    • rolePackageName - array of strings, collection of user/roles that should be directly assigned.

Note

Please note that the Import Configuration function does not support Custom Fields Definitions (metadata) imports. Therefore, when updating via import an entity that already has metadata defined, the metadata will not be affected.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{
 "areas": [{
		"siteName": "",
		"path": [
			"",
			"",
		],
		"page": ,
		"measureAggregations": [{
			"measureGroup": "",
			"measureType": ""
		}],
		"userAssignments": [{
			"userName": "",
			"rolePackageName": [""]
		}]
	}]
}

Organizational Units

In order to create or update Organizational Units, the following parameters need to be defined:

Note

When creating new entities, the parameters marked with an asterisk (*) are mandatory. When updating an entity, the parameters marked with an asterisk (*) need to be an exact match with the existing entity.

  • path* - specifies the OrgUnit parent names distributed between square brackets, as an array of strings, where each string should be placed between quotation marks. Listed OrgUnits should be in the system/JSON. 

    Because root orgunit name should be unique in installation scope, child orgunit should be unique in parent orgunit scope.

  • alias - alias.

  • userAssignments

    • userName - string.

    • roleNames - string.

    • rolePackageName - string, collection of user/roles that should be directly assigned.

  • page - link fragment of page. If present, should be in the system.

  • measureAggregations - aggregation for measureGroup / measureType should be in the system/ JSON file.

    • measureGroup* - name of the measure group.

    • measureType* - name of the measure type.

Note

Please note that the Import Configuration function does not support Custom Fields Definitions (metadata) imports. Therefore, when updating via import an entity that already has metadata defined, the metadata will not be affected.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{   
 "orgUnits":[{
        "path": [""],
        "alias": "",
        "userAssignments": [{
            "userName": "",
            "roleNames": [""],
            "rolePackageName": "",
        }], 
        "page": "",
        "measureAggregations": [
            {
                "measureGroup": "", 
                "measureType": ""  
            }
        ]
    }]
}

Devices

In order to create or update Devices, the following parameters need to be defined:

Note

When creating new entities, the parameters marked with an asterisk (*) are mandatory. When updating an entity, the parameters marked with an asterisk (*) need to be an exact match with the existing entity.

  • adapter* - name of the adapter.

  • name* - unique in the system.

  • alias - alias.

  • description - description of the device.

  • site - name of the site, should be in the system / JSON.

  • areaPath - path of the area (area names from root to area), from the selected site. Should be in the system / JSON.

  • orgUnitPath - array of strings, the path of the organizational units. Should be in system / JSON.

  • visible* - boolean, visible in filters.

  • .active* - boolean,

  • deviceType - name of the device type. If the device type does not already exist in the system, it will be created based on the JSON file.

  • manufacturer - name of the device manufacturer. If the manufacturer does not already exist in the system, it will be created based on the JSON file.

  • model - name of the device model. If the device model does not already exist in the system, it will be created based on the JSON file.

    Note: To add a new device mode, the device manufacturer and device type are required.

  • hwVersion - name of the system hardware version. If the device hwVersion does not already exist in the system it will be created based on the JSON file.

  • swVersion - name of the system software version.

    Note: if the swVersion device does not exist in the system, hwVersion is required.

  • configuration - JSON configuration for specific device. For more details about configuration of specific Devices, please visit the upcoming articles.

  • userAssignments

    • userName - string.

    • roleNames - array of strings, collection of user/roles which should be directly assigned.

  • overwriteEventPriorityValue - number, event priority value. Must be in the system/JSON.

  • suppressionMode - 0 / Manual, 1 / Suppression mode. By default, Manual/0.

  • suppressAlarms - boolean, false by default.

  • suppressionStartDate - JSON date time, start of scheduled suppression. e.g. "02/01/2022 19:30"

  • suppressionEndDate - JSON date time, end of scheduled suppression. e.g. "02/01/2022 19:30".

Note

Please note that the Import Configuration function does not support Custom Fields Definitions (metadata) imports. Therefore, when updating via import an entity that already has metadata defined, the metadata will not be affected.

Note

Please note that the Import Configuration function does not support the GPS Tracking settings. Therefore, the user needs to manually enable the GPS Tracking settings after creating a new Device. In the case of existing Devices that already have the GPS Tracking settings enabled, the import operation will not affect these settings.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{   
 "devices":[{
        "adapter": , 
        "name": "", 
        "alias": "", 
        "description": "", 
        "site": "", 
        "areaPath": , 
        "orgUnitPath": [""],
        "visible": , 
        "active": , 
        "deviceType": "",
        "manufacturer": "", 
        "model": , 
        "hwVersion": "", 
        "swVersion": "", 
        "configuration": "", 
        "userAssignments": [{
            "userName": "",
            "roleNames": [""],
        }],  
        "overwriteEventPriorityValue": "",
        "suppressionMode": 0,
        "suppressAlarms": false, 
        "suppressionStartDate": "",
        "suppressionEndDate": "" 
    }]
}

Adapters

In order to create or update Adapters, the following parameters need to be defined:

Note

When creating new entities, the parameters marked with an asterisk (*) are mandatory. When updating an entity, the parameters marked with an asterisk (*) need to be an exact match with the existing entity.

  • name* - unique in the system.

  • configuration - JSON. Configuration for specific adapter. For more details about configuration of specific Adapters, please visit the upcoming articles.

  • enabled - boolean, true if not present.

  • adapterType* - name of the adapterType from the system.

  • timeZone* - name from the system. e.g."W. Europe Standard Time".

    Note: If the adapter timeZone does not exist in the system, UTC will be used.

  • traceLevel* - name from the system. e.g. Debug.

    Note: If the traceLevel does not exist in the system, "Off" will be used.

  • server - name of the server. If the server does not exist, the system will take the first server from the system.

  • userAssignments

    • userName - string.

    • roleNames - array of strings - collection of user/roles which should be directly assigned.

  • ownerName - user name which will be set as adapter's owner. This user will have access to the adapter even if it does not have assignments to it.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{  
  "adapters":[{
        "name": "", 
        "configuration": "{}", 
        "enabled": ,
        "adapterType": "", 
        "timeZone": "", 
        "traceLevel": , 
        "serverName": "", 
        "userAssignments": [{
            "userName": "",
            "roleNames": [""]
        }], 
        "ownerName": "" 
    }]
}

Signals

In order to create or update Signals, the following parameters need to be defined:

Note

When creating new entities, the parameters marked with an asterisk (*) are mandatory. When updating an entity, the parameters marked with an asterisk (*) need to be an exact match with the existing entity.

  • active - boolean, true by default.

  • deviceName* - name of the device.

  • name* - unique per device,

  • alias - alias.

  • description - description.

  • counter - float. Only by adding a new signal.

  • counterOverflow - float.

  • type - name of the signal type.

    Note: If the signal type does not exist in the system, it will be created with default values.

  • configuration - specific JSON configuration. For more details about configuration of specific Signals, please visit the upcoming articles.

  • factor* - 1 by default.

  • conversionFactorFrom* - float.

  • conversionFactorTo* - float.

  • deadband - float.

  • timeDeadband - milliseconds.

  • plausibilityDelta - double.

  • gapInterval - integer, measured in seconds,

  • interpolate* - boolean, interpolation should be applied if gap is detected.

  • inactivityInterval - integer, seconds for interpolation.

  • log* - boolean, measurements will be logged.

  • stream* - boolean, can be used in a query.

  • mode - HistoricalScript, // 2-Online script, 3-Historical script, 6-GPS.

    Note: If the signal mode is not defined, the system will use "None".

  • script - script for virtual signal.

    Note: If "null", the signal will not be created as a virtual signal, therefore the "scriptSignals" parameters should not be used in the JSON file.

  • scriptSignals - if it is virtual signal (mode equal 2 or 3) and script contains signal as parameter.

    • deviceName* - device name.

    • signalName* - signal name from device above.

    • parameterName* - parameter name.

    • testValue* - float.

  • userAssignments

    • userName - string.

    • roleNames - array of strings, collection of user/roles which should be directly assigned.

  • readAccess - number, 0-Deny, 1-AllowUnsecured, 2-AllowSecured. Default value 2.

  • writeAccess* - number, 0-Deny, 1-AllowUnsecured, 2-AllowSecured. Default value 0.

  • minValue - number, minimum value for the signal.

  • maxValue - number, maximum value for the signal.

  • isCounter - boolean, true if the signal is counter.

  • useAbsoluteValue - boolean, true if the signal should use absolute of number,

  • compressionAlgorithm - number, 0-None, 1-SwingingDoor. This signal uses algorithm to compress signal values.

  • compressionSettings - JSON for Swinging Door.

    • deviation* - number.

    • minimumTimeInterval - number, timespan in milliseconds.

    • maximumTimeInterval - number, timespan in milliseconds.

  • staleDataDetectionInterval - number, stale data detection interval in seconds.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{  
  "signals":[{
        "active": true,  
        "deviceName": "",
        "name": "",
        "alias": "", 
        "description": "", 
        "counter": , 
        "counterOverflow": , 
        "type": "", 
        "configuration": "", 
        "factor": "1",
        "conversionFactorFrom": "",
        "conversionFactorTo": "",
        "deadband": , 
        "timeDeadband": , 
        "plausibilityDelta": , 
        "gapInterval": ,  
        "interpolate": , 
        "inactivityInterval": , 
        "log": ,
        "stream": ,
        "mode": , 
        "script": ,
        "scriptSignals":[ 
            {
                "deviceName": "", 
                "signalName": "", 
                "parameterName": "",
                "testValue":
            }
        ],
        "userAssignments": [{
            "userName": "",
            "roleNames": [""]
        }], 
        "readAccess": ,  
        "writeAccess": ,
        "minValue": "", 
        "maxValue": "",
        "isCounter": , 
        "useAbsoluteValue": ,
        "compressionAlgorithm": ,
        "compressionSettings": {
            "deviation": ,
            "minimumTimeInterval": "",
            "maximumTimeInterval": "",
        },
        "staleDataDetectionInterval": "", 
    }]
}

Signal types

In order to create or update Signal types, the following parameters need to be defined:

Note

When creating new entities, the parameters marked with an asterisk (*) are mandatory. When updating an entity, the parameters marked with an asterisk (*) need to be an exact match with the existing entity.

  • name* - unique in the system.

  • measureGroup - name of measure group, should be in the system.

    Note: If the measureGroup is not in the system it will be created with default values.

  • measureType - name of the measure type, should be in the system.

    Note: If the measureType is not in the system, it will be created with default values.

  • icon - string, CSS icon name.

  • aggregation - string, e.g. [Measures].[Average].

  • unit - string, e.g. °C.

  • visible* - boolean.

  • siteVariable* - boolean.

  • areaVariable* - boolean.

  • orgUnitVariable* - boolean.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{    
"signalTypes":[
        {
            "name": "",
            "measureGroup": "", 
            "measureType": "", 
            "icon": "",
            "aggregation": "", 
            "unit": "", 
            "visible": ,
            "siteVariable": , 
            "areaVariable": ,
            "orgUnitVariable":
        }
    ]
}

Measure types

In order to create or update Measure types, the following parameters need to be defined:

Note

When creating new entities, the parameters marked with an asterisk (*) are mandatory. When updating an entity, the parameters marked with an asterisk (*) need to be an exact match with the existing entity.

  • name* - string, name of measure type.

  • icon - string, css icon name.

  • order - int, position.

  • visible - boolean, true by default.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{   
 "measureTypes": [{
        "name": "", 
        "icon": "",
        "order": ,
        "visible": true
    }]
}

Measure groups

In order to create or update Measure groups, the following parameters need to be defined:

Note

When creating new entities, the parameters marked with an asterisk (*) are mandatory. When updating an entity, the parameters marked with an asterisk (*) need to be an exact match with the existing entity.

  • name* - string, name of the group.

  • description - description of the measure group

  • icon - string, css icon name.

  • order - int, position.

  • visible - boolean, true by default.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{
	"measureGroups": [{
		"name": "",
	        "description": "",
		"icon": "",
		"order": ,
		"visible": true
	}]
}

Measure aggregations

In order to create or update Measure aggregations, the following parameters need to be defined:

Note

When creating new entities, the parameters marked with an asterisk (*) are mandatory. When updating an entity, the parameters marked with an asterisk (*) need to be an exact match with the existing entity.

  • measureGroup* - name of the measure group, should be in the system.

    Note: If the measureGroup aggregation is not in the system, it will be created with default values.

    Aggregation should be unique for measureGroup/measureType pair.

  • measureType* - name of the measure type, should be in the system.

    Note: If the measureType aggregation is not in the system, it will be created with default values.

  • aggregation* - aggregation formula.

  • goal - goal formula.

  • reversed* - boolean.

  • unit - unit name.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{    
"measureAggregations":[{
        "measureGroup": "",
        "measureType": "", 
        "aggregation": "[]", 
        "goal": "", 
        "reversed": , 
        "unit" : "" 
    }]
}

KPIs

In order to create or update KPIs, the following parameters need to be defined:

Note

When creating new entities, the parameters marked with an asterisk (*) are mandatory. When updating an entity, the parameters marked with an asterisk (*) need to be an exact match with the existing entity.

  • name* - unique in the system.

  • description - description of the KPI.

  • measureGroup - name of the measure group, should be in the system.

    Note: If the measureGroup KPI is not in the system, it will be created with default values.

  • measureType - name of the measure type, should be in the system.

    Note: If the measureType KPI is not in the system, it will be created with default values.

  • icon - string, css icon name.

  • visible - boolean.

  • aggregation* - aggregation formula.

  • goal - goal formula.

  • reversed* - boolean.

  • unit - unit name.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{    
"kpis":[{
        "name": "", 
        "description": "",
        "measureGroup": "", 
        "measureType": "",
        "icon": "", 
        "visible": , 
        "aggregation": "", 
        "goal": "", 
        "reversed": ,
        "unit" : ""
    }]
}

Events

In order to create or update KPIs, the following parameters need to be defined:

Note

When creating new entities, the parameters marked with an asterisk (*) are mandatory. When updating an entity, the parameters marked with an asterisk (*) need to be an exact match with the existing entity.

  • name* - unique in the system.

  • alias - alias.

  • description - description of the Event.

  • cause - string.

  • effect - string.

  • repair - string.

  • helpLink -string, URL.

  • stream - boolean.

  • manualEvent - boolean.

  • priorityValue - should be in the system / iJSON file.

  • type - should be in the system.

    Note: If the Event type is not in the system, it will be created with default values.

  • groupPath - should be in the system.

    Note: If the groupPath Event is not in the system, it will be created with default values.

  • acknowledgeInterval - number, SLA acknowledge interval in seconds.

  • ownershipInterval - number, SLA acknowledge interval in seconds.

  • closeInterval - number, SLA close interval in seconds.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{   
 "events":[{
        "name": "", 
        "alias": "",
        "description": "",
        "cause": "", 
        "effect": "", 
        "repair": "", 
        "helpLink": "",
        "stream": , 
        "manualEvent": ,
        "priorityValue": "",
        "type": "",
        "groupPath": [""], 
        "acknowledgeInterval": "",
        "ownershipInterval": "", 
        "closeInterval": ""  
    }]
}

Event scripts

In order to create or update Event scripts, the following parameters need to be defined:

Note

When creating new entities, the parameters marked with an asterisk (*) are mandatory. When updating an entity, the parameters marked with an asterisk (*) need to be an exact match with the existing entity.

  • deviceName* - name of the device, should be in the system.

  • eventName* - name of the event. should be in the system.

    Note: If the eventname does not exist in the system, it will be added with default values.

  • script* - script.

  • mode* - number, 2-Online script, 3-Historical script.

  • scriptSignals - if script contains signal as parameter

    • deviceName* - name of the device.

    • signalName* - name of the signal from device above.

    • parameterName* - parameter name.

    • testValue* - float.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{   
 "eventScripts":[{
        "deviceName": "",
        "eventName": "", 
        "script": "", 
        "mode": ,  
        "scriptSignals":[ 
            {
                "deviceName": "", 
                "signalName": "", 
                "parameterName": "", 
                "testValue": 
            }
        ]
    }]
}

Event priorities

In order to create or update Event priorities, the following parameters need to be defined:

  • value* - number.

  • name* - name of the event.

  • color - HEX color string.

  • displayInStatusBar - boolean.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

{  
  "eventPriorities": [{
        "value": , 
        "name": "", 
        "color": "", 
        "displayInStatusBar": , 
    }]
}
i4connected Import Service JSON for Azure IoT devices, adapters, and signals
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for Azure IoT devices, adapters, and signals.

The following article describes the needed configuration parameters of a JSON file for Azure IoT devices, adapters, and signals. For more details on how to prepare your JSON files, please check the dedicated article, here.

Entity

Configuration parameters

Example

Device

In order to define the configuration for the Azure IoT device, here are the necessary parameters:

  • filter - the filters which parse the data received from the IoT Hub.

  • deviceId - the identification number of the device.

  • methodConnectionTimeoutInSec - the timeout expressed in seconds, for waiting for the IoT device connection (min:0, default 0, cannot be more than the Method Response Timeout in Seconds.

  • methodResponseTimeoutInSec - the timeout, expressed in second, for waiting for a response from the method (min: 0 / max: 300, default: 120).

  • methodName - the name of the method which should be called.

  • methodPayload - the JSON payload method.

Tip

For more details about the Azure IoT devices, please visit the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"filter\":null,\"deviceId\":null,\"methodConnectionTimeoutInSec\":0,\"methodResponseTimeoutInSec\":120,\"methodName\":null,\"methodPayload\":null}"

Adapter

In order to define the configuration for the Azure IoT adapter, here are the necessary parameters:

  • connectionString

  • ioTHubConnectionString - the IoT hub connection string. It is needed to call the direct method from the IoT Device. It can be found in the Microsoft Azure portal, under Shared access policies, by clicking on the iothubowner field. The Primary Key here can be copied to the clipboard, using the dedicated Microsoft Azure Copy option.

  • methodResponseTimeoutInSec

  • methodName - the name of the method which should be called.

  • transportType - the type of protocol to call the method from the IoT device. The user can select from:

    • amqp (Advanced Message Queuing Protocol) is an open standard internet protocol for passing business messages between applications or organizations. This messaging protocol allows multiple modes of operation.

    • amqp_Websocket_Only - with AMQP over WebSockets, a bridge is set up, exposing the MQTT protocol over HTML5 WebSockets.

  • methodPayload - the JSON payload method.

    • parameters

      • name

      • value

Tip

For more details about the Azure IoT adapters, please visit the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"connectionString\":\"connectionString\",\"ioTHubConnectionString\":\"\",\"methodConnectionTimeoutInSec\":0,\"methodResponseTimeoutInSec\":120,\"methodName\":\"\",\"transportType\":1,\"methodPayload\":null}"

Signal

In order to define the configuration for the Azure IoT signal, here are the necessary parameters:

  • filter - opens the Test Expression panel, where the user can fill in the filter JSON property.

  • timestamp - opens the Test Expression panel, where the user can fill in the timestamp JSON property.

  • value - opens the Test Expression panel, where the user can fill in the value JSON property.

Tip

For more details about the Azure IoT signals, please visit the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"filter\":null,\"timestamp\":null,\"value\":null}"
i4connected Import Service JSON for CSV adapters and signals
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for CSV adapters and signals.

This tutorial describes the needed steps to update or create new entities using a JSON file. For more details on how to prepare your JSON files, please check the dedicated article, here.

Entity

Configuration parameters

Example

Adapter

In order to define the configuration for CSV adapter, here are the necessary parameters:

  • address

  • correctionAddress

  • pollInterval

  • userName

  • password

  • fileTimePattern

  • searchSubFolders

  • measurementParsers

    • separator

    • decimalSeparator

    • thousandsSeparator

    • delimiter

    • dateIndex

    • dateColumn

    • dateFormat

    • timeIndex

    • timeColumn

    • timeFormat

    • hasHeaders

    • searchString

    • encoding

    • id

Tip

For more details about the CSV adapters, please visit the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"address\":\"C:\\\\CSV\",\"correctionAddress\":null,\"pollInterval\":500,\"userName\":\"username\",\"password\":null,\"fileTimePattern\":null,\"searchSubFolders\":false,\"measurementParsers\":[{\"separator\":\";\",\"decimalSeparator\":\".\",\"thousandsSeparator\":\",\",\"delimiter\":\"'\",\"dateIndex\":\"0\",\"dateColumn\":null,\"dateFormat\":\"dd.MM.yyyy HH:mm\",\"timeIndex\":null,\"timeColumn\":null,\"timeFormat\":null,\"hasHeaders\":true,\"searchString\":\"searchString\",\"encoding\":encodingnumber,\"id\":\"id\"},{\"separator\":\",\",\"decimalSeparator\":\".\",\"thousandsSeparator\":\",\",\"delimiter\":\"'\",\"dateIndex\":-1,\"dateColumn\":null,\"dateFormat\":\"ddMMyy\",\"timeIndex\":null,\"timeColumn\":null,\"timeFormat\":null,\"hasHeaders\":true,\"searchString\":\"test\",\"encoding\":encodingnumber,\"id\":\"id\"}]}"

Signal

In order to define the configuration for CSV signal, here are the necessary parameters:

  • parserName

  • index

  • name - the name of the CSV signal.

  • type - the signal type:

    • Boolean - only for Coils and Discrete Inputs;

    • Char

    • Byte

    • Int16

    • Int32

    • Int64

    • SByte

    • UInt16

    • UInt32

    • UInt64

    • Single

    • Double

  • columnSpecification

Tip

For more details about the CSV signals, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"parserName\":\"parserName\",\"index\":null,\"name\":\"name\",\"type\":\"Double\",\"columnSpecification\":\"columnSpecification\"}"
i4connected Import Service JSON for Email devices & adapters
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for Email devices and adapters.

The following article describes the needed configuration parameters of a JSON file for Email devices and adapters. For more details on how to prepare your JSON files, please check the dedicated article, here,

Category

Configuration parameters

Example

Device

In order to define the configuration for the Email device, here are the necessary parameters:

  • senderNamePattern - the name pattern of the Email sender (source), used to filter the Emails corresponding to the device.

  • senderAddressPattern - the address pattern of the Email sender (source address), used to filter the Emails corresponding to the device.

  • recipientNamePattern - the name pattern of the Email recipient (target), used to filter the Emails corresponding to the device.

  • recipientAddressPattern - the address pattern of the Email recipient (target address), used to filter the Emails corresponding to the device.

  • subjectPattern - the pattern of the Email subject is used to filter the Emails corresponding to the device. The Subject Pattern field can match strings with wildcards (*), where the wildcard means "any".

  • bodyPattern - the pattern of the Email body is used to filter the Emails corresponding to the device. The Body Pattern field can match strings with wildcards (*), where the wildcard means "any".

  • snippetId

    • Advitronic

    • Carel

    • Carel2

    • Danfoss

    • Dixell

    • Dixell2

    • Eliwell

    • Wurm

Tip

For more details about the Email devices, please visit the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"senderNamePattern\":null,\"senderAddressPattern\":null,\"recipientNamePattern\":null,\"recipientAddressPattern\":null,\"subjectPattern\":\"subjectPattern\",\"bodyPattern\":\"bodyPattern\",\"snippetId\":\"snippetId\"}"

Adapter

In order to define the configuration for the Email adapter, here are the necessary parameters:

  • password

  • username

  • pollInterval - the data synchronization time interval, expressed in milliseconds (the default is 60000 – 1 minute).

  • host - specifies the Email hosting service in which the email messages and associated files are stored on the server (e.g. pop.gmail.com).

  • maxMessages

  • useSsl

  • protocol - sets the communication protocol.

  • port - specifies the communication port of the IMAP Email server account (e.g. 993, when using SSL).

  • exchangeAppId - specifies the OAuth application ID issued by Azure Active Directory.

  • exchangeTenantId - specifies the identification number of the application tenant.

  • exchangeClientSecret - specifies the application secret attributed to the OAuth application at the app registration step.

  • exchangeUrl - The URL of the application, where authentication responses can be sent and received by the app.

  • exchangeMailBox - the address of the target Email account.

Tip

For more details about the Email adapters, please visit the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"password\":\"<password>\",\"username\":\"username\",\"pollInterval\":60000,\"host\":\"host\",\"maxMessages\":\"maxMessages\",\"useSsl\":true,\"protocol\":1,\"port\":port,\"exchangeAppId\":null,\"exchangeTenantId\":null,\"exchangeClientSecret\":null,\"exchangeUrl\":null,\"exchangeMailBox\":null}"
i4connected Import Service JSON for Ewon devices, adapters, and signals
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for Ewon devices, adapters, and signals.

The following article describes the needed configuration parameters of a JSON file for Ewon devices, adapters, and signals. For more details on how to prepare your JSON files, please check the dedicated article, here.

Entity

Configuration parameters

Example

Device

In order to define the configuration for the Ewon device, here are the necessary parameters:

  • ewonDeviceName

  • userName

  • password

Tip

For more details about the Ewon devices, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": {\"ewonDeviceName\":\"ewonDeviceName\",\"userName\":null,\"password\":null}"

Adapter

In order to define the configuration for the Ewon adapter, here are the necessary parameters:

  • talk2MAccount - the Ewon device from which we want to retrieve the data must be associated with a Talk2M account.

  • talk2MToken

  • talk2MUserName

  • talk2MPassword

  • pollInterval - the time interval, in milliseconds, when the synchronization will be performed (the default is 60000 – 1 minute).

  • deleteDataAfterReading - when set to true, the successfully read data will be deleted from the DataMailbox. By default the value is false.

  • enableAlarms - when set to true, the alarm history will be read from the DataMailbox. When false, the following alarm settings are not required anymore.

  • alarmHighPrefix - the prefix to use for the alarm name when the HIGH or HIGH-HIGH threshold is exceeded (the type is string and the default value is “High” – i.e. High Temperature). The event name is obtained by combining the prefix, the tag (signal) name, and the suffix.

  • alarmHighSuffix - he suffix to use for the alarm name when the HIGH or HIGH-HIGH threshold is exceeded (the type is string and the default value is “high” – i.e. Temperature high). The event name is obtained by combining the prefix, the tag (signal) name, and the suffix.

  • alarmLowPrefix - the prefix to use for the alarm name when the LOW or LOW-LOW threshold is exceeded (the type is string and the default value is “Low” – i.e. Low Temperature). The event name is obtained by combining the prefix, the tag (signal) name, and the suffix.

  • alarmLowSuffix - the suffix to use for the alarm name when the LOW or LOW-LOW threshold is exceeded (the type is string and the default value is “low” – i.e. Temperature low). The event name is obtained by combining the prefix, the tag (signal) name, and the suffix.

  • alarmLevelPrefix - he prefix to use for the alarm name when a boolean (bit) alarm is on. (the type is string and the default value is “Set” – i.e. Set Enabled). The event name is obtained by combining the prefix, the tag (signal) name, and the suffix.

  • alarmLevelSuffix - the suffix to use for the alarm name when a boolean (bit) alarm is on. (the type is string and the default value is “set” – i.e. Enabled Set). The event name is obtained by combining the prefix, the tag (signal) name, and the suffix.

  • alarmWarningPriorityId - the event priority used when creating or updating the event occurrence in the i4connected system for a HIGH or LOW Ewon alarm. The event priority can be selected from the Priorities panel.

  • alarmDangerPriorityId - the event priority used when creating or updating the event occurrence in the i4connected system for a HIGH-HIGH or LOW-LOW Ewon alarm. The event priority can be selected from the Priorities panel.

Tip

For more details about the Ewon adapters, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"talk2MAccount\":\"talk2MAccount\",\"talk2MToken\":\"talk2MToken\",\"talk2MUserName\":\"talk2MUsername\",\"talk2MPassword\":\"talk2MPassword\",\"pollInterval\":60000,\"deleteDataAfterReading\":false,\"enableAlarms\":false,\"alarmHighPrefix\":\"High\",\"alarmHighSuffix\":\"high\",\"alarmLowPrefix\":\"Low\",\"alarmLowSuffix\":\"low\",\"alarmLevelPrefix\":\"Set\",\"alarmLevelSuffix\":\"set\",\"alarmWarningPriorityId\":null,\"alarmDangerPriorityId\":null}""-:l: 0

Signal

In order to define the configuration for the Ewon signal, here are the necessary parameters:

  • ewonSignalName

Tip

For more details about the Ewon signals, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"ewonSignalName\":\"EwonSignalName\"}"
i4connected Import Service JSON for GridVis devices, adapters, and signals
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for GridVis devices, adapters, and signals.

The following article describes the needed configuration parameters of a JSON file for GridVis devices, adapters, and signals. For more details on how to prepare your JSON files, please check the dedicated article, here.

Entity

Configuration parameters

Example

Device

In order to define the configuration for the GridVis device, here are the necessary parameters:

  • id

  • name

Tip

For more details about the GridVis devices, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"id\":idnumber,\"name\":\"name\"}"

Adapter

In order to define the configuration for the GridVis adapter, here are the necessary parameters:

  • userName

  • password

  • pollInterval - the time interval, in milliseconds, when the synchronization will be performed (the default is 90000 milliseconds – 15 minutes). This setting is mandatory.

  • projectName

  • baseAddress

  • importMonths - specifies the number of months, for historical data imports. This setting is mandatory.

  • concurrentConnections

Tip

For more details about the GridVis adapters, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"userName\":null,\"password\":null,\"pollInterval\":\"900000\",\"projectName\":\"projectName\",\"baseAddress\":\"baseAddress/\",\"importMonths\":\"importMonthsNumber\",\"concurrentConnections\":-1}"

Signal

In order to define the configuration for the GridVis signal, here are the necessary parameters:

  • id

  • valueTypeType

  • valueTypeValue

  • timebase

  • online

  • valueType

Tip

For more details about the GridVis signals, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"id\":id,\"valueTypeType\":\"valueTypeType\",\"valueTypeValue\":\"ValueTypeValue\",\"timebase\":3600,\"online\":false,\"valueType\":\"valueType\"}"
i4connected Import Service JSON for HMS devices, adapters, and signals
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for HMS devices, adapters, and signals.

The following article describes the needed configuration parameters of a JSON file for HMS devices, adapters, and signals. For more details on how to prepare your JSON files, please check the dedicated article, here.

Entity

Configuration parameters

Example

Device

In order to define the configuration for the HMS device, here are the necessary parameters:

  • protocol - the WebSocket communications protocol.

  • project - the mandatory name of the Project using the HMSHub device.

  • domain

  • port

  • userName

  • rootPath

  • password

  • inactivityInterval - the time frame between two consecutive updates.

  • inactivityTimeout - the time frame for waiting for a response.

Tip

For more details about the HMS devices, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"protocol\":\"protocol\",\"project\":\"project\",\"domain\":\"domain\",\"port\":\"port\",\"userName\":\"userName\",\"rootPath\":\"\",\"password\":\"password\",\"inactivityInterval\":120,\"inactivityTimeout\":10}"

Adapter

In order to define the configuration for the HMS adapter, here are the necessary parameters:

  • protocol - the WebSocket communications protocol:

    • ws - connects on HTTP.

    • wss - connects on the HTTPS.

  • project - the mandatory name of the Project using the HMSHub adapter.

  • domain - the mandatory domain name.

  • port - the port used for the HMSHub connection.

  • userName

  • password

  • inactivityInterval - the time frame between two consecutive updates.

  • inactivityTimeout - the time frame for waiting for a response.

Tip

For more details about the HMS adapters, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration":  "{\"protocol\":\"protocol\",\"project\":\"project\",\"domain\":\"domain\",\"port\":\"port\",\"userName\":\"username\",\"password\":\"password\",\"inactivityInterval\":120,\"inactivityTimeout\":10}"

Signal

In order to define the configuration for the HMS signal, here are the necessary parameters:

  • path - the Endpoint URL establishing the connection to the WEBservice.

Tip

For more details about the HMS signals, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": {\"path\":\"/path/variables/variable\"}"
i4connected Import Service JSON for i4SCADA devices, adapters, and signals
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for i4SCADA devices, adapters, and signals.

The following article describes the needed configuration parameters of a JSON file for i4SCADA devices, adapters, and signals. For more details on how to prepare your JSON files, please check the dedicated article, here.

Entity

Configuration parameters

Example

Device

In order to define the configuration for the i4SCADA device, here are the necessary parameters:

  • alarms

Tip

For more details about the i4SCADA devices, please visitthe dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"alarms\":[\"alarm1\",\"alarm2\"]}"

Adapter

In order to define the configuration for the I4SCADA adapter, here are the necessary parameters:

  • address

  • concurrentConnections - the maximum number of connections that the server supports, at one time.

  • maxResults - the maximum number of records returned by a web service call. The default value is 1000.

  • pollInterval - the time in milliseconds, between two consecutive web service request.

  • userName

  • password

Tip

For more details about the i4SCADA adapters, please visit the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"address\":\"address\",\"concurrentConnections\":10,\"maxResults\":1000,\"pollInterval\":500,\"userName\":null,\"password\":null}"

Signal

In order to define the configuration for the i4SCADA signal, here are the necessary parameters:

  • logID

  • signalAlias

  • logTag

  • type

Tip

For more details about the i4SCADA signals, please visit the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"logId\":null,\"signalAlias\":\"signalAlias\",\"logTag\":\"logTag\",\"type\":\"type\"}"
i4connected Import Service JSON for Modbus devices, adapters, and signals
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for Modbus devices, adapters, and signals.

The following article describes the needed configuration parameters of a JSON file for Modbus devices, adapters, and signals. For more details on how to prepare your JSON files, please check the dedicated article, here.

Entity

Configuration parameters

Example

Device

In order to define the configuration for the Modbus device, here are the necessary parameters:

  • id - the identification number of the Modbus server. The field will only accept a number between 0 to 255.

Tip

For more details about the Modbus devices, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"id\":\"id\"}"

Adapter

In order to define the configuration for the Modbus adapter, here are the necessary parameters:

  • address - the address of the server providing the data.

  • port - The port used for the Modbus connection. Default value: 502.

  • pollInterval - The time interval (in milliseconds) between subsequent polls. By default, the value is set to 10000 ms.

  • reverseRegisters - Toggles between the normal register reading (default format) and the reversed register reading (Motorola format). This attribute must be set to true (setting enabled) when using the reversed registers reading (the Motorola format), in order to reverse the read data before interpretation.

  • maxChunkSize - The maximum number of straight data records (uninterrupted by empty records) to be read. The reading starts with the first data record. Default value: 100.

  • maxWasteSize - The maximum number of straight empty records (uninterrupted by data records) to be read. Default value: 30.

Tip

For more details about the Modbus adapters, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"address\":\"serveraddress\",\"port\":502,\"pollInterval\":10000,\"reverseRegisters\":true,\"byteIsLittleEndian\":false,\"maxChunkSize\":100,\"maxWasteSize\":30}"

Signal

In order to define the configuration for the Modbus signal, here are the necessary parameters:

  • address - the address of the signal, which depends on the register type. Can be:

    • coils addresses

    • discrete input addresses

    • input register addresses

    • holding register addresses.

  • length

  • registerType - the Modbus register type. Can be:

    • Coil

    • discrete input

    • input register

    • holding register.

  • dataType - the type of data of the signal.

Tip

For more details about the Modbus signals, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"address\":\"address\",\"length\":1,\"registerType\":registerType,\"dataType\":dataType}"
i4connected Import Service JSON for MQTT devices, adapters, and signals
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for MQTT devices, adapters, and signals.

The following article describes the needed configuration parameters of a JSON file for MQTT devices, adapters, and signals. For more details on how to prepare your JSON files, please check the dedicated article, here.

Entity

Configuration parameters

Example

Device

In order to define the configuration for the MQTT device, here are the necessary parameters:

  • host - the IP or DNS name of the MQTT broker.

  • port - the number of the port used for connection;

  • ssl - the SSL protocol used for communication:

    • 0 (none)

    • 1 (SSLv3)

    • 2 (TLSv1.0)

    • 3 (TLSv1.1)

    • 4 (TLSv 1.2)

  • username

  • password

  • clientId

  • parser

    • 0 (JSON)

    • 1 (RAW)

Tip

For more details about the MQTT Device, please visit the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"host\":\"host\",\"port\":\"portnumber\",\"ssl\":4,\"username\":\"username\",\"password\":\"password\",\"clientId\":\"clientId\",\"parser\":0}"

Adapter

In order to define the configuration for the MQTT adapter, here are the necessary parameters:

  • host - the IP or DNS name of the MQTT broker.

  • port - the number of the port used for connection;

  • ssl - the SSL protocol used for communication:

    • 0 (none)

    • 1 (SSLv3)

    • 2 (TLSv1.0)

    • 3 (TLSv.1.1)

    • 4 (TLSv1.2)

  • username

  • password

  • clientId

  • parser

    • 0 (JSON)

    • 1 (RAW)

Tip

For more details about the MQTT Adapter, please visit the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"host\":\"host\",\"port\":\"portnumber\",\"ssl\":4,\"username\":\"username\",\"password\":\"password\",\"clientId\":\"clientId\",\"parser\":0}"

Signal

In order to define the configuration for the MQTT signal, here are the necessary parameters:

  • filter - the JSON filter;

  • timestamp - the date and time of the registered measurement.

  • value

  • topic

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"filter\":null,\"timestamp\":\"timestamp\",\"value\":\"null\",\"topic\":\"topic\"}"
i4connected Import Service JSON for MSCONS adapters and signals
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for MSCONS adapters, and signals.

The following article describes the needed configuration parameters of a JSON file for MSCONS adapters, and signals. For more details on how to prepare your JSON files, please check the dedicated article, here.

Entity

Configuration parameters

Example

Adapter

In order to define the configuration for the MSCONS device, here are the necessary parameters:

  • address - the location of the directory where the MSCONS data is collected, The directory can be accessed using one of the following methods:

    • FTP

    • HTTP

    • Local (complete)

    • Local (relative)

  • pollInterval - the interval of time, defined in milliseconds, for scanning the folder for MSCONS data.

  • userName - if required, only when using FTP or Local address.

  • password

  • fileTimePattern -represents the date/time format of the date or/and time from the name of the MSCONS file.

  • obisCode - the corresponding device value.

Tip

For more details about the MSCONS adapters, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": {\"address\":\"adapter.com\",\"pollInterval\":500,\"userName\":\"username\",\"password\":null,\"fileTimePattern\":null,\"obisCode\":null}"

Signal

In order to define the configuration for the MSCONS signals, here are the necessary parameters:

  • locationId - the identification number of the device location.

  • obisCode - the corresponding device value.

Tip

For more details about the MSCONS signals, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"locationId\":\"123\",\"obisCode\":\"22222\"}"
i4connected Import Service JSON for Netbiter devices, adapters, and signals
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for Netbiter devices, adapters, and signals.

The following article describes the needed configuration parameters of a JSON file for Netbiter devices, adapters, and signals. For more details on how to prepare your JSON files, please check the dedicated article, here.

Entity

Configuration parameters

Example

Device

In order to define the configuration for the Netbiter device, here are the necessary parameters:

  • id

  • name

  • timezone

  • gpsActivated -

  • radius - the circle radius, measured in meters. This field supports numerical integer values, only.

  • longitude - sets the longitude, used to supply the Device's GPS location.

  • latitude - sets the latitude, used to supply the Device's GPS location.

Tip

For more details about the Netbiter devices, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"id\":\"idnumber\",\"name\":\"devicename\",\"timezone\":\"timezone\",\"gpsActivated\":false,\"radius\":500,\"longitude\":123.456789,\"latitude\":1.23456789}"

Adapter

In order to define the configuration for the Netbiter adapter, here are the necessary parameters:

  • accessKey

  • name

  • id

  • enableAlarms - when set to true, the user can customize the alarm priority associated with the alarm type.

  • useDataChannel - enables communication through the Customer Data Channel application. Regardless if the Use Data Channel option is enabled or not, the user is still required to fill in the Argos Access Key and apply a Netbiter project.

  • dataChannelUrl - the Url pointing to the Customer data Channel Application.

  • datachannelPassword - the Password used to log into the Customer Data Channel application.

  • dataChannelUserName - the UserName of the Customer Data Channel application.

  • dataChannelLogQueue - the Log Queue of the Customer Data Channel application.

  • dataChannelAlarmQueue - the Alarm Queue of the Customer Data Channel application.

  • pollInterval - the time interval, in milliseconds, when the synchronization will be performed (the default is 90000 milliseconds - 15 minutes).

  • criticalAlarmPriorityId

  • majorAlarmPriorityId - the event priority used when creating or updating a major event occurrence in the i4connected system for a high or low Netbiter alarm.

  • minorAlarmPriorityId - the event priority used when creating or updating a minor event occurrence in the i4connected system for a high or low Netbiter alarm.

  • warningAlarmPriorityId - the event priority used when creating or updating a warning event occurrence in the i4connected system for a high or low Netbiter alarm.

  • clearedAlarmPriorityId

Tip

For more details about the Netbiter adapters, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"accessKey\":\"accessKeynumber\",\"name\":\"name\",\"id\":idnumber,\"enableAlarms\":true,\"useDataChannel\":false,\"dataChannelUrl\":\"tcp://datachannelUrl\",\"dataChannelPassword\":\"dataChannelPassword\",\"dataChannelUserName\":\"DataChannelUserName\",\"dataChannelLogQueue\":\"LOG\",\"dataChannelAlarmQueue\":\"ALARM\",\"pollInterval\":900000,\"criticalAlarmPriorityId\":null,\"majorAlarmPriorityId\":1,\"minorAlarmPriorityId\":null,\"warningAlarmPriorityId\":null,\"clearedAlarmPriorityId\":null}"

Signal

In order to define the configuration for the Netbiter signal, here are the necessary parameters:

  • id

  • name

  • logInterval - the logging interval.

  • deviceName

  • unit - the unit of measure associated with the Netbiter signal.

Tip

For more details about the Netbiter signals, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"id\":\"idnumber\",\"name\":\"name\",\"logInterval\":logIntervalnumber,\"deviceName\":\"deviceName\",\"unit\":\"unit\"}"
i4connected Import Service JSON for OPC UA devices, adapters, and signals
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for OPC UA devices, adapters, and signals.

The following article describes the needed configuration parameters of a JSON file for OPC UA devices, adapters, and signals. For more details on how to prepare your JSON files, please check the dedicated article, here.

Entity

Configuration parameters

Example

Device

In order to define the configuration for the OPC UA device, here are the necessary parameters:

  • subscriptionId - the id of the OPC UA subscription used to define data acquisition from the server.

Tip

For more details about the OPC UA devices, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example:

"configuration": "{\"subscriptionId\":\"SubscriptionId\"}"

Adapter

In order to define the configuration for the OPC UA adapter, here are the necessary parameters:

  • url

  • securityMode - specifies the authentication method:

    • Invalid

    • None

    • Sign

    • SignandEncrypt

  • securityPolicyUri - specifies the security policy of the OPC UA adapter.

  • userTokenType - the type of the user identity token required:

    • Anonymous - the connection does not require a login, however, this is an unsecured connection.

    • Username - the connection requires a login via username and password.

  • userName

  • password

  • autoAcceptUntrustedCertificates - specifies whether untrusted certificates should be accepted or rejected,

  • subjectName - specifies the name of the trusted OPC UA client certificate.

  • subscription

Tip

For more details about the OPC UA adapters, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example:

"configuration": {"url":"/url","securityMode":"None","securityPolicyUri":"/securityPolicyUri","userTokenType":"userTokenType","userName":"username","password":"pasword","autoAcceptUntrustedCertificates":true,"subjectName":"subjectName","subscriptions":[{"id":"Test"}]}

Signal

In order to define the configuration for the OPC UA signal, here are the necessary parameters:

  • namespaceUri - the signal's namespace, generated on basis of a unique OPC UA identifier.

  • identifierType - the type of the signal's identifier as used in the OPC UA server.

  • identifier - the signal identifier as used in the OPC UA server.

  • attributeId

Tip

For more details about the OPC UA signals, please check the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example:

"configuration": "{\"namespaceUri\":\"namespaceUri/\",\"identifierType\":\"String\",\"identifier\":\"identifier\",\"attributeId\":13}"
i4connected Import Service JSON for SQL adapters
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for SQL adapters.

The following article describes the needed configuration parameters of a JSON file for SQL adapters. For more details on how to prepare your JSON files, please check the dedicated article, here.

Entity

Configuration parameters

Example

Adapter

In order to define the configuration for the SQL adapter, here are the necessary parameters:

  • commandText - sets or returns a string that contains a provider command, like a SQL statement, a table name, a relative URL, or a stored procedure call.

  • connectionString - the connection string, provides information about a data source and the means of connecting to it.

  • pollInterval - the time interval (in milliseconds) between subsequent polls. By default, the value is set to 60000 ms.

Tip

For more details about the SQL adapters, please visit the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example.

"configuration": "{\"commandText\":\"SELECT column1, column2 FROM table1, table2 WHERE column2='value';\",\"connectionString\":\"connectionString\",\"pollInterval\":60000}"
i4connected Import Service JSON for WEBfactory adapters and signals
Abstract

Check out this article and learn more details about configuring i4connected Import Service JSON for WEBfactory adapters, and signals.

The following article describes the needed configuration parameters of a JSON file for WEBfactory adapters and signals. For more details on how to prepare your JSON files, please check the dedicated article, here.

Entity

Configuration parameters

Example

Adapter

In order to define the configuration for the WEBfactory adapter, here are the necessary parameters:

  • address - the URL address of the web services that will handle the communication with the WEBfactory server.

  • concurrentConnections

  • maxResults - the maximum number of results to be returned in a single request.

  • pollInterval - the time span in milliseconds, between two consecutive servers polls.

  • version - the version of the WEBfactory server to which the device needs to connect. The available options are:

    • V34 - version 3.4;

    • V35 - version 3.5;

    • V36 - version 3.6.

  • userName - if required, only when using FTP or Local address.

  • password

Tip

For more details about the WEBfactory adapters, please visit the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example:

"configuration": "{\"address\":\"address\",\"concurrentConnections\":10,\"maxResults\":1000,\"pollInterval\":500,\"version\":\"V34\",\"userName\":null,\"password\":null}"

Signal

In order to define the configuration for the WEBfactory signal, here are the necessary parameters:

  • logId

  • signalAlias - the alias of the WEBfactory signal.

  • logTag

  • type - the type of signal value, the available options are:

    • double

    • string

Tip

For more details about the WEBfactory signals, please visit the dedicated article, here.

This is an example. Please make sure to fill in your custom data when using the below JSON example:

"configuration": "{\"logId\":null,\"signalAlias\":\"SignalAlias\",\"logTag\":\"logTag",\"type\":\"Double\"}"