J.R.I.B. hat geschrieben: ↑Fr 14. Jul 2017, 18:31
Nichts gegen Liquid. Oder gegen RRD.
Es ist nur deutlich komplexer (liquid -> RRD Tool custom database format, script -> Data poll using custom SNMProtocol) als direkt Dateien auf einen Server via FTP|SCP hochzuladen und dann GNUPlot oder Octave zur ASCII (oder graphischen) Visualisierung zu verwenden (sogar ohne Database moeglich) oder ein x beliebiges JavaScript render framework in nem Browser. Oder Python mit NumPy und SciPy und GNUPlot subprocess.
Naja, ich seh das halt hauptsächlich als Home-Anwendung, d.h., ich hab ein oder mehrere SolarBoxen und will die zentral monitoren, am besten auf nem Raspi3. Das brauche ich sowieso, weil ich soone wichtige Anwendung niemals irgendwo ins Internet auslagern würde. Zu unreliable.
Und in dem Fall kann der Raspi natürlich auch gleich die Datenaufbereitung managen und die Bilder im lokalen Netz zur Verfügung stellen, das kostet kaum CPU-Kapazität und Netzbandbreite. Und das hochladen der Bilder auf nen externen Internet Server hab ich nur als schnellen Workaround für Demozwecke gemacht. Falls die Diagramme unbedingt vom Internet aus zugreifbar sein sollten könnte man ansonsten aber auch genausogut einfach eine Port-Weiterleitung auf den Raspi in der lokalen Fritzbox-Firewall einrichten.
So etwas wie Round robin geht auch in MySQL via 'DELETE FROM sensor_data WHERE time_created > 90days;'. Ein fester Zeitraum klingt auch intuitiver als so und so viele verbrauchte Slots in einer Round Robin Database. Und es geht auch in einfachen text data files indem man die Zeilen zaehlt und die ersten X loescht. Tada Round Robin. Kein extra tool, scripting language und spezielle Datenbank notwendig.
Ja, das mit der Text-Datei gefällt mir besser, weil dadurch auch gleich das Shifting miterledigt wird. Mit MySQL wärs glaubich etwas umständlich, weil der normale update-Zyklus statt 90 Tagen eher 1 oder 2 Min beträgt. Das rrdtool hingegen wird seit Jahren genau auf diesen speziellen Zeck hin entwickelt und ist dafür optimiert.
Die von RRDTool erzeugten Bilder brauchen bei Uebermittlung auch viel mehr Bandbreite als Text (insbesondere Zahlen).
Also, bei grad mal 30 kB pro Bild wäre das bei 5Mbit upstream Bandbreite (oder selbst bei weniger) nicht wirklich ein Problem
und wie gesagt besteht ja auch noch die Möglichkeit der port-Freigabe. Wenn mans denn wirklich auch im Internet bräuchte, was bei mir eigentlich eh nicht der Fall ist, ausser ich will jemandem die Anwendung demonstrieren.
Was ich eher als Nachteil beim rrdtool sehe, ist das es ein ziemliches Biest ist beim konfigurieren (oder ändern) der Diagramme und Time-Slots - nicht gerade sehr intuitiv; ich durchblicke das auch bis heute noch nicht wirklich sondern fummle immer so lange daran rum bis alles passt
und weil ichs schon seit Jahren nutze hab ich da inzwischen ne gewisse Übung drin. Aber für nen User, der sich das eh als fertige Anwendung runterlädt würde dies Problem entfallen .
Was man auch konzidieren muss, das ist eine gewisse Langsamkeit. Das speichern der Daten in die DB und das anschliessende erzeugen der Diagramme braucht halt einige Sekunden, bzw. ich rechne immer pauschal ne Minute pro Update-Zyklus, um auf der sicheren Seite zu sein. Für jede Art von Solar-Anwendung ist das mehr als ausreichend aber für andere Anwendungen sollte man dies im Hinterkopf haben.
Langfristig schwebt mir mit dem Liquid aber noch was anderes vor, was auch schnellere Update-Zyklen mit einschliesst . Ich strebe da langfristig eine deutlich schnellere und komnplexere Grafik an so das es für ein umfassendes Monitoring aller möglichen (also nicht nur Solar) home-automation Prozesse universell geeignet ist. Das sollte dann ungefähr so aussehen, wie in diesem LCARS-Demo (min 1:36):
https://www.youtube.com/watch?v=N24MKsJjlFI und nur gelegentlich interaktiv bedient werden -- die meiste Zeit würde das wie eine Art Bildschirmschoner vor sich hinlaufen und periodisch durch alle Anzeige-Displays switchen. Als Plattform um das zu programmieren scheint mir "processing" ideal geeignet zu sein.
Ich hab das Demo übrigens auf der MakerFaire auf meinem DIY-Laptop immer am laufen gehabt und bin da von mehreren Leuten drauf angesprochen worden, die sofort mitmachen würden, wenn da jemals ein konkretes Projekt draus würde.
Und was wenn in Zukunft das Internet gefaehrdet ist (z.B. Abschaffung net neutrality oder ein elektronischer Krieg)? Historisch betrachtet ist das gar nicht mehr so unwahrscheinlich in Europa.
Verwendet man so ein einfaches text basiertes System, dann kann man auch noch ohne Mbit oder Gbit Internet auf die Daten zugreifen - z.B. mittels ZigBee oder irgendeinem anderen Protokoll. Die Reichweite von XBee geht bis zu 30 Km.
Ja, also wie gesagt, bei 30kb pro Bild würde selbst das noch gehen, aber Du hast schon recht damit das Orientierung in Richtung textbasiert und schmale Bandbreite eine gute Sache ist. Ich diskutiere da oft mit paar alten Freunden drüber, wie man einen schmalbandigen und dafür dezentralen (gehört niemandem !!!) physikalischen Backbone für eine alternative Internetstruktur einrichten könnte, wobei noch nicht ganz klar ist, auf welcher Grundlage. Freifunk wäre eine Möglichkeit, oder besonders interessant finde ich auch sowas wie TheThingsNetwork/LoRaWan (bis zu 38kBs, aber auch bis zu 15 Km Reichweite). Das man mit Zigbee auch so große Reichweiten erreichen kann wusste ich bis lang noch nicht aber das wäre dann noch so ein Kandidat
https://weblogs.asp.net/mschwarz/how-to ... 68-modules
Wenn wir uns schon die Muehe machen, freie Systeme zu entwickeln. Dann sollten sie auch krisenhart und leicht pflegbar sein. Also minimalistisch. z.B. bei Abschaffung Netz Neutralitaet - was wenn dein ISP ploetzlich Verbindungen von diesen freien Netzwerkknoten nur noch ganz wenig Bandbreite gibt ausser man bezahlt ewig viel?
Ja, genau, das ist einer der Gründe, warum wir über sowas nachdenken. Die anderen beiden Gründe wären:
- ein Crash-szenario
- dieser ganze Überwachungs-Scheiss nimmt langsam unerträgliche Formen an: das neue Fake-News-Gesetz (=Zensur), das neue Staatstrojaner-Gesetz, und das größte Übel von allen: Android.
Gruss, Oliver
