Feature/346 enable markdown linting (#371)
* Add action for linting markdown * fix action syntax * more syntax fix for yaml * fix job syntax * edit markdown to trigger action * fix format of task * Fix line lengths and linting * linting of all docs/*.md * replace config with jsonc * add config to action * fix some additional linting * use CLI instead of bloated superlinter * syntax again Not used to Action syntax yet * splitting steps * ignore node-modules in linting * Linting of additional docs * fix another file that was missed * rename Action and remove comments from previous implementation * add config for mlc * add more config for linkcheck * test with verbose logging * wrong links for test * the config file was broken * fix all broken links hopefully * fixing links once more * fix links and reduce verbosity * final link fix * simplify yaml, parallel jobs * split runs * inject linting error and wrong link as final test * fixed and ci working as expected
This commit is contained in:
Roel Fauconnier
GitHub
Родитель
3813fe97fe
Коммит
8f6993ef06
|
|
@ -0,0 +1,32 @@
|
|||
name: Lint and Check Markdown
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
branches: [master, dev]
|
||||
# only trigger when the PR contains a markdown file
|
||||
paths:
|
||||
- '**.md'
|
||||
- '**.markdown'
|
||||
|
||||
jobs:
|
||||
lint-markdown:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/setup-node@v2
|
||||
- run: |
|
||||
npm install markdownlint-cli
|
||||
- run: |
|
||||
node_modules/.bin/markdownlint -c .markdownlint.jsonc -i node_modules/ .
|
||||
|
||||
check-markdown-links:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Markdown Link Check
|
||||
uses: gaurav-nelson/github-action-markdown-link-check@v1
|
||||
with:
|
||||
check-modified-files-only: 'no' #todo make this dependent on label
|
||||
config-file: .markdown-link-check.jsonc
|
||||
use-quiet-mode: 'yes'
|
||||
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
{
|
||||
"ignorePatterns": [
|
||||
{
|
||||
"pattern": "^http://modulename"
|
||||
},
|
||||
{
|
||||
"pattern": "^https://xxx"
|
||||
},
|
||||
{
|
||||
"pattern": "^http://localhost"
|
||||
},
|
||||
{
|
||||
"pattern": "^http://yourhost"
|
||||
}
|
||||
],
|
||||
"replacementPatterns": [
|
||||
{
|
||||
"pattern": "^/",
|
||||
"replacement": "{{BASEURL}}/"
|
||||
},
|
||||
{
|
||||
"pattern": "^./",
|
||||
"replacement": "{{BASEURL}}/"
|
||||
}
|
||||
],
|
||||
"aliveStatusCodes": [200, 206]
|
||||
}
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
{
|
||||
// disable line length limitations for existing documentation
|
||||
"MD013": false,
|
||||
// allow same headings
|
||||
"MD024": false
|
||||
}
|
||||
|
|
@ -1,7 +1,6 @@
|
|||
## Arduino Demo Code
|
||||
|
||||
__Please make sure the device twin tags are set correctly in IoT Hub, otherwise the sample won't work. Necessary tags are at the start of every sample file.ino.__
|
||||
# Arduino Demo Code
|
||||
|
||||
> **Please make sure the device twin tags are set correctly in IoT Hub, otherwise the sample won't work. Necessary tags are at the start of every sample file.ino.**
|
||||
|
||||
This samples were tested with the [Seeeduino LoRaWan boards](http://wiki.seeedstudio.com/Seeeduino_LoRAWAN/). The LoRaWan libraraie (referenced thru "LoRaWan.h" in the ino files) is coming when you select the platform as a Seeduino LoRaWan board.
|
||||
|
||||
|
|
@ -17,4 +16,4 @@ This samples were tested with the Seeeduino LoRaWan boards. Samples are organize
|
|||
|
||||
3. **GPSOTAALoRa** - This sample sends GPS latitude and longitude information every 30 seconds using the onboard GPS. It uses OTAA activation. It uses OTAA activation to authenticate.
|
||||
|
||||
34 **TemperatureOTAALoRa** - This sample use the [Grove temperature sensor](http://wiki.seeedstudio.com/Grove-Temperature_Sensor/) to send temperature information every 30 seconds. It uses OTAA activation to authenticate. The sample also display on the serial interface any cloud to device message.
|
||||
34 **TemperatureOTAALoRa** - This sample use the [Grove temperature sensor](http://wiki.seeedstudio.com/Grove-Temperature_Sensor/) to send temperature information every 30 seconds. It uses OTAA activation to authenticate. The sample also display on the serial interface any cloud to device message.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,8 @@
|
|||
|
||||
# Contributing
|
||||
|
||||
This project welcomes contributions and suggestions. Most contributions require you to agree to a
|
||||
Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us
|
||||
the rights to use your contribution. For details, visit https://cla.microsoft.com.
|
||||
the rights to use your contribution. For details, visit <https://cla.microsoft.com>.
|
||||
|
||||
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide
|
||||
a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions
|
||||
|
|
|
|||
|
|
@ -2,13 +2,27 @@
|
|||
|
||||
## Background
|
||||
|
||||
LoRaWAN is a type of wireless wide-area networking that is designed to allow long-range communication at a low bit rate among low-power connected objects, such as sensors operated on a battery.
|
||||
LoRaWAN is a type of wireless wide-area networking that is designed to allow
|
||||
long-range communication at a low bit rate among low-power connected objects,
|
||||
such as sensors operated on a battery.
|
||||
|
||||
Network topology is of star-of-stars type, with the leaf sensors sending data to gateways for forwarding telemetry to and receiving commands from backing Internet services. Nowadays, even for simple scenarios like having 10 devices connected to a single LoRaWan gateway (hardware with antenna), you need to connect your gateway to a Network Server and then work through connectors provided by the server vendor to integrate your LoRa gateways and devices with the back end. These setups can be connected to Azure IoT Hub quite easily. As a matter of fact [such scenarios exist](https://github.com/loriot/AzureSolutionTemplate). Customers looking for an operated network with national or international reach (e.g. fleet operators, logistics) will tend to choose this setup accepting the potentially higher complexity and dependency on the network operator.
|
||||
Network topology is of star-of-stars type, with the leaf sensors sending data to
|
||||
gateways for forwarding telemetry to and receiving commands from backing
|
||||
Internet services. Nowadays, even for simple scenarios like having 10 devices
|
||||
connected to a single LoRaWan gateway (hardware with antenna), you need to
|
||||
connect your gateway to a Network Server and then work through connectors
|
||||
provided by the server vendor to integrate your LoRa gateways and devices with
|
||||
the back end. These setups can be connected to Azure IoT Hub quite easily.
|
||||
As a matter of fact [such scenarios exist](https://github.com/loriot/AzureSolutionTemplate).
|
||||
Customers looking for an operated network with national or international reach
|
||||
(e.g. fleet operators, logistics) will tend to choose this setup accepting the
|
||||
potentially higher complexity and dependency on the network operator.
|
||||
|
||||
However, customers looking for any of the following are expected to prefer a setup where the LoRaWAN network servers runs directly on the gateway/Azure IoT Edge:
|
||||
However, customers looking for any of the following are expected to prefer a
|
||||
setup where the LoRaWAN network servers runs directly on the gateway/Azure IoT Edge:
|
||||
|
||||
- Primarily coverage on their own ground (e.g. manufacturing plants, smart buildings, facilities, ports).
|
||||
- Primarily coverage on their own ground (e.g. manufacturing plants,
|
||||
smart buildings, facilities, ports).
|
||||
- Capabilities that Azure IoT edge brings to the table:
|
||||
- Local processing on the gateway.
|
||||
- Offline capabilities of the gateway.
|
||||
|
|
@ -16,11 +30,22 @@ However, customers looking for any of the following are expected to prefer a set
|
|||
- Homogenous management of devices and gateways independent of connectivity technology.
|
||||
|
||||
## High Level Architecture
|
||||
Below is a high level diagram of how the framework works, for more details refer to the [dev guide](devguide.md).
|
||||
|
||||
Below is a high level diagram of how the framework works, for more details refer
|
||||
to the [dev guide](devguide.md).
|
||||
|
||||
|
||||
|
||||
## Concepts
|
||||
|
||||
### Adaptive Data Rate
|
||||
Solution support Adaptive Data Rate (ADR) device management as specified in [LoRa spec v1.0.2](https://lora-alliance.org/resource-hub/lorawantm-specification-v102). The main goal of the ADR is to optimize the network for maximum capacity ensuring devices always transmit with their best settings possible (highest DR, lowest power), you can find more ADR information on this [page](https://www.sghoslya.com/p/how-does-lorawan-nodes-changes-their.html).
|
||||
Adaptive Data rate is always initiated and set on the device side. ADR should never be used with moving devices. Our implementation currently implement the [Semtech proposed Algorithm for ADR](https://www.thethingsnetwork.org/forum/uploads/default/original/2X/7/7480e044aa93a54a910dab8ef0adfb5f515d14a1.pdf) and has been tested against EU868 region plan.
|
||||
|
||||
Solution support Adaptive Data Rate (ADR) device management as specified in
|
||||
[LoRa spec v1.1](https://lora-alliance.org/resource_hub/lorawan-specification-v1-1/).
|
||||
The main goal of the ADR is to optimize the network for maximum capacity ensuring
|
||||
devices always transmit with their best settings possible (highest DR, lowest power),
|
||||
you can find more ADR information on this [page](https://www.sghoslya.com/p/how-does-lorawan-nodes-changes-their.html).
|
||||
Adaptive Data rate is always initiated and set on the device side. ADR should
|
||||
never be used with moving devices. Our implementation currently implement the
|
||||
[Semtech proposed Algorithm for ADR](https://www.thethingsnetwork.org/forum/uploads/default/original/2X/7/7480e044aa93a54a910dab8ef0adfb5f515d14a1.pdf)
|
||||
and has been tested against EU868 region plan.
|
||||
|
|
|
|||
109
Docs/devguide.md
109
Docs/devguide.md
|
|
@ -6,12 +6,15 @@ The code is organized into three sections:
|
|||
|
||||
- **LoRaEngine** - a .NET core 3.1 solution with the following folders:
|
||||
- **modules** - Azure IoT Edge modules.
|
||||
- **LoraKeysManagerFacade** - An Azure function handling device provisioning (e.g. LoRa network join, OTAA) with Azure IoT Hub as persistence layer.
|
||||
- **LoraKeysManagerFacade** - An Azure function handling device provisioning
|
||||
(e.g. LoRa network join, OTAA) with Azure IoT Hub as persistence layer.
|
||||
- **LoRaDevTools** - library for dev tools (git submodule)
|
||||
- **Arduino** - Examples and references for LoRa Arduino based devices.
|
||||
- **Template** - Contain code useful for the "deploy to Azure button"
|
||||
- **Tools** - Contains tools that support the LoRaWan Gateway project
|
||||
- **Cli-LoRa-Device-Provisioning** - .NET Core 2.1 Command Line tool that allows to list, query, verify, insert, edit, update and delete LoRa leaf device configurations into IoT Hub
|
||||
- **Cli-LoRa-Device-Provisioning** - .NET Core 2.1 Command Line tool that
|
||||
allows to list, query, verify, insert, edit, update and delete LoRa leaf
|
||||
device configurations into IoT Hub
|
||||
- **Samples** - Contains sample decoders
|
||||
- **Docs** - Additional modules, pictures and documentations
|
||||
|
||||
|
|
@ -20,7 +23,7 @@ The code is organized into three sections:
|
|||
A **.NET Core 3.1** solution with the following projects:
|
||||
|
||||
- **modules** - Azure IoT Edge modules.
|
||||
- **LoRaWanPktFwdModule** packages the network forwarder into an IoT Edge compatible docker container. See https://github.com/Lora-net/packet_forwarder and https://github.com/Lora-net/lora_gateway. If you are using a RAK833-USB see this [submodule](/Docs/LoRaWanPktFwdRAK833USB)
|
||||
- **LoRaWanPktFwdModule** packages the network forwarder into an IoT Edge compatible docker container. See <https://github.com/Lora-net/packet_forwarder> and <https://github.com/Lora-net/lora_gateway>. If you are using a RAK833-USB see this [submodule](/Docs/LoRaWanPktFwdRAK833USB)
|
||||
- **LoRaWanNetworkSrvModule** - is the LoRaWAN network server implementation.
|
||||
- **LoraKeysManagerFacade** - An Azure function handling device provisioning (e.g. LoRa network join, OTAA) with Azure IoT Hub as persistence layer.
|
||||
- **LoRaDevTools** - library for dev tools (git submodule)
|
||||
|
|
@ -32,23 +35,23 @@ This schema represent the various components and how they interact to have a bet
|
|||
|
||||
|
||||
1. Once the IoT Edge engine start on the Edge device, the code modules are downloaded from the Azure Container Registry.
|
||||
2. The module containing the ```LoRaWan network server``` is downloaded on the Edge device
|
||||
1. The module containing the ```LoRaWan network server``` is downloaded on the Edge device
|
||||
|
||||
Notes:
|
||||
> Notes:
|
||||
>
|
||||
> - The LoRaWanPktFwdModule can be replaced by the [LoRaWan Packet Forwarder for RAK833-USB](/Docs/LoRaWanPktFwdRAK833USB) if you have a RAK833 connected thru USB
|
||||
> - The LoRaWan gateway must implement a UDP server on port 1680 to forward the LoRa commands from/to the ```LoRaWan Network Server``` module. In our case it is called ```LoRaWan Packet Forwarder```
|
||||
|
||||
- The LoRaWanPktFwdModule can be replaced by the [LoRaWan Packet Forwarder for RAK833-USB](/Docs/LoRaWanPktFwdRAK833USB) if you have a RAK833 connected thru USB
|
||||
- The LoRaWan gateway must implement a UDP server on port 1680 to forward the LoRa commands from/to the ```LoRaWan Network Server``` module. In our case it is called ```LoRaWan Packet Forwarder```
|
||||
1. The LoRaWan Network Server request status for the LoRa devices. The Azure Function ```LoraKeysManagerFacade``` is used to aquire the device identity from IoT Hub.
|
||||
1. In the case you're using the demo device with the automatic deployment Azure Resource Manager (ARM) template: the Azure function ```LoraKeysManagerFacade``` will register the device ```47AAC86800430028``` into the Azure IoT Hub for you. Otherwise you need to provision a device yourself in IoT Hub: [device provisioning](./Tools/Cli-LoRa-Device-Provisioning)
|
||||
1. The Azure function ```LoraKeysManagerFacade``` sends back the device identity to the module
|
||||
1. The ```LoRaWan Network Server``` module:
|
||||
|
||||
3. The LoRaWan Network Server request status for the LoRa devices. The Azure Function ```LoraKeysManagerFacade``` is used to aquire the device identity from IoT Hub.
|
||||
4. In the case you're using the demo device with the automatic deployment Azure Resource Manager (ARM) template: the Azure function ```LoraKeysManagerFacade``` will register the device ```47AAC86800430028``` into the Azure IoT Hub for you. Otherwise you need to provision a device yourself in IoT Hub: [device provisioning ](/README.md/#lora-device-provisioning)
|
||||
5. The Azure function ```LoraKeysManagerFacade``` sends back the device identity to the module
|
||||
6. The ```LoRaWan Network Server``` module:
|
||||
- instantiate the device on the LoRa Gateway if needed
|
||||
- gather the LoRa sensor data from the LoRaWan gateway thru the ```LoRaWan Packet Forwarder```
|
||||
- decode the LoRa data if requested
|
||||
|
||||
- instantiate the device on the LoRa Gateway if needed
|
||||
- gather the LoRa sensor data from the LoRaWan gateway thru the ```LoRaWan Packet Forwarder```
|
||||
- decode the LoRa data if requested
|
||||
|
||||
7. Publish the LoRa sensor data to Azure IoT Hub
|
||||
1. Publish the LoRa sensor data to Azure IoT Hub
|
||||
|
||||
Another view of the architecture and a more message driven view is the following:
|
||||
|
||||
|
|
@ -84,7 +87,7 @@ If you want to update a LoRa Gateway running a previous version fo our software
|
|||
|
||||
You have the option to either deploy the Azure Function code from your Visual Studio Code to Azure or create an empty Azure Function that points to a Zip file hosted by us, containing the function code. Follow one of the two sets of instructions that follow:
|
||||
|
||||
#### Deploy manually using Visual Studio
|
||||
#### Deploy manually using Visual Studio
|
||||
|
||||
On your Visual Studio Solution, right click on the 'LoRaKeysManagerFacade' project, select 'deploy', then 'Azure' and then 'Azure function'. You should then arrive on a page where you just need to hit the deploy button to get the code deployed on Azure.
|
||||
|
||||
|
|
@ -105,7 +108,7 @@ On your Visual Studio Solution, right click on the 'LoRaKeysManagerFacade' proje
|
|||
|-|-|
|
||||
|WEBSITE_RUN_FROM_ZIP|<https://github.com/Azure/iotedge-lorawan-starterkit/releases/download/v1.0.4/function-1.0.4.zip>|
|
||||
|
||||
|
||||
|
||||
|
||||
#### Follow these next steps in both cases
|
||||
|
||||
|
|
@ -148,19 +151,19 @@ FACADE_AUTH_CODE=yourfunctionpassword
|
|||
|
||||
### Use a Proxy server to connect your Concentrator to Azure
|
||||
|
||||
**This step is optional and should only be executed if your concentrator needs to use a proxy server to communicate with Azure**
|
||||
> **This step is optional and should only be executed if your concentrator needs to use a proxy server to communicate with Azure**
|
||||
|
||||
Follow the guide on [configuring an IoT Edge device to communicate through a proxy server](https://docs.microsoft.com/en-us/azure/iot-edge/how-to-configure-proxy-support) to:
|
||||
|
||||
1. Configure the Docker daemon and the IoT Edge daemon on your device to use a proxy server.
|
||||
2. Configure the edgeAgent properties in the config.yaml file on your device.
|
||||
3. Set environment variables for the IoT Edge runtime in the deployment manifest.
|
||||
3. Set environment variables for the IoT Edge runtime in the deployment manifest.
|
||||
|
||||
After that, add the environment variable `https_proxy` to the `LoRaWanNetworkSrvModule` in your `IoT Hub` → `IoT Edge` → `Edge Device` → `Set Modules` section.
|
||||
|
||||
|
||||
|
||||
**End of optional proxy configuration**
|
||||
> **End of optional proxy configuration**
|
||||
|
||||
### Setup concentrator with Azure IoT Edge
|
||||
|
||||
|
|
@ -186,7 +189,7 @@ After that you can push the solution to your IoT Edge device by right clicking o
|
|||
|
||||
### Provision LoRa leaf device
|
||||
|
||||
The [sample code](/Arduino/TemperatureOtaaLora/TemperatureOtaaLora.ino) used in this example is based on [Seeeduino LoRaWAN](http://wiki.seeedstudio.com/Seeeduino_LoRAWAN/) with a [Grove - Temperature Sensor](http://wiki.seeedstudio.com/Grove-Temperature_Sensor_V1.2/). It sends every 30 seconds its current temperature reading and prints out a Cloud-2-Device message if one is transmitted in its receive window.
|
||||
The [sample code](/Arduino/EU/TemperatureOtaaLora/TemperatureOtaaLora.ino) used in this example is based on [Seeeduino LoRaWAN](http://wiki.seeedstudio.com/Seeeduino_LoRAWAN/) with a [Grove - Temperature Sensor](http://wiki.seeedstudio.com/Grove-Temperature_Sensor_V1.2/). It sends every 30 seconds its current temperature reading and prints out a Cloud-2-Device message if one is transmitted in its receive window.
|
||||
|
||||
The sample has configured the following sample [device identifiers and credentials](https://www.thethingsnetwork.org/docs/lorawan/security.html):
|
||||
|
||||
|
|
@ -202,8 +205,8 @@ Look out for these code lines:
|
|||
lora.setId(NULL, "47AAC86800430010", "BE7A0000000014E3");
|
||||
lora.setKey(NULL, NULL, "8AFE71A145B253E49C3031AD068277A3");
|
||||
```
|
||||
|
||||
To provisioning a device in Azure IoT Hub with these identifiers and capable to [decode](/LoRaEngine/modules/LoRaWanNetworkSrvModule/LoRaWan.NetworkServer/LoraDecoders.cs) simple value payload into Json you have to create a device with:
|
||||
<!-- markdown-link-check-disable -->
|
||||
To provisioning a device in Azure IoT Hub with these identifiers and capable to [decode](/LoRaEngine/modules/LoRaWanNetworkSrvModule/LoRaWan.NetworkServer/LoraPayloadDecoder.cs) simple value payload into Json you have to create a device with:
|
||||
|
||||
Device Id: `47AAC86800430010` and Device Twin's deired properties:
|
||||
|
||||
|
|
@ -214,8 +217,11 @@ Device Id: `47AAC86800430010` and Device Twin's deired properties:
|
|||
"SensorDecoder": "DecoderValueSensor"
|
||||
}
|
||||
```
|
||||
|
||||
You can provision the device manually in the Azure portal or use the provided [Command Line Interface Provisioning Tool to list, query, verify add, update, and remove devices](../Tools/Cli-LoRa-Device-Provisioning).
|
||||
|
||||
<!-- markdown-link-check-enable -->
|
||||
|
||||
The command to execute is:
|
||||
|
||||
```powershell
|
||||
|
|
@ -296,40 +302,45 @@ The Arduino example provided above will print the message on the console. Keep i
|
|||
|
||||
## Debugging in Visual Studio, outside of IoT Edge and Docker
|
||||
|
||||
<!-- markdown-link-check-disable -->
|
||||
|
||||
It is possible to run the LoRaEngine locally from Visual Studio in order to enable a better debugging experience. Here are the steps you will need to follow in order to enable this feature:
|
||||
|
||||
1. Either change the value *server_adress* in the file [local_conf.json](./modules/LoRaWanPktFwdModule/local_conf.json) (located in LoRaEngine/modules/LoRaWanPktFwdModule) to point to your computer. Rebuild and redeploy the container.
|
||||
1. Either change the value *server_adress* in the file [local_conf.json](/LoraEngine/modules/LoRaWanPktFwdModule/local_conf.json) (located in LoRaEngine/modules/LoRaWanPktFwdModule) to point to your computer. Rebuild and redeploy the container.
|
||||
|
||||
2. **Alternatively**, configure your unmodified LoRaWanPktFwdModule Docker container / Edge module with the environment variable `NETWORK_SERVER=<ip of your computer>`
|
||||
1. **Alternatively**, configure your unmodified LoRaWanPktFwdModule Docker container / Edge module with the environment variable `NETWORK_SERVER=<ip of your computer>`
|
||||
|
||||
3. If you are using a Wireless network in Windows, make sure it is configured as a private network in your Windows settings. Otherwise, the Windows Firewall will bock the incoming UDP packets.
|
||||
1. If you are using a Wireless network in Windows, make sure it is configured as a private network in your Windows settings. Otherwise, the Windows Firewall will bock the incoming UDP packets.
|
||||
|
||||
4. Open the properties of the project [LoRaWanNetworkServerModule](/modules/LoRaWanNetworkSrvModule/LoRaWanNetworkSrvModule/LoRaWanNetworkSrvModule.csproj) and set the following Environment Variables under the Debug tab:
|
||||
1. Open the properties of the project [LoRaWanNetworkServerModule](/LoraEngine/modules/LoRaWanNetworkSrvModule/LoRaWanNetworkSrvModule/LoRaWanNetworkSrvModule.csproj) and set the following Environment Variables under the Debug tab:
|
||||
|
||||
- IOTEDGE_IOTHUBHOSTNAME : XXX.azure-devices.net (XXX = your iot hub hostname)
|
||||
- ENABLE_GATEWAY : false
|
||||
- LOG_LEVEL : 1 or Debug (optional, to activate most verbose logging level)
|
||||
- FACADE_SERVER_URL : http://localhost:7071/api/ (when debugging locally or any other URL of the Azure function you want to use)
|
||||
- IOTEDGE_DEVICEID : The Name of your PC
|
||||
- IOTEDGE_IOTHUBHOSTNAME : XXX.azure-devices.net (XXX = your iot hub hostname)
|
||||
- ENABLE_GATEWAY : false
|
||||
- LOG_LEVEL : 1 or Debug (optional, to activate most verbose logging level)
|
||||
- FACADE_SERVER_URL : <http://localhost:7071/api/> (when debugging locally or any other URL of the Azure function you want to use)
|
||||
- IOTEDGE_DEVICEID : The Name of your PC
|
||||
|
||||
5. Add a `local.settings.json` file to the project [LoRaKeysManagerFacade](./LoRaKeysManagerFacade) containing:
|
||||
1. Add a `local.settings.json` file to the project [LoRaKeysManagerFacade](/LoraEngine/LoRaKeysManagerFacade) containing:
|
||||
|
||||
```json
|
||||
{
|
||||
"IsEncrypted": false,
|
||||
"values": {
|
||||
"AzureWebJobsStorage": "<Connection String of your deployed blob storage>",
|
||||
"WEBSITE_CONTENTSHARE": "<Name of your Azure function>"
|
||||
```json
|
||||
{
|
||||
"IsEncrypted": false,
|
||||
"values": {
|
||||
"AzureWebJobsStorage": "<Connection String of your deployed blob storage>",
|
||||
"WEBSITE_CONTENTSHARE": "<Name of your Azure function>"
|
||||
|
||||
},
|
||||
"ConnectionStrings": {
|
||||
"IoTHubConnectionString": "<Connection string of your IoT Hub Owner (go to keys -> IoT Hub owner and select the connection string)>",
|
||||
"RedisConnectionString": "<Connection string of your Redis Cache>"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
},
|
||||
"ConnectionStrings": {
|
||||
"IoTHubConnectionString": "<Connection string of your IoT Hub Owner (go to keys -> IoT Hub owner and select the connection string)>",
|
||||
"RedisConnectionString": "<Connection string of your Redis Cache>"
|
||||
}
|
||||
}
|
||||
```
|
||||
5. Right click on your solution and select properties, select multiple startup projects. Start `LoRaWanNetworkSrvModule` and `LoRaKeysManagerFacade`.
|
||||
1. Right click on your solution and select properties, select multiple startup projects. Start `LoRaWanNetworkSrvModule` and `LoRaKeysManagerFacade`.
|
||||
|
||||
6. If you hit start in your VS solution, you will receive messages directly from your packet forwarder. You will be able to debug directly from your computer.
|
||||
1. If you hit start in your VS solution, you will receive messages directly from your packet forwarder. You will be able to debug directly from your computer.
|
||||
|
||||
Happy Debugging!
|
||||
|
||||
<!-- markdown-link-check-enable -->
|
||||
|
|
@ -1,32 +1,40 @@
|
|||
# Device Manufacturer Guidance
|
||||
|
||||
We have developed the LoRaWAN starter kit agnostic of a device manufacturer implementation and focussed on the specifics on underlying architectures (arm, x86). However, we understand that device manufacturers can have specific requirements to ensure the LoRa packets are processed and decoded correctly. In this section, we provide guidance for the following:
|
||||
|
||||
- **Gateway Manufacturers**: Allow a gateway to be compatible with our kit. Gateway manufacturers will test / make our Edge Hub modules work on their gateway.
|
||||
|
||||
- **LoRA Sensor Manufacturers**: These manufacturers will develop a custom decoder using our decoding framework for their sensors.
|
||||
|
||||
Please choose from a section that relates to your requirements.
|
||||
|
||||
## Device Gateway Manufacturer Guidance
|
||||
|
||||
The LoRaWAN starter kit currently is tested on many popular gateways, we run some of those as part of daily CI/CD pipeline to test integrity and performance of our codebase. However, we cannot test each and every gateway out there and hence we have created a process for device manufacturer to support their gateways and get them highlighted in this repo.
|
||||
|
||||
### Instructions
|
||||
|
||||
If you would like to test gateway compatibility with out starter kit and also get it highlighted on our GitHub page. To test gateway compatibility, please follow these steps:
|
||||
|
||||
- Go through the [Developer Guidance](/Docs/devguide.md) to clone the repo and make sure everything works in your local dev environment.
|
||||
- Make sure everything works with an Azure subscription with Standard Pricing SKU's, for example we do not support the Free Azure IoT Hub SKU.
|
||||
- Ensure that the gateway specification meet the minimal hardware configuration required for Azure IoT Edge and a container framework like Docker, Moby to run. We recommend at the minimum of 1 GB RAM, rPi based boards and similar configuration devices will be a good candidate for our starter kit.
|
||||
- If the gateway requires a specific packet forwarder not provided by our kit (we leverage an implementation of the LoRa packet forwarder). Create the appropriate code for the packet forwarded and link to our repo.
|
||||
- Run the tests on the Gateway (must be a real device) to connect to a LoRa end node and receive and send packets.
|
||||
- Once you have tested the framework and have all things running, open an issue on the repo and we will invite you to add a page for your gateway on our repo. The page can include details about your gateway and any specific instructions to make your gateway running with LoRaWAN starter kit.
|
||||
- Run the tests on the Gateway (must be a real device) to connect to a LoRa end node and receive and send packets.
|
||||
- Once you have tested the framework and have all things running, open an issue on the repo and we will invite you to add a page for your gateway on our repo. The page can include details about your gateway and any specific instructions to make your gateway running with LoRaWAN starter kit.
|
||||
|
||||
This approach provides us with validation that things work on the gateway and also allows others using the same Gateway to leverage the learnings.
|
||||
|
||||
## Device Node (sensor) Manufacturer Guidance
|
||||
|
||||
If you are a LoRa Node/Sensor manufacturer that leverages specific decoding scheme for the LoRa packets, we have provision for you to run those devices using our decoding framework.
|
||||
|
||||
### Instructions
|
||||
|
||||
Follow these steps to onboard your device with a custom decoder:
|
||||
|
||||
- Go through the [Developer Guidance](/Docs/devguide.md) to clone the repo and make sure everything works in your local dev environment.
|
||||
- Make sure everything works with an Azure subscription with Standard Pricing SKU's, for example we do not support the Free Azure IoT Hub SKU.
|
||||
- We have provided a [sample reference implementation](/Samples/DecoderSample) of a decoder, please refer to this as a template and leverage the [instructions](/Samples/DecoderSample/ReadMe.md) to create implementation of your customer decoder.
|
||||
- We have provided a [sample reference implementation](/Samples/DecoderSample) of a decoder, please refer to this as a template and leverage the [instructions](/Samples/DecoderSample/ReadMe.md) to create implementation of your customer decoder.
|
||||
- The Sample code can also contain device model specific tests that when run allows for testing of the gateway.
|
||||
- Since we are .NET Core and C# based, the sample is based on the .NET technology stack, however you can create your decoders in your preferred languages by implementing similar interfaces. If you have a specific language or platform to be supported, submit an issue to let us know.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,22 +22,23 @@ The template will deploy in your Azure subscription the Following resources:
|
|||
## Step-by-step instructions
|
||||
|
||||
1. Press on the button here below to start your Azure Deployment.
|
||||
|
||||
<a href="https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fiotedge-lorawan-starterkit%2Fmaster%2FTemplate%2Fazuredeploy.json" target="_blank">
|
||||
<img src="http://azuredeploy.net/deploybutton.png"/>
|
||||
</a>
|
||||
<!-- markdownlint-disable MD033 -->
|
||||
<a href="https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fiotedge-lorawan-starterkit%2Fmaster%2FTemplate%2Fazuredeploy.json" target="_blank">
|
||||
<img src="http://azuredeploy.net/deploybutton.png"/>
|
||||
</a>
|
||||
<!-- markdownlint-enable MD033 -->
|
||||
|
||||
2. You will get to a page asking you to fill the following fields :
|
||||
|
||||
- **Resource Group** - A logical "folder" where all the template resource would be put into, just choose a meaningful name.
|
||||
- **Location** - In which DataCenter the resources should be deployed. Make sure to choose a location where [IoT Hub is available](https://azure.microsoft.com/en-us/global-infrastructure/services/?products=iot-hub®ions=all)
|
||||
- **Unique Solution Prefix** - A string that would be used as prefix for all the resources name to ensure their uniqueness. Hence, avoid any standard prefix such as "lora" as it might already be in use and might make your deployment fail. NB: the template is creating a Storage account with the value specified here, therefore the [naming restrictions of Storage](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules#microsoftstorage) apply here.
|
||||
- **Edge gateway name** - the name of your LoRa Gateway node in the IoT Hub.
|
||||
- **Deploy Device** - Do you want demo end devices to be already provisioned (one using OTAA and one using ABP)? If yes set this to true, the code located in the [Arduino folder](/Arduino) would be ready to use immediately.
|
||||
- **Reset pin** - The reset pin of your gateway (the value should be 7 for the Seed Studio LoRaWam, 25 for the IC880A)
|
||||
- **Region** - In what region are you operating your device (currently only EU868 and US915 is supported)
|
||||
- **Resource Group** - A logical "folder" where all the template resource would be put into, just choose a meaningful name.
|
||||
- **Location** - In which DataCenter the resources should be deployed. Make sure to choose a location where [IoT Hub is available](https://azure.microsoft.com/en-us/global-infrastructure/services/?products=iot-hub®ions=all)
|
||||
- **Unique Solution Prefix** - A string that would be used as prefix for all the resources name to ensure their uniqueness. Hence, avoid any standard prefix such as "lora" as it might already be in use and might make your deployment fail. NB: the template is creating a Storage account with the value specified here, therefore the [naming restrictions of Storage](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules#microsoftstorage) apply here.
|
||||
- **Edge gateway name** - the name of your LoRa Gateway node in the IoT Hub.
|
||||
- **Deploy Device** - Do you want demo end devices to be already provisioned (one using OTAA and one using ABP)? If yes set this to true, the code located in the [Arduino folder](/Arduino) would be ready to use immediately.
|
||||
- **Reset pin** - The reset pin of your gateway (the value should be 7 for the Seed Studio LoRaWam, 25 for the IC880A)
|
||||
- **Region** - In what region are you operating your device (currently only EU868 and US915 is supported)
|
||||
|
||||
The deployment would take c.a. 10 minutes to complete.
|
||||
The deployment would take c.a. 10 minutes to complete.
|
||||
|
||||
3. During this time, you can proceed to [install IoT Edge to your gateway](https://docs.microsoft.com/en-us/azure/iot-edge/how-to-install-iot-edge-linux-arm).
|
||||
|
||||
|
|
@ -57,7 +58,7 @@ If you are using the the RAK833-USB, you'll need to adjust the template to use t
|
|||
|
||||
This is an optional configuration that should only be executed if your concentrator needs to use a proxy server to communicate with Azure.
|
||||
|
||||
Follow [this guide](./devguide.md#use-a-proxy-server-to-connect-your-concentrator-to-azure) to:
|
||||
Follow [this guide](devguide.md#use-a-proxy-server-to-connect-your-concentrator-to-azure) to:
|
||||
|
||||
1. Configure the Docker daemon and the IoT Edge daemon on your device to use a proxy server.
|
||||
2. Configure the `edgeAgent` properties in the `config.yaml` file on your device.
|
||||
|
|
@ -162,9 +163,9 @@ Customization's to lora devices are set by creating specific twin desired proper
|
|||
|Enable/disable downstream messages|Allows disabling the downstream (cloud to device) for a device. By default downstream messages are enabled| Add twin desired property `"Downlink": false` to disable downstream messages. The absence of the twin property or setting value to `true` will enable downlink messages.|Disabling downlink on devices decreases message processing latency, since the network server will not look for cloud to device messages when an uplink is received. Only disable it in devices that are not expecting messages from cloud. Acknowledgement of confirmed upstream are sent to devices even when downlink is set to false|
|
||||
|Preferred receive window|Allows setting the device preferred receive window (RX1 or RX2). The default preferred receive window is 1| Add twin desired property `"PreferredWindow": 2` sets RX2 as preferred window. The absence of the twin property or setting the value to `1` will set RX1 as preferred window.|Using the second receive window increases the chances that the end application can process the upstream message and send a cloud to device message to the lora device without requiring and additional upstream message. Basically completing the round trip in less than 2 seconds.|
|
||||
|Message Deduplication|Allows controlling the handling of duplicate messages received by multiple gateways.The default is None.| Add twin desired property `"Deduplication": "Drop"` to instruct dropping duplicate messages on the gateway, set it to `"Mark"` if you want to mark messages to the IotHub with `"dupmsg": true` in case the message was already processed. Example payload: Device: [47AAC86800430028], Data:[{"time":null,"tmms":0,"tmst":3201165987,"freq":868.3,"chan":1,"rfch":1,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","rssi":-61,"lsnr":8.2,"size":14,"data":{"value":1},"port":10,"fcnt":2,"rawdata":"QImRWQIAAgAK8I3rbqc=","eui":"47AAC86800430028","gatewayid":"simulatorpaschule1","edgets":1550501633879,`"dupmsg": true`}]|Deduplication on the gateway allows you to control how you want to handle duplicate messages in a multi gateway environment without having to add additional logic on the receiving or processing end. |
|
||||
| RX1 Datarate Offset | Allows setting an offset between received Datarate and retransmit datarate as specified in the LoRa Specifiations. Valid for OTAA devices. If an invalid value is provided the network server will use default value 0. | Add twin desired property `"RX1DROffset": # ` where # is a valid specification number to create an offset of # between received Datarate and Transmit Datarate. Please find the full table in the LoRa Specification example: upstream DR2, with a RX1DROffset of 1 will result in a transmission on DR1 | Setting an offset between receive and transmit could help deal with very saturated network. Warning, this is an advanced option, please only use if you are aware of your network specification.|
|
||||
| RX2 Datarate | Allows setting a custom Datarate for second receive windows. Valid for OTAA devices. If an invalid value is provided the network server will use default value 0 (DR0). | Add twin desired property `"RX2DataRate": # ` where # is a valid specification number to set the RX2 DR to DR#. Example: if a value of 2 is provided, second receive windows will use DR2 instead of the default DR0. | Setting a custom RX2 Datarate could help your RX2 devices to benefit of higher datarate. Warning, this is an advanced topic, changing it to higher datarate could be very dangerous and result in RX2 becoming unusable if the devices are not within reach of the specified datarate. Usage of this feature is especially not recommanded if ADR is enabled.
|
||||
| RX Delay | Allows setting a custom wait time between receiving and transmission as specified in the specification. | Add twin desired property `"RXDelay": # ` where # is a valid specification number to set the RxDelay to wait for # seconds. Note that values 0 and 1 are default. Example: if a value of 2 is provided, The RX1 transmit windows will open 2 second after receiving the message. RX2 windows will always stay 1 second after RX1 | Setting a custom RXDelay could be usefull in case of long processing time, this could give more time to the server/device to compute their answers and lower the risk of missing the transmission windows. The defaults should work in most production scenarios, we recommend to use the default unless you have an explicit need for a longer delay|
|
||||
| RX1 Datarate Offset | Allows setting an offset between received Datarate and retransmit datarate as specified in the LoRa Specifiations. Valid for OTAA devices. If an invalid value is provided the network server will use default value 0. | Add twin desired property `"RX1DROffset": #` where # is a valid specification number to create an offset of # between received Datarate and Transmit Datarate. Please find the full table in the LoRa Specification example: upstream DR2, with a RX1DROffset of 1 will result in a transmission on DR1 | Setting an offset between receive and transmit could help deal with very saturated network. Warning, this is an advanced option, please only use if you are aware of your network specification.|
|
||||
| RX2 Datarate | Allows setting a custom Datarate for second receive windows. Valid for OTAA devices. If an invalid value is provided the network server will use default value 0 (DR0). | Add twin desired property `"RX2DataRate": #` where # is a valid specification number to set the RX2 DR to DR#. Example: if a value of 2 is provided, second receive windows will use DR2 instead of the default DR0. | Setting a custom RX2 Datarate could help your RX2 devices to benefit of higher datarate. Warning, this is an advanced topic, changing it to higher datarate could be very dangerous and result in RX2 becoming unusable if the devices are not within reach of the specified datarate. Usage of this feature is especially not recommanded if ADR is enabled.
|
||||
| RX Delay | Allows setting a custom wait time between receiving and transmission as specified in the specification. | Add twin desired property `"RXDelay": #` where # is a valid specification number to set the RxDelay to wait for # seconds. Note that values 0 and 1 are default. Example: if a value of 2 is provided, The RX1 transmit windows will open 2 second after receiving the message. RX2 windows will always stay 1 second after RX1 | Setting a custom RXDelay could be usefull in case of long processing time, this could give more time to the server/device to compute their answers and lower the risk of missing the transmission windows. The defaults should work in most production scenarios, we recommend to use the default unless you have an explicit need for a longer delay|
|
||||
|Disable ABP relax mode|Allows to disable the relax mode when using ABP. By default relaxed mode is enabled | Add twin desired property `"ABPRelaxMode": false` will disable relaxed mode.|Disable the relaxed mode to minimize reply attack possiblitites. Allowing relaxed mode, allows a device to reset framecounters on the server by specifying 0/1. **Important**: in production deployments, we recommend turning relaxed mode off|
|
||||
|Specify frame counter up start value|Allows to explicitly specify a frame counter up start value. If the device joins, this value will be used to validate the first frame and initialize the server state for the device.| Add twin desired property `"FCntUpStart": 10` will set the frame counter up to 10.|If you disable ABP relax mode (see ABPRelaxMode) you usually want to set this value. In general, if your device starts with anything but 0 or 1, you specify the value here. If your device has relaxed mode disabled or uses 32 bit counters and got out of sync, this is a way to re-synchronize the counter between the server and the device. see 32bit counter support and reset counter|
|
||||
|Specify frame counter down start value|Allows to explicitly specify a frame counter down start value.| Add twin desired property `"FCntDownStart": 10` will set the frame counter up to 10.|If your device expects a frame counter down other than 1 in the first message, use this to configure the value|
|
||||
|
|
@ -277,7 +278,7 @@ Setting **LOG_LEVEL** to **Debug** causes a lot of messages to be generated. Mak
|
|||
| LOG_TO_HUB | true | Log info are sent from the module to IoT Hub. |
|
||||
| | false | Log info is not sent to IoT Hub (default if omitted) |
|
||||
|
||||
You can use VSCode, [IoTHub explorer](https://github.com/Azure/iothub-explorer) or [Device Explorer](https://github.com/Azure/azure-iot-sdk-csharp/tree/master/tools/DeviceExplorer) to monitor the log messages directly in IoT Hub if **LOG_TO_HUB** is set to **true**.
|
||||
You can use VSCode or [Azure IoT CLI extension](https://github.com/azure/azure-iot-cli-extension) to monitor the log messages directly in IoT Hub if **LOG_TO_HUB** is set to **true**.
|
||||
|
||||
Log in to the gateway and use `sudo docker logs LoRaWanNetworkSrvModule -f` to follow the logs if you are not logging to IoT Hub.
|
||||
|
||||
|
|
@ -286,7 +287,6 @@ Log in to the gateway and use `sudo docker logs LoRaWanNetworkSrvModule -f` to f
|
|||
| LOG_TO_CONSOLE | true | Log to docker logs (default if omitted) |
|
||||
| | false | Does not log to docker logs |
|
||||
|
||||
|
||||
## Local Processing and Routing
|
||||
|
||||
By default the network server does not use the local edge queue (edgeHub), sending directly messages to IoT Hub. If you need to do local processing, please set the following setting to true on the `LoRaWanNetworkSrvModule`.
|
||||
|
|
@ -312,12 +312,12 @@ Sending cloud to device messages in the solution uses the following JSON format
|
|||
"payload": "string",
|
||||
"rawPayload": "string",
|
||||
"macCommands":[
|
||||
{ "cid": "string" }
|
||||
{ "cid": "string" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
#### Fields
|
||||
### Fields
|
||||
|
||||
|Field|Type|Description|Required|
|
||||
|-|-|-|-|
|
||||
|
|
@ -337,11 +337,13 @@ The companion Azure Function deployed with the solution has a HTTP based endpoin
|
|||
The function endpoint looks like `https://YOUR-FUNCTION-NAME.azurewebsites.net/api/cloudtodevicemessage/{devEUI}?code=YOUR-FUNCTION-APP-CODE`
|
||||
|
||||
To send a message to a device send a POST request including the content as the body:
|
||||
|
||||
```bash
|
||||
curl -d '{"rawPayload": "AAA=","fport": 1}' -H "Content-Type: application/json" https://YOUR-FUNCTION-NAME.azurewebsites.net/api/cloudtodevicemessage/YOUR-DEVEUI?code=YOUR-FUNCTION-APP-CODE
|
||||
```
|
||||
|
||||
Should return
|
||||
|
||||
```json
|
||||
{"devEUI":"47AAC86800430028","messageID":"10c3e09f-0e58-4d28-8da1-37bb3fcf9435","deviceClassType":"A"}
|
||||
```
|
||||
|
|
@ -354,9 +356,9 @@ The solution support sending Cloud to device (C2D) messages to LoRa class A devi
|
|||
|
||||
The following tools can be used to send cloud to devices messages from Azure :
|
||||
|
||||
* [Azure Portal](http://portal.azure.com) → IoT Hub → Devices → message to device
|
||||
* [Device Explorer](https://github.com/Azure/azure-iot-sdk-csharp/tree/master/tools/DeviceExplorer)
|
||||
* [Visual Studio Code IoT Hub Extension](https://marketplace.visualstudio.com/items?itemName=vsciot-vscode.azure-iot-toolkit)
|
||||
- [Azure Portal](http://portal.azure.com) → IoT Hub → Devices → message to device
|
||||
- [Azure IoT CLI Extension](https://github.com/azure/azure-iot-cli-extension)
|
||||
- [Visual Studio Code IoT Hub Extension](https://marketplace.visualstudio.com/items?itemName=vsciot-vscode.azure-iot-toolkit)
|
||||
|
||||
In confirmed messages a ConfirmedDataDown message will be send to the LoRa device (as in picture above and below). You can enable additional message tracking options by setting the C2D message id to a value (C2D message ID is automatically populated with the Device Explorer tool used in the image below).
|
||||
|
||||
|
|
@ -375,8 +377,8 @@ To send downstream messages to class C devices the following is required:
|
|||
|
||||
Once the requirements are met, sending downstream messages is achieved by calling the direct method `CloudToDeviceMessage` in the module client. In Azure Portal:
|
||||
|
||||
* [Azure Portal](http://portal.azure.com) → IoT Hub → IoT Edge → LoRaWanNetworkSrvModule (under Modules) → Direct Method
|
||||
* [Visual Studio Code IoT Hub Extension](https://marketplace.visualstudio.com/items?itemName=vsciot-vscode.azure-iot-toolkit)
|
||||
- [Azure Portal](http://portal.azure.com) → IoT Hub → IoT Edge → LoRaWanNetworkSrvModule (under Modules) → Direct Method
|
||||
- [Visual Studio Code IoT Hub Extension](https://marketplace.visualstudio.com/items?itemName=vsciot-vscode.azure-iot-toolkit)
|
||||
|
||||
The method name is `CloudToDeviceMessage` and the payload is the JSON following the structure previously described. Don't forget to set a value to the `devEUI` property.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
|
||||
The LoRaWan device simulator allow to simulate both ABP devices and OTAA devices. The simulator is only available for class A devices. So devices which connect time to time to send and receive messages.
|
||||
|
||||
* ABP devices have a Dev Address as well ad the Network and Application Server Keys. They can directly send data without having to be joined.
|
||||
* OTAA devices need to join first the network before being able to send data.
|
||||
- ABP devices have a Dev Address as well ad the Network and Application Server Keys. They can directly send data without having to be joined.
|
||||
- OTAA devices need to join first the network before being able to send data.
|
||||
|
||||
For more information regarding the various devices and the all up architecture, see the [LoRaEngine documentation](/LoRaEngine/README.md).
|
||||
|
||||
|
|
@ -45,31 +45,30 @@ All simulated devices has to be created into the ```testconfig.json``` file loca
|
|||
|
||||
The above example shows one ABP device, the first one and one OTAA device, the second one. For ABP devices, mandatory fields are:
|
||||
|
||||
* ```DevAddr``` which does contains the Dev Address of the device. This address has to be unique for all the devices connected to one gateway.
|
||||
* ```AppSKey``` which contains the Application Server Key used to encode the data payload send to the server.
|
||||
* ```NwkSkey``` which contains the Network Server Key used to encode the MIC bytes used to verify the integrity of the packet sent from the device to the server.
|
||||
* other LoRa fields can be ignore or left empty
|
||||
- ```DevAddr``` which does contains the Dev Address of the device. This address has to be unique for all the devices connected to one gateway.
|
||||
- ```AppSKey``` which contains the Application Server Key used to encode the data payload send to the server.
|
||||
- ```NwkSkey``` which contains the Network Server Key used to encode the MIC bytes used to verify the integrity of the packet sent from the device to the server.
|
||||
- other LoRa fields can be ignore or left empty
|
||||
|
||||
For OTAA devices, mandatory fields are the following:
|
||||
|
||||
* ```DevAddr``` **must** be an empty string
|
||||
* ```DevEUI``` which does represent a unique device id. Please note that this unique device id **must** be the same device id as in your Azure IoT Hub. For OTAA devices, it is important to have it as a name.
|
||||
* ```AppKey`` which is used to code the message sent from the gateway to the device one the request for join has been accepted.
|
||||
* ```AppEUI``` which is used by the device to the gateway for the join request.
|
||||
* Optional field: ```DevNonce``` which is normally a random number used for the join request from the device to the gateway.
|
||||
* other LoRa fields can be ignore or left empty.
|
||||
- ```DevAddr``` **must*- be an empty string
|
||||
- ```DevEUI``` which does represent a unique device id. Please note that this unique device id **must*- be the same device id as in your Azure IoT Hub. For OTAA devices, it is important to have it as a name.
|
||||
- ```AppKey`` which is used to code the message sent from the gateway to the device one the request for join has been accepted.
|
||||
- ```AppEUI``` which is used by the device to the gateway for the join request.
|
||||
- Optional field: ```DevNonce``` which is normally a random number used for the join request from the device to the gateway.
|
||||
- other LoRa fields can be ignore or left empty.
|
||||
|
||||
Common mandatory fields:
|
||||
|
||||
* ```Interval``` is the interval in seconds for which the simulated device will send data to the server. This allow to generate messages to the server at various moments.
|
||||
- ```Interval``` is the interval in seconds for which the simulated device will send data to the server. This allow to generate messages to the server at various moments.
|
||||
|
||||
Common optional fields, they can be left empty or not present:
|
||||
|
||||
* ```RandomInterval``` add/remove seconds in a random way to the original ```Interval``` one.
|
||||
* ```FrmCntUp``` the frame number to start with for message going from the device to the gateway. This allow to start the frame counter at any number. Number has to be a uint32 and not larger. For OTAA devices, it should always be 0 but you may want to test various scenarios.
|
||||
* ```FrmCntDown``` the frame number to start with for message going from the gateway to the device. This allow to start the frame counter at any number. Number has to be a uint32 and not larger. For OTAA devices, it should always be 0 but you may want to test various scenarios.
|
||||
* ```GroupRxpk``` is used to send at the same time, as an array multiple xrpk at the same time.
|
||||
|
||||
- ```RandomInterval``` add/remove seconds in a random way to the original ```Interval``` one.
|
||||
- ```FrmCntUp``` the frame number to start with for message going from the device to the gateway. This allow to start the frame counter at any number. Number has to be a uint32 and not larger. For OTAA devices, it should always be 0 but you may want to test various scenarios.
|
||||
- ```FrmCntDown``` the frame number to start with for message going from the gateway to the device. This allow to start the frame counter at any number. Number has to be a uint32 and not larger. For OTAA devices, it should always be 0 but you may want to test various scenarios.
|
||||
- ```GroupRxpk``` is used to send at the same time, as an array multiple xrpk at the same time.
|
||||
|
||||
**Note**: all the string representation are hexadecimal representations of bytes in bigendian except for ```Interval```, ```RandomInterval```, ```GroupRxpk```, ```FrmCntUp``` and ```FrmCntDown``` which are decimal numbers.
|
||||
|
||||
|
|
@ -81,11 +80,11 @@ Please note you'll have to create the devices and have the right Device Twin inf
|
|||
|
||||
**Note**: If you want to use a specific decoder, you have to specify it as well in the device twin. The simulator is so far built for the ```DecoderValueSensor``` one. If nothing is specified, the convertion will be a byte array to string and won't really represent anything valid. You still can run tests of course with it.
|
||||
|
||||
**Note**: one more time, for ABP devices, you **must** use the same device id as the DevEUI property.
|
||||
**Note**: one more time, for ABP devices, you **must*- use the same device id as the DevEUI property.
|
||||
|
||||
## Creating the simulated gateway
|
||||
|
||||
The gateway definition is stored in the same file as for the simulated devices. ```testconfig.json``` file located in [/LoRaSimulator/LoraSimulator](/LoRaSimulator/LoraSimulator) folder. As for the simulated devices, the file is copied when building the solution with the executable, once done, if you want to adjust it, make sure you'll do it in the build directory.
|
||||
The gateway definition is stored in the same file as for the simulated devices. ```testconfig.json``` file located in [/LoRaSimulator/LoraSimulator](/LoRaEngine/modules/LoRaSimulator/LoRaSimulator) folder. As for the simulated devices, the file is copied when building the solution with the executable, once done, if you want to adjust it, make sure you'll do it in the build directory.
|
||||
|
||||
```json
|
||||
"rxpk": {
|
||||
|
|
@ -101,7 +100,7 @@ The gateway definition is stored in the same file as for the simulated devices.
|
|||
}
|
||||
```
|
||||
|
||||
All fields are mandatory for the simulation to work correctly. They **must** represent real possible values for a gateway. Please refer to the LoRaWan specifications for those values. Except having real values, there is no test done for network related elements. But the LoRaEngine module will use some of those values to adjust the answer which will be done to the simulator. This allow you to test all the region and channel usage in a correct way.
|
||||
All fields are mandatory for the simulation to work correctly. They **must*- represent real possible values for a gateway. Please refer to the LoRaWan specifications for those values. Except having real values, there is no test done for network related elements. But the LoRaEngine module will use some of those values to adjust the answer which will be done to the simulator. This allow you to test all the region and channel usage in a correct way.
|
||||
|
||||
## Running the simulator and the LoRaEngine on the same machine as debug more
|
||||
|
||||
|
|
@ -117,15 +116,15 @@ then to the debug tab:
|
|||
|
||||
and add the following environment variables:
|
||||
|
||||
* IOTEDGE_IOTHUBHOSTNAME: XXX.azure-devices.net where XXX is your IoT Hub registry name
|
||||
* FACADE_AUTH_CODE: key. Where key is the secret key to access the function used to gather the device information like twins, get their own secret key to realize posting operation in Azure IoT Hub
|
||||
* FACADE_SERVER_URL: https://XXX.azurewebsites.net/api where XXX is the name of your function. If you want as well to debug the functions, you can do it. See full documentation [here](/LoRaEngine/README.md) if needed.
|
||||
* LOG_LEVEL:
|
||||
* "1" or "Debug": Everything is logged, including the up- and downstream messages to the packet forwarder
|
||||
* "2" or "Information": Errors and information are logged.
|
||||
* "3" or "Error": Only errors are logged.
|
||||
* ENABLE_GATEWAY: false this will allow to directly post the data from the devices to Azure IoT Hub. If you have a gateway, you'll need to specify true and adjust other environment variable. See full documentation [here](/LoRaEngine/README.md) if needed.
|
||||
* LOG_TO_HUB: false. So you won't log the data into Azure IoT Hub
|
||||
- IOTEDGE_IOTHUBHOSTNAME: XXX.azure-devices.net where XXX is your IoT Hub registry name
|
||||
- FACADE_AUTH_CODE: key. Where key is the secret key to access the function used to gather the device information like twins, get their own secret key to realize posting operation in Azure IoT Hub
|
||||
- FACADE_SERVER_URL: <https://xxx.azurewebsites.net/api> where XXX is the name of your function. If you want as well to debug the functions, you can do it. See full documentation [here](/LoRaEngine/README.md) if needed.
|
||||
- LOG_LEVEL:
|
||||
- "1" or "Debug": Everything is logged, including the up- and downstream messages to the packet forwarder
|
||||
- "2" or "Information": Errors and information are logged.
|
||||
- "3" or "Error": Only errors are logged.
|
||||
- ENABLE_GATEWAY: false this will allow to directly post the data from the devices to Azure IoT Hub. If you have a gateway, you'll need to specify true and adjust other environment variable. See full documentation [here](/LoRaEngine/README.md) if needed.
|
||||
- LOG_TO_HUB: false. So you won't log the data into Azure IoT Hub
|
||||
|
||||
### Setting up the LoRaSimulator
|
||||
|
||||
|
|
@ -137,4 +136,4 @@ All the code is running in different threads and asynchronously. So make sure yo
|
|||
|
||||
the UDP Port used by the LoRaEngine to listen is 1680. The port used by the LoRaSimulator is 1681 which does allow to run both on the same machine. You can change both ports in the source code.
|
||||
|
||||
It is as well possible to debug both in a Docker container. Both solution should be first deployed and attached to the containers to be able to debug.
|
||||
It is as well possible to debug both in a Docker container. Both solution should be first deployed and attached to the containers to be able to debug.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
# Upgrade LoRaWAN to a new version
|
||||
|
||||
<!-- allow github to generate 'copy' buttons for coded URLs -->
|
||||
<!-- markdownlint-disable MD040 -->
|
||||
## Release 1.0.6
|
||||
|
||||
> Note that this version switch IoT Edge to use version 1.2 of IoT Edge that include major changes on the edge. Please follow this [documentation](https://docs.microsoft.com/azure/iot-edge/how-to-update-iot-edge?view=iotedge-2020-11&tabs=linux) to upgrade IoT Edge to 1.2.
|
||||
|
|
@ -34,7 +35,7 @@ On the same `Set Modules` page, also update your current edge version to 1.0.9.5
|
|||
|
||||
### Updating the Azure Function Facade
|
||||
|
||||
If you have manually deployed the Azure Function, re-deploy the updated version of the Azure Function Facade as outlined [here](./devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
If you have manually deployed the Azure Function, re-deploy the updated version of the Azure Function Facade as outlined [here](/Docs/devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
|
||||
If you have deployed the solution and with it the Azure Function through the Azure Resource Manager template, you will see an `App Setting` in the function with the name "WEBSITE_RUN_FROM_ZIP". Update it's value to:
|
||||
|
||||
|
|
@ -43,9 +44,11 @@ https://github.com/Azure/iotedge-lorawan-starterkit/releases/download/v1.0.5/fun
|
|||
```
|
||||
|
||||
## Release 1.0.4
|
||||
|
||||
To update from version 1.0.3 you can follow the below instructions. If you want to update manually from a version prior to 1.0.3, please refer to the instructions in the [Release 1.0.3](#Release-1.0.3) section below.
|
||||
|
||||
### Updating from 1.0.3
|
||||
|
||||
|Deployment Module|Image URI|
|
||||
|-|-|
|
||||
|LoRaWanNetworkSrvModule|loraedge/lorawannetworksrvmodule:1.0.4|
|
||||
|
|
@ -55,7 +58,7 @@ On the same `Set Modules` page, also update your current edge version to 1.0.9.4
|
|||
|
||||
### Updating the Azure Function Facade
|
||||
|
||||
If you have manually deployed the Azure Function, re-deploy the updated version of the Azure Function Facade as outlined [here](./devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
If you have manually deployed the Azure Function, re-deploy the updated version of the Azure Function Facade as outlined [here](devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
|
||||
If you have deployed the solution and with it the Azure Function through the Azure Resource Manager template, you will see an `App Setting` in the function with the name "WEBSITE_RUN_FROM_ZIP". Update it's value to:
|
||||
|
||||
|
|
@ -80,7 +83,7 @@ On the same `Set Modules` page, also update your current edge version to 1.0.9 b
|
|||
|
||||
### Updating the Azure Function Facade
|
||||
|
||||
If you have manually deployed the Azure Function, re-deploy the updated version of the Azure Function Facade as outlined [here](./devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
If you have manually deployed the Azure Function, re-deploy the updated version of the Azure Function Facade as outlined [here](devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
|
||||
If you have deployed the solution and with it the Azure Function through the Azure Resource Manager template, you will see an `App Setting` in the function with the name "WEBSITE_RUN_FROM_ZIP". Update it's value to:
|
||||
|
||||
|
|
@ -105,7 +108,7 @@ On the same `Set Modules` page, also update your current edge version to 1.0.7 b
|
|||
|
||||
### Updating the Azure Function Facade
|
||||
|
||||
If you have manually deployed the Azure Function, re-deploy the updated version of the Azure Function Facade as outlined [here](./devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
If you have manually deployed the Azure Function, re-deploy the updated version of the Azure Function Facade as outlined [here](devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
|
||||
If you have deployed the solution and with it the Azure Function through the Azure Resource Manager template, you will see an `App Setting` in the function with the name "WEBSITE_RUN_FROM_ZIP". Update it's value to:
|
||||
|
||||
|
|
@ -130,7 +133,7 @@ Go to your solution's Azure IoT Hub and under IoT Edge, select each of your gate
|
|||
|
||||
### Updating the Azure Function Facade
|
||||
|
||||
If you have manually deployed the Azure Function, re-deploy the updated version of the Azure Function Facade as outlined [here](./devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
If you have manually deployed the Azure Function, re-deploy the updated version of the Azure Function Facade as outlined [here](devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
|
||||
If you have deployed the solution and with it the Azure Function through the Azure Resource Manager template, you will see an `App Setting` in the function with the name "WEBSITE_RUN_FROM_ZIP". Update it's value to:
|
||||
|
||||
|
|
@ -151,7 +154,7 @@ Make sure the IoT Hub and Redis connection strings are properly configured in th
|
|||
|
||||
### Updating the Azure Function Facade
|
||||
|
||||
If you have manually deployed the Azure Function, re-deploy the updated version of the Azure Function Facade as outlined [here](./devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
If you have manually deployed the Azure Function, re-deploy the updated version of the Azure Function Facade as outlined [here](devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
|
||||
If you have deployed the solution and with it the Azure Function through the Azure Resource Manager template, you will see an `App Setting` in the function with the name "WEBSITE_RUN_FROM_ZIP". Update it's value to:
|
||||
|
||||
|
|
@ -169,9 +172,9 @@ Make sure the IoT Hub and Redis connection strings are properly configured in th
|
|||
|
||||
## Updating existing installations from 0.3.0-preview to 0.4.0-preview
|
||||
|
||||
### Updating IoT Edge Runtime Containers to Version 1.0.6 ###
|
||||
### Updating IoT Edge Runtime Containers to Version 1.0.6
|
||||
|
||||
We highly recommend running the latest version of the IoT Edge runtime containers on your gateway to Version 1.0.6. The way that you update the `IoT Edge agent` and `IoT Edge hub` containers depends on whether you use rolling tags (like 1.0) or specific tags (like 1.0.2) in your deployment.
|
||||
We highly recommend running the latest version of the IoT Edge runtime containers on your gateway to Version 1.0.6. The way that you update the `IoT Edge agent` and `IoT Edge hub` containers depends on whether you use rolling tags (like 1.0) or specific tags (like 1.0.2) in your deployment.
|
||||
|
||||
The process is outlined in detail [here](https://docs.microsoft.com/en-us/azure/iot-edge/how-to-update-iot-edge#update-the-runtime-containers).
|
||||
|
||||
|
|
@ -189,7 +192,7 @@ Make sure the **DevAddr** of your ABP LoRa devices starts with **"02"**: Due to
|
|||
|
||||
### Updating the Azure Function Facade
|
||||
|
||||
Re-deploy the updated version of the Azure Function Facade as outlined [here](./devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
Re-deploy the updated version of the Azure Function Facade as outlined [here](devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
|
||||
Make sure the IoT Hub and Redis connection strings are properly configured in the function.
|
||||
|
||||
|
|
@ -197,12 +200,14 @@ Make sure the IoT Hub and Redis connection strings are properly configured in th
|
|||
|
||||
### Updating IoT Edge Runtime Containers to Version 1.0.5
|
||||
|
||||
We highly recommend running the latest version of the IoT Edge runtime containers on your gateway (Version 1.0.5 at the time of writing). The way that you update the `IoT Edge agent` and `IoT Edge hub` containers depends on whether you use rolling tags (like 1.0) or specific tags (like 1.0.2) in your deployment.
|
||||
We highly recommend running the latest version of the IoT Edge runtime containers on your gateway (Version 1.0.5 at the time of writing). The way that you update the `IoT Edge agent` and `IoT Edge hub` containers depends on whether you use rolling tags (like 1.0) or specific tags (like 1.0.2) in your deployment.
|
||||
|
||||
The process is outlined in detail [here](https://docs.microsoft.com/en-us/azure/iot-edge/how-to-update-iot-edge#update-the-runtime-containers).
|
||||
|
||||
### Updating the Azure Function Facade
|
||||
|
||||
Re-deploy the updated version of the Azure Function Facade as outlined [here](./devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
Re-deploy the updated version of the Azure Function Facade as outlined [here](devguide.md#setup-azure-function-facade-and-azure-container-registry) if you have a previous version of this Azure Function running.
|
||||
|
||||
Make sure the IoT Hub and Redis connection strings are properly configured in the function.
|
||||
|
||||
<!-- markdownlint-enable MD040 -->
|
||||
|
|
@ -1,3 +1,3 @@
|
|||
# LoRa Engine
|
||||
|
||||
refer to [Developer Guidance](/Docs/devguide.md)
|
||||
refer to [Developer Guidance](/Docs/devguide.md)
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Part of our [Azure IoT Hub LoRaWan starter kit](https://github.com/Azure/iotedge
|
|||
|
||||
Software tests are not the only one that we want to run as we want to be able to validate specific region settings and make sure any modification in the code will work great as well on a real device. To run and automate test in a proper CI/CD chain, we're using Azure DevOps, formally known as VSTS (Visual Studio Team Services). Azure DevOps allow to run remote tests and gather results thru an agent running remotely. The pipeline is specifically build to run our hardware tests. In short, we are sending serial commands to an Arduino (a Seeeduino LoRaWan device) connected thru a serial port on a Raspberry Pi3. The Raspberry Pi has a LoRaWan shield and the needed Azure IoT Edge modules to manage the Lora device(s). The test compare what is sent thru serial port, what is received from the device with what arrives to the LoRaEngine gateway and what is finally published in Azure IoT Hub.
|
||||
|
||||
So in order to run the test, deploy and manage them the best way, we've decided to build an Azure DevOps agent in a container. It will execute the tests written in C# in .NET Core.
|
||||
So in order to run the test, deploy and manage them the best way, we've decided to build an Azure DevOps agent in a container. It will execute the tests written in C# in .NET Core.
|
||||
|
||||
## Building the container
|
||||
|
||||
|
|
@ -77,9 +77,8 @@ To build and deploy the solution, we strongly encourage you to use VS Code and t
|
|||
|
||||
|
||||
|
||||
Select ```deployment.template.json```, right click on it and then select ```Build and Push IoT Edge solution```. This will automatically create a ```deployment.json``` file in the ```config``` folder. Right click on it and select ```Create deployment for single device``` and select the Azure IoT Edge device you want to deploy the solution on. Of course, you can as well deploy it on any docker enable Linux arm32 device (or amd64 if you selected this configuration).
|
||||
Select ```deployment.template.json```, right click on it and then select ```Build and Push IoT Edge solution```. This will automatically create a ```deployment.json``` file in the ```config``` folder. Right click on it and select ```Create deployment for single device``` and select the Azure IoT Edge device you want to deploy the solution on. Of course, you can as well deploy it on any docker enable Linux arm32 device (or amd64 if you selected this configuration).
|
||||
|
||||
## Building and deploying the solution part of other containers
|
||||
|
||||
If you are deploying the solution part of other containers on an IoT Edge solution, make sure you have this module part of the same ```modules``` folder and that you merge the specific Azure DevOps modules option into the main file. You can find an example [here](https://github.com/Azure/iotedge-lorawan-starterkit/blob/oneweek-pipeline/LoRaEngine/deployment.test.template.json).
|
||||
|
||||
If you are deploying the solution part of other containers on an IoT Edge solution, make sure you have this module part of the same ```modules``` folder and that you merge the specific Azure DevOps modules option into the main file. You can find an example [here](/LoRaEngine/deployment.test.template.json).
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ This guide helps you to execute and author integration tests on your local envir
|
|||
|
||||
## Requirements
|
||||
|
||||
|
||||
```ascii
|
||||
+----------+ |
|
||||
| Dev | A
|
||||
|
|
@ -31,33 +30,33 @@ This guide helps you to execute and author integration tests on your local envir
|
|||
|
||||
1. Connect and setup Seeduino Arduino with the serial pass sketch
|
||||
|
||||
```c
|
||||
void setup()
|
||||
{
|
||||
Serial1.begin(9600);
|
||||
SerialUSB.begin(115200);
|
||||
}
|
||||
```c
|
||||
void setup()
|
||||
{
|
||||
Serial1.begin(9600);
|
||||
SerialUSB.begin(115200);
|
||||
}
|
||||
|
||||
void loop()
|
||||
{
|
||||
while(Serial1.available())
|
||||
void loop()
|
||||
{
|
||||
SerialUSB.write(Serial1.read());
|
||||
while(Serial1.available())
|
||||
{
|
||||
SerialUSB.write(Serial1.read());
|
||||
}
|
||||
while(SerialUSB.available())
|
||||
{
|
||||
Serial1.write(SerialUSB.read());
|
||||
}
|
||||
}
|
||||
while(SerialUSB.available())
|
||||
{
|
||||
Serial1.write(SerialUSB.read());
|
||||
}
|
||||
}
|
||||
```
|
||||
```
|
||||
|
||||
2. Create/edit integration settings in file `appsettings.local.json`
|
||||
|
||||
The value of `LeafDeviceSerialPort` in Windows will be the COM port where the Arduino board is connected to (Arduino IDE displays it). On macos you can discover through `ls /dev/tty*` and/or `ls /dev/cu*` bash commands. On Linux you can discover them with `ls /dev/ttyACM*`.
|
||||
The value of `LeafDeviceSerialPort` in Windows will be the COM port where the Arduino board is connected to (Arduino IDE displays it). On macos you can discover through `ls /dev/tty*` and/or `ls /dev/cu*` bash commands. On Linux you can discover them with `ls /dev/ttyACM*`.
|
||||
|
||||
```json
|
||||
{
|
||||
"testConfiguration": {
|
||||
{
|
||||
"testConfiguration": {
|
||||
"IoTHubEventHubConnectionString": "Endpoint=sb://xxxx.servicebus.windows.net/;SharedAccessKeyName=iothubowner;SharedAccessKey=xxx;EntityPath=xxxxx",
|
||||
"IoTHubEventHubConsumerGroup": "your-iothub-consumer-group",
|
||||
"IoTHubConnectionString": "HostName=xxxx.azure-devices.net;SharedAccessKeyName=iothubowner;SharedAccessKey=xxx",
|
||||
|
|
@ -85,30 +84,30 @@ To create a new device modify the IntegrationTestFixture class by:
|
|||
|
||||
1. Creating a new property of type `TestDeviceInfo` as (increment the device ids by 1):
|
||||
|
||||
```c#
|
||||
// Device13_OTAA: used for wrong AppEUI OTAA join
|
||||
public TestDeviceInfo Device13_OTAA { get; private set; }
|
||||
```
|
||||
```c#
|
||||
// Device13_OTAA: used for wrong AppEUI OTAA join
|
||||
public TestDeviceInfo Device13_OTAA { get; private set; }
|
||||
```
|
||||
|
||||
2. Create the `TestDeviceInfo` instance in IntegrationTestFixture.SetupDevices() method
|
||||
|
||||
```c#
|
||||
// Device13_OTAA: used for Join with wrong AppEUI
|
||||
this.Device13_OTAA = new TestDeviceInfo()
|
||||
{
|
||||
DeviceID = "0000000000000013",
|
||||
AppEUI = "BE7A00000000FEE3",
|
||||
AppKey = "8AFE71A145B253E49C3031AD068277A3",
|
||||
SensorDecoder = "DecoderValueSensor",
|
||||
```c#
|
||||
// Device13_OTAA: used for Join with wrong AppEUI
|
||||
this.Device13_OTAA = new TestDeviceInfo()
|
||||
{
|
||||
DeviceID = "0000000000000013",
|
||||
AppEUI = "BE7A00000000FEE3",
|
||||
AppKey = "8AFE71A145B253E49C3031AD068277A3",
|
||||
SensorDecoder = "DecoderValueSensor",
|
||||
|
||||
// GatewayID property of the device
|
||||
GatewayID = gatewayID,
|
||||
// GatewayID property of the device
|
||||
GatewayID = gatewayID,
|
||||
|
||||
// Indicates if the device exists in IoT Hub
|
||||
// Some tests don't require a device to actually exist
|
||||
IsIoTHubDevice = true,
|
||||
};
|
||||
```
|
||||
// Indicates if the device exists in IoT Hub
|
||||
// Some tests don't require a device to actually exist
|
||||
IsIoTHubDevice = true,
|
||||
};
|
||||
```
|
||||
|
||||
3. Create the test method / fact in a test class. If a new test class is needed (to group logically test) read the section 'Creating Test Class'). Code should be similar to this:
|
||||
|
||||
|
|
|
|||
108
README.md
108
README.md
|
|
@ -1,24 +1,34 @@
|
|||
# Azure IoT Edge LoRaWAN Starter Kit
|
||||
|
||||
[](https://github.com/Azure/iotedge-lorawan-starterkit/actions/workflows/ci.yaml)
|
||||
[](https://github.com/Azure/iotedge-lorawan-starterkit/actions/workflows/ci.yaml)
|
||||
[](https://github.com/Azure/iotedge-lorawan-starterkit/actions/workflows/md-linter.yaml)
|
||||
|
||||
# Azure IoT Edge LoRaWAN Starter Kit
|
||||
|
||||
The LoRaWAN starter kit is an OSS cross platform private network implementation of the [LoRaWAN specification](https://lora-alliance.org/resource_hub/lorawan-specification-v1-0-2/) built for connectivity to Azure IoT Hub. It enables users to setup their own LoRaWAN network that can connect to LoRa based nodes (sensors) and send decoded message packets to Azure IoT Hub for cloud based processing, analytics and other workloads. Alternatively, it allows sending commands from the cloud to the end nodes. The goal of the the project is to provide guidance and a reference for Azure IoT Edge users to experiment with LoRaWAN technology.
|
||||
The LoRaWAN starter kit is an OSS cross platform private network implementation
|
||||
of the [LoRaWAN specification](https://lora-alliance.org/resource_hub/lorawan-specification-v1-0-2/)
|
||||
built for connectivity to Azure IoT Hub. It enables users to setup their own
|
||||
LoRaWAN network that can connect to LoRa based nodes (sensors) and send decoded
|
||||
message packets to Azure IoT Hub for cloud based processing, analytics and other
|
||||
workloads. Alternatively, it allows sending commands from the cloud to the end
|
||||
nodes. The goal of the the project is to provide guidance and a reference for
|
||||
Azure IoT Edge users to experiment with LoRaWAN technology.
|
||||
|
||||
|
||||
|
||||
- [Features](#features)
|
||||
- [LoRaWAN Specification Support](#lorawan-specification-support)
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Getting Started](#getting-started)
|
||||
- [Known Issues and Limitations](#known-issues-and-limitations)
|
||||
- [Tested Gateways](#tested-gateways)
|
||||
- [Support](#support)
|
||||
- [Contributing](#contributing)
|
||||
- [Features](#features)
|
||||
- [LoRaWAN Specification Support](#lorawan-specification-support)
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Getting Started](#getting-started)
|
||||
- [Known Issues and Limitations](#known-issues-and-limitations)
|
||||
- [Tested Gateways](#tested-gateways)
|
||||
- [Support](#support)
|
||||
- [Contributing](#contributing)
|
||||
|
||||
## Features
|
||||
- LoRaWAN 1.0.2 implementation (see [LoRaWAN Specification Support](#LoRaWAN-1.0.2-Specification-Support) for more details)
|
||||
|
||||
- LoRaWAN 1.0.2 implementation
|
||||
(see [LoRaWAN Specification Support](#LoRaWAN-1.0.2-Specification-Support)
|
||||
for more details)
|
||||
- Device and Gateway management done completely through Azure IoT Hub.
|
||||
- Bi-directional communication between LoRa end devices and Azure cloud.
|
||||
- Custom packet decoding framework.
|
||||
|
|
@ -29,7 +39,11 @@ The LoRaWAN starter kit is an OSS cross platform private network implementation
|
|||
- Simulator for development and testing without the need to own a Gateway.
|
||||
|
||||
## LoRaWAN Specification Support
|
||||
We plan to support the following key features of LoRaWAN 1.0.2 specification, however please note that not all of them are available as of today. Please refer to our release notes for more details on what is available.
|
||||
|
||||
We plan to support the following key features of LoRaWAN 1.0.2 specification,
|
||||
however please note that not all of them are available as of today. Please refer
|
||||
to our release notes for more details on what is available.
|
||||
|
||||
- Current supported Specification: *1.0.2*.
|
||||
- Support of Class A and C devices.
|
||||
- Support of **EU868** and **US915** channel frequencies.
|
||||
|
|
@ -41,40 +55,76 @@ We plan to support the following key features of LoRaWAN 1.0.2 specification, ho
|
|||
- Support of MAC commands.
|
||||
- ADR Support.
|
||||
|
||||
|
||||
## Prerequisites
|
||||
The following should be completed before proceeding with the LoRaWAN starter kit development or deployment in your environment.
|
||||
|
||||
- You must have an Azure subscription. Get an [Azure Free account](https://azure.microsoft.com/en-us/offers/ms-azr-0044p/) to get started.
|
||||
- We are based on Azure IoT Edge so it is important that you understand the concepts and deployment model for Azure IoT Edge. Refer to Azure [IoT Edge documentation](https://docs.microsoft.com/en-us/azure/iot-edge/) to see how it works.
|
||||
- Understand how LoRa and LoRaWAN works. A great primer is available at the [LoRa Alliance website](https://lora-alliance.org/resource_hub/what-is-lorawan/).
|
||||
- To test the solution on a device, you need to have a LoRaWAN Device Kit Gateway and a LoRa end node. We have some recommendations in the [Tested Gateways](#tested-gateways) section below.
|
||||
The following should be completed before proceeding with the LoRaWAN starter kit
|
||||
development or deployment in your environment.
|
||||
|
||||
- You must have an Azure subscription. Get an
|
||||
[Azure Free account](https://azure.microsoft.com/en-us/offers/ms-azr-0044p/)
|
||||
to get started.
|
||||
- We are based on Azure IoT Edge so it is important that you understand the
|
||||
concepts and deployment model for Azure IoT Edge. Refer to Azure
|
||||
[IoT Edge documentation](https://docs.microsoft.com/en-us/azure/iot-edge/)
|
||||
to see how it works.
|
||||
- Understand how LoRa and LoRaWAN works. A great primer is available at the
|
||||
[LoRa Alliance website](https://lora-alliance.org/resource_hub/what-is-lorawan/).
|
||||
- To test the solution on a device, you need to have a LoRaWAN Device Kit
|
||||
Gateway and a LoRa end node. We have some recommendations in the
|
||||
[Tested Gateways](#tested-gateways) section below.
|
||||
|
||||
## Getting Started
|
||||
|
||||
We have a variety of ways you can get started with the kit, chose the appropriate documentation based on your persona and applicability.
|
||||
- **Setup a LoRaWAN Gateway**: We provide an easy to use Azure ARM template and deployment guidance to get you quickly started with the LoRaWAN starter kit. Use the [Quick Start](/Docs/quickstart.md) to setup a LoRaWAN Gateway and connect to LoRA end nodes.
|
||||
- **Upgrade an existing installation**: Refer to the [upgrade guide](/Docs/upgrade.md) for instructions and tips for a clean upgrade.
|
||||
- **Develop and debug the LoRaWAN starter kit**: If you are a developer and want to contribute or customize the LoRaWAN starter kit, refer to our [Developer Guidance](/Docs/devguide.md) for more details on how to build, test and deploy the kit in your dev environment. We also support a [simulator](/Docs/simulator.md) that allows for developing without the need of an actual device gateway.
|
||||
- **Enable a gateway or device to be compatible with the starter kit**: We have developed the LoRaWAN starter kit agnostic of a device manufacturer implementation and focussed on the specifics on underlying architectures (arm, x86). However, we understand that device manufacturers can have specific requirements; these could be specific to a gateway and the packet forwarders they use or to the LoRa nodes and the decoders the device may use. We have provided specific instructions on making these specialized hardware compatible with our kit. You can follow these [instructions](/Docs/partner.md) depending on your scenarios and also have your device gateway highlighted on our repo.
|
||||
We have a variety of ways you can get started with the kit, chose the
|
||||
appropriate documentation based on your persona and applicability.
|
||||
|
||||
- **Setup a LoRaWAN Gateway**: We provide an easy to use Azure ARM template and
|
||||
deployment guidance to get you quickly started with the LoRaWAN starter kit.
|
||||
Use the [Quick Start](/Docs/quickstart.md) to setup a LoRaWAN Gateway and
|
||||
connect to LoRA end nodes.
|
||||
- **Upgrade an existing installation**:
|
||||
Refer to the [upgrade guide](/Docs/upgrade.md) for instructions and tips for a
|
||||
clean upgrade.
|
||||
- **Develop and debug the LoRaWAN starter kit**: If you are a developer and want
|
||||
to contribute or customize the LoRaWAN starter kit, refer to our
|
||||
[Developer Guidance](/Docs/devguide.md) for more details on how to build, test
|
||||
and deploy the kit in your dev environment. We also support a
|
||||
[simulator](/Docs/simulator.md) that allows for developing without the need of
|
||||
an actual device gateway.
|
||||
- **Enable a gateway or device to be compatible with the starter kit**: We have
|
||||
developed the LoRaWAN starter kit agnostic of a device manufacturer
|
||||
implementation and focussed on the specifics on underlying architectures
|
||||
(arm, x86). However, we understand that device manufacturers can have specific
|
||||
requirements; these could be specific to a gateway and the packet forwarders
|
||||
they use or to the LoRa nodes and the decoders the device may use. We have
|
||||
provided specific instructions on making these specialized hardware compatible
|
||||
with our kit. You can follow these [instructions](/Docs/partner.md) depending on
|
||||
your scenarios and also have your device gateway highlighted on our repo.
|
||||
|
||||
## Known Issues and Limitations
|
||||
|
||||
Refer to [Known Issues](/Docs/issues.md) for known issues, gotchas and limitations.
|
||||
Refer to [Known Issues](/Docs/issues.md) for known issues, gotchas and
|
||||
limitations.
|
||||
|
||||
## Tested Gateways
|
||||
|
||||
- [Seeed Studio LoRa LoRaWAN Gateway - 868MHz Kit with Raspberry Pi 3](https://www.seeedstudio.com/LoRa-LoRaWAN-Gateway-868MHz-Kit-with-Raspberry-Pi-3-p-2823.html)
|
||||
- [AAEON AIOT-ILRA01 LoRa® Certified Intel® Based Gateway and Network Server](https://www.aaeon.com/en/p/intel-lora-gateway-system-server)
|
||||
- [AAEON Indoor 4G LoRaWAN Edge Gateway & Network Server](https://www.industrialgateways.eu/UPS-IoT-EDGE-LoRa)
|
||||
- [AAEON AIOT-IP6801 Multi radio Outdoor Industrial Edge Gateway](https://www.aaeon.com/en/p/iot-gateway-systems-aiot-ip6801)
|
||||
- [MyPi Industrial IoT Integrator Board](http://www.embeddedpi.com/integrator-board) with [RAK833-SPI mPCIe-LoRa-Concentrator](http://www.embeddedpi.com/iocards)
|
||||
- [MyPi Industrial IoT Integrator Board](http://www.embeddedpi.com/integrator-board)
|
||||
with [RAK833-SPI mPCIe-LoRa-Concentrator](http://www.embeddedpi.com/iocards)
|
||||
- Raspberry Pi 3 with [IC880A](https://wireless-solutions.de/products/radiomodules/ic880a.html)
|
||||
- [RAK833-USB mPCIe-LoRa-Concentrator with Raspberry Pi 3](https://github.com/Ellerbach/lora_gateway/tree/a31d80bf93006f33c2614205a6845b379d032c57)
|
||||
|
||||
## Support
|
||||
The LoRaWAN starter kit is an open source solution, it is NOT a Microsoft supported solution or product. For bugs and issues with the codebase please log an issue in this repo.
|
||||
|
||||
The LoRaWAN starter kit is an open source solution, it is NOT a Microsoft
|
||||
supported solution or product. For bugs and issues with the codebase please log
|
||||
an issue in this repo.
|
||||
|
||||
## Contributing
|
||||
|
||||
If you would like to contribute to the IoT Edge LoRaWAN Starter Kit source code, please base your own branch and pull request (PR) off our [dev branch](/tree/dev). Refer to the [Dev Guide](/Docs/devguide.md) for development and debugging instructions.
|
||||
|
||||
If you would like to contribute to the IoT Edge LoRaWAN Starter Kit source code,
|
||||
please base your own branch and pull request (PR) off our dev branch.
|
||||
Refer to the [Dev Guide](/Docs/devguide.md) for development and debugging instructions.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## Cayenne Decoder
|
||||
|
||||
This sample allows you to create and run your own LoRa message decoder in an independent container running on your LoRa gateway without having to edit the main LoRa Engine. It is based on the sample decoder.
|
||||
This sample allows you to create and run your own LoRa message decoder in an independent container running on your LoRa gateway without having to edit the main LoRa Engine. It is based on the sample decoder.
|
||||
|
||||
## How to use the sample decoder
|
||||
|
||||
|
|
@ -17,12 +17,13 @@ The payload ```AWcA5gJoMANzJigEZQD9``` will then be transformed as:
|
|||
```
|
||||
|
||||
You can build the docker image or use the module.json file to build an iot edge module. You can then use the following command to start the module:
|
||||
```
|
||||
|
||||
```bash
|
||||
docker run --rm -it -p 8881:80 your.azurecr.io/cayennedecoder:tag
|
||||
```
|
||||
|
||||
You can then submit the payload from the example here above by hitting the following URL: http://yourhost:8881/api/CayenneDecoder?fport=1&payload=AWcA5gJoMANzJigEZQD9
|
||||
You can then submit the payload from the example here above by hitting the following URL: <http://yourhost:8881/api/CayenneDecoder?fport=1&payload=AWcA5gJoMANzJigEZQD9>
|
||||
|
||||
## Supported Cayenne devices
|
||||
|
||||
All Cayenne devices are supported.
|
||||
All Cayenne devices are supported.
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
# Azure IoT Edge LoRaWAN Starter Kit
|
||||
<!-- markdownlint-disable MD040 -->
|
||||
|
||||
## DecoderSample
|
||||
|
||||
This sample allows you to create and run your own LoRa message decoder in an independent container running on your LoRa gateway without having to edit the main LoRa Engine. This description shows you how to get started.
|
||||
|
||||
### Customizing
|
||||
|
||||
To add a new decoder, simply copy or reuse the sample ```DecoderValueSensor``` method from the ```LoraDecoders``` class in [LoraDecoder.cs](/Samples/DecoderSample/Classes/LoraDecoder.cs). You can name the method whatever you like and can create as many decoders as you need by adding new, individual methods to the ```LoraDecoders``` class.
|
||||
To add a new decoder, simply copy or reuse the sample ```DecoderValueSensor``` method from the ```LoraDecoders``` class in [LoraDecoder.cs](/Samples/DecoderSample/Classes/LoraDecoders.cs). You can name the method whatever you like and can create as many decoders as you need by adding new, individual methods to the ```LoraDecoders``` class.
|
||||
|
||||
The payload sent to the decoder is passed as string ```devEui```, byte[] ```payload``` and uint ```fport```.
|
||||
|
||||
|
|
@ -31,7 +33,7 @@ internal static class LoraDecoders
|
|||
}
|
||||
```
|
||||
|
||||
You can test the decoder on your machine by debugging the SensorDecoderModule project in Visual Studio.
|
||||
You can test the decoder on your machine by debugging the SensorDecoderModule project in Visual Studio.
|
||||
|
||||
When creating a debugging configuration in Visual Studio Code or a ```launchSettings.json``` file in Visual Studio, the default address that the webserver will try to use is ```http://localhost:5000``` or ```https://localhost:5001```. You can override this with any port of your choice.
|
||||
|
||||
|
|
@ -40,6 +42,7 @@ On launching the debugger you will see a webbrowser with a ```404 Not Found``` e
|
|||
You will also manually need to [base64-encode](https://www.base64encode.org/) and [URL-encode](https://www.urlencoder.org/) the payload before adding it to the URL parameters.
|
||||
|
||||
For example, to test a payload of `ABCDE12345`, you:
|
||||
|
||||
- Convert it to a base64 encoded string: `QUJDREUxMjM0NQ==`
|
||||
- Convert the result to a valid URL parameter: `QUJDREUxMjM0NQ%3D%3D`
|
||||
- Add this to your test URL.
|
||||
|
|
@ -48,7 +51,8 @@ For the built-in sample decoder ```DecoderValueSensor``` with Visual Studio (Cod
|
|||
|
||||
```
|
||||
http://localhost:5000/api/DecoderValueSensor?devEui=0000000000000000&fport=1&payload=QUJDREUxMjM0NQ%3D%3D
|
||||
`````
|
||||
```
|
||||
|
||||
You can call your decoder at:
|
||||
|
||||
```
|
||||
|
|
@ -69,7 +73,7 @@ We are using the [Azure IoT Edge for Visual Studio Code](https://marketplace.vis
|
|||
|
||||
Make sure you are logged in to the Azure Container Registry you are using. Run `docker login <mycontainerregistry>.azurecr.io` on your development machine.
|
||||
|
||||
Edit the file [module.json](./module.json) to contain your container registry address, image name and version number:
|
||||
Edit the file [module.json](/Samples/DecoderSample/module.json) to contain your container registry address, image name and version number:
|
||||
|
||||
|
||||
|
||||
|
|
@ -78,7 +82,7 @@ We provide the Dockerfiles for the following architectures:
|
|||
- [Dockerfile.amd64](/Samples/DecoderSample/Dockerfile.amd64)
|
||||
- [Dockerfile.arm32v7](/Samples/DecoderSample/Dockerfile.arm32v7)
|
||||
|
||||
To build the Docker image, right-click on the [module.json](./module.json) file and select "Build IoT Edge Module Image" or "Build and Push IoT Edge Module Image". Select the architecture you want to build for (ARM32v7 or AMD64) from the drop-down menu.
|
||||
To build the Docker image, right-click on the [module.json](/Samples/DecoderSample/module.json) file and select "Build IoT Edge Module Image" or "Build and Push IoT Edge Module Image". Select the architecture you want to build for (ARM32v7 or AMD64) from the drop-down menu.
|
||||
|
||||
To **temporarily test** the container running you decoder using a webbrowser or Postman, you can manually start it in Docker and bind the container's port 80 to a free port on your host machine, like for example 8881.
|
||||
|
||||
|
|
@ -104,7 +108,7 @@ Configure your IoT Edge gateway device to include the custom container. IoT Hub
|
|||
|
||||
|
||||
|
||||
To activate the decoder for a LoRa device, navigate to your IoT Hub → IoT Devices → Device Details → Device Twin and set the ```SensorDecoder``` value in the desired properties to:
|
||||
To activate the decoder for a LoRa device, navigate to your IoT Hub → IoT Devices → Device Details → Device Twin and set the ```SensorDecoder``` value in the desired properties to:
|
||||
|
||||
```
|
||||
http://<decoder module name>/api/<DecoderName>
|
||||
|
|
@ -115,3 +119,5 @@ http://<decoder module name>/api/<DecoderName>
|
|||
|
||||
|
||||
In case the custom decoder is unreachable, throws an error or return invalid JSON, the error message will be shown in your device's messages in IoT Hub.
|
||||
|
||||
<!-- markdownlint-enable MD040 -->
|
||||
|
|
@ -1,38 +1,45 @@
|
|||
# Universal Decoder
|
||||
<!-- markdownlint-disable MD040 -->
|
||||
|
||||
This project gives access to decoders in the [TTN repo](https://github.com/TheThingsNetwork/lorawan-devices#payload-codecs) through a HTTP REST interface compliant with the LoraWan implementation in this repository.
|
||||
This project gives access to decoders in the [TTN repo](https://github.com/TheThingsNetwork/lorawan-devices#payload-codecs) through a HTTP REST interface compliant with the LoraWan implementation in this repository.
|
||||
|
||||
Codecs provided by TTN are stored in a well defined [folder structure](https://github.com/TheThingsNetwork/lorawan-devices#files-and-directories). The universal decoder copies the codec files into its docker image at build time for later use from the web application. As currently codecs are not implemented as node modules (see [open issue](https://github.com/TheThingsNetwork/lorawan-devices/issues/177)), these files were patched accordingly after being copied so that they can be imported and reused.
|
||||
|
||||
## Quick start
|
||||
|
||||
Install node dependencies and copy/patch codecs from the TTN repository:
|
||||
```
|
||||
|
||||
```bash
|
||||
npm install
|
||||
npm run codecs
|
||||
```
|
||||
|
||||
Create docker image (replace `amd64` with the architecture of your choice)
|
||||
```
|
||||
|
||||
```bash
|
||||
docker build . -f Dockerfile.amd64 -t universaldecoder
|
||||
```
|
||||
|
||||
Run docker image:
|
||||
```
|
||||
|
||||
```bash
|
||||
docker run --rm -d -p 8080:8080 universaldecoder
|
||||
```
|
||||
|
||||
Call the built-in `DecoderValueSensor` decoder at the following url. You should see the result as JSON string.
|
||||
|
||||
```
|
||||
http://localhost:8080/api/DecoderValueSensor?devEui=0000000000000000&fport=1&payload=QUJDREUxMjM0NQ%3D%3D
|
||||
```
|
||||
|
||||
Finally list all available decoders with the following url:
|
||||
|
||||
```
|
||||
http://localhost:8080/decoders
|
||||
```
|
||||
|
||||
You can finally call any other supported decoder at:
|
||||
|
||||
```
|
||||
http://localhost:8080/api/<decoder>?devEui=0000000000000000&fport=<fport>&payload=<payload>
|
||||
```
|
||||
|
|
@ -41,7 +48,7 @@ http://localhost:8080/api/<decoder>?devEui=0000000000000000&fport=<fport>&payloa
|
|||
|
||||
### Start local server
|
||||
|
||||
```
|
||||
```bash
|
||||
npm start
|
||||
```
|
||||
|
||||
|
|
@ -49,7 +56,7 @@ You can access the universal decoder at the url available in the output of the p
|
|||
|
||||
### Run tests
|
||||
|
||||
```
|
||||
```bash
|
||||
npm test
|
||||
```
|
||||
|
||||
|
|
@ -78,6 +85,7 @@ LoRaWan Port field as integer value.
|
|||
Base64 and URL encoded payload to decode.
|
||||
|
||||
For example, to test a payload of `ABCDE12345`, you:
|
||||
|
||||
- Convert it to a base64 encoded string: `QUJDREUxMjM0NQ==`
|
||||
- Convert the result to a valid URL parameter: `QUJDREUxMjM0NQ%3D%3D`
|
||||
- Add this to your URL as the payload query parameter.
|
||||
|
|
@ -92,17 +100,17 @@ Install the [Azure IoT Edge for Visual Studio Code](https://marketplace.visualst
|
|||
|
||||
Make sure you are logged in to the Azure Container Registry you are using. Run `docker login <mycontainerregistry>.azurecr.io` on your development machine, or `az acr login -n mycontainerregistry` if the Azure CLI is available.
|
||||
|
||||
Edit the file [module.json](./module.json) to contain your container registry address, image name and version number:
|
||||
Edit the file [module.json](/Samples/UniversalDecoder/module.json) to contain your container registry address, image name and version number:
|
||||
|
||||
|
||||
|
||||
We provide the Dockerfiles for the following architectures:
|
||||
|
||||
- [Dockerfile.amd64](./Dockerfile.amd64)
|
||||
- [Dockerfile.arm32v7](./Dockerfile.arm32v7)
|
||||
- [Dockerfile.arm64v8](./Dockerfile.arm64v8)
|
||||
- [Dockerfile.amd64](/Samples/UniversalDecoder//Dockerfile.amd64)
|
||||
- [Dockerfile.arm32v7](/Samples/UniversalDecoder//Dockerfile.arm32v7)
|
||||
- [Dockerfile.arm64v8](/Samples/UniversalDecoder//Dockerfile.arm64v8)
|
||||
|
||||
To build the Docker image, right-click on the [module.json](./module.json) file and select "Build IoT Edge Module Image" or "Build and Push IoT Edge Module Image". Select the architecture you want to build for from the drop-down menu.
|
||||
To build the Docker image, right-click on the [module.json](/Samples/UniversalDecoder/module.json) file and select "Build IoT Edge Module Image" or "Build and Push IoT Edge Module Image". Select the architecture you want to build for from the drop-down menu.
|
||||
|
||||
To **temporarily test** the container running you decoder using a webbrowser or Postman, you can manually start it in Docker and bind the container's port 8080 to a free port on your host machine (8080 is usually good).
|
||||
|
||||
|
|
@ -146,4 +154,4 @@ http://universaldecoder:8080/decoders
|
|||
|
||||
In case the custom decoder is unreachable, throws an error or return invalid JSON, the error message will be shown in your device's messages in IoT Hub.
|
||||
|
||||
|
||||
<!-- markdownlint-enable MD040 -->
|
||||
|
|
@ -31,9 +31,9 @@ dotnet .\bin\Release\netcoreapp3.1\loradeviceprovisioning.dll -- (add verbs and
|
|||
|
||||
## Setting up
|
||||
|
||||
[appsettings.json](/appsettings.json) needs to be in the same directory as the cli-lora-device-provisioning binary (verifyloradevice.dll or verifyloradevice.exe).
|
||||
[appsettings.json](appsettings.json) needs to be in the same directory as the cli-lora-device-provisioning binary (verifyloradevice.dll or verifyloradevice.exe).
|
||||
|
||||
[appsettings.json](/appsettings.json) needs to contain a connection string from the Azure IoT Hub you want to work with. This connection string needs to belong to a shared access policy with **registry read**, **registry write** and **service connect** permissions enabled. You can use the default policy named **iothubowner**.
|
||||
[appsettings.json](appsettings.json) needs to contain a connection string from the Azure IoT Hub you want to work with. This connection string needs to belong to a shared access policy with **registry read**, **registry write** and **service connect** permissions enabled. You can use the default policy named **iothubowner**.
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -41,7 +41,7 @@ dotnet .\bin\Release\netcoreapp3.1\loradeviceprovisioning.dll -- (add verbs and
|
|||
}
|
||||
```
|
||||
|
||||
[appsettings.json](/appsettings.json) may **optionally** contain a Network Id (NetId) in case your solution does not use the default Network Id 000001. Since just the last byte from this 3 hex string byte array (6 characters) are used to create a valid DevAddr for ABP LoRa devices, the setting can be either the full 3 bytes (000000 to FFFFFF) or just the shortened, last byte (0 to FF).
|
||||
[appsettings.json](appsettings.json) may **optionally** contain a Network Id (NetId) in case your solution does not use the default Network Id 000001. Since just the last byte from this 3 hex string byte array (6 characters) are used to create a valid DevAddr for ABP LoRa devices, the setting can be either the full 3 bytes (000000 to FFFFFF) or just the shortened, last byte (0 to FF).
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -213,7 +213,7 @@ The update verb supports the following parameters:
|
|||
|--appeui|no|AppEUI (only for OTAA devices): A 16 bit hex string.|
|
||||
|--appkey|no|AppKey (only for OTAA devices): A 16 bit hex string.|
|
||||
|--gatewayid|no|GatewayID: A hostname. |
|
||||
|--decoder|no|SensorDecoder: The name of an integrated decoder function or the URI to a decoder in a custom decoder module in the format: http://modulename/api/decodername. |
|
||||
|--decoder|no|SensorDecoder: The name of an integrated decoder function or the URI to a decoder in a custom decoder module in the format: <http://modulename/api/decodername>. |
|
||||
|--classtype|no|ClassType: "A" (default) or "C". |
|
||||
|--downlinkenabled|no|DownlinkEnabled: True or false. |
|
||||
|--preferredwindow|no|PreferredWindow (Preferred receive window): 1 or 2. |
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче