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

[DS_Starter]

Moin Bernd,

es ist also so dass dein notify funktioniert wie es soll wenn du den event per trigger auslöst, richtig ?
Und du setzt eigentlich immer nur "0" in der DB, auch richtig ?

In deinen Logangaben vermisse ich grundsätzlich den Start der Aktion mit "-------- New selection ---------" Ausgabe mit verbose 4.
Gibt es den nicht ?

Was ist der Unterschied zwischen dem Trigger und dem normalen Event ?
Du kannst in deinem Debug mal den kompletten Event mit $EVENT aufnehmen und ausdrucken lassen.

Es müsste mit verbose 5 auch die Meldung

Code Auswählen Erweitern


DbRep <name> - BlockingCall with PID "..." started


erscheinen. Sehe ich auch nicht in deinem Auszug.
Checke das bitte nochmal.

Grüße,
Heiko

[frober]

Moin Bernd,

es ist also so dass dein notify funktioniert wie es soll wenn du den event per trigger auslöst, richtig ?
Und du setzt eigentlich immer nur "0" in der DB, auch richtig ?

Hallo Heiko, ja beides ist so.

In deinen Logangaben vermisse ich grundsätzlich den Start der Aktion mit "-------- New selection ---------" Ausgabe mit verbose 4.
Gibt es den nicht

Das hat mich auch verwundert, ich habe verbose 5 benutzt, um erstmal selbst die Fehler zu finden. Mehr, wie gepostet, kommt nicht.

Was ist der Unterschied zwischen dem Trigger und dem normalen Event ?

Eigentlich nur, dass Power eher bei 300 (296.4 o.ä.) ist.

Du kannst in deinem Debug mal den kompletten Event mit $EVENT aufnehmen und ausdrucken lassen.

Mache ich aber erst heute Mittag...

Es müsste mit verbose 5 auch die Meldung

Code Auswählen Erweitern


DbRep <name> - BlockingCall with PID "..." started


erscheinen. Sehe ich auch nicht in deinem Auszug.
Checke das bitte nochmal.

Ich schaue heute Mittag nochmal.
Verbose von DbRep ist doch von Global verbose unabhängig, bzw. wird bevorzugt, richtig?

Grüße Bernd

[DS_Starter]

Code Auswählen Erweitern


Verbose von DbRep ist doch von Global verbose unabhängig, bzw. wird bevorzugt, richtig?

Das verbose Verhalten unterscheidet sich nicht von anderen Modulen.
Um ein Problem in DbRep zu suchen ist es sinnvoll das globale verbose auf 3 (default) zu belassen und nur das betroffene DbRep Device auf 4 / 5 zu setzen. Das erhöht die Übersichtlichkeit enorm. Sonst hast du einen Wald vor Augen. 

[frober]

Ich habe alles auf verbose 1 und setze nur bei Bedarf auf 4 oder 5.

OK, mein Fehler...verbose 5 war nur im notify gesetzt.

[DS_Starter]

Ok. Dann kannst du im Dbrep erhöhen auf 2, 3, 4 oder 5. Sonst nimmt DbRep auch den global eingestellten Wert (1 bei dir).

[frober]

Ok. Dann kannst du im Dbrep erhöhen auf 2, 3, 4 oder 5. Sonst nimmt DbRep auch den global eingestellten Wert (1 bei dir).

Ich habe heute Morgen noch auf verbose 5 gestellt und die notify Bedingung auf >0.3.
Wenn die Pumpe steht, streut die Messung zw. 0 und 0.4 W.

Das hat dann funktiniert 

2022-09-04_11:35:53 0.3
2022-09-04_12:07:01 0.3
2022-09-04_12:37:13 0.3
2022-09-04_13:08:22 0
2022-09-04_13:08:22 0.4
2022-09-04_13:38:32 0
2022-09-04_14:09:42 0.3

Eben habe ich den Schwimmerschalter ausgelöst (Tauchpumpe) und das hat auch funktioniert 

2022-09-04_14:52:56 0.3
2022-09-04_14:54:56 0
2022-09-04_14:54:56 299.3
2022-09-04_14:55:56 0

Lag es doch an der älteren Version von DbRep?? Fhem ist seit gestern aktuell. Oder Fhem hat einfach einen Neustart benötigt!?

2022.09.04 13:08:22 1: DEBUG>2022-09-04,13:08:22,Zisternenpumpe,power,event = power: 0.4
2022.09.04 13:08:22 3: DbRep insertDB - get initial structure information of database "fhem", remaining attempts: 3
2022.09.04 13:08:22 3: DbRep insertDB - Connectiontest to database mysql:database=fhem;host=localhost;port=xxxx with user xxx
2022.09.04 13:08:22 5: DbRep insertDB - start BlockingCall with PID "12705"
2022.09.04 13:08:22 4: DbRep insertDB - Database connect - user: xxx, UTF-8 option set: yes
2022.09.04 13:08:22 4: DbRep insertDB - Oldest timestamp determined: 2018-03-31 22:56:30
2022.09.04 13:08:22 4: DbRep insertDB - Encoding of database determined: utf8
2022.09.04 13:08:22 3: DbRep insertDB - Index Report_Idx exists. Check ok
2022.09.04 13:08:22 4: DbRep insertDB - Grants determined: USAGE
2022.09.04 13:08:22 5: DbRep insertDB - getInitData finished PID "12705"
2022.09.04 13:08:22 3: DbRep insertDB - Initial data information retrieved - total time used: 0.0144 seconds
2022.09.04 13:08:22 3: DbRep insertDB - Connectiontest to db mysql:database=fhem;host=localhost;port=3306 successful
2022.09.04 13:08:22 4: DbRep insertDB - -------- New selection ---------
2022.09.04 13:08:22 4: DbRep insertDB - Command: insert 2022-09-04 13:08:22,Zisternenpumpe,power,0,
2022.09.04 13:08:23 5: DbRep insertDB - BlockingCall with PID "12706" started
2022.09.04 13:08:23 4: DbRep insertDB - Database connect - user: xxx, UTF-8 option set: yes
2022.09.04 13:08:23 5: DbRep insertDB -> Primary Key used in fhem.history: 0 (none)
2022.09.04 13:08:23 5: DbRep insertDB -> Primary Key used in fhem.current: 0 (none)
2022.09.04 13:08:23 5: DbRep insertDB -> data to insert Timestamp: 2022-09-04 13:08:22, Device: Zisternenpumpe, Type: manual, Event: manual, Reading: power, Value: 0, Unit:
2022.09.04 13:08:23 4: DbRep insertDB - SQL prepare: INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2022.09.04 13:08:23 4: DbRep insertDB - begin transaction
2022.09.04 13:08:23 4: DbRep insertDB - transaction committed
2022.09.04 13:08:23 4: DbRep insertDB - Inserted into fhem.history: 2022-09-04 13:08:22, Zisternenpumpe, manual, manual, power, 0,
2022.09.04 13:08:23 5: DbRep insertDB - BlockingCall PID "12706" finished
2022.09.04 14:54:56 1: DEBUG>2022-09-04,14:54:56,Zisternenpumpe,power,event = power: 299.3
2022.09.04 14:54:56 4: DbRep insertDB - -------- New selection ---------
2022.09.04 14:54:56 4: DbRep insertDB - Command: insert 2022-09-04 14:54:56,Zisternenpumpe,power,0,
2022.09.04 14:54:56 5: DbRep insertDB - BlockingCall with PID "16068" started
2022.09.04 14:54:56 4: DbRep insertDB - Database connect - user: xxx, UTF-8 option set: yes
2022.09.04 14:54:56 5: DbRep insertDB -> Primary Key used in fhem.history: 0 (none)
2022.09.04 14:54:56 5: DbRep insertDB -> Primary Key used in fhem.current: 0 (none)
2022.09.04 14:54:56 5: DbRep insertDB -> data to insert Timestamp: 2022-09-04 14:54:56, Device: Zisternenpumpe, Type: manual, Event: manual, Reading: power, Value: 0, Unit:
2022.09.04 14:54:56 4: DbRep insertDB - SQL prepare: INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)
2022.09.04 14:54:56 4: DbRep insertDB - begin transaction
2022.09.04 14:54:56 4: DbRep insertDB - transaction committed
2022.09.04 14:54:56 4: DbRep insertDB - Inserted into fhem.history: 2022-09-04 14:54:56, Zisternenpumpe, manual, manual, power, 0,
2022.09.04 14:54:56 5: DbRep insertDB - BlockingCall PID "16068" finished

Nun muss ich erstmal warten, bis es wieder regnet...

Danke nochmal.

Grüße und schönen Restsonntag
Bernd

[DS_Starter]

Lag es doch an der älteren Version von DbRep?? Fhem ist seit gestern aktuell. Oder Fhem hat einfach einen Neustart benötigt!?

Eher unwahrscheinlich. Das ist m.M. nach eine grundsätzliche Problematik.

