I’m sorry to revive this topic Pass device attributes into uplink JSON but still don’t understand why when we receive an uplink frame we can’t get device attributes into? I put information on these attributes to be able to do action on receive packet, that’s the goal indeed. I don’t want to request API to get these on each uplink I’m receiving.
It’s the first time I’m stuck due to not receiving these information. Is there a way to have this feature implemented (at least on MQTT side), it works like that on every network server I use (Orange LiveObject, Bouygues Spot, Chirpstack, Helium, …)
Thanks
Because it’s not in the code is about all anyone here can answer. Why not open a GitHub issue? But as I said on the other thread, that’s going to have an impact on what is held in the Redis database so it’s not a trivial change.
Or for preference, cache the data in your database.
Thanks,
By redis you mean where is stored historic of data received?
nice idea about github, just submitted issue #5120
No, by Redis, the in memory database, that holds the key data so that uplinks can be processed as fast as they are. Which is why the servers need so much memory, there just isn’t enough time to perform queries on the standing data. If more items are added to the store, servers need more memory …
1 Like
Why can’t you hold the static data in an in-memory store at your MQTT or Web-hook endpoint and lookup what you need?
It’s not trivial but it’s not rocket surgery.
I’m subscribing to TTN MQTT, then got JSON and just manipulating payload with JS scripts that’s just what I have and I need. if on startup I need to query and store tags (and do it on basis interval in case of update) there is no reason to have them on TTN, simplier to have a local mapping table (and this is what I want to avoid).
I’m using tags for years with Orange LiveObject, Bouygues, Chirpstack, gotthardp and even new Helium, I was just expected tags would work same way with TTN to avoid change of the way I process data, but I can hear you need to keep memory as low as possible.
You, me, everyone, we are all TTN. We can request any number of changes, but anything that impacts the servers has cost implications, costs we don’t pay for.
Nick, agree, was just surprised because other have that’s all, but once again makes sense.
There are a whole pile of extras we get in the JSON that I can live without - ideally we’d have two or three levels of choice - minimal, average & full-fat - where full-fat is what we get right now.
From a database perspective, I’m very happy to trade convenience for speed & reliability - so I’d rather we didn’t have anything in the JSON that is static that we can lookup if it’s needed and/or cache for local lookup.
Nick,
Absolutely, I saw that also, that’s why I thought at 1st time adding a TAG would not hurt 