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

[ch.eick]

Die Zählung hat jedoch nicht bei ckey:1 begonnen, sondern bei einem Device bei 2 und bei einem anderen bei 5.
Nach einem ___purge_sqlhistory___ und erneutem set ging es dann bei 1 los.

Das ist normal.

Ich hatte damit gerechnet, wenn das Attribut neu definiert wird, dass es auch bei 0 oder 1 mit der Zählung beginnt.

Mit dem set <Device> sqlCmd aus dem Device heraus wurde nichts in der sqlCmdHistory gespeichert.

Kann ich nicht glauben. 
Funktioniert bei mir tadellos.

Ich schau mir das beim nächsten DbRep nochmal genauer an, jetzt bin ich erstmal froh, dass es läuft und das rufende Device nicht mehr seitenweise MySQL beinhaltet.
Du kennst ja meine optimierten Abfragen

[RalfRog]

Hallo
Nach dem Update von Sonntag (mit DBLog und DBRep) ist bei einem DBRep-Device ein Attribut beim/nach dem Hochlauf gelöscht worden
=> "attr DBRep_avgtim_total_power executeAfterProc set DBRep_avgtim_unit changeValue old="%" new={"($VALUE,$UNIT) = ($VALUE,"W")"}"
Im Restore-Dir ist es noch enthalten 

Beim neu Anlegen erhalte ich die Fehlermeldung:
=> "syntax error at (eval 163764) line 1, near ""%" new""

Diese Meldung (PERL-Warning) ist auch im Log des Hochlaufs enthalten, war aber leider nicht direkt zuzuordnen:

Code Auswählen Erweitern

2023.06.25 00:35:41.220 1: PERL WARNING: Bareword found where operator expected at (eval 256) line 1, near ""%" new"
2023.06.25 00:35:41.221 1: PERL WARNING: (Missing operator before new?)
2023.06.25 00:35:41.223 1: PERL WARNING: String found where operator expected at (eval 256) line 1, near "W")""
2023.06.25 00:35:41.223 3: syntax error at (eval 256) line 1, near ""%" new"

2023.06.25 00:35:41.898 1: Including ./log/fhem.save
2023.06.25 00:35:43.077 1: Messages collected while initializing FHEM:configfile: syntax error at (eval 256) line 1, near ""%" new"
1) ich überlege was an der Syntax falsch ist um das Attribut erneut zu konfigurieren
2) welches Modul -> DBRep selber oder fhem.pl? löscht die Zeile aus der fhem.cfg. Ein Hinweis im Log wäre hilfreich.

Gruß Ralf

[DS_Starter]

Hallo Ralf,

seit der letzte Version kann executeAfterProc Perl code ausführen.
Die Syntax prüfe ich im Modul.
Leider hat die Prüfung bei deinem Konstrukt ein "false positiv" gebracht.

Ich habe die Prüfung gefixt und die V 8.52.8 vorerst in mein contrib geladen damit du es schnell bei dir implementieren und testen kannst.
Wird dann noch zügig eingecheckt wenn ok.

Grüße,
Heiko

[RalfRog]

Danke ich hole es mir gleich und gebe eine Rückmeldung.

Das heisst, dass das Modul die Zeile aus der CFG löscht. Ist es möglich dafür auch bei niedrigem verbose-Level eine Log-Meldung zu bekommen?

Gruß Ralf

[DS_Starter]

Naja, das war etwas unglücklich.
Wenn du das gefixte Modul aktiv hast, wird dir direkt bei der Eingabe der Syntaxfehler angezeigt und das Attr
nicht gesetzt.
Andererseits wäre dir mit dem gefixten Modul kein Fehler gemeldet worden und das Attr auch nicht entfernt worden.

Das Löschen macht nicht das Modul. Das Attr konnte beim Restart wegen des "false positiv" durch FHEM nicht aktiviert werden und fiel so aus der cfg. Zumindest sofern man nach dem Restart "save" gedrückt hat, sonst nicht.

[RalfRog]