Folgender Zusammenhang ist wichtig zu verstehen.
Wenn ein Vorgang im DbRep gestartet wird, erstellt das Modul einen parallelen Prozess um die DB-Aktion auszuführen.
Mit verbose 5 sieht man das im Log:

Code Auswählen Erweitern


2022.09.04 13:08:23 5: DbRep insertDB - BlockingCall with PID "12706" started


Durch diesen Mechanismus kann FHEM weiter werkeln und muß nicht auf das Ergebnis der DB warten, deswegen ist DbRep (und auch andere Module) über diesen Mechanismus non-blocking. Es werden aber Ressourcen im RAM allokiert.
Nun gibt es die Design-Vorgabe, dass ein Device nur einen ! BlockingCall aktiv haben darf.
Wenn du jetzt im selben DbRep-Device über dein notify ein neues insert antriggerst und der vorherige insert noch nicht abgeschlossen ist, wird der vorherige (noch laufende) BlockingCall abgebrochen.

Im Log erscheint dann zunächst eine WARNING dass der Prozess abgebrochen wird (verbose 3) und dann gibt es als Reaktion auf diesem Abbruch den Timeout:

Code Auswählen Erweitern


2022.09.03 17:00:13 1: DbRep insertDB -> BlockingCall DbRep_insert pid:12706 Timeout: process terminated


In beiden Fällen wird dir die PID angezeigt und du kannst darüber erkennen welcher Prozess abgebrochen wurde.

Es hängt also ganz stark davon ab wie schnell deine DB den insert verarbeitet in Bezug zu dem Triggerintervall über dein notify.
Um dieses Problem zu verhindern umgehen könntest du das DbRep kopieren und den beiden notify jeweils ein DbRep exklusiv zuordnen falls es nötig wird.

Grüße und auch einen schönen Restsonntag.
Heiko

[frober]

Danke für die Erläuterung.

Das könnte passen, da das andere notify (Mysensors) beim Start der Pumpe ( unter bestimmten Bedingungen) parallel auch  anspricht (spülen des Filtersiebs der Zisterne).

Dann lege ich eine Kopie vom DbRep an.

Mir war nicht klar, das hier nur ein nonblocking erlaubt ist.

Danke nochmals.
Bernd

[thomasg]

Hallo zusammen,

ich logge u.a. Messwerte von meinem Stromzähler und Wärmemengenzähler der Wärmepumpe. Das sind immer Summenwerte, die alle 15 Minuten protojolliert werden ins dblog mit sqllite hinten dran.

Nun habe ich den Wunsch, auf der fhem-Weboberfläche übersichtlich die abgegrenzten Monatsverbräuche/Wärmeerzeugung darzustellen. Vielleicht in einem Balkendiagramm auf der Y-Achse KwH und der X-Achse Monat.

Nun bin auf dieses Modul aufmerksam geworden. Meint Ihr, damit kann ich die Messwerte entsprechend aufbereiten?

Ich würde mir das So vorstellen: ein mal am Tag soll der abgerenzte Monatswert für den aktuellen Monat ermittelt/aktualisiert werden - dann in eine temporäre variable ... und wenn der monat voll ist kann die variable in die sqllite dtenbank geschrieben werden.

Vielen Dank & beste Grüße

[frober]

Das könnte passen, da das andere notify (Mysensors) beim Start der Pumpe ( unter bestimmten Bedingungen) parallel auch  anspricht (spülen des Filtersiebs der Zisterne).

Dann lege ich eine Kopie vom DbRep an.

Mit der Kopie funktioniert es nun.
Danke nochmals.

LG
Bernd

[DS_Starter]

Guten Abend,

@Bernd,  freut mich. 

@thomasg
ich könnte mir vorstellen, dass

Code Auswählen Erweitern


set .... diffValue writeToDB


ein Weg für dich wäre. Mit dem Attr aggregation = month wird jeweils Differenz zwischen einem Montsanfangswert und Monatsendwert in den eingestellten Zeitgrenzen (time.* -Attribute) berechnet und mit einem neuen Readingsnamen in die DB geschrieben.
Dieses Reading kannst du dann im SVG anzeigen lassen.

diffValue  ist anwendbar für den Fall dass der Wert sich immer erhöht. Es wäre bei gegeben wenn ich deine Beschreibung richtig verstanden habe. Es würde in dem Beispiel reichen einmal im Monat für den Vormonat diese Berechnung auszuführen.

Grüße,
Heiko

[thomasg]

