Forum - Open Source Ecology Germany

Hi.

Da das Trello eher für Tracking-Zwecke gedacht ist hab ich die nachfolgende Diskussion mal nach hier ausgelagert.

Martin schrieb im COSH-Trelloboard:

Habe mal mit dem bestehenden System im Fablab ein bisschen rumgespielt. OpenEnergyMonitor ist ziemlich einfach einzurichten:
https://emoncms.org/dashboard/view?id=41772

Dort passiert leider im Moment nicht viel, da die Batterie voll ist und keine Last dran hängt

Das läuft jetzt über einen ESP8266 und Übertragung im Fablab-WLAN. In unserem Fall könnte man die Daten auf einem Raspberry Pi speichern (also dort das emoncms aufsetzen).

Ihr könnt ja mal gucken, wie flexibel OpenEnergyMonitor an unsere Bedürfnisse anpassbar ist. Mit dem von Oliver vorgeschlagenen Liquid-System ist man wahrscheinlich flexibler, allerdings ist EMon ggf. einfacher einzurichten... vielleicht ein Mix aus beidem?

Hab das Emoncms jetzt auf dem RaspberryPi am laufen und dazu das fertige sd-card-Image von denen verwendet.

Jetzt will ich dazu noch das Liquid installieren; voraussichtlich dürften beide reibungslos parallel nebeneinander auf dem Raspi laufen, womit die Voraussetzung für einen Mix grundsätzlich gegeben sind, oder aber sie sich einfach komplementär ergänzen können.

Es liegen hier zwei unterschiedliche Grundparadigmen zugrunde: Beim Emoncms werden die Daten vom Sensor zum Server "gepushed" und in einer MySQL-DB abgelegt. Das wäre zB. für internetweite (WAN) Datenübertragung ganz interessant, wo vielleicht auch für eine große Anzahl von Nutzern (die somit keinen eigenen Raspi betreiben brauchen) ein Service a la Thingspeak bereitgestellt werden soll.

Beim Liquid holt der Server die Daten von den Sensoren gezielt via "get" ab und legt sie in einer Ringpuffer-DB ab. Ich sehe den Haupteinsatzbereich eher im lokalen Hausnetzwerk (LAN) , wo der Server das zentrale Monitoring und damit die Überwachung aller im Haus befindlichen Sensoren ermöglicht.

Grundsätzlich können aber beide beides, d.h. das Emoncms kann auch lokal eingesetzt werden und die Daten vom Liquid natürlich auch im Internet bereitgestellt werden, siehe zB. http://makeable.de/blog/transfer/lsbms.html und http://makeable.de/blog/transfer/balancer.html (ist momentan nicht aktiv und zeigt grad nur "kaputte" Daten, aber man kann schonmal das Interface sehen).

Das Emoncms ist ziemlich mächtig, wird schon seit Jahren von einer Community entwickelt und bietet von daher sehr viele schöne Möglichkeiten und ausgereifte Features. Erfordert aber auch umfangreiche Einarbeitung.

Beim Liquid ist manches noch rudimentär und weniger weit/universell angelegt, aber es wurde halt speziell auf das BMS ausgerichtet entwickelt und ist sehr schlank und gut überschaubar. Zur Installation muss eigentlich nur das Github-Repository geclont werden.

Alles in allem gute Voraussetzungen, sich aus beidem das Beste rauszusuchen und zu verbinden.


Gruss, Oliver

Hi,

bin gerade dabei das liquid parallel zu installieren. Dazu ein paar erste Anmerkungen:


1. Das Emoncms operiert auf einer schreibgeschützten Partition. Mit dem Befehl

sudo rpi-rw

kann man die Partition wieder schreibfähig machen, wasnotwendig ist, um zB. per apt-get weitere Software installieren zu können.



2. Um benötigte Zusatzsoftware zu installieren, sollte anstatt dem Befehl

sudo apt-get install rrdtool tr bc cu lighttpd