...
Das Löschen macht nicht das Modul. Das Attr konnte beim Restart wegen des "false positiv" durch FHEM nicht aktiviert werden und fiel so aus der cfg. Zumindest sofern man nach dem Restart "save" gedrückt hat, sonst nicht.

War mir nicht klar (kann ich mir hoffentlich merken  )
Weiss leider nicht mehr ob ich ein save ausgeführt habe. Da aber in "/opt/fhem/restoreDir/save/2023-06-25" um 0:38 Uhr eine CFG liegt werde ich es wohl getan haben.
Da fällt man ggfs. allerdings schnell drauf rein, dass etwas beim Hochlauf nicht gesetzt wird und man "leichtfertig" eine save absetzt.



Habe die Datei in ./FHEM abgelegt und per "reload 93_DbRep.pm" neu geladen.
Das Attribut ist wieder gesetzt! 
"attr DBRep_avgtim_total_power executeAfterProc set DBRep_avgtim_unit changeValue old="%" new={"($VALUE,$UNIT) = ($VALUE,"W")"}"

Werde nachher noch ein Restart durchführen - ist sauberer und heute Nacht sehen ob die chain durchläuft.

[DS_Starter]

Wenn beim Start Fehler passieren schreibt FHEM zur Info für den User auf der Startseite ein "Autosave deactivated" oder ähnliches aus um mitzuteilen dass die Konfiguration wegen eines/des Fehlers nicht gesichert wurde.
Siehe das globale Attr autosave.

[RalfRog]

ja so:

Code Auswählen Erweitern

You can disable this message with attr global motd none
Autosave deactivated
2023.06.25 00:35:43.158 3: Opening UartRpi device /dev/ttyAMA0Danke für den Hinweis. Konnte ich nicht einordnen.

Edit:
Stimmt.
Attribut "autosave = 0". Ist aber offensichtlich (lt. Backups) schon länger so...  vielleicht hab ich es sogar selber so gesetzt um bewusst zu entscheiden ob etwas in die CFG kommt.

[RalfRog]

Werde nachher noch ein Restart durchführen - ist sauberer und heute Nacht sehen ob die chain durchläuft.

Alles gut.

[DS_Starter]

Danke für die Info Ralf ... ist eingecheckt.

[flummy1978]

Hallo zusammen,

ich tue mir grad irgendwie schwer einen Ansatz zu schaffen und bräuchte mal einen Schubs in die richtige Richtung:

Ich habe seit diesem Jahr eine Balkonanlage wo ich mit den Werten immer mal wieder ein wenig rumgespielt habe. Was ist allerdings nicht beachtet habe: Meine aktuelle Auswertung zeigt mir gewisse Werte an die ich mir als einzelne Tage super anschauen kann. Der Gesamtwert wird zusammengerechnet und diesen sehe ich. Was mir fehlt ist eine Übersicht von Tageserträgen, Wochen / Monatzusammenfassung usw. Ich habe von der Anlage einzelne (steigende) Werte wieviel die Anlage zum jeweiligen Tageszeitpunkt gemacht hat, die in der DB gespeichert sind.

Gibt es eine "einfache" Möglichkeit, aus den vorhandenen Werten jeweils den Tageshöchstwert zu ermitteln (alles andere kann ja gelöscht werden) und daraus dann wiederum neue Readings zu generieren die dann Summ7days Summ30days heißen könnten oder oder? Oder denke ich hier zu kompliziert und es gibt einen anderen Weg?

Für zukünftige Tage könnte ich es lösen, indem ich jeweils an dem Tag / Sonntags und am 1 eines Monats die Erfassung machen würde, aber für die vergangenen Monate interessiert es mich.

Vielen dank im Voraus
VG
Andreas

[RalfRog]

Als Schubs fallen mir die set-Funktionen maxValue, diffValue und sumValue mit entsprechendem Aggregationszeitraum ein.

Damit hat es soweit ich erinnere schon Umsetzungen gegeben.

Ausserhalb der Datenbank wäre das statistics-Modul eine Möglichkeit.
Das Modul bereitet Stunden-, Tages-, Monats und Jahres-Summen auf.

