Changes

{{Template:Networking_rutx_manual_fw_disclosure

{{Template:Networking_rutx_manual_fw_disclosure

| fw_version = RUTX_R_00.02.01.1

| fw_version = RUTX_R_00.02.01.1

}}

}}

==Prerequisites==

==Prerequisites==

You will need:

You will need:

*A router from the RUTX09 or RUTX11

*A Teltonika Networks router;

*An Azure IoT Hub account

*An Azure IoT Hub account.

==Azure account creation==

==Azure account creation==

<ul>

<ul>

<div> 1. The initial step is to generate certificates. You can refer to the Microsoft guide to generate the required certificates successfully. The Microsoft guide can be found here: https://learn.microsoft.com/en-us/azure/iot-dps/tutorial-custom-hsm-enrollment-group-x509?pivots=programming-language-ansi-c#create-a-root-ca-certificate  

<div> 1. The initial step is to generate certificates. You can refer to the Microsoft guide to generate the required certificates successfully. The Microsoft guide can be found [https://learn.microsoft.com/en-us/azure/iot-dps/tutorial-custom-hsm-enrollment-group-x509?pivots=programming-language-ansi-c#create-a-root-ca-certificate here]

The required certificates and keys:

The required certificates and keys:

<li> Root CA certificate </li>

<li> Root CA certificate </li>

[[File:Azure RutOSconf 13.png|border|class=tlt-border]]

[[File:Azure RutOSconf 13.png|border|class=tlt-border]]

Inspecting the newly created enrollment group will reveal some keys. The primary key will be used to derive each individual device identity. This can be done using a simple script, which is available in the following Microsoft guide.: https://learn.microsoft.com/en-us/azure/iot-dps/how-to-legacy-device-symm-key?tabs=linux&amp%3Bpivots=programming-language-ansi-c&pivots=programming-language-ansi-c#derive-a-device-key

Inspecting the newly created enrollment group will reveal some keys. The primary key will be used to derive each individual device identity. This can be done using a simple script, which is available [https://learn.microsoft.com/en-us/azure/iot-dps/how-to-legacy-device-symm-key?tabs=linux&amp%3Bpivots=programming-language-ansi-c&pivots=programming-language-ansi-c#derive-a-device-key in this Microsoft guide]

In the script, you will notice a couple of important variables: KEY and REG_ID. In the KEY field, you must specify the primary key, which can be obtained from the newly created enrollment group.

In the script, you will notice a couple of important variables: KEY and REG_ID. In the KEY field, you must specify the primary key, which can be obtained from the newly created enrollment group.

[[File:Azure_RutOSconf_15.png|border|class=tlt-border]]

[[File:Azure_RutOSconf_15.png|border|class=tlt-border]]

After executing the script, go back to the RUT device Services -> Cloud Solutions -> Azure IoT Hub configurations page and add a new instance. In the configuration window, select DPS connection type and Symmetric Key connection type.

After executing the script, go back to the RUT device '''Services -> Cloud Solutions -> Azure IoT Hub''' configurations page and add a new instance. In the configuration window, select DPS connection type and Symmetric Key connection type.

<ul>

<ul>

<li> In the "ID scope" field, specify your Azure DPS service ID. </li>

<li> In the "'''ID scope'''" field, specify your Azure DPS service ID. </li>

<li> In the "Registration ID" field, enter the "REG_ID" value you specified in the script. For example, "wiki-newly-generated-device". </li>

<li> In the "'''Registration ID'''" field, enter the "REG_ID" value you specified in the script. For example, "wiki-newly-generated-device". </li>

<li>In the "Symmetric key" field, enter the "SharedAccessKey" obtained from the script execution.  </li>

<li>In the "'''Symmetric key'''" field, enter the "SharedAccessKey" obtained from the script execution.  </li>

</ul>

</ul>

If you are following this guide, your configuration window should look similar to the screenshot below.

If you are following this guide, your configuration window should look similar to the screenshot below.

[[File:Azure RutOSconf 19.png|border|class=tlt-border]]

[[File:Azure RutOSconf 19.png|border|class=tlt-border]]

For testing and demonstration purposes, we will use the Azure IoT Explorer application. The Azure IoT Explorer is a graphical tool for interacting with devices connected to your IoT hub. If you are not familiar with it, you can follow this Microsoft installation and usage guide https://learn.microsoft.com/en-us/azure/iot/howto-use-iot-explorer

For testing and demonstration purposes, we will use the Azure IoT Explorer application. The Azure IoT Explorer is a graphical tool for interacting with devices connected to your IoT hub. If you are not familiar with it, you can follow [https://learn.microsoft.com/en-us/azure/iot/howto-use-iot-explorer this Microsoft installation and usage guide]

After enabling the Direct Method feature, go to Azure IoT Explorer, select the appropriate device identity, and navigate to the Direct Methods tab. All our RUT devices support the api_call direct method, which exposes the API interface to be used from the Azure side. In this example, we will make a simple GET request to retrieve the I/O status of the device. Full documentation of Teltonika devices API can be found here https://developers.teltonika-networks.com/

After enabling the Direct Method feature, go to Azure IoT Explorer, select the appropriate device identity, and navigate to the Direct Methods tab. All our RUT devices support the api_call direct method, which exposes the API interface to be used from the Azure side. In this example, we will make a simple GET request to retrieve the I/O status of the device. Full documentation of Teltonika devices API can be found [https://developers.teltonika-networks.com/ here]

In the Azure IoT Explorer Direct Method tab, you will see a Payload field. It expects to receive JSON-formatted information.

In the Azure IoT Explorer Direct Method tab, you will see a Payload field. It expects to receive JSON-formatted information.

To determine the appropriate payload and method to use, we provide an additional file currently called "teltonikaGenericDevice.json." This file is written in Digital Twin Definition Language (DTDL). It is similar to SNMP MIB documents by design, as it also describes device capabilities. In this file, you can see that it supports the api_call method, which accepts three values. The request body is optional, as some methods, such as the GET method, may not require it. INSERT FILES!

To determine the appropriate payload and method to use, we provide an additional file currently called "teltonikaGenericDevice.json." This file is written in Digital Twin Definition Language (DTDL). It is similar to SNMP MIB documents by design, as it also describes device capabilities. In this file, you can see that it supports the api_call method, which accepts three values. The request body is optional, as some methods, such as the GET method, may not require it. INSERT FILES!

The IoT Explorer can be configured to parse DTDL files and display them to the user. Let's configure it:

The IoT Explorer can be configured to parse DTDL files and display them to the user. Let's configure it:

After a few seconds, you should see that data was sent from the device to the Azure IoT Hub. If you see a similar response, it indicates that everything was configured correctly.

After a few seconds, you should see that data was sent from the device to the Azure IoT Hub. If you see a similar response, it indicates that everything was configured correctly.