Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

DS_Starter · 10 November 2020, 23:01:26

Hallo Christian,

ZitatWas soll ich denn morgen für Attribute für den letzten Sync setzen, damit die Nacht noch dazu kommt? Mir fehlt momentan die Konzentration ein wenig.

Da du einen PK gesetzt hast, brauchst du dir nicht so viel Gedanken über eine Time-Überschneidung zu machen.
Du stellst den timeDiffToNow auf das Anfang des ersten Synclaufs, d.h. die Zeit als du den ersten Lauf gestartet hast, z.B. heute früh um 8:00 oder so. Kannst auch einen Tag zurück gehen zur Sicherheit.
Dann läuft alles rein was noch dazu kam. Der PK schützt vor doppelten DS.

ZitatUnd wie wäre der Weg zur Umschaltung auf die neue DB dann am einfachsten.

Kommt darauf an, wie du mit DbLog arbeitest. Am einfachsten übernimmst du den Regex im DEF des alten DbLog und loggst erstmal parallel.
Dann stellst du nach und nach deine SVG, DbRep etc. um. Das neue DbLog hat ja einen neuen Namen.
Während dessen kannst du beide parallel laufen lassen.
Wenn du fertig bist stellst du das alte DbLog auf disable und irgendwann wirfst du alles Alte weg.

ODER

Nach dem Sync stellst du beide DbLog auf disable. Benennst das alte um und benennst das neue DbLog in den alten Namen um. Danach das neue DbLog wieder enablen.
Dadurch gehen ein paar Events verloren, aber du brauchst dir nicht die Arbeit zu machen alle SVG etc. anzupassen.
So würde ich es wohl machen wenn viele Auswertungen existieren.

Grüße.
Heiko

ch.eick · 10 November 2020, 23:03:58

Oh, Du bist noch wach.
Ich habe gerade im alten post noch eine Merkwürdigkeit nachgetragen.

Okay, in Deiner Antwort steht auch schon die Erklärung, warum es bei mir doppelt logged.

Danke und gute Nacht

DS_Starter · 10 November 2020, 23:08:01

ZitatOh, Du bist noch wach.

Aber gleich nicht mehr

ZitatKann das sein, dass das Logging parallel in beide Datenbanken geht?

Ja klar. Ich habe auf meinem Testsystem vllt. 6 parallele DB's ... MySQL, SQLite und Postgre um die Ergebnisse vergleichen zu können bei der Entwicklung.

Ein Dblog Device ist ja defacto auch nur ein notify mit angehängter Datenbank

Gute Nacht...

DS_Starter · 11 November 2020, 22:48:24

Die neue Version mit dem Feature der Berechnung eine Grünlandtemperatursumme ist finalisiert und eingecheckt. Morgen früh wie üblich im Update.
Ich habe noch ein Reading "reachedGTSthreshold" implemntiert welches das Datum des erstmaligen Erreichens des Schwellwertes 200 enthält. Auch darauf kann man dann gut über ein Event reagieren.

Ein paar kleine Bugfixes sind auch enthalten.

Grüße,
Heiko

DS_Starter · 15 November 2020, 09:35:19

Hallo Christian,

in meinem contrib liegt die Version 8.42.0.
Dort gibt es nun die Möglichkeit next_day_begin und next_day_end zu spezifizieren.

Mal für mein Verständnis.... wozu braucht man die Auswertung der DB für den kommenden Tag. Dafür gibt es i.A. noch keine Werte in der DB oder fügst du sie mit irgendeiner Routine vorher ein ?

Grüße,
Heiko

ch.eick · 15 November 2020, 10:44:11

Zitat von: DS_Starter am 15 November 2020, 09:35:19
in meinem contrib liegt die Version 8.42.0.
Dort gibt es nun die Möglichkeit next_day_begin und next_day_end zu spezifizieren.

Mal für mein Verständnis.... wozu braucht man die Auswertung der DB für den kommenden Tag. Dafür gibt es i.A. noch keine Werte in der DB oder fügst du sie mit irgendeiner Routine vorher ein ?

Hallo Heiko,
ich bin doch meiner Zeit voraus

Bei der PV_Anlage Implementierung für den Kostal Plenticore Plus ist auch ein Forecast implementiert. Hierbei wird die Wetterprognose mit Sonnenstrahlung, Wolken und Regen in Stundenwerte für die zu erwartende Leistung berechnet. Der Forecast fc_0 ist der aktuelle Tag und wird auch mit diesem Datum in die Datenbank geschrieben. fc_1 ist der Forecast für den nächsten Tag, der dann auch vordatiert auf den nächsten Tag in die Datenbank geschrieben wird. Hierdurch bekomme ich dann im Diagramm zu einem bestimmten Tag die Daten, die am vortag geschrieben wurden und die vom aktuellen Tag gleichzeitig angezeigt.

Ein request, der an mich gestellt wurde war die Summe der Tagesleistung von morgen zu berechnen

, um daraufhin eine Entscheidung zu treffen, ob ein Verbraucher jetzt gestartet werden kann oder ob es besser wäre bis morgen zu warten.

Und da ich dafür gerne DbRep verwende und rechnen lasse, habe ich diesen Wunsch geäußert.

Gruß
Christian

DS_Starter · 15 November 2020, 10:51:33

Danke für die Erläuterung. Habs verstanden.

Vielleicht kann ich sowas auch für das Modul SMAPortal implementieren, da dieses Modul ebenfalls bei entsprechender Parametrisierung Prognosedaten liefert. Hat aber noch niemend diesen Wunsch geäußert es loggen zu wollen.

Na dann teste mal

... Bei mir sieht es gut aus und wenn nichts gegenteiliges zurück kommt checke ich die Version heute Abend ein und du/deine Moduluser haben die Version dann ab morgen früh im Update.

