This very long post is about how to connect a Dragino LHT65 Temperature and Humidity sensor to Azure IoT Central using my TTI/TTN V3Azure IoT Connector and the Digital Twin Definition Language (DTDL).
The first step was to add an application(dragino-lht65) in my The Things Industries(TTI) tenant
The new Application API Key used by the MQTTnet managed client only needs to have write downlink and read uplink traffic enabled.
So I could reliably connect to my LHT65 devices to configure them I modified a programming cable so I could use it with a spare FTDI adaptor without jumper wires. Todo this I used a small jewelers screwdriver to “pop” out the VCC cable and move the transmit data line.
After entering the device password and checking the firmware version I used the AT+CFG command to display the device settings
AT+CFG: Print all configurations
[334428]***** UpLinkCounter= 0 *****
[334430]TX on freq 923200000 Hz at DR 2
[334804]txDone
[339807]RX on freq 923200000 Hz at DR 2
[339868]rxTimeOut
[340807]RX on freq 923200000 Hz at DR 2
[340868]rxTimeOut
Correct Password
Stop Tx events,Please wait for all configurations to print
Printf all config...
AT+DEUI=a8 .. .. .. .. .. .. d6
AT+DADDR=01......D6
AT+APPKEY=9d .. .. .. .. .. .. .. .. .. .. .. .. .. .. 2e
AT+NWKSKEY=f6 .. .. .. .. .. .. .. .. .. .. .. .. .. .. 69
AT+APPSKEY=4c 35 .. .. .. .. .. .. .. .. .. .. .. .. .. 3d
AT+APPEUI=a0 .. .. .. .. .. .. 00
AT+ADR=1
AT+TXP=0
AT+DR=0
AT+DCS=0
AT+PNM=1
AT+RX2FQ=923200000
AT+RX2DR=2
AT+RX1DL=1000
AT+RX2DL=2000
AT+JN1DL=5000
AT+JN2DL=6000
AT+NJM=1
AT+NWKID=00 00 00 00
AT+FCU=0
AT+FCD=0
AT+CLASS=A
AT+NJS=0
AT+RECVB=0:
AT+RECV=0:
AT+VER=v1.7 AS923
AT+CFM=0
AT+CFS=0
AT+SNR=0
AT+RSSI=0
AT+TDC=1200000
AT+PORT=2
AT+PWORD=123456
AT+CHS=0
AT+DATE=21/3/26 07:49:15
AT+SLEEP=0
AT+EXT=4,2
AT+RTP=20
AT+BAT=3120
AT+WMOD=0
AT+ARTEMP=-40,125
AT+CITEMP=1
Start Tx events OK
[399287]***** UpLinkCounter= 0 *****
[399289]TX on freq 923400000 Hz at DR 2
[399663]txDone
[404666]RX on freq 923400000 Hz at DR 2
[404726]rxTimeOut
[405666]RX on freq 923200000 Hz at DR 2
[405726]rxTimeOut
I copied the AppEUI and DevEUI for use on the TI Dragino LHT65 Register end device form provided by the TTI/TTN.
The Dragino LHT65 uses the DeviceEUI as the DeviceID which meant I had todo more redaction in my TTI/TTN and Azure Application Insights screen captures. The rules around the re-use of EndDevice ID were a pain in the arse(PITA) in my development focused tenant.
The connector supports both uplink and downlink messages with JSON encoded payloads. The Dragino LHT65 has a vendor supplied formatter which is automatically configured when an EndDevice is created. The EndDevice formatter configuration can also be overridden at the Application level in the app.settings.json file.
Once an EndDevice is configured in TTI/TTN I usually use the “Live data Uplink Payload” to work out the decoded payload JSON property names and data types.
For Azure IoT Central “automagic” provisioning the DTDLModelId has to be copied from the Azure IoT Central Template into the TTI/TTN EndDevice or app.settings.json file application configuration.
Configuring the DTDLV2 @ID at the TTI application level in the app.settings.json file
{
"Logging": {
"LogLevel": {
"Default": "Debug",
"Microsoft": "Debug",
"Microsoft.Hosting.Lifetime": "Debug"
},
"ApplicationInsights": {
"LogLevel": {
"Default": "Debug"
}
}
},
"ProgramSettings": {
"Applications": {
"application1": {
"AzureSettings": {
"DeviceProvisioningServiceSettings": {
"IdScope": "0ne...DD9",
"GroupEnrollmentKey": "eFR...w=="
}
},
"DTDLModelId": "dtmi:ttnv3connectorclient:FezduinoWisnodeV14x8;4",
"MQTTAccessKey": "NNSXS.HCY...RYQ",
"DeviceIntegrationDefault": false,
"MethodSettings": {
"Reboot": {
"Port": 21,
"Confirmed": true,
"Priority": "normal",
"Queue": "push"
},
"value_0": {
"Port": 30,
"Confirmed": true,
"Priority": "normal",
"Queue": "push"
},
"value_1": {
"Port": 30,
"Confirmed": true,
"Priority": "normal",
"Queue": "push"
},
"TemperatureOOBAlertMinimumAndMaximum": {
"Port": 30,
"Confirmed": true,
"Priority": "normal",
"Queue": "push"
}
}
},
"seeeduinolorawan": {
"AzureSettings": {
"DeviceProvisioningServiceSettings": {
"IdScope": "0ne...DD9",
"GroupEnrollmentKey": "AtN...g=="
},
},
"DTDLModelId": "dtmi:ttnv3connectorclient:SeeeduinoLoRaWAN4cz;1",
"MQTTAccessKey": "NNSXS.V44...42A",
"DeviceIntegrationDefault": true,
"DevicePageSize": 10
},
"dragino-lht65": {
"AzureSettings": {
"DeviceProvisioningServiceSettings": {
"IdScope": "0ne...DD9",
"GroupEnrollmentKey": "SLB...w=="
}
},
"DTDLModelId": "dtmi:ttnv3connectorclient:DraginoLHT656w6;1",
"MQTTAccessKey": "NNSXS.RIJ...NZQ",
"DeviceIntegrationDefault": true,
"DevicePageSize": 10
}
},
"TheThingsIndustries": {
"MqttServerName": "eu1.cloud.thethings.industries",
"MqttClientId": "MQTTClient",
"MqttAutoReconnectDelay": "00:00:05",
"Tenant": "...-test",
"ApiBaseUrl": "https://...-test.eu1.cloud.thethings.industries/api/v3",
"ApiKey": "NNSXS.NR7...ZSA",
"Collaborator": "devmobile",
"DevicePageSize": 10,
"DeviceIntegrationDefault": true
}
}
}
The Azure Device Provisioning Service(DPS) is configured at the TTI application level in the app.settings.json file. The IDScope and one of the Primary or Secondary Shared Access Signature(SAS) keys should be copied into DeviceProvisioningServiceSettings of an Application in the app.settings.json file. I usually set the “Automatically connect devices in this group” flag as part of the “automagic” provisioning process.
For testing the connector application can be run locally with diagnostic information displayed in the application console window as it “automagically’ provisions devices and uploads telemetry data.
One a device has been provisioned I check on the raw data display that all the fields I configured have been mapped correctly.
I then created a dashboard to display the telemetry data from the LHT65 sensors.
The dashboard also has a few KPI displays which highlighted an issue which occurs a couple of times a month with the LHT65 onboard temperature sensor values (327.7°). I have connected Dragino technical support and have also been unable to find a way to remove the current an/or filter out future aberrant values.
I also noticed that the formatting of the DeviceEUI values in the Application Insights logging was incorrect after trying to search for one of my Seeedstudio LoRaWAN device with its DeviceEUI.
Pingback: TTI V3 Connector Device EUI Representation | devMobile's blog