Gruß Ralf

[DS_Starter]

Gibt es eine "einfache" Möglichkeit, aus den vorhandenen Werten jeweils den Tageshöchstwert zu ermitteln (alles andere kann ja gelöscht werden) und daraus dann wiederum neue Readings zu generieren die dann Summ7days Summ30days heißen könnten oder oder? Oder denke ich hier zu kompliziert und es gibt einen anderen Weg?

Ich weiß nicht inwieweit du schon die richtigen Hinweise von Ralf verfolgt hast.
Ergänzend dazu gibt es im DbRep Befehle wie "maxValue writeToDB" welcher genau das macht was du oben beschreibst (aggregation=day).

Weiterhin habe ich mal vor langer Zeit im Wiki Auswertungsszenarios beschrieben: https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschusseinspeisung

Vllt. hilft dir das weiter.

[flummy1978]

Hey Ihr zwei,

@RalfRog: sorry, ich hab irgendwie eine Antwort an Dich geschrieben gehabt und sie scheinbar nicht abgeschickt. Dachte dann "OK da kommt erstmal nichts mehr" und dabei war ich das Problem .. sorry nochmal. War keine Absicht....

@DS_Starter: Ich hab es (für die jetzt kommenden Werte) genauso gelöst.  maxValue deleteOther löst das Ganze ab jetzt

Code Auswählen Erweitern

SELECT `TIMESTAMP`, `DEVICE`, `TYPE`, `EVENT`, `READING`, `UNIT`, MAX(CAST(`VALUE` AS UNSIGNED)) AS 'VALUE'
FROM `history`
WHERE `DEVICE` = 'Flummy_DTU' AND `READING` = 'YieldDay'
GROUP BY date( `TIMESTAMP` ) 
ORDER BY `history`.`TIMESTAMP`  DESCals SQL Befehl hat es für die Vergangenheit gelöst. Die MaxWerte habe ich übernommen, alles andere gelöscht und somit passt es 

VG
Andreas

[Jewe]

Moin,

habe versucht die SQLiteDB mit DBrep und exporttofile in eine csv datei zu exportieren. Diese möchte ich dann in Influx wieder einlesen. Die DB´s sind recht groß 14,2Mio Datensätze (5,2GB) und 5,2 Mio Datensätze (2,7GB).
DBRep startet und legt auch die CSV-Files an, dann stürzt Fhem ab startet neu. Die erstellte CSV-Dateien sind ca. 1,1 und 1,4GB groß.

Bin mir nicht sicher ob dieser Weg ein guter ist. Vmtl. geht das auch anders?

Code Auswählen Erweitern

define Rep.impDbLog DbRep impDbLog
attr Rep.impDbLog DbLogExclude .*
attr Rep.impDbLog aggregation month
attr Rep.impDbLog devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.impDbLog dumpDirLocal ./log
attr Rep.impDbLog dumpFilesKeep 0
attr Rep.impDbLog event-on-update-reading state
attr Rep.impDbLog executeAfterProc set impDbLog reopen
attr Rep.impDbLog executeBeforeProc set impDbLog reopen 3600
attr Rep.impDbLog expimpfile /opt/fhem/expimpDbLog_%Y-%m-%d.csv
attr Rep.impDbLog optimizeTablesBeforeDump 1
attr Rep.impDbLog room DbLog
attr Rep.impDbLog showproctime 1
attr Rep.impDbLog verbose 3
#   DATABASE   /opt/fhem/important.db
#   DEF        impDbLog
#   FUUID      5c4cce27-f33f-9f49-19f3-51254aae6d47c978
#   FVERSION   93_DbRep.pm:v8.52.11-s27975/2023-09-17
#   LASTCMD    initial database connect stopped due to attribute 'fastStart'
#   MODEL      Client
#   NAME       Rep.impDbLog
#   NOTIFYDEV  global,Rep.impDbLog
#   NR         383
#   NTFY_ORDER 50-Rep.impDbLog
#   ROLE       Client
#   STATE      initialized
#   TYPE       DbRep
#   UTF8       0
#   HELPER:
#     DBLOGDEVICE impDbLog
#     IDRETRIES  3
#     PACKAGE    main
#     VERSION    8.52.11
#   READINGS:
#     2023-10-14 02:19:17   after_command_message Reopen executed.
#     2023-10-14 07:32:13   state           initialized
#
setstate Rep.impDbLog initialized
setstate Rep.impDbLog 2023-10-14 02:19:17 after_command_message Reopen executed.
setstate Rep.impDbLog 2023-10-14 07:32:13 state initialized


