DeviceEui is not passed on

[reitsma]

For automatic device provisioning (through a device group configuration), the device_eui is used to lookup the device. Although in TtnAppService.ttpreProcessMessage deviceId and deviceEui are the same by convention, the deviceEui is not forwarded to the message handler. The device is registered without deviceEui set.

By more analyzing I cannot determine when it becomes really an issue, but it seems incorrect. O I see, the lookup call is used only by the loraserverio.

The root cause of many problems with provisioning and deprovisioning is caused by the parallel management of device lists. See issue #21.

[dcalvoalonso]

For TTN, as you can see in https://www.thethingsnetwork.org/docs/applications/mqtt/api.html, the MQTT API for uplink messages does not contain or passes the deviceEui. This is not the case of LoRaServer.io, from https://www.loraserver.io/lora-app-server/integrate/sending-receiving/mqtt/:

Uplink: application/[applicationID]/device/[devEUI]/rx

Thus, in the latter case, we are able to pass this information when the device has not been provisioned previously.

I have reviewed the functionality and I don't find any bug or issue caused by not passing the deviceEui in the case of TTN. Have you found some problems?

[reitsma]

That is a good point. I think in TTN the device id is de facto the device EUI. For automatic configuration you need to know the device EUI. At some point you have to decide these two are the same. I have code it in the TTN handler, because that seemed the right place for this piece of knowledge.

I have no experience with the LoRaServer.io.

[dcalvoalonso]

I think in TTN the device id is de facto the device EUI

Please find attached an screenshot from TTN console:

As you can see the Device ID (lora-n-001) is different from the Device EUI (3339343752356A14).

This is also explained in https://www.thethingsnetwork.org/docs/devices/registration.html:

For Device ID, choose a - for this application - unique ID of lower case, alphanumeric characters and nonconsecutive - and _. For Device EUI, copy-paste the one you retrieved from your device.

[reitsma]

You are right, after consulting my TTN collegue I discovered he used the same ID for two different fields. I should have read the docs in more detail. My fault.

Nevertheless was the deviceEUI in the original code not passed for TTN. For completeness, the parameters for TTN as received in the TTN message handler (in my code) are:

• app_id (human readable application id, as in screenshot previous comment)
• dev_id (human readable device id, as in screenshot previous comment)
• hardware_serial (the device EUI)
• counter
• port
• metadata (time, latitude, longitude, altitude)
• payload_raw (encoded payload)
• payload_fields (decoded payload)

So in addition to the dev_id, also the hardware_serial should be passed. Otherwise automatic device configuration will not be possible. I have not tested it yet, except then for visually checking the actual parameters. In the link you mentioned earlier https://www.thethingsnetwork.org/docs/applications/mqtt/api.html I see indeed a comment that links the hardware_serial to the deviceEUI.

[dcalvoalonso]

Fixed with #54 . @reitsma could you please check and close the issue?

[dcalvoalonso]

I close the issue as it is solved with #54. @reitsma, you can reopen it if you consider necessary.

[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: