An example of the problem we’re trying to solve:
- We have data flowing from TTN into our app.
- We have a tank sensor, and the data is getting recorded against a device in our app.
- The tank sensor breaks and we replace it. New TTN device with new deveui, devId, maybe even appId.
- We want to data from the new TTN device to go to the same device in our app.
So we need a way to map a TTN device to a device in our app.
ATM we have a database table that does this using the TTN appId and devId. This requires maintenance when we swap devices in the field, and we need to run the database. And we’re moving away from our in-house platform to ubidots.
Today we brainstormed an idea where we could use the TTN device name (which we can carry over to the replacement device and change on the old device) as a more automatic way of doing this mapping.
Then we realised the device name doesn’t come in the message from TTN.
I just looked at webhook variables and I can’t do it that way.
Is there a way to get TTN to include extra device metadata, either standard info like the device name or one of the user-defined properties in the message it sends to a webhook or mqtt topic?
I would prefer not to have to make a REST auth then API call for every message we receive. I don’t think we can cache the auth token due to the runtime environment we’re moving to (an ubidots ubifunction).
More generally I’m puzzled as to how little I see this discussed. It seems to me that if you want to do historical analysis over a time period where a physical device has failed and been replaced you need to be able to stitch the timeseries data from each device into a single stream, or have it recorded in a single stream through some sort of logical device layer as we do in our current system.