Hint für alle die es ausprobieren wollen, und so wie ich keine Ahnung haben:
Das ganze läuft nicht mit node.js v0.10. Das ist Default bei Ubuntu Trusty (aktuelles LTS), da muss man also ein externes Repo hinzufügen um ein neueres Node zu kriegen.
Die Mindestanforderungen hatte ich noch nirgends dokumentiert gefunden, darum lass ich das einfach mal hier.
Ansonsten ist zumindest der hopglass-server so ziemlich Just Works™, Frontend hab ich noch nicht getestet.
Eventuell ergibt es einen Unterschied, ob man
-var targetip = argv.targetip ? argv.targetip : 'ff02::2'
+var targetip = argv.targetip ? argv.targetip : 'ff02::1'
nutzt.
Auf ::2 antworten nicht alle Gluon-Versionen (zuverlässig).
Mag sein, dass sich da noch was ändert, und dass es ärgerlich ist, dass man so auch alle Clients einmal anstubst, aber zumindest funktioniert letzteres.
Also bei mir war es User-Fehler. Oder weiß nicht.
Als ich das mit --ifaces bat02,bat03… gemacht habe lief es eine Weile, dann kamen auf einmal keine Daten mehr raus. Hab die raw.json und die hosts gelöscht, dann wurden die neu erstellt mit 0 bzw. 2 Bytes Große.
Jetzt habe ich es auf die Bridges ins Freifunknetz lauschen lassen, jetzt gehts wieder. Macht ja auch Sinn.
Ich frag mich aber gerade wieso es überhaupt mal bei den batXX interfaces geklappt hat…
Irgendwo hab ich grade wohl nen grundsätzlichen Verständnisfehler.
Wir hatten bei uns in einigen Domains das von Dir beschriebene Szenario, dass der batctl o ein x-faches der Nodes auswarf als der HopGlass. In anderen Broadcast-Domains passte es jedoch 100%.
Es scheint so, dass Gluon-Master „aus Q3/4 2015“ nur auf auf die ::1 reagieren, d.h. sowohl die alten 2015.1.2 wie auch die aktuelleren Master (und natürlich das 2016.1-release) auch mit der ::2 antworten.
Wer sich also sicher ist, von diesen Versionen nicht betroffen zu sein, kann die Netzlast (geringfügigst) durch „nur ::2“ reduzieren. Ist ja immerhin ein Broadcast…
„Client-Pünktche“ und „Nodenamen“ auf der höchsten Map-Zoomstufe würden wirklich(!) helfen.
Wenn die Nodes eng stehen wie hier:
Eine Stufe höher gibt’s dann nix mehr:
Eine Möglichkeit die Routernamen auszublenden wäre auch fein, dann wird es ein wenig übersichtlicher und bei mouseover bekommt man den Namen dann weiterhin angezeigt.
Das zu implementieren ist kindergeburtstag bzw relativ einfach
Das mit den aus geblendeten Clients und nodenamen kommt vom leaflet dort ist hardcoded das die nur bis zoomstufe 18 gezeichnet werden
Hatte im meshviewer v4 mod thread glaube ich eine Lösung dafür gepostet
Ich kann’s leider nicht.
Daher meine Bitte, das zu Implemtieren, wenn es keine Designziele gibt, die dem widersprechen.
Bzw wegen den Clients
Im leaflet ändern und den meshviewer neu bauen
Muss bei jeden leaflet update neu gemacht werden
Ist auf der Eulenkarte getan.
Wie man das jetzt ordentlich einbaut - keine Ahnung…
mann müsste disen Bug featurewunsch bei leaflet äußern
die zeichenen halt nur bis zoomstufe 18 weil bis dahin die meisten karten gehen.
Ätzend 
mann sollte noch die zeichnenreihenfolge ändern das die meshlinks ganz nach hinten rücken 
Hopglass kann jetzt nach verschiedenen Link-Typen unterscheiden und z.B. Kabellinks im Graph blau zeichnen. Auch werden VPN-Verbindungen jetzt ohne weiteren Aufwand als Solche erkannt. In den Linklisten eines Nodes sind die Richtungen der Verbindungen markiert und natürlich der Typ.
Erstklassig!
Wenn man jetzt noch anhand der Knotenfarbe nicht nur Uplink sondern auch noch erkennen lönnte ob die Router nur mesh oder nur client oder beides sprechen wäre ein Traum.
27 Beiträge wurden in ein neues Thema verschoben: Hopglass Server Installation (keine Antworten der Router am Server)
Der Prometheus-Doc auf
http://graphite.readthedocs.io/en/latest/config-carbon.html#storage-schemas-conf
entnehme ich, dass wenn man z.B. die Bytecouter an den Interfaces zu Daten-Raten zusammenfassen würde
(und unter Auslassung der Negativ-Sprünge bei Reboots/Reconnects), dann könnte man das aggregieren.
Und somit auch effizienter Daten über längere Zeiträume halten.
P.S. ich habe die Haltezeit im Prometheus durch Einfügen von -storage.local.retention 760h0m0s
in /etc/init.d/prometheus auf rund 2 Monate hochgedreht.
_
es ist nicht korrekt das die Router diese Daten nicht liefern - die sagen sehr wohl ob und welche fastd sie zum beispiel benutzen … daraus lässt sich indirekt und sicher der mesh/uplink status bestimmen
Die Erkennung von Tunneldigger-Devices ist aber eher schwierig. Zumindest sehe ich keinen trivialen Weg außer per manueller Aliases-Datei für die Server.
Oder wie wäre der Trick?
sagen die nicht irgendwo ob die je an mesh-vpn (oder wie das tunneldigger if heissen mag) oder an ibss0 hängen … ich hatte damals sowas angefangen in diese richtung. Mach doch mal nen diff auf ne meshnode und ne uplinknode (alfred oder respondd thread nach nodeinfo bzw statistics, dort könnte man denen das sonst auch beibringen)