openhabforum.de

Hallo zusammen

Vorweg: ich fühle mich immer noch sehr frisch und unsicher in OH3.
Aktuelles Vorhaben:
Ich möchte die Betriebsstunden eines Verbraucher protokollieren. Der Verbraucher hängt an einer Tasmota Steckdose mit Verbrauchsmessung und wird zu bestimmten Zeiten über einen Timer komplett ein-/ausgeschaltet.
Der Verbraucher selbst hat eine eigene Regelung und schaltet sich je nach Temperatur ein und aus, unabhängig von OH. Also möchte ich die Betriebsstunden über den Stromverbrauch/die Leistung erfassen.
Verbrauch > 5Watt = Verbraucher läuft = Betriebsstundenzähler läuft (der tatsächliche Verbrauch ist >200 Watt, 5 Watt ist ein willkürlicher Schwellwert)
Verbrauch < 5Watt = Verbraucher steht = Betriebsstundenzähler steht
Summarische Fragestellung: wie lange läuft der Verbraucher in den vom Timer definierten "ein" Phasen tatsächlich.

Die erste Voraussetzung ist ja wohl eine Datenbank. Wenn ich es richtig verstanden habe, ist rrd4j bei OH3 schon dabei. Allerdings werden wegen des fixierten Speicherplatzkontingents alte Werte anscheinend gelöscht oder zu Durchschnittswerten zusammengefasst. Das wäre mir hier nicht sehr recht. Ich will mindestens ein Jahr besser mehrere Jahre Daten sammeln können, ohne über einen "Datenverlust" nachdenken zu müssen.

Mein System läuft auf einem Raspi3B und zZ noch auf einem 32GB USB Stick als Systemlaufwerk. Eigentlich will ich mittelfristig alles auf eine 256GB SSD kopieren (klappt noch nicht mit dem Booten, aber anderes Thema!). Platz wäre also grundsätzlich vorhanden.

Welche Datenbank wäre zu empfehlen. Ich habe so gar keinen Überblick zu Vor- und Nachteilen der unterschiedlichen Möglichkeiten.
Ich würde mich über ein wenig Beratung dazu freuen.

Gruß
Thomas

Warum nutzt Du einen USB-Stick? Das ist nicht sinnvoll. Sinnvoll ist es hingegen, eine SD-Karte zum Booten zu verwenden, aber das root-Verzeichnis auf eine SSD zu verschieben. Der Raspberry Pi 3B ist schon lange in der Lage, von SSD zu booten, das sollte ohne Probleme funktionieren. Die SD-Karte ist aber nicht schlechter (zumindest beim Pi 3B), weil die SSD ja höchstens etwas mehr als 30MByte/s macht - wegen USB2. Eine gute SD-Karte hält da mit. Der einzige gute Grund (ein sehr guter Grund!) für die SSD im Zusammenhang mit dem Pi 3B ist das bessere Wear Out der SSD.

Als Persistence kommt eigentlich nur jdbc in Frage. Ich selbst nutze dazu MariaDB, letztlich ist das aber Geschmacksache und eine Frage, welche Leistung man braucht. Ich habe halt Erfahrung mit MariaDB

Da Du die Einschaltdauer haben willst, ist es sinnvoll, den Momentanverbrauch nicht als Zahl, sondern als Switch zu speichern. In der Datenbank landen dann nur die Einschalt- und Ausschaltzeitpunkte. Leider ist es in openHAB nicht vorgesehen, mehrere solcher Zeitpunkte aus einer Datenbank systematisch zu extrahieren. Du kannst aber beim "Ausschalten" des Thermostaten den Zeitpunkt vom letzten Einschalten abfragen und daraus die Zeitspanne bestimmen - Diese Zeit wiederum kannst Du ebenfalls in der Datenbank abspeichern, diesmal als Zahl. Damit kannst Du dann per sumSince() die Summe aller Einschaltzeitspannen seit Zeitpunkt x auslesen. Man muss nur aufpassen, dass Daten nicht doppelt geschrieben werden...

Die Auswertung der daten kannst Du natürlich auch mit externen SQL Analyse Tools vornehmen, das ist oft sinnvoller, als die Auswertung mit hohem Aufwand in openHAB zu programmieren.

Moin

Das Wear out ist genau der Grund warum ich eine SSD nutzen will. Obwohl ich das lauffähige Image vom Stick auf die SSD geclont habe, bootet der Raspi nicht. Vom USB Stick schon. Ich halte den USB Stick für haltbarer bzgl. Wearout als eine SD Karte. Im Moment ist das eh nur die Übergangslösung bis zur SSD. Das soll hier aber nicht das Thema sein Dennoch danke.

Ich glaube mir fehlt noch weitere Infos...
In OH3 kann ich ja jetzt schon, im original Installationszustand, gewesene Werte sehen. Das Item für die Leistungsmessung zeigt mir den Graphen im Zeitlichen Verlauf an. Wo/wie speichert OH denn diese Daten? Eine Datenbank habe ich ja noch nicht installiert!? Wo wäre mit Datenbank (=Persitance!?) der Unterschied/Vorteil?
jdbc ist "lediglich" die Schnittstelle zwischen OH und einer Datenbank. Richtig?
Für die Datenbank selbst könnte man unter mehreren Produkten wählen.zB MariaDB, MySQL,... Richtig?

Zwischenzeitlich habe ich gelesen, dass Tasmota an dieser Stelle wohl auch was bieten könnte. Über eine Rule in Tasmota könnte es möglich sein beim überschreiten eins threshold ein MQTT Topic abzusetzen. (vgl.: https://tasmota.github.io/docs/Commands ... monitoring). Mir schwebt da sowas wie ein individuelles tele/STAT/hasLOAD vor, welches auch on/off übermittelt. Das hätte vielleicht den Vorteil den OH-Raspi von irgendwelchen periodischen Aufgaben zu entlasten.
Da muss ich mich erst noch weiter einlesen.

Bzgl. einer ersten Auswertung der geloggten Daten wäre es natürlich schön, wenn das OH selbst könnte. zB Betriebsstunden pro Tag/Woche etc.
Betriebsstunden und Temperaturverlauf von Sensroen in einem Graphen und sowas.
Tiefere Analysen könnten dann schon extern laufen.

Gruß
Thomas

Hallo

Ich habe weiter recherchiert.
Mit folgender rule in Tasmota frage ich nun den Betriebszustand des Verbrauchers an der Stekckdose ab.
In die Tasmotakonsole eingeben: bei mehr bzw. weniger als 10 Watt Verbrauch wird ein Topic BETRIEB=1 oder BETRIEB=0 abgesetzt.
rule1 5 bewirkt, dass das Topic nur einmalig bei über-/unterschreiten der 10 Watt gesendet wird. Ansonsten würde es ständig feuern.
In OH nun einen Chanel am Thing eingerichtet: KG2/stat/BETRIEB.
Dann noch ein Item verlinkt. Jetzt habe ich schonmal aus dem Verbrauch/der Leistung ein Rechtecksignal gemacht

Freue mich gerade über den kleinen Erfolg

Gruß
Thomas

Bubbleman hat geschrieben: ↑24. Jan 2021 11:08Ich halte den USB Stick für haltbarer bzgl. Wearout als eine SD Karte.

Wenn Du nicht gerade einen sehr speziellen USB-Stick nimmst (nämlich einen, der einen SSD-Controller für den Speicher hat - die sind sauteuer) dann ist der USB-Stick auch nicht ein klitzekleines Stückchen besser bezüglich des Wearout. Wie gesagt, man kann wunderbar von SD-Karte booten und das System anschließend vom externen Speicher nutzen.

Bubbleman hat geschrieben: ↑24. Jan 2021 11:08 In OH3 kann ich ja jetzt schon, im original Installationszustand, gewesene Werte sehen. Das Item für die Leistungsmessung zeigt mir den Graphen im Zeitlichen Verlauf an. Wo/wie speichert OH denn diese Daten? Eine Datenbank habe ich ja noch nicht installiert!?

openHAB3 nutzt dafür rrd4j. Measurements werden automatisch gesichert. Aber rrd4j speichert die Daten eben (wie Du schon selbst erkannt hast) nicht verlustfrei, und schon gar nicht für mehrere Jahre.

Bubbleman hat geschrieben: ↑24. Jan 2021 11:08 Wo wäre mit Datenbank (=Persitance!?) der Unterschied/Vorteil?

Persistence (drei e, kein a) kommt von persist -> bestehen, andauern und bedeutet in der Hausautomation das Speichern von Daten allgemein, in welcher Form auch immer (keine Erfindung von openHAB, der Gira HomeServer z.B. nutzt "persistente Daten"). Dabei ist es egal, was als Backend genutzt wird. In openHAB3 stehen derzeit 13 verschiedene Persistence Services zur Verfügung, MapDB speichert exakt den letzten (also den aktuellen!) Wert, rrd4j speichert die Daten in einer fixen (im Sinne von gleichbleibende Größe) Datei, um den Preis sinkender Genauigkeit bei länger zurückliegenden Daten und einer harten Grenze die gewöhnlich ein Jahr in der Vergangenheit liegt. Ältere Daten werden gelöscht.
InfluxDB ist auf Zeitserien spezialisiert und spielt vor allem in Verbindung mit Grafana eine Rolle - man möchte ja die Daten auch sinnvoll verwenden. InfluxDB ist eine SQL-Datenbank, so wie alle anderen Datenbanken, die von openHAB mit jdbc angesprochen werden (JavaDataBaseConnector oder so ähnlich). DynamoDB, MongoDB und JPA sind ebenfalls Datenbanken, da ich sie nicht nutze, kann ich weiter nichts dazu sagen.

Bubbleman hat geschrieben: ↑24. Jan 2021 11:08jdbc ist "lediglich" die Schnittstelle zwischen OH und einer Datenbank. Richtig?
Für die Datenbank selbst könnte man unter mehreren Produkten wählen.zB MariaDB, MySQL,... Richtig?

Genau.