Danke für den Tipp. Musste erst mein System neu aufsetzten und die sqlite Datenbank reparieren. Deswegen die Späte Rückmeldung.

Das funktioniert wunderbar. Ich habe ein neues Device "WP.Verbrauch.Mon" angelegt:

Code Auswählen Erweitern


defmod WP.Verbrauch.Mon DbRep thomasDbLog
attr WP.Verbrauch.Mon aggregation month
attr WP.Verbrauch.Mon comment Abgegrenzter Stromverbrauch Wärmepumpe
attr WP.Verbrauch.Mon device HAR.Counter
attr WP.Verbrauch.Mon reading consumption
attr WP.Verbrauch.Mon room Sensoren

Wenn ich dann in der Weboberfläche bei set diffValue und display auswähle rechnet er die abgegrenzen Werte einmalig aus und zeigt sie als Reading an.
Kannst Du mir jetzt noch einen Hinweis geben, wie ich das automatisieren kann? Also einmal am tag soll er die Werte ermitteln und in die Datenbank schreiben.

ein 

Code Auswählen Erweitern

attr WP.Verbrauch.Mon diffValue writeToDB führt leider zu einer Fehlermeldung.

Gibt es auch eine Möglichkeit fürs Reinschreiben in die Datenbank als Alternative zu den generierten Readingbezeichnungen:

2022-02-28_23-56-48__HAR.Counter__consumption__DIFF__2022-02
2022-03-31_23-48-49__HAR.Counter__consumption__DIFF__2022-03
2022-04-30_23-56-00__HAR.Counter__consumption__DIFF__2022-04

ein konsistenten Readingnamen zu haben.

Also bspw. einfach nur WP.Verbrauch.Mon ohne Zeitstempel im Namen?



Lieben Dank

[DS_Starter]

Regelmässige Ausführungen machst du einfach über die Definition eines at Devices.

Diese führt dann ein set ... diffValue writeToDB aus.

Um das geschriebene neue Reading umzubenennen kannst du das Attr readingNameMap benutzen.
Aber schau mal ob dir der generisch gebildete Namen nicht ausreicht. Ist in der Commandref zu diffValue weiteToDB beschrieben.

LG

[thomasg]

Du hast recht .. der generische Name ist nachvollziehbarer und passt dann zu den anderen attributen in der datenbank.
Habe es jetzt hinbekommen. Super Sache. Das Ergebnischart mal im Anhang dargestellt. Wenn ich mit der Maus über die Legende des Charts gehe, wird Min, Max, Lastals Mouseover angezeigt. Hast Du vielleicht noch einen Tipp, wie ich da stattdessen die Summe des Monats anzeiegn lassen kann? Oder gerne auch dauerhaft einblenden im Diagramm. Ich habe auch einmal einen Screenshot meiner DBrep devices gemacht. Ist das so ok, wenn ich zwei Werte ermitteln möchte zwei Devices anzulegen, oder wäre es gecshickter diese beiden Werte (Verbrauch, Erzeugung) in ein DBREP Device zusammenzufassen. Würde dann auch nur in ein AT Device resultieren. Wäre dann alles etwas übersichtlicher/einfacher. Danke & schönes Restwochenende

[DS_Starter]

Hast Du vielleicht noch einen Tipp, wie ich da stattdessen die Summe des Monats anzeiegn lassen kann? Oder gerne auch dauerhaft einblenden im Diagramm.

Schau doch dafür mal im SVG Forum vorbei. Ich will nicht sagen es ginge nicht, habe aber addhoc keinen Vorschlag.
Und weil ich aktuell auch bisschen Urlaub mache, will ich jetzt auch nicht danach schauen ... 

Ist das so ok, wenn ich zwei Werte ermitteln möchte zwei Devices anzulegen, oder wäre es gecshickter diese beiden Werte (Verbrauch, Erzeugung) in ein DBREP Device zusammenzufassen.

Zwei Devices ist absolut ok und war von mir vom Design her auch so gedacht. Wenn man beide Funktionen (Verbrauch, Erzeugung) vom selben DbRep erzeugen lassen will geht das zwar auch, man muß sich aber genau überlegen wie man das zeitlich steuert. Durch die asynchrone Arbeitsweise dürfen sich beide Aufgaben zeitlich nicht überschneiden usw.
Ich habe bei mir über 100 DbRep's für die unterschiedlichsten Aufgaben definiert.
Welche Strukturierung man als übersichtlicher erachtet ist dann letztlich Ansichtssache.

LG