I’ve set up the TTIG to connect to my wifi, which seems to work given the steady green light I get after config and restart. Using 868 MHz device.
Adding the TTIG to the TTN console (community edition) also worked, it’s accepted and shows up green.
The “Last Seen” field is reset to zero when the TTIG is started (indicating that some status update was sent from the TTIG), but then the Last Seen field in the console never updates.
At least not until I power cycle the TTIG again.
I also have a Kerlink iFemtoCell-Evolution, for which the Last Seen field updates every 30 sec.
I realise that the two devices use different software inside, but I kind of expect the TTIG to send some kind of hearbeat to show its alive… Or?
Not sure if it’s related, but the “Status” field in the console is always “connected”, it seems. I can remove power to the gateways (TTIG and iFemtoCell) and leave them like that for hours, but their status still shows as connected.
Is that really intended behaviour?
There is a translation layer between TTIG and the community backend. It would be a waste of resources to have that translation layer simulate alive packets…
I understand there is probably lots of translations, mappings, and other stuff going on. I write large scale software systems all day for a living, so I have lots of respect for a platform like this.
Still (or maybe because of that) I don’t really follow why it would be a waste of resources to show whether a device is up/down or how long it’s been since it was last seen. Especially if those fields are shown in the web UI for the device in question.
Unless… the device doesn’t send a heartbeat to begin with, of course.
I have no clue if the TTIG does that or not. I just assumed it did, to be honest.
Do you know, @kersing?
Also, is there some (high level) docs that explain the software layers of TTN? Would make it easier to understand what’s going on when something isn’t working as expected.
Check the basicstation documentation and you know if it is available in the protocol. Next is whether TTIG implements the current document which is anybody’s guess because the code closed source.
Have you checked the documentation part of the TTN website? That lists the main components. However the community network is currently in a transition phase where the backend is partially V2 and some parts are V3 (gateways are connected to V3 component) and there is some ‘magic’ glue in between. Details of the current setup are known to the TTI crew only at the moment as far as I know.
Since our community network clusters all look different, and things are changing all the time, it would cost us too much time to maintain an up-to-date overview of how things are connected in each region.
In the image below you’ll see how gateways can connect to a v2 network. The old situation (yellow) will slowly be migrated to the new situation (green). We do this by first routing a small percentage of traffic for a given gateway protocol through the new components, and slowly increasing that percentage. The same for the other gateway protocols.
As @johan mentioned during his presentation at the conference, many community network gateways already connect through a v3 gateway server, and we are slowly connecting more gateways through v3 Gateway Servers over time.
Apart from these Gateway Servers the entire Public Community Network still runs v2 components.
