## 6 Analysis and Results
### SensorData Connector: Payload Analysis and Results  
In this section, we will test the behaviour of a SensorData connector when receiving a payload. After taking some measurements, the sensor transmits the obtained values through a payload containing the hexadecimal string that follows to the gateway:  
\[``1B089\text{C7157}A3334801260618231006A18\"\]  
As shown in Figure 6, the LoRaWAN gateway receives the payload through port 10 and in turn forwards it to the system broker in a message that includes the unique ID identifying the sensor, in this case set to \"001\". The broker, upon receiving the packet, publishes it to the respective SensorData topic, where the connector associated with the SensorData devices is listening. The connector receives the message as shown in Listing 1, and the first operation performed by the connector is to extract the THING entity from its internal database, which is present in the SensorThing system of the central server, correlated with the received ID according to the following Listing 2. ```
1 ID:001, PORT:10, PMIOAD:AF4D3276 CESF3334801260618231006A18
```  
Listing 1: SensorData PHING extraction. ```
1 Name:\"Sens-IA12\", Description:\"Device SensorData1\"
```  
Listing 2: SensorData THING extraction. In this way, the connector recognizes which device sent the message and can proceed to update the data present on the server based on the information received. Furthermore, as specified, the LoRaWAN port number corresponds to the ID of the first \"data field\" sent; in this case, the number 10 corresponds to the \"data field\" GPS, while the payload starts from byte 0 with the values related to the \"data field\" corresponding to the port. The connector proceeds to analyse the received payload according to the following specifications:  
```
1**1B089C7157A**: From the port number, it can be inferred that the first 6 bytes of the payload contain the position value of the device. Specifically, the first 3 bytes (1B089C) correspond to the device's latitude, while the last 3 bytes (7157A) correspond to the longitude. Therefore, in this case, after the appropriate conversions, the latitude and longitude coordinates obtained are \(Latitude\) = 45.3549056 and \(Longitude\) = 11.884812, as shown in Listing 3. With these values, the connector has created a new LOCATION entity to associate with the

Figure 6: Architecture for testing the Digital Matter SensorData device and the corresponding connector. device in the system. In particular, the sensor is located at the coordinates that correspond to a rural geographic area near Padova. ```
{encodingType:application/vnd.geo+json, location:[ type:Feature, geometry:[ type:Point, coordinates:[45.3549056,11.884812] ] ] ] ] ] ]
```
**Listing 3**Association SensorData LOCATION of the device in the system. \(\blacksquare\) **3334**: From byte '33', we derive ID 51, which corresponds to the battery level indicator, while from byte '34', we obtain the measured value, which is 52 (Listing 4). The connector searches among the DATASTREAMs linked to the THING entity of the device for the one related to the remaining battery measurement (Listing 5). ```
{ result:52 ] ]
```
**Listing 5**DATASTREAM associated with the battery Digital Matter sensor. ```
{ name:\"Batteryremain\", description:\"Remaining batteryofthedevice\", unitOHMeasurement: name:\"Percentage\", symbol:\"%\", definition:\"\" ], observationType:\"OM_Observation\", ] ]
```
**Listing 6**SensorData OBSERVED PROPERTY entity. If the DATASTREAM is not present in the OGC SensorThings system, the connector extracts its properties and the related entities from its internal database and creates a new one. The same operation is performed for the SENSOR and OBSERVED PROPERTY entities if they are missing in the central system, as shown in Listings 6 and 7. ```
{ name:\"Batteryremain\", definition:\"HTHS//en.wikipedia.org/wiki /Electric_battery\" description:\"The remaining energy levelofan electricbattery\" ]
```
**Listing 7**SENSOR entity.