TTN Decoder Repository Update Issue
**
I would like to open this discussion in the hope of advising caution to other TTN users when selecting “use device repository” when creating sensor applications and introducing hardware.
It would appear that** TTN (The Things Network) has been pushing uplink payload decoders/formatters to their device repository without informing hardware and application holders on their sandbox (free) platform.
A problem arose when a variable name was changed in an update from Milesight, but could easily have been from another manufacturer. It would seem they sent that payload decoder update to TTN, TTN then updated their repository without checking for changes or informing relevant users. Every user that chose “use device repository” in their application and device set up may/will have issues when their variable names are changed.
In our case, on Milesight magnetic contact switches, the variable was changed as follows:
from
door: 0 or 1
to
magnet_status: “open” or “closed”
This has led to processing and dashboarding failures as they’re now unable to find their source variables.
To prevent this happening again we will manually enter custom payload decoders, which can be made or sourced from device manufacturer websites, and NOT “use device repository” which can be updated and broken without any notice.
This hidden issue has been service affecting on our Milesight sensor applications since late December.
To make this otherwise helpful “use device repository” feature more stable, I would recommend both a comparison scan between old and new, then a notification to all TTN application administrators to warn of the change. Even better, would be a default “do not update automatically” option available on device and application registration.
No one here can action your suggestion - suggestions should be made as a GitHub repro.
TTI, the developers of the free software & infrastructure you are using, do not change the payload formatters for a device, that is done by the manufacturer, so you may want to take this up with Milesight.
You could script something that checks GitHub for any PF changes but overall, I’d go with explaining to Milesight how they shot some customers in the foot. There is version of device available which they could have implemented to leave the old one alone.
Also, tell them that magnets aren’t open or closed, so door_status would have been better if they were going to mess with the semantics of the PF.
Plus, PF aren’t guaranteed to be processed on any TTS if server load times out the processing. Good practise is to decode yourself from raw at your own end point as you have control over both the code and system load.
Additionally, if your applications are not directly used by the communities, you may fall in to commercial use territory which means that a TTI instance with access to the TTI team to take up such issues would be appropriate - @rish1 can advise you best.
Hi @descartes you may note the purpose of this discussion, to advise caution when using a feature on TTN. I’ve quoted it here for you again. Milesight have been informed, separately. I’m of course aware that Milesight are the ones to change their decoders, however TTN is the platform where all applications are automatically changed to use the new decoder, and are therefore directly relevant to this notice.
This issue is relevant to all users using the device repository for their applications. As such, there seems to be no benefit from discussing it directly with a commercial use support team, while keeping the wider TTN community uninformed. You may also note that your advise on good practice is redundant as I already stated we’d “manually enter custom payload decoders, which can be made or sourced from device manufacture websites”.
Full consideration of the text within an informative post may lead to a more constructive discussion. This was not a support request, nor an opportunity for unnecessary correction, it was a caution related to a feature with alternative workarounds.
But then it looked like an issue about known functionality outside TTI’s remit with suggestions on what TTI & the user base could change to ameliorate the situation.
I didn’t say to not tell TTN users. I was noting that if you are outside the remit of TTN by having a critical issue with the way it works, you are best off using TTI. And life-ring cabinet sensors strike me as being pretty critical, so using a service with no SLA that’s explicitly for testing and called Sandbox triggers a certain amount of cognitive dissonance. Always fear The Daily Mail headlines!
The point I was making was about not running the PF at all. Ever. Not even on TTI. Because timeouts. Which means all values should be validated which can be done by boundary checks or by running the PF locally with an error handler. So you may as well run it once locally where you have control.
All these PF’s have to be held in Redis in memory which increases server load on the free service for memory & CPU time. So copying the PF in to the application or, worse, device, is not great for TTN and can still lead to errors due to timeouts.
As to the last paragraph, I saw the post differently. Giving us all heads up or a reminder was great. I did perceive there was a suggestion of a notification system - a change - an issue. I also perceived an error in the description how TTN device PF’s are updated, which is not arbitrarily by TTI, potentially leaving people to request changes of TTI when it would be better for people to be directed to the right place, the manufacturer. The work around creates additional processing load on a free service.