Ich habe ein Python-Skript, das meine Repeater überwacht. Keine Ahnung, ob es sowas bereits gibt.
Das Skript läuft auf Windows über BLE mit meinem T-Beam Supreme. Ich denke, eine Abfrage alle 12h ist ok?
Die Resultate werden in einer InfluxDB für die Ewigkeit gespeichert 
und mit Grafana visualisiert. So zumindest der Plan. Falls einer der Parameter aus dem Ruder läuft, wird per E-Mail oder Messenger (Telegram/Slack) alarmiert.
73
Roland HB9VQQ
Generell muss das jeder für sich selbst wissen. Andererseits bin ich da etwas die Spassbremse. Wir erhöhen die Flood Adverts auf 24h, führen Regions ein um die Air-Time aller nicht notwendigen Repeater nicht zu belasten usw. Du bist leider nicht der Einzige der sowas betreibt. Viele Leute betreiben das Ganze mit Home Assistant und ähnlichen Sachen ebenfalls. Die Frage die sich mir da einfach stellt ist immer ein wenig die Notwendigkeit.
Vielleicht bin ich da etwas zu übervorsichtig weil man bei Meshtastic gut sehen kann, wie es einige Wenige für Viele verschlechtern. Du könntest ja auch einfach passiv hören ob sich dein Repeater im Zero- oder Flood-Interval meldet oder nicht. Würde weder die Airtime belasten noch sonst irgendwie für zusätzlichen Traffic sorgen.
Und soweit ich informiert bin, gibt es solche Lösungen bereits von Anderen welche einfach passiv hören. Solltest du dann innert normalem Flood oder Zero-Hop-Interval nichts hören, kannst du die Geschichte sicher noch dahingehend erweitern, dass dann aktiv abgefragt wird ob alles okay ist.
Generell sollten wir, uns allen zu Liebe, bereits jetzt angewöhnen unnötigen Traffic bestmöglich zu vermeiden. Ich sage nicht dass du das Hauptproblem bist. Bitte nicht so auffassen. Aber bereits jetzt sieht man leider zu Hauf unnötige Abfragen, Gastzugänge die endlos abgefragt werden einfach so aus Spass. Da das Mesh bzw deren Nutzer immer mehr werden, führt das irgendwann zu Problemen.
Dies aber nur meine Meinung dazu.
Liebe Grüsse
Ich habe Deinen Einwand zur Kenntnis genommen, danke. Allerdings ist mir nicht bekannt, wie man durch passives Monitoring an die Telemetrie-Daten kommt. Wenn der Repeater keine Adverts mehr sendet, ist es zu spät.
Was kann alles schiefgehen?
| Problem | Symptom im Monitoring | Frühwarnung |
|---|---|---|
| Batterie geht zur Neige | Spannung fällt über Tage von 4.1V → 3.6V → 3.2V | Alarm bei <3.5V, Wartung planen bevor Ausfall |
| Solarpanel defekt/verschmutzt | Spannung erholt sich nicht mehr nach Sonnenuntergang | Trend über Wochen sichtbar |
| Überhitzung im Gehäuse | Temperatur >50°C an sonnigen Tagen | Korrelation mit Reboots erkennbar |
| Hardware-Instabilität | Uptime fällt regelmässig auf 0 zurück (Reboots) | Reboot-Counter steigt, bevor Totalausfall |
| QRM/Interferenz am Standort | Noise Floor steigt von -115dBm auf -95dBm | Empfangsprobleme erklärbar, Standort prüfen |
| Netzwerk-Überlastung | TxQueue >0, Airtime steigt stark | Bottleneck identifizieren |
| Antenne/Kabel defekt | RSSI/SNR verschlechtert sich graduell | Schleichender Defekt vor Totalausfall sichtbar |
Apropos “vermeidbarer Traffic”
Die Advert-Leaderboard zeigt 10-33 Adverts/Tag für die Top-Nodes in der Schweiz. Meine 12 Monitoring-Pakete/Tag liegen im gleichen Bereich - mit dem Unterschied, dass ich dafür verwertbare Telemetrie-Daten bekomme, während reine Adverts nur “ich bin hier” signalisieren.
https://analyzer.letsmesh.net/stats/advert-leaderboard?region=switzerland
Hintergrund
Ich bin der Gründer eines weltweiten WSPR-Baken-Netzwerks auf Kurzwelle. Die Baken befinden sich zum Teil an sehr abgelegenen Orten wie Gough Island im Südatlantik oder auf Spitzbergen. Wenn dort etwas ausfällt, kann man nicht “kurz hochfahren”. Aus dieser Erfahrung weiss ich: Monitoring der Komponenten ist etwas vom Wichtigsten - natürlich nur, wenn man den Anspruch hat, dass die Infrastruktur langfristig stabil und zuverlässig läuft.
Status
Inzwischen werden die Daten in InfluxDB geschrieben. Als Nächstes folgen die Grafana-Dashboards für die Visualisierung. Der Mehrwert von historischen Daten:
Langzeit-Trends erkennen (Batterie-Degradation über Monate)
Korrelationen finden (Temperatur ↔ Reboots, Wetter ↔ Noise Floor)
Saisonale Muster verstehen (Winter vs. Sommer Performance)
Das Skript läuft stabil. Falls jemand Interesse hat, kann ich den Code gerne teilen.
73 de Roland HB9VQQ https://www.qrz.com/db/HB9VQQ
Mir ist schon bewusst dass du durch reine Adverts überwachen keine Telemetriedaten bekommst. Aber deine Repeater werden kaum so ausgelegt sein, dass innert 1-2 Tagen die Akku-Ladestände sich dermassen verabschieden werden dass ein sofortiges, notfallmässiges Handeln notwendig wäre.
Gerade als Amateurfunker, wovon ich durch deinen Namen ausgehe, sollte es doch eigentlich eher an dir/euch liegen uns zu informieren mit den Funkfrequenzen die wir haben sorgfältig umzugehen.
Wie gesagt - du bist nicht das Hauptproblem. Aber viele tun es dir gleich sammeln am laufenden Band Daten. Daten die teilweise erst Tage später ein Handeln bedürfen würden. Und viele Leute sammeln Daten aus allerlei Gastzugriffen, einfach weil sie es können. Ich kanns dir nicht verbieten und das ist auch nicht mein Ziel. Dennoch sieht man mehr und mehr, dass dieses zum Problem wird und zukünftig noch stärker zum Problem wird.
Dass du deine Abfragen mit dem Topscorer in der Schweiz gleichstellst, macht die Sache für mich nicht besser. Ein Flood-Advert alle 12h, bzw besser 24h und die Zero Hops auf ein minimum gestellt, sollten eigentlich für Jedermann ausreichen und auch das Ziel sein. Zumal durch die Discovery-Funktion die Zero Hops ja auch nicht im 30min Intervall notwendig sind. Wenn da nun Jemand meint er müsse dies um etliches schneller einstellen, ist das, meiner Meinung nach, keine Messlatte an derer man sich messen sollte.
Bitte nicht persönlich nehmen. Ich komme aus einem komplett kaputt gefahrenem Meshtastic-Mesh welches sich, auch Dank solchem unnötigen Zeugs, immer mehr und mehr an die Wand gefahren hat. Zusätzlich durch die offenen Möglichkeiten von IoT Zeugs usw welches mit Meshtastic möglich ist, nutzt das jeder ganz egoistisch für seinen eigenen Kram. Aber ich kann das ja auch verstehen dass man bei einer unbewohnten Berghütte, einem stillgelegtem Camper, an einem Baum im Wald etc. unbedingt alle 30min die Temperatur, Akkuspannung oder Luftdruck erhalten muss Ironie
Dank den Meshcore Entwicklern sind wir von sowas noch bestmöglich verschont. Langfristig graben wir uns aber ein neues Meshtastic, nur mit Namen Meshcore, wenn wir alle mit Bots, unzähligen Abfragen, Adverts usw daherkommen.
Ich belasse es jetzt weiter meine Gedanken und Meinung diesbezüglich Kund zu tun. Dennoch denke ich aber, dass wir es uns allen gegenseitig schulden, dass wir dem Mesh Sorge tragen und es nicht unnötig mit vermeidbaren Dingen zukleistern sollten. Denn aktuell läuft Meshcore absolut super. Wenn das so weitergeht, bin ich langfristig nicht sicher.
Liebe Grüsse, Silvio
Lieber Silvio
Meiner Meinung nach sprichst Du ein wichtiges Thema an. Ich beobachte mit grosser Sorge die Zunahme von automatisierten Meldungen wie Pongdroid und ähnlichen Programmen die sinnlosen Datenverkehr produzieren. Die explosionsartige Zunahme des Datenverkehrs auf Meshcore seit ca. 3 Monaten ist beängstigend. Ich werde deshalb so bald wie möglich den Autoadvert meiner Repeater auf 24h setzen. Es reicht mir im Übrigen, wenn ich einmal wöchentlich die Akkuspannung kontrolliere.
mit besten Grüssen, Heinz
Ich arbeite beruflich viel mit Server-Monitoring (meist Maschinen in Rechenzentren). Dort sind Telemetrie-Daten (CPU, RAM, Temperatur, Spannung, Disk-I/O usw.) extrem wertvoll für proaktive Fehlererkennung. Aber je mehr Server man überwacht, desto unübersichtlicher wird das Datenvolumen.
Deshalb speichere ich oftmals die detaillierten Messwerte nur lokal auf dem Server und lasse nur Ausreisser/Alarme an mein Monitoring-System schicken - genau dieses Prinzip würde ich als Möglichkeit für die Überwachung von MeshCore Repeatern sehen.
Meine Ideen:
Messwerte wie Batteriespannung, Temperatur, RSSI/SNR der LoRa-Verbindungen, Uptime, Solar-Ladezustand etc. lokal loggen
NUR bei Überschreitung definierter Schwellwerte (z. B. Batt < 3.4 V, Temp > 55 °C) und NUR maximal 1x täglich (idealerweise nachts um 3–4 Uhr) eine Meldung schicken
Alle detaillierten Logs bleiben lokal gespeichert – und zwar monatelang möglich durch einen günstigen externen Speicherchip
Die vollständigen Logs können “beim Besuch” des Repeater z.B. über USB-CDC (virtueller COM-Port) exportieren werden
Wie viel Speicher ist realistisch?
Mit einem klassischen SPI/QSPI-NOR-Flash (z. B. Winbond W25Q128 = 16 MByte, kostet oft weniger als 1 Franken) kann man bei 32-64 Byte pro Eintrag locker Tausende bis Zehntausende Einträge speichern
Mit einem Eintrag pro 5-10 Minuten sind mehrere Monate History möglich
Stromverbrauch im Deep-Power-Down ist ca. 1-5 µA und sollte kein Problem sein
Das ist noch alles theoretisch und alle Angaben ohne Gewähr solange ich das nicht selber getestet habe 
Meine Frage an @HB9VQQ und an alle anderen Interessierten:
Was loggt ihr? Oder was denkt ihr macht Sinn zum loggen?
und wie oft?
Kritik oder andere Ideen dazu?
Gruss BigMike
Aktuell zieht mein Skript die gesamte Telemetrie. MIBs/OIDs, wie man sie von snmp kennt, gibt es nicht. All or nothing.
In Grafana
73
Roland
Hallo Silvio
Mir gehen die selben Gedanke durch den Kopf, welche du hier niedergeschrieben hast. Ich mache mir, ebenso wie du, Sorgen, dass auf ‘unserem’ Mesh alles und jedes gemacht wird, was technisch möglich erscheint. Jeder begründet, bereits heute, sein Tun damit, dass alles open-source sei, er das dürfe und sein Ding nur wenig Verkehr erzeuge. Wohlgemerkt, Verkehr welcher nicht allen zu Gute kommt und den es für den Betrieb des Mesh’s nicht zwingend braucht. Ein gutes Beispiel: die Pong-Bots. Dass dabei von den Betreibern dieser Geräte in Kauf genommen wird, mit dem eigenen Vorgehen, den Verkehr auf dem Netz erheblich zu beeinträchtigen, das darf so nicht sein!
Da bin ich mal gespannt wie das an einem heissen Sommertag wird
RAK WisMesh Repeater Solar Mini. Aussentemp. aktuell +6°C.
Ich glaube man sieht den Tenor in dem Thread. Es interessiert ihn nicht. Bringt also auch nichts hier an die Vernunft und Fairness zu appelieren.
Hallo Mike
Zu deiner Frage, welche Daten der Repeater für mich wichtig sind, hier meine Praxiserfahrungen:
Ich habe bei allen RAK-Repeatern einen Temperatur- und Feuchtigkeitsfühler verbaut und die Telemtrie ist für Besucher ohne Passwort erreichbar. So können Interessierte allenfalls Daten abfragen.
Ob die Repeater werkeln, kontrolliere ich etwa alle zwei Tage (sofern ich es nicht vergesse). Mehr braucht es m.E. gar nicht. Die Konstruktion (Hardware) und die Stromversorgung habe ich rubust ausgelegt.
Was ich aber mache: Etwa alle drei bis vier Monate besuche ich den Repeater. Das ist immer auch die Gelegenheit für ein Update (es ist ja immer noch alles um Meshcore herum im Fluss…).
Und ja, wenn mir die Krähen das Solarpanel anfressen, nützt auch ein Monitoring über das Mesh nichts.
Lieber Gruss
Paul
Ich muss zugeben, ich mach genau dasselbe wie du Roland:
allerdings mit dem Unterschied dass ich per Cronjob jeweils um 1:30 wenn das Mesh schläft einmal im Tag abfrage.
Dies befriedigt meine Neugier zur Genüge, erlaubt mir Verkehrstrends oder Akkus welche sich leeren zu entdecken und sollte für das Netz im verträglichen Rahmen sein.
Meine Repeater sind auch max 1, einer 2 Hops entfernt und der grosse Anteil der Pakete sind Direct und nicht Flooded.
Du hast einleitend geschrieben, du würdest eine Abfrage pro 12h tätigen. Hier sehe ich aber jeweils einen Messpunkt alle drei Stunden. Wie hast du die Zwischen-Speicherung der Daten der dreistündlichen Messung im Repeater gelöst?
Mein letzter Post hier. Zu viele Nörgler. Ich habe den Admin um Löschung meines Accounts gebeten, da ich trotz Privacy Statement kein Delete Account gefunden habe in meinem Profil.
Ich habe die Firmware um einen Ringbuffer erweitert, welches die Telemetrie sammelt. Werde ich auch noch für den RAK4631 machen
So long
Find ich schade dass du dich gleich wieder verabschiedest und hilft auch nicht.
Dass nicht alle immer einer Meinung sind liegt in der Natur der Sache und eine konstruktive Diskussion sollte immer möglich sein.
Tatsache ist das die verfügbare Bandbreite sehr beschränkt und immer mehr belegt wird.
Es fürchten sich alle, nicht ganz unbegründet, vor Meshtastic ähnlichen Zuständen in welchen vor lauter Telemetry, Position und Nodeupdates kaum noch eine vernünftige Kommunikation möglich war.
Danke für den Tip mit der Firmware-Erweiterung. Habe mich bis anhin nicht getraut, dort den Schraubenschlüssel anzulegen, aber offensichtlich funktioniert das zur Zufriedenheit.
Es geht mir nicht ums Nörgeln und ums Spass verderben. Vielmehr geht es mir darum, dass wir alle, welche es Aufbauen und Nutzen, zu MeshCore Sorge tragen. Es ist eine faszinierende Sache, aber es ist auch ein sehr fragiles Pflänzchen. Ein Pflänzchen, welches nur wachsen und gedeihen kann, wenn Gemeinnutz vor Eigennutz steht.
Spannend, wie sich dieser Thread entwickelt.
Dass nicht alle dieselben Interessen und dieselbe Sichtweise haben, liegt in der Natur des Menschen. Den hier geführten Diskussionen sollte sich aber Jedermann stellen dürfen, Flucht ist eine schwache Option.
Ich beobachte jedenfalls auch mit Sorge, wie sich die Airtime einiger Repeater nach oben verändert. In den bisher zwei Wochen des Betriebs der Transalp Repeater ist sie an diesen exponierten Standorten von ca. 3.7% auf über 4.5% angestiegen. Es kann sich um “saisonale Schwankungen” handeln, wir werden in ein paar Wochen mehr darüber wissen. Jedenfalls wären dafür nicht die wenigen “redaktionellen Beiträge” in Form direkter menschlicher Kommunikation verantwortlich, sondern die zu tausenden sichtbaren sinnbefreiten Ping-Pongs sowie unnötige automatisierte Abfragen der Repeater.
Monitoring ist in gesundem Masse sinnvoll. Die Idee, ein solches auch in Form von Traps zu realisieren, erachte ich als interessant. Dahingehende Erweiterungen der Firmware würde ich begrüssen. Dies würde eine erhebliche Reduktion von Polling-Abfragen ermöglichen und trotzdem eine genügende Datenbasis liefern.
Mein “Monitoring” erfolgt übrigens ganz altbacken mit Zettel und Bleistift. Je nach Lust und Laune frage ich die Batteriespannung und die Temperatur alle paar Tage mal ab. Dies reicht vollauf, um den Zustand der Repeater beurteilen zu können.
Sollte sich die Situation stabilisieren, dann könnten Betreiber von Repeatern die Public-Statusabfrage offen lassen. Sollte sich die Situation jedoch in beobachteter Weise weiterentwickeln, dann wäre die Abschaltung der Public-Abfrage eine erste und sehr schnell wirksame Gegenmassnahme.
Ich überlege mir auch ernsthaft Anpassungen der Firmware mit dem Ziel, Ping-Pong Traffic konsequent vom Repeating auszuschliessen. Damit könnten Betreiber von Repeatern zugunsten des Ganzen Partikularinteressen gezielt übersteuern.
Liebe Grüsse und gute Nacht
Christoph
