It is because of the HTTP Integration. As the webhook needs to be public, anybody could register devices without acutally owning them. Thus I thought it might be better to check the device.
As far as I understand MQTT I would need a MQTT connection for each Application I want to monitor? This could grow to many idling connections. So it isn’t really usable for this case.
Good point, I guess. Now wondering how difficult it would be to create a dedicated integration 
I think there is a lack of documentation
I just added a map showing the nodes and gateways. Furthermore it shows the link between the node and the gateways which received the packets. The lines color indicates the SNR. If there is no link between a node and a gateweay within 7 days the line is removed.
Of course nodes can only be shown if coordinates are specified. So it would be great if all of you could consider to enter the nodes (approximate) coordinates in the TTN console.
interesting nodes location 
Today I captured a packet sent from a node in Apeldoorn at 65 meters high being received by a gateway in Utrecht over a distance of aproximately 60 km using TTNMon. The same packet was received in Delft over a distance of more than 112 km:
Below a composite of the registrations:
Because of this I have a feature request: please add the distance to the gateway with the gateway location, and altitude.
Utrecht registration in TTNMon
Delft registration in TTNMon:
Thanks.
I added the distance next to the coordinates. Unfortunately your node didn’t send it’s coordinates with this packet. This is why TTNmon will show the gateway distance only starting with 10.04.2018 for your node.
I also fixed the map. It broke with a server migration. Links will be shown of the past seven days. However it currently only shows the links of a few hours as I didn’t record the data before. Previously it was generated from the data tables every 10 minutes which caused high server load and took a quite long time. Link information are now instantly updated.
Additionally gateways will now be removed from the map if they haven’t been heard within the last two weeks. This is the reason why some gateways disappeared in Amsterdam which were online during the TTN conference.
Hi,
The node was in test until last friday. Then it was installed at the final location and in the weekend I added the location because I found that is was not set.
The rest of your information makes perfect sense. I will study the coming weeks behavior and will keep you posted.
Thanks.
I have some updates on TTNmon
Gateways SNR and RSSI values are now sperated by their channel. This way high noise on a single channel can be easily identified.
Checking the map I noticed a few nodes with very long and still pretty good links. It seems that the nodes where moved. Can the owner verify this? I think I will have to implement a check for moved nodes to hide old links.
“Device 34” ist my node.
And, indeed, it moved temporary from Berlin to Frankfurt.
And is currently moving back, while writing these lines 
Hi, when I had a look the site shows the same RSSI graph for a gateway and a node for both RSSI and SNR.
Seems a bug to me:
Thanks for your bug report. I fixed the problem.
Time to announce some updates. I fixed some bugs and added new features to TTNmon.
First of all you can now switch between UTC and local time. If local time is selected, your browsers timezone will be used to convert the time.
It is now possible to link directly to a nodes data within a specified date range and a gateway. Example: The URL https://ttnmon.meis.space/console/#device-1-29.4.2018-30.4.2018-eui-b827ebfffed5ce60 shows connection during severe weather in Aachen last month. The RSSI of the preselected gateway drops during heavy rain. URLs can be directly copied from the browsers address bar. It is recommended to share only UTC urls.
Last but not least I added a gateway explorer which I want to enhance soon. It shows a searchable list of all gateways. Viewing the details page you can see a list of nodes which has a link to this gateway. This list is currently incomplete as I had some changes in the database. I’ll try to restore this data but it will take some time because of the raw data size of about 1GB.
My next goal is to compare nodes connected to a gateway to add the ability to find highly used channels and calculate used airtime. Do you have any more suggestions for the gateway explorer?
I was also thinking about a small deamon which could run on gateways and send some information like CPU temperature and load to TTNmon. Additionally it could be added to the poly forwarder and collect basic information of nodes which don’t send their data to TTNmon. This way airtime calculations and channel analysis would become more accurate. Another nice feature would be to find other LoRaWAN networks in the region. What do you think about this idea? Would you install such an application on your gateay?
@SmartNOOB is TTNMon still operational?
I cannot access my data for weeks now.
I hope it will stay operational.
Cu, Remko.
Well not really, but at least a bit. When I started with TTNmon I didn’t expect getting the huge amount of data I collected after nearly two years. Thus I built a solution based on PHP and MySQL. I had to change to another server after just a few months. Currently TTNmon runs on a dedicated server which is also hosting some other services like mail or my personal blog. But TTNmon is consuming most of the available ressources (main problem are the slow disks in RAID1).
This is why the MySQL based TTNmon version became completely unuseable a few weeks ago. In June or July I started a new TTNmon version based on MySQL for relational data like auth tokens and devices, Influx for the time series and Python as new web backend. I’m currently missing the time to add all functions which were available in the old version.
As the PHP version became completely unuseable I decided to switch to the new version which is already collecting all packets. I also migrated the old data to Influx. There is a Beta version available at https://beta.tttnmon.meis.space/. It is currently able to list your devices and show the basic gateway metadata for your gateway. Unfortunately the graphs to show the connection quality between a node and a gateway are not yet available. Graphing is now done by Grafana and there is a publicly available dashboard for nodes and gateways which can be used to show your data right now: https://grafana.ttnmon.meis.space/. I know that this doesn’t have a good usability but it is sadly the only option at the moment.
While TTNmon became much more responsive with Influx + Grafana it is already obvious that the disk load is still much too high to ensure a stable system in future. I’m currently looking for a way to host TTNmon on an SSD based server in future. To stay on budget I will need to restructure a bigger part of my infrastructure which is again time consuming.
I apologize for the inconvenience and hope to be able to enhance the new version as soon as possible.
Hi @SmartNOOB there is no need to apologize. This is a volunteering activity. 
Happy to hear that avtivities are still on-going and the project is not abandoned. Thank you for your effort. I hope to here more soon.
After about two months TTNmon is available again at https://ttnmon.meis.space. The basic functionality has been restored. It is now possible to query packet metadata as well as gateway metadata. Performance is much better than before.
The map as well as the gateway explorer are currently still unavailable. I hope to finish the implementation of these modules soon.
It is now no longer required to give TTNmon access to your devices list. Device EUIs are now connected to the authentication token. This circumvents the requirement of validating passed information and allows duplicate EUIs within TTN (which might actually happen).
You might need to clear your webcache to load the latest javacript files.
Nice work @SmartNOOB
I have several devices in several applications and now have a nice overview of all of them. A good example of an efficient device management tool.
Keep on with the work so we can get the maps too.
Thank you for your effort. Keep-up the good work!
Unfortionately I cannot use my old token. Is this correct?