LG,
Heiko

ch.eick · 15 November 2020, 11:36:04

Zitat von: DS_Starter am 15 November 2020, 10:51:33
Danke für die Erläuterung. Habs verstanden.
Vielleicht kann ich sowas auch für das Modul SMAPortal implementieren, da dieses Modul ebenfalls bei entsprechender Parametrisierung Prognosedaten liefert. Hat aber noch niemand diesen Wunsch geäußert es loggen zu wollen.

Beim SMA hatte ich auch mal gespickt

Plenticore hat eine WR Interne Prognose, die jedoch manchmal daneben liegt, wenn es von gutem zu schlechten Wetter übergeht.
Dank KölnSolar habe ich dann mit der eigenen Berechnung begonnen und das passt echt gut

Der Bedarf entsteht nur, wenn Du auch Verbraucher hast, die man schieben kann. Also schiebe ich die erlaubte Pool Startzeit zwischen einer Sommer und einer Winterzeit hin und her, jenachdem wie die Prognose aussieht. Wird das Wetter schlechter startet der Pool eher und ist dann auf Temperatur, wenn er verwendet wird.
Du findest es ja im Wiki.

ch.eick · 15 November 2020, 15:21:53

Hallo Heiko,
das next_day[begin|end] hat funktioniert. Vielen Dank

DS_Starter · 15 November 2020, 16:55:59

Ist eingecheckt.

frober · 15 November 2020, 19:26:12

Hi,

ich habe einen kleinen Fehler im Wiki entdeckt:

Beim Anlegen der Sync-Datenbank fehlt bei

Zitat
1. Anlegen der DB und Tabellen
wie in diesem Link hinterlegt, erfolgt die Erstellung mit den Befehlen für MySQL:
...
ALTER TABLE `fhemtest`.`history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
...

die Angabe der Tabelle.

Könnte das bitte jemand korrigieren, bevor sich noch jemand den Kopf zerbrechen muss.

Danke Bernd

DS_Starter · 15 November 2020, 19:39:38

Danke für den Hinweis Bernd. Habe es ergänzt.

ch.eick · 17 November 2020, 20:12:43

Ist hier der DbRep thread

Hallo Heiko,
beim sqlCmd kann man den reading Namen nicht verändern.

Code Auswählen


SELECT sum(VALUE) AS 'Solar_calculation_fc1_tomorrow' FROM history WHERE DEVICE = 'PV_Anlage_1' AND READING = 'Solar_Calculation_fc1' AND TIMESTAMP > DATE_ADD(DATE(now()),INTERVAL 1 DAY) AND TIMESTAMP < DATE_ADD(DATE(now()),INTERVAL 2 DAY);
+--------------------------------+
| Solar_calculation_fc1_tomorrow |
+--------------------------------+
|                           9288 |
+--------------------------------+

## man kann auch den Header auf leer setzen ;-)
## Im DbRep ist aber immer SqlResultRow_1 fest für die Überschriften gesetzt, aber das ist sicherlich mySQL spezifisch :-)
SELECT sum(VALUE) AS '' FROM history WHERE DEVICE = 'PV_Anlage_1' AND READING = 'Solar_Calculation_fc1' AND TIMESTAMP > DATE_ADD(DATE(now()),INTERVAL 1 DAY) AND TIMESTAMP < DATE_ADD(DATE(now()),INTERVAL 2 DAY);
+------+
|      |
+------+
| 9288 |
+------+

Und es wird brutal der Spaltenname in Großbuchstaben umgewandelt, was nicht aus dem SQL kommt.

Code Auswählen


SqlResultRow_1 SOLAR_CALCULATION_FC1_TOMORROW
SqlResultRow_2 9288
readingNameMap Solar_calculation_fc1_tomorrow

Variante eins wäre schön

Code Auswählen


SqlResultRow_1 Solar_calculation_fc1_tomorrow
SqlResultRow_2 9288

Oder Variante zwei mit as '' und readingNameMap

Code Auswählen


Solar_calculation_fc1_tomorrow_1 9288
readingNameMap Solar_calculation_fc1_tomorrow

Ups, jetzt fällt es mir gerade auf, Variante zwei ohne die SqlResultRow_1 wäre nur Möglich, wenn keine Columne Überschrift kommt, also bei mehrspaltigen Abfragen.
Ich lasse es einfach mal zur Diskussion hier so stehen.

VG
Christian

DS_Starter · 18 November 2020, 00:22:25

Hallo Christian,

ZitatUnd es wird brutal der Spaltenname in Großbuchstaben umgewandelt, was nicht aus dem SQL kommt.

Das hab ich im Code so hinterlegt, damit man die Überschriften leicht als solche erkennt. Der Header wird übrigens auch bei mehrspaltigen Ausgaben ausgegeben sofern diese geliefert werden, z.B. bei get <> procInfo.
Der Header wird vom DBI-Interface geliefert, siehe -> https://metacpan.org/pod/DBI#NAME1

Grüße,
Heiko

DS_Starter · 20 November 2020, 18:45:39

Nabend Christian,

das ist hsitorisch bedingt. Als ich vor ein paar Jahren Dblog begonnen hatte zu übernehmen, war die Column Struktur bereits gegeben.
Allerdings hatte ich später die Attribute colEvent, colReading und colValue eingebaut.
Damit kann man die Breite verändern, aber auch mit

colEvent=0

das Datenbankfeld EVENT nicht füllen lassen. Das dann freie Feld könnte man für eigene Zwecke verwenden, z.B. um mit einem DbRep SQL Werte dort eintragen.
Ich kann dir auch nicht sagen wozu man ursprünglich die EVENT Column verwendet hat.

Edit: Uuuups, wo ist die Frage hin ?

Grüße,
Heiko