Modbus-XMPP Bridge
The IoTBridgeModbus repository provides an IoT bridge between devices connected to Modbus, for use in closed intra-networks or enterprise networks, and the harmonized XMPP-based Neuro-Foundation network, for open and secure cross-domain interoperation on the Internet.
To run the bridge, you need access to both a Modbus gateway, and an XMPP broker, that supports the Neuro-Foundation extensions. You can use the TAG Neuron for XMPP.
Running and configuring the bridge
The code is written using .NET Standard, and compiled to a .NET Core console application that can be run on most operating systems. Basic configuration is performed using the console interface during the first execution, and persisted. You can also provide the corresponding configuration using environment variables, making it possible to run the bridge as a container. If an environmental variable is missing, the user will be prompted to input the value on the console.
Environmental Variable | Type | Description |
---|---|---|
XMPP_HOST |
String | XMPP Host name |
XMPP_PORT |
Integer | Port number to use when connecting to XMPP (default is 5222 ) |
XMPP_USERNAME |
String | User name to use when connecting to XMPP. |
XMPP_PASSWORD |
String | Password (or hashed password) to use when connecting to XMPP. Empty string means a random password will be generated. |
XMPP_PASSWORDHASHMETHOD |
String | Algorithm or method used for password. Empty string means the password is provided in the clear. |
XMPP_APIKEY |
String | API Key. If provided together with secret, allows the application to create a new account. |
XMPP_APISECRET |
String | API Secret. If provided together with key, allows the application to create a new account. |
MODBUS_HOST |
String | Modbus Gateway Host name |
MODBUS_TLS |
String | If TLS encryption is to be used when connecting to the Modbus gateway. |
MODBUS_PORT |
String | Port number to use when connecting to the Modbus gateway (default is 502 ). |
REGISTRY_COUNTRY |
String | Country where the bridge is installed. |
REGISTRY_REGION |
String | Region where the bridge is installed. |
REGISTRY_CITY |
String | City where the bridge is installed. |
REGISTRY_AREA |
String | Area where the bridge is installed. |
REGISTRY_SRTEET |
String | Street where the bridge is installed. |
REGISTRY_STREETNR |
String | Street number where the bridge is installed. |
REGISTRY_BUILDING |
String | Building where the bridge is installed. |
REGISTRY_APARTMENT |
String | Apartment where the bridge is installed. |
REGISTRY_ROOM |
String | Room where the bridge is installed. |
REGISTRY_NAME |
String | Name associated with bridge. |
REGISTRY_LOCATION |
Boolean | If location has been completed. (This means, any location-specific environment variables not provided, will be interpreted as intensionally left blank, and user will not be prompted to input values for them. |
Claiming ownership of bridge
Once the bridge has been configured, it will generate an iotdisco
URI, and save it to its programd data folder. It will also create a file with extension .url
, containing a shortcut with the iotdisco
URI inside. A .png
file with a QR code will also be generated. All three files contain information about the bridge, and allows the owner to claim ownership of it. This can be done by using the Neuro-Access App. This app is also downloadable for Android and iOS. You scan the QR code (or enter it manually), and claim the device. Once the device is claimed by you, you will receive notifications when someone wants to access the deice. They will only be able to access it with the owner’s permission. For more information, see:
Configuring the bridge
The bridge can be configured in detail by a client that implements the concentrator interface. Concentrators consist of data sources, each containing tree structures of nodes. Nodes may be partitioned into partitions, which permits the nesting of subsystems seamlessly into container systems. Each node can be of different types, and have different properties and underlying functionality. They can each implement then sensor interface and actuator interface.
You can use the Simple IoT Client to configure concentrators and their nodes in detail. An initial setup is done using the initial configuration of the bridge. The client is also available in the IoTGateway repository, in the Clients folder.
Node Types
The bridge includes several different node types that can be used to configure its operation:
The
Modbus Gateway
maintains a connection to a Modbus Gateway using TCP/IP, and converts requests into binary Modbus TCP/IP communication.The
XMPP Broker
maintains a connection to an XMPP Broker. It allows the bridge to connect to other entities on the federated network and communicate with them. It supports communication with remote standalone sensors and actuators, as well as remote concentrators embedding devices into data sources and nodes. Such concentrators can be bridges to other protocols and networks.Note: The bridge has a client-to-server connection by default, setup during initial configuration. Through this connection, the bridge acts as a concentrator. Through the use of
XMPP Broker
nodes you can setup additional XMPP connections to other brokers. In these cases the bridge will only act as a client, to connect to remove devices for the purposes of interacting with them.IP Host
nodes allow you to monitor network hosts accessible from the bridge.Script
nodes allow you to create nodes with custom script logic. They can be used to interface bespoke devices in the network accessible from the bridge, for example.Virtual
nodes are placeholders where external logic (or script logic) can aggregate information in a way that makes them accessible by others in the federated network.
MQTT-XMPP Bridge
The IoTBridgeMqtt repository provides an IoT bridge between devices connected to MQTT, for use in closed intra-networks or enterprise networks, and the harmonized XMPP-based Neuro-Foundation network, for open and secure cross-domain interoperation on the Internet.
To run the bridge, you need access to both an MQTT broker, and an XMPP broker, that supports the Neuro-Foundation extensions. You can use the Mosquitto broker for MQTT, and the TAG Neuron for XMPP.
Running and configuring the bridge
The code is written using .NET Standard, and compiled to a .NET Core console application that can be run on most operating systems. Basic configuration is performed using the console interface during the first execution, and persisted. You can also provide the corresponding configuration using environment variables, making it possible to run the bridge as a container. If an environmental variable is missing, the user will be prompted to input the value on the console.
Environmental Variable | Type | Description |
---|---|---|
XMPP_HOST |
String | XMPP Host name |
XMPP_PORT |
Integer | Port number to use when connecting to XMPP (default is 5222 ) |
XMPP_USERNAME |
String | User name to use when connecting to XMPP. |
XMPP_PASSWORD |
String | Password (or hashed password) to use when connecting to XMPP. Empty string means a random password will be generated. |
XMPP_PASSWORDHASHMETHOD |
String | Algorithm or method used for password. Empty string means the password is provided in the clear. |
XMPP_APIKEY |
String | API Key. If provided together with secret, allows the application to create a new account. |
XMPP_APISECRET |
String | API Secret. If provided together with key, allows the application to create a new account. |
MQTT_HOST |
String | MQTT Host name |
MQTT_TLS |
String | If TLS encryption is to be used when connecting to the MQTT broker. |
MQTT_PORT |
String | Port number to use when connecting to MQTT (default is 1883 for unencrypted MQTT and 8883 for encrypted MQTT). |
MQTT_USERNAME |
String | User name to use when connecting to MQTT. Can be empty if no user credentials are provided. |
MQTT_PASSWORD |
String | Password to use when connecting to XMPP. Can be empty if no user credentials are provided. |
REGISTRY_COUNTRY |
String | Country where the bridge is installed. |
REGISTRY_REGION |
String | Region where the bridge is installed. |
REGISTRY_CITY |
String | City where the bridge is installed. |
REGISTRY_AREA |
String | Area where the bridge is installed. |
REGISTRY_SRTEET |
String | Street where the bridge is installed. |
REGISTRY_STREETNR |
String | Street number where the bridge is installed. |
REGISTRY_BUILDING |
String | Building where the bridge is installed. |
REGISTRY_APARTMENT |
String | Apartment where the bridge is installed. |
REGISTRY_ROOM |
String | Room where the bridge is installed. |
REGISTRY_NAME |
String | Name associated with bridge. |
REGISTRY_LOCATION |
Boolean | If location has been completed. (This means, any location-specific environment variables not provided, will be interpreted as intensionally left blank, and user will not be prompted to input values for them. |
Claiming ownership of bridge
Once the bridge has been configured, it will generate an iotdisco
URI, and save it to its programd data folder. It will also create a file with extension .url
, containing a shortcut with the iotdisco
URI inside. A .png
file with a QR code will also be generated. All three files contain information about the bridge, and allows the owner to claim ownership of it. This can be done by using the Neuro-Access App. This app is also downloadable for Android and iOS. You scan the QR code (or enter it manually), and claim the device. Once the device is claimed by you, you will receive notifications when someone wants to access the deice. They will only be able to access it with the owner’s permission. For more information, see:
Configuring the bridge
The bridge can be configured in detail by a client that implements the concentrator interface. Concentrators consist of data sources, each containing tree structures of nodes. Nodes may be partitioned into partitions, which permits the nesting of subsystems seamlessly into container systems. Each node can be of different types, and have different properties and underlying functionality. They can each implement then sensor interface and actuator interface.
You can use the Simple IoT Client to configure concentrators and their nodes in detail. An initial setup is done using the initial configuration of the bridge. The client is also available in the IoTGateway repository, in the Clients folder.
Node Types
The bridge includes several different node types that can be used to configure its operation:
The
MQTT Broker
maintains a connection to an MQTT Broker, and allows the bridge to subcribe to content published on topics, as well as publish content to topics on the broker. The topic hierarchy will be modelled usingMQTT Topic
nodes, or derivatives. Common data types are recognized and parsed. You can read each topic individually, or a parent topic, and receive information from all child topics, as field values.The
XMPP Broker
maintains a connection to an XMPP Broker. It allows the bridge to connect to other entities on the federated network and communicate with them. It supports communication with remote standalone sensors and actuators, as well as remote concentrators embedding devices into data sources and nodes. Such concentrators can be bridges to other protocols and networks.Note: The bridge has a client-to-server connection by default, setup during initial configuration. Through this connection, the bridge acts as a concentrator. Through the use of
XMPP Broker
nodes you can setup additional XMPP connections to other brokers. In these cases the bridge will only act as a client, to connect to remove devices for the purposes of interacting with them.IEEE 1451
nodes are derivatives of MQTT nodes, and implement support for theIEEE 1451
family of standards, of whichIEEE 1451.1.6
manages communication over MQTT.IP Host
nodes allow you to monitor network hosts accessible from the bridge.Script
nodes allow you to create nodes with custom script logic. They can be used to interface bespoke devices in the network accessible from the bridge, for example.Virtual
nodes are placeholders where external logic (or script logic) can aggregate information in a way that makes them accessible by others in the federated network.
Integrating Serpro into Neuron®-based services
You can use Serpro in Neuron®-based services, by installing the TAG.Serpro.package
, available in the Packages page in the Admin menu, and use the examples provided in your own services. Serpro provides an identity application authenticator, that can be used to automate the approval of identity applications on the Neuron® where it is installed. You will need to provide a key when installing. Use the following public key:
Some more information | |
---|---|
Package | TAG.Serpro.package |
Installation key | 0WMoLBoAObn+SPgJ6Zfl6iJTxhnW8050o0sHba37z+51BUHjRm3dyL08qqQ+n4iTFDL6PYVOWeAA4bda1f2a8fb0d70921434eed848e39e7 |
Configuring Service | /Serpro/Settings.md on the Neuron® on which the service is installed. |
More information | <https://github.com/Trust-Anchor-Group/NeuronSerpro> |
Neuro Exchange Theme
The Neuro Exchange theme has been made into a package that can be downloaded and installed on any TAG Neuron. You can configure to use this theme in the Theme menu accessible from the admin dashboard.
Package information | |
---|---|
Package | TAG.NeuroExchange.Theme |
Installation key | BGVWw9FYGj6+mY8nxScZgoKRC8SiV80mWJhHXfUZL3ASrwZSab5PdEwmyfwpJVUEWEMNST4HWayA1640d45c2eae16ecf48e883c75dd25f7 |
More Information | https://github.com/Trust-Anchor-Group/TAG.NeuroExchange.Theme |
Identity Authenticator Service Template
A new open repository has been published that simplifies the creation of new identity authenticator services on the TAG Neuron® to customize KyC. The repository also contains instructions on how to implement such a service, what interfaces to use, and the different steps that need to be completed in order to create an installable package for the service, to distribute it in a Neuron® network.

For more information, see the TemplateIdentityAuthenticator repository on GitHub.
Posts tagged #repository
No more posts with the given tag could be found. You can go back to the main view by selecting Home in the menu above.