LOGFILE:

Code Auswählen Erweitern

2023.10.14 02:13:07 3: DbRep Rep.impDbLog - get initial structure information of database "/opt/fhem/important.db", remaining attempts: 3
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - Connectiontest to database SQLite:dbname=/opt/fhem/important.db with user
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - Index Report_Idx exists. Check ok
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - Initial data information retrieved - total time used: 0.0102 seconds
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - Connectiontest to db SQLite:dbname=/opt/fhem/important.db successful
2023.10.14 02:13:07 3: DbRep Rep.impDbLog - execute command before exportToFile: 'set impDbLog reopen 3600'
2023.10.14 02:13:07 2: impDbLog - Connection closed until 03:13:07 (3600 seconds).
2023.10.14 02:13:08 3: impDbLog - Database disconnected by request.
2023.10.14 02:19:09 1: Server shutdown delayed due to myDbLog,alexa for max 10 sec
2023.10.14 02:19:15 1: [Freezemon] freezemon: possible freeze starting at 02:17:28, delay is 107.342 possibly caused by: tmr-CODE(0x55fcfa6d2bb8)(ResponseTimeout) tmr-CODE(0x55fcfa62c3c8)(ProcessRequestQueue) tmr-HM485_LAN_KeepAlive(HM485_LAN) tmr-DOIF_SleepTrigger(Heizung_HK2_Solltemperatur)
2023.10.14 02:19:16 3: alexa: stopped
2023.10.14 02:19:17 1: DbRep Rep.impDbLog -> BlockingCall DbRep_expfile pid:DEAD:84022 Process died prematurely
2023.10.14 02:19:17 3: DbRep Rep.impDbLog - execute command after command: 'set impDbLog reopen'
2023.10.14 02:19:17 3: impDbLog - Reopen requested
2023.10.14 02:19:17 2: DbRep Rep.impDbLog - command message after command: >Reopen executed.<
2023.10.14 02:19:17 2: DbRep Rep.impDbLog - Database command aborted: "Process died prematurely"
2023.10.14 02:19:17 0: Server shutdown


2023.10.14 07:27:18 3: DbRep Rep.myDbLog - get initial structure information of database "/opt/fhem/fhem.db", remaining attempts: 3
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - Connectiontest to database SQLite:dbname=/opt/fhem/fhem.db with user
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - Index Report_Idx exists. Check ok
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - Initial data information retrieved - total time used: 0.0096 seconds
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - Connectiontest to db SQLite:dbname=/opt/fhem/fhem.db successful
2023.10.14 07:27:18 3: DbRep Rep.myDbLog - execute command before exportToFile: 'set myDbLog reopen 3600'
2023.10.14 07:32:02 2: impDbLog - Wait for last database cycle due to shutdown ...
2023.10.14 07:32:02 1: Server shutdown delayed due to alexa,impDbLog for max 10 sec
2023.10.14 07:32:03 2: impDbLog - Last database write cycle done
2023.10.14 07:32:03 1: DbRep Rep.myDbLog -> BlockingCall DbRep_expfile pid:DEAD:88816 Process died prematurely
2023.10.14 07:32:03 3: DbRep Rep.myDbLog - execute command after command: 'set myDbLog reopen'
2023.10.14 07:32:03 2: DbRep Rep.myDbLog - command message after command: >Reopen executed.<
2023.10.14 07:32:03 2: DbRep Rep.myDbLog - Database command aborted: "Process died prematurely"
2023.10.14 07:32:05 0: Server shutdown