stattdessen

sudo apt-get install rrdtool bc cu

verwendet werden. Der tr ist Bestandteil von coreutils, was auf dem Emoncms schon mit drauf ist, ebenso wie apache2, weshalb der Lighttpd auch nicht benötigt wird.



(... t.b.c.)

So, hat geklappt, ich hab jetzt beide auf nem Raspberry Pi nebeneinander am laufen.


Das Raspian vom Emoncms ist ziemlich "verbaut" bzw. speziell eingerichtet, es wäre daher schöner auf einem komplett jungfräulichen und aktuellen Raspian als Platform aufzusetzen, dazu müsste das Emnocms aber manuell installiert werden, was auch i.d. Doku beschrieben ist, aber es ist wohl auch nicht so ganz unaufwendig.



Aber wieauchimmer, letztlich wird es ohnehin darauf hinauslaufen, die ganze Visualisierung modular zugestalten und in abstrakt beschriebene Teilaufgaben zu unterteilen, beispielsweise

- Sensordatenübertragung
- DB-Speicherung
- Erstellung von Grafiken/Diagrammen
- ergonomische Darstellung und Benutzerführung/Navigation

Die Datenweitergabe zwischen den einzelnen Modulen erfolgt anhand klar definierter Schnittstellen, damit sollte es auch prinzipiell möglich sein, für die jeweiligen Aufgaben Module aus verschiedenen Systemen zu verwenden oder auch komplett neue Module zu entwickeln.

Als erstes wird eine Auflistung benötigt, welche Sensordaten überhaupt transportiert werden, also zB. Zellspannungen (die können beim BMS auf max. 15 limitiert sein), Solar-Ampere (einkommend), Verbraucher-Ampere (ausgehend) und wo ggflls. daraus resultierende Ableitungen wie etwa die Umrechnung in Watt (im Sensor ==> mehr Datenübertragungsvolumen, darum lieber im Host) oder Akkumulationen wie zB. der Tages- od. Jahresertrag erfolgen sollen .

Im weiteren kommt dann noch die Aufbereitung der Zeitreihen mit hinzu, also etwa: welche Zeiträume bekommt der User angezeigt und wie kann er zwischen verschiedenen Zeiträumen navigieren. Dabei gibts schon größere Spielräume, aber letztlich wird die Gestaltung hier durch bereits gesammelte Erfahrungen mit dieser Art von Anwendung geprägt und kann andererseits auch durch User-Konfigurierbarkeit optimiert werden.


Ein weitere Aspekt könnte (im Falle einer bidirektionalen Kommunikation) noch die Visualisierung (bzw. das Interfacing) von Steuerbefehlen sein, aber das ist zunächst nicht zwingend erforderlich, da ein gut eingerichtetes System eigentlich automatisch funktionieren und nicht auf manuelle Usereingaben angewisen sein sollte. Es könnte aber bei zunehmender Komplexität, etwa im Zusammenhang mit dem OpenNanoGrid, hilfreich sein, z.B. die Bus-Kommunikation zu visualisieren oder auch zu interfacen und ebenso generell für Development- und Entwicklungszwecke (debugging, testen).


Im übrigen ist zuberücksichtigen, das es verschiedene Arten von userinterfaces gibt, z.B. das Direct-Userinterface, welches sich direkt am Gerät befindet und auch Eingaben über Tasten erlaubt aber vielleicht mit einem eher minimalistischen Display ausgestattet ist (was Ergonomie umso wichtiger macht). Oder eben dem "großen" Visualisierungs-System wie Emoncms oder Liquid, welches (sofern es nicht als App auf dem Smartphone läuft) ein großes und hochaufgelöstest Display optimal nutzen sollte um seine Haupt-Zielvorgabe zu erfüllen: Der User sollte möglichst auf einen Blick alle relevanten Information über den Zustand des Systems erfassen können. Und dann je nach Bedarf in einzelne Aspekte davon stärker "reinzoomen" können und das möglichst "reibungslos/fliessend".


So, ich hoffe damit schonmal insgesamt den groben Rahmen abgesteckt zu haben

Gruss, Oliver

Hey, macht euch ueber die verschiedenen Formate keine Sorgen.
Das Ausblenden von Inhalten fuer mobile Endgeraete ist _nicht_ mehr der Trend! (wird sogar von Google search bots "bestraft")
Stattdessen simplicity:
* 1 einiziges formatfuellendes Design.
* Umbruch von horizontal angeordneten Elementen auf neue Zeile bei Bedarf automatisch mittels CSS. (=> dynamischer Uebergang von Querformat auf Hochformat)

Skalierbar sozusagen.
Vor allem Nischenprodukte wie wir sollten den oft unnoetigen Perfektions-Hype fuer verschiedene Formate meiden. Wir sind keine grosse Firma sondern nur ein paar kleine Lichter.

EmonCMS klingt von deinen Ausfuehrungen her modularer:
* Sensor push
* Server database
* webapp reads database (und wo website, da reicht ein Shortcut auf diese Seite auf dem Android homescreen!! keine extra "App" noetig)

Sensor push ist deswegen gut, weil es entkoppelt:
* Jeder Sensor Knoten mit Netzwerk Zugang kann z.B. mittels SSH oder FTP Daten auf jeden x-beliebigen zugaenglichen Server uploaden.
* Dann braucht man nur noch ein Programm (service), welches die Daten fuer die Webapp in die Datenbank sammelt.
Also ist jeder x beliebige Sensor und Microcontroller kompatibel. Egal ob RPI, BBB oder Jetson oder Arduino sensor nodes oder sonstwas.

Sage ich deswegen, weil mich natuerlich auch LibreSolar interessiert. Und LibreSolar verwendet ST Microcontrollers. Sehe ich also so wie du, das ganze in Teilprobleme zu entkoppeln. (Und wie es scheint, hat jedes Teilproblem bereits eine Loesung oder fehlt da noch was? Obwohl, man sieht hier, dass noch kein Upload der BMS-Daten stattfindet?)

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.

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.

Die von RRDTool erzeugten Bilder brauchen bei Uebermittlung auch viel mehr Bandbreite als Text (insbesondere Zahlen).

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.

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?

J.R.I.B. hat geschrieben: ↑

Fr 14. Jul 2017, 14:56

Hey, macht euch ueber die verschiedenen Formate keine Sorgen.
Das Ausblenden von Inhalten fuer mobile Endgeraete ist _nicht_ mehr der Trend!

Ja, seh ich auch so, die einzige App die man auf dem Smartphone dafür braucht ist ein WebBrowser. Und in den meisten Fällen wird mans wahrscheinlich sowieso von zu Hause aus benutzen, d.h. man hat eh den Desktop-PC mit nem großen Screen verfügbar.

EmonCMS klingt von deinen Ausfuehrungen her modularer:
* Sensor push
* Server database
* webapp reads database (und wo website, da reicht ein Shortcut auf diese Seite auf dem Android homescreen!! keine extra "App" noetig)

Ja, in gewisser Weise ist es modularer bzw. das Liquid demgegenüber bislang noch recht eng auf die Anwendung zugeschnitten . Aber letzteres sehe ich für mich eigentlich noch eher als Vorteil: Das Liquid besteht bislang nur aus ein paar Zeilen Sourcecode, ist also sehr gut überschaubar und somit ganz easy erweiterbar. Es kann eng auf den Anwendungszweck zugeschnitten werden und bliebe dann auch weiterhin absolut schlank.

