Adding new V3 device, the LoRaWAN Device Repository and Payload functions

@johan

I added some Tektelic Kona Smart Room Sensors to a V3 application and used the definitions from the LoRaWAN Device Repository via the device type selection option.

For this device both payload decoder and encoder functions are available in the Device Repository.
However, the payload functions available in the repository were not automatically included when adding the devices to the V3 application.

I would expect the payload functions to be automatically included when available in the repository.

  • Why are the payload decoder and encoder functions in the repository not used when creating a new device?

In V3 payload decoder and encoder functions can be defined at the application level and at the device level. A device can either use the payload functions defined for the application (default) or use it’s own device-specific payload functions.

When adding a new device to a V3 application, using a device definition from the Device Repository I would expect to get informed that payload functions are available for the device and be asked if these:

  1. Should be added to the application if no decoder/encoder functions are defined already
    (For cases where all application devices use the same payload functions)

  2. Should be added to the newly added device as device specific payload functions.

Is such functionality currently planned (for Console and API)?

What do you mean by this, that the code doesn’t show when looking at the payload format? They aren’t set to none or code, but they should be set to device repository. The codec will then be loaded in real-time.

Showing the code in the Console could be a nice feature, just to show the user what will be executed. Still, if the vendor updates the codec in the device repository, it will be applied to all devices that are referring the codec. That is, the code is not copied to each and every end device, but it’s a pointer.

Looping in @neoaggelos for additional expertise.

1 Like

Cool. I wasn’t aware that ‘from registry’ is actually an option where it automatically uses the latest version from the repository (which is nice but can also be a potential external risk for an application).

What I meant for application level payload functions in not relevant anymore here.

Yes, good suggestion. This however is not just a ‘nice feature’ but an essential feature that allows a user to actually verify what code really will be executed.
If the functions can be pulled live from the repository in real-time when used, then it should not be a problem to load them into the console for showing the user what will be executed.
(And yes it’s a pointer so what is shown for each device should be consistent).

I have not checked the Device Repository framework/rules but are objects like payload functions actually versioned with a (symantic versioning) version number that is easy to read and verify by humans? This will make it easier to detect anomalies and inconsistencies between versions.

Yes they are versioned by firmware version. Also, the device repository contains examples that are automatically validated. The end device that you mentioned also has an example: lorawan-devices/vendor/tektelic/t00048xx-codec.yaml at b24c9ba3f7cd92e84acaf23ff1fafcbc4caacb18 · TheThingsNetwork/lorawan-devices · GitHub

uplinkDecoder:
  fileName: decoder_smart_room_sensor.js
  examples:
    - description: Periodic uplink
      input:
        fPort: 10
        bytes: [0x03, 0x67, 0x00, 0x0A, 0x04, 0x68, 0x28]
      output:
        data:
          ambient_temperature: 1
          relative_humidity: 20

The Console will be able to simulate uplinks with these examples, so that application developers can test integrations with per-device and validated application payload, before even activating a physical device. I suppose that gives the verification you want.

Note that you can already simulate binary uplink, and you will be able to see the decoded uplink in configured integrations.

1 Like