Device attributes in webhook json

[jpmeijers]

Summary

I would like to see the device attributes which are set on TTS console to appear in the json I receive via the webhook. This would allow me to have a stateless lambda function process the webhook. Depending on the attributes the lambda can do different things with the data.

Current Situation

Device attributes are not included in the webhook json data. One needs to do an api call to TTS to obtain the device attributes.

Why do we need this? Who uses it, and when?

All device configuration can be moved to a single place: TTS. Depending on the configuration on TTS, a stateless middleware can process the data and send it on to a third party system.

Example:
A gps tracker need to be added to ArcGis. The tracker is added to TTS. A lambda funtion creates features on ArcGis. The configuration of the ArcGis api key, feature layer ID, and some other configurations need to be stored somewhere on a per device basis. Using the attributes on TTS would be ideal, as the same lambda function could then be used for any device or any ArcGis account.

Proposed Implementation

Add the device attributes to the webhook uplink (and other) json

Contributing

• I can help by doing more research.
• I can help by implementing the feature after the proposal above is approved.
• I can help by testing the feature before it's released.

Code of Conduct

• I agree to follow TTN's Community Code of Conduct.

[descartes]

This has been raised before, I believe the challenge is about how much is held in Redis for timely access. Plus there are petitions to reduce the size of the JSON ...

[jpmeijers]

The workaround I'm currently pursuing is:

1. Create ApiKey for webhook, giving permissions to list application devices.
2. Uplink happens and Lambda receives uplink json, as well as ApiKey.
3. Inside the Lambda do a call to /api/v3/applications/{end_device_ids.application_ids.application_id}/devices/{end_device_ids.device_id}?field_mask=name,attributes using the ApiKey.
4. Now I obtained the Attributes and the device name, and the Lambda can continue processing the data.

This workaround causes more load on both my Lambda as well as TTS, as would have been if the attributes were included in the uplink. However, now I also get the device name, which I anyway needed, and that is also not included in the uplink message.

[descartes]

I have some alpha PHP code to replicate / mirror the standing data of the device so it is locally available. If you are using the AWS Lambda service this db would need to be on another service. It periodically checks timestamps for any changes or additions. This is faster & less load on TTN which is the target audience as some aspire to use TTN as some form of online database.

[descartes]

I also have beta PHP code to take a payload formatted uplink and get it in to a database - again for the same reasons above. It sorts out any additions & changes in PF field names.