Das EmonCMS hingegen ist ein Riesen-Monster, zwar modular und für vielfältige Zwecke einsetzbar, aber nen Großteil davon braucht man hier eigentlich gar nicht und hat dafür aber andererseits dann einige Wochen Einarbeitungszeit am Bein (zumindest wenn man da aktiv dran entwickeln will). Für meinen Geschmack viel zu viel Overhead, aber es wurde halt von anderen aus der Gruppe favorisiert, insofern muss ich mich damit wohl oder übel arrangieren. Das wäre etwas erträglicher, wenn das EmonCMS nicht mit so einem stark customisierten Raspian daherkäme, ein Standard-Raspian wäre m.E. hier wesentlich besser gewesen.

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

Immerhin für Android gibt's eine Loesung: Projekt Halium. Insbesondere ArchLinux auf 'nem Mobiltelefon. hehe. Wird 'ne Hammer Zukunft für die freie Welt. Aber das Glück trifft leider nur wenige. Die Realitaet sieht so aus, dass mal wieder alle paar Jahre die Platine ausgetauscht wird - sei es Hackschnitzelheizung - oder man Industrie-Biegemaschinen wegschmeissen muss, weil alle Platinen kaputt und keine ausreichen Plaene und Programmcodes.

Oder dass Traktoren abbrennen - oder Autos einfach stehen bleiben. Elektronik ist kompliziert und empfindlich. Freie Technik liefert immerhin detaillierte Plaene und zumindest binary code.

Neulich beim Energie sparen als ich mal wieder die Mehrfachsteckdose ausknipsen wollte, ist mir der Schalter hin- und hergesprungen - hat sowohl Bildschirm als auch Maus zerschossen. Maus konnte ich retten, aber der Bildschirm war es mir nach der dritten Reparatur nicht mehr wert (hatte schon grüne Streifen wg. control Platine).

Ich kann deine Beweggründe jetzt besser nachvollziehen. Wenn die Bilder so klein sind, dann geht's ja.

Persoenlich denke ich wie bereits erwaehnt, dass man Software text-basiert wann immer moeglich|ausreichend (selbe Funktionalitaet) und vor allem aus Paketmanagern installieren sollte.
Alles andere führt über kurz oder lang zu Chaos (und ist m.E. nicht einfach genug zu reproduzieren! Zeit vs. Nutzen für install, config, update, compile, ...) -- ausser 0install wird mehr angenommen, das waere die _dezentrale_ Paketmanager-Loesung, die leider zu wenige Entwickler verwenden. (mich eingeschlossen, denn worlddevelopment Programme sind auch eher nur auf Github, wenn überhaupt. OK bis auf freecad_convert. Das ist das einzige, das ich dezentral über 0install anbiete)

Das Ziel waere ein Software Stack für Realtime (ARM) - der entweder komplett via 0install oder für alle einzelnen Paketmanager (Riesenaufgabe!) verfügbar ist. Wie bei freecad_convert demonstriert, ist es kein Problem, wenn - oder zumindest moeglich, dass jedes Projekt auf Github zusaetzlich ein Feed für 0install anbietet. (Der workflow ist jedoch derzeit nicht trivial genug, als dass ich dir einen Release empfehlen würde. Die `local.xml` Dateien sind jedoch locker machbar, v.a. für Code. Für Hardware ist eine modded 0install Version noetig. Nur ich komm halt auch nicht ganz hinterher^^, bzw. man muss Prioritaeten setzen und wenn das worlddevelopment intern einigermassen funktioniert, dann muss ich ja schon froh sein.)

Das sollte spaeter alles super easy laufen wie das worlddevelopment bin.configuration repository, das immer wieder zum selben Ergebnis führt, naemlich einer minimalistischen graphischen Oberflaeche, sowohl zum Entwickeln als auch für Notfaelle auf Realtime Systemen (RPi, BBB, Jetson) die sonst nur text basiert laufen (sollten).

Darunter würde auch dein Liquid fallen. Wie auch machinekit. Aber das ist Zukunftsmusik. Wir sind eh an unseren Grenzen mit den 1000 Projekten die wir schon haben. Wir sind ja nur ein verwegener Haufen Generalisten. haha