Property TTN payload_fields is not passed on

[reitsma]

TTN has payload_raw and optionally payload_fields properties. If the payload_fields are present, no decoding is necessary anymore. Obviously, the fields property must be passed on from from TtnAppService.preProcessMessage to the messageHandler. If not present, then the payload_raw property must be passed on.

[dcalvoalonso]

As you pointed In https://github.com/Atos-Research-and-Innovation/IoTagent-LoRaWAN/blob/master/lib/applicationServers/ttnAppService.js#L98:

            if (message && message['payload_raw']) {
                this.messageHandler(this, deviceId, null, message['payload_raw']);

So, payload_raw field is always passed. Why should we pass also payload_fields? If I am not wrong, it is just the same information transmitted with payload_raw but unencrypted, isn't it?

[reitsma]

Payload_raw is the base64-encoded payload (no encryption). This payload is encoded in some way. In TTN the knowledge of the encoding/decoding algorithm may be restricted to the TTN application, i.e. inside the TTN platform. The MQTT client does not necessarily know how to decode. In our case, the encoding algorithm was proprietary. Fortunately, there is this payload_fields object. So, I think you should pass it. I don't know how it matches cayenne or cbor with the known encodings, I don't have sensors around to test.

[dcalvoalonso]

Sorry, I made a mistake, you're right, payload_raw does not contain encrypted information.

Nevertheless:

This payload is encoded in some way. In TTN the knowledge of the encoding/decoding algorithm may be restricted to the TTN application, i.e. inside the TTN platform.

The encoding/decoding algorithm is not restricted to the TTN but the sensor/device provider/developer. In your devices' application, you can decide the payload format that you want to use. Then, in TTN console you can define if the payload format is CayenneLPP or a custom one. For this reason, when you do the device /service provisioning you can specify the data_model.

As you can see, we don't need to pass payload_fields because we are actually obtaining this value by decoding the payload_raw. The advantage of our approach is that the IoT Agent capabilities in this sense are beyond TTN, supporting an additional payload format (i.e. CBOR). Our intention is to add more payload formats in the future and any developer can easily add proprietary solutions by forking the agent.

[reitsma]

All well, but sometimes the payload decoding algorithm is proprietary and not available for the agent developer. That is my case. I do not have access to that algorithm, I need the payload_fields.

[dcalvoalonso]

Just to understand your use-case, if you don't have access to the payload decoding algorithm, how the TTN application server is aware of it?

[reitsma]

The TTN application server is aware of the payload decoding algorithm, but the application owner has only given me an access key for subscribing to the MQTT topics of the application. A strict role separation so to say.

[dcalvoalonso]

I understand the situation now. I will think about how to solve this in the agent.

[dcalvoalonso]

This should have been fixed by https://github.com/Atos-Research-and-Innovation/IoTagent-LoRaWAN/pull/33.

Now, in addition to cayennelpp and cbor, you can use in the data_model field the option application_server. For instance:

      "internal_attributes": {
        "lorawan": {
          "application_server": {
            "host": "localhost",
            "username": "ari_ioe_app_demo1",
            "password": "ttn-account-v2.UitfM5cPazqW52_zbtgUS6wM5vp1MeLC9Yu-Cozjfp0",
            "provider": "TTN"
          },
          "dev_eui": "3339343752356A14",
          "app_eui": "70B3D57ED000985F",
          "application_id": "ari_ioe_app_demo1",
          "application_key": "9BE6B8EF16415B5F6ED4FBEAFE695C49",
          "data_model": "application_server"
        }
      }

[dcalvoalonso]

@reitsma could you please check if this issue can be closed? Thanks! :)

[reitsma]

This issue is now solved with your fix. Thanks!

[dcalvoalonso]

Thanks for the feedback!

[dcalvoalonso]

:tada: This issue has been resolved in version 1.0.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: