Hi to all,
it’s realy an issue to not have any history file to understand and debug uplink ans downlink message during the day or 2 days before.
Please could you add this feature ?
Thank
Arnaud (Paris)
You are so right so I got on it straight away and it’s done!
Check out the Data Storage option in the Integrations section of an Application.
But ssssshhhh, don’t tell anyone I did this for you, otherwise they’ll want something too.
Hi Nick,
Thank you for your feedback but it realy dedicated to expert people and realy too complex.
Why not a “Refresh button” to get 24H data in the windows “Live data” that will become “Live data & history data” ?.
ssshhh, i tell this to my sister and she agree !
Ah, I thought when you said file you wanted it as a file, not on the console, my bad.
You could just leave the console window open.
As to the why not a button to get the previous data, the architecture of the stack is all about getting the data out the system to the user. The Data Storage is a copy of the stream of uplinks in to a convenience database as a backup of last resort. It’s not been setup to feed the data back up the line and out to the console.
I did have a tool that allows me to see the contents of data storage but unfortunately the brightest brains here weren’t able to cope with the security model and the API key settings so it was discontinued. I now have a desktop database that is fed from web hooks, so I can see the history of everything of all time.
Because that would require storing millions of messages. Who is going to pay for that on the community network? Don’t forget the current infrastructure is already setting TTI back a considerable amount each month.
There is already event data retention configured on TTN. However, to keep the running costs of our TTN network deployment reasonable, this retention is quite short (I don’t know the exact numbers currently). Storing data is relatively expensive, especially on a huge network like TTN. The retention works with different quotas (time-limits, quantity-limits and payload limits) to ensure an effective mix of criterions to keep server strain low.
If such functionality is crucial to you, you can either:
- Use storage integration (uplink events only, max 24h on TTN)
- Setup your own retention service by ingesting and storing event data through an integration
- Use TTS Cloud (paid), which has much higher retention periods configured, meaning you’ll be able to view much more historical data in the live data view
Can you expand on what exactly the issue was here?
Nope, but you have mail …
I have a large network of z-Waves objects (25 modules) with a Jeedom gateway.
I wanted to use the Lora network and do tests for the long distance module.
Obviously the reliability of this chain is not reach (2 Lora Dragino Open/Close detectors)
Dragino/Lora Gateway/my network/Lora Jeedom Plugin
It Works well most of the time and from time to time I receive "fail to send webhook” and therefore no opening or closing detection of my gate or my mailbox!
I don’t know who is responsible… and I don’t have much time right now to dig and not many simple tools to help me so I leave it like that for now.
Could the Z-Waves network disrupt the Lora network (868Mhz)?
Arnaud
Where is TTN in your setup?
You are.
You designed and built this life-critical application - if you need it to be more robust you’ll have to follow the instructions provided. The download of Data Storage records requires you to install the CLI and run the command that’s fully detailed here.
Really Thank you Nick for your feed back but unfortunately CLI is not in the target of my need (and skills)
regards