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

[DS_Starter]

ich muss die DB ja eh ständig zu und auf machen...

Nein.
Was ich meine, du schließt DbLog mit dem "set ... reopen xxx" Kommando bevor du die ganze Kommandokette startest und lässt den close auch solange bis DbRep mit seinen ganzen Aktionen durch ist.
DbLog cached seine Daten in der Zwischenzeit.
Ist DbRep dann mit dem Summs fertig, wird DbLog mit "set ... reopen" Befehl wieder mit der DB verbunden.
Für den letzten Schritt braucht man einen passenden Trigger/Event um mit einem Notify zu reagieren oder man macht zeitgesteuert, wie auch immer.

[DS_Starter]

Guten Morgen,

in meinem contrib liegt eine neue DbRep Version zunächst zum Test.
Folgende Punkte sind umgesetzt:

- das Attribut allowDeletion ist obsolet
- die Beschränkung für DbRep Kommandos bei gesetzten DbLog "set ... reopen xxx" ist aufgehoben
- im multiCmd Kommandohash können die Attribute executeBeforeProc, executeAfterProc verwendet werden

@flummy1978, die letzen beiden Punkte können für deinen Case sehr hifreich sein. Damit kann die Kommandochain zum Beipiel folgendermaßen aufgebaut werden um zu Beginn und zum Ende das DbLog Management mit zu integrieren:

Code Auswählen Erweitern

{
  1  => { executeBeforeProc => 'set LogDB reopen 900',
          timestamp_begin   => '2023-12-17 00:00:00',
  timestamp_end     => '2023-12-17 01:00:00',
  device            => 'SMA_Energymeter',
  reading           => 'Einspeisung_Wirkleistung_Zaehler',
  cmd               => 'countEntries history'
},
  2  => { timestamp_begin   => '2023-12-15 11:00:00',
  timestamp_end     => 'previous_day_end',
  device            => 'SMA_Energymeter',
  reading           => 'Einspeisung_Wirkleistung_Zaehler',
  cmd               => 'countEntries'
},
  3  => { timeDiffToNow     => 'd:2',
  readingNameMap    => 'COUNT',
  autoForward       => '{ ".*COUNT.*" => "Dum.Rep.All" }',
  device            => 'SMA_%,MySTP.*',
  reading           => 'etotal,etoday,Ein% EXCLUDE=%Wirkleistung',
  cmd               => 'countEntries history'
},
  4  => { timeDiffToNow     => 'd:2',
  readingNameMap    => 'SUM',
  autoForward       => '{ ".*SUM.*" => "Dum.Rep.All" }',
  device            => 'SMA_%,MySTP.*',
  reading           => 'etotal,etoday,Ein% EXCLUDE=%Wirkleistung',
  cmd               => 'sumValue'
},
  5  => { executeAfterProc => 'set LogDB reopen',
  cmd              => 'sqlCmd select count(*) from current'
},
}

!HINWEIS!  Beim Start kommen Meldungen der Art
"Device xxxx -> The attribute allowDeletion is obsolete and will be deleted soon. Please press "save config" when FHEM start is finished.

Ursache ist die Entfernung des allowDeletion Attributs sofern es gesetzt war.

Grüße,
Heiko

[flummy1978]

Hey Heiko,

vielen dank für die neue Version, wird grad getestet. Ich hab den vorherigen Teil noch nicht so verstanden gehabt und war noch in der Bearbeitungsphase ... mit exec before / after im multiCmd macht es die Sache natürlich NOCH einfacher - Das wird gleich getestet.

Guten Morgen,

in meinem contrib liegt eine neue DbRep Version zunächst zum Test.
....
@flummy1978, die letzen beiden Punkte können für deinen Case sehr hifreich sein. Damit kann die Kommandochain zum Beipiel folgendermaßen aufgebaut werden um zu Beginn und zum Ende das DbLog Management mit zu integrieren:

!HINWEIS!  Beim Start kommen Meldungen der Art
"Device xxxx -> The attribute allowDeletion is obsolete and will be deleted soon. Please press "save config" when FHEM start is finished.

Ursache ist die Entfernung des allowDeletion Attributs sofern es gesetzt war.

Meldung taucht im Log auf - man bekommt außerhalb vom Log aber keinen Hinweis, dass was geändert wurde (daher auch nicht direkt ersichtlich - vielleicht für den normal Sterblichen den Fragezeichen Hinweis einbauen, wenn das nicht zu viel Umstand macht)

VG
Andreas

[DS_Starter]

man bekommt außerhalb vom Log aber keinen Hinweis, dass was geändert wurde

Sagt doch  ... Device xxxx -> The attribute allowDeletion is obsolete and will be deleted soon ..
Wüßte nichts was ich da noch ergänzen könnte.

Das betrifft natürlich nur das entfernte Attribut.
Die Ergänzungen bzgl. multiCmd findet man natürlich in der Hilfe und es kommmt auch ein Verweis in die Update.Txt damit man den Hinweis im regulären Update auch sieht.

[uwirt]

Ich bekomme immer wieder dieselbe Fehlermeldung im Zusammenhang mit fastSTart Attribut:

Code Auswählen Erweitern

LASTCMD    initial database connect stopped due to attribute 'fastStart'


Code Auswählen Erweitern

define repdb DbRep logdb
attr repdb averageCalcForm avgDailyMeanGWSwithGTS
attr repdb devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr repdb device Mean_Temp_outside
attr repdb executeAfterProc set logdb reopen
attr repdb executeBeforeProc set logdb reopen 86400
attr repdb fastStart 1
attr repdb reading state
attr repdb room DBLog
attr repdb showproctime 1
attr repdb timestamp_begin current_year_begin
attr repdb timestamp_end previous_day_end
attr repdb userExitFn saveGTS
#   DATABASE   fhem
#   DEF        logdb
#   FUUID      65e841ba-f33f-c144-4162-bc12999b8dae2a68
#   FVERSION   93_DbRep.pm:v8.53.2-s28590/2024-03-03
#   LASTCMD    initial database connect stopped due to attribute 'fastStart'
#   MODEL      Client
#   NAME       repdb
#   NOTIFYDEV  global,repdb
#   NR         147
#   NTFY_ORDER 50-repdb
#   ROLE       Client
#   STATE      initialized
#   TYPE       DbRep
#   UTF8       0
#   HELPER:
#     DBLOGDEVICE logdb
#     IDRETRIES  3
#     PACKAGE    main
#     VERSION    8.53.2
#   READINGS:
#     2024-03-07 10:33:11   state           initialized
#
setstate repdb initialized
setstate repdb 2024-03-07 10:33:11 .associatedWith Mean_Temp_outside
setstate repdb 2024-03-07 10:33:11 state initialized


Habe ich da was vergessen?

[DS_Starter]

Das ist keine Fehlermeldung sondern die Info dass beim Start zunächst keine DB Verbindung aufgebaut wurde. Ist auch nicht neu. fastStart 1 ist schon lange Standard, du kannst das Attr löschen und nur auf explizit 0 setzen wenn du eine sofortige Verbindung haben willst.

[DS_Starter]

@all,

Morgen früh ist die neue DbRep Version im Update enthalten.
Folgende Punkte sind umgesetzt:

- das Attribut allowDeletion ist obsolet
- die Beschränkung für DbRep Kommandos bei gesetzten DbLog "set ... reopen xxx" ist aufgehoben
- im multiCmd Kommandohash können die Attribute executeBeforeProc, executeAfterProc verwendet werden
- DbRep ist für die Verwendung von MariaDB Perl-Treibern (DBD::MariaDB) vorbereitet und kann damit arbeiten sobald DbLog sie (in Kürze) unterstützt

Noch einmal der HINWEIS:
Die Meldungen

Code Auswählen Erweitern

"Device xxxx -> The attribute allowDeletion is obsolete and will be deleted soon. Please press "save config" when FHEM start is finished."
sind kein Fehler, sondern ein Hinweis und eine Aufforderung das zu tun was geschrieben steht, nämlich die Konfiguration sichern wenn der Restart beendet ist.
Diese Meldungen kommen dann auch nicht wieder.

LG

[Thowe]

Hallo Heiko,
vielen Dank für Deinen Mut zur Umsetzung der Hash-Steuerung.
Jetzt kommen natürlich die Fragen zur skripttypischen Beeinflussung des Ablaufs (Bedingungen, Sprünge, Einsprung an einer Hash-Element-Nr., Aussprung bei einem Hash-Element, ... ). In meinem Ablauf werden datumsabhängig unterschiedliche SQL-Befehls-Sequenzen durchlaufen.
Wie kann in einem cmd ein sqlCmd mit where der Spaltennamen in Hochkomma angeschrieben werden, z.B. für

Code Auswählen Erweitern

select value from history where device = 'beispiel' Könnte dafür ein Sonderzeichen gesetzt werden, das intern im SQL-Befehl wieder in ein Hochkomma umgewandelt wird?
Viele Grüße,
Thome

[DS_Starter]

Hallo Thome,

hier zwei Syntax Varianten wie du sqlCmd schreiben könntest:

Code Auswählen Erweitern

{
  1  => { cmd => 'sqlCmd select count(*) from current where device = "SMA_Energymeter"'
        },
  2  => { cmd => qq{sqlCmd select count(*) from current where device = 'SMA_Energymeter'}
        },
}

Bezüglich einer Script (ähnlichen) Steuerung hätte ich evtl. eine vage Vorstellung einer Umsetzbarkeit.
Könntest du mir ein praktisches Beipiel eine Use Cases posten?

Grüße,
Heiko

[DS_Starter]

@all,
ich verschiebe dieses Thema jetzt nach "Automatisierung" um das Modul im gleichen Forum wie DbLog zu supporten.

LG

[Thowe]

Hallo Heiko,
ich starte einen Hash-gestützten Ablauf täglich nach Mitternacht, ca. 200 DB-Operationen verarbeiten Daten des Tages (Wetter, Hausstatus, Kraftstoffpreise, Energie-Verbrauchswerte und deren Kosten, etc.). Nach dem Monatswechsel wäre der Ablauf nahezu gleich, jedoch kommen ein paar DB-Operationen zusätzlich für die Monatswerte hinzu.
Als Lösung müsste ich einen zusätzlichen Ablauf mit teilweise identischen DB-Operationen vom täglichen Ablauf aufrufen.
Oder der Ablauf erlaubt das Überspringen einiger Hash-Elemente, dann ließe sich ein einziger Ablauf pflegen.
BTW: im Hash sqlCmd wird bei §timestamp_end§ das § als Fehler angezeigt.
Viele Grüße,
Thowe

[DS_Starter]

Hallo Thowe,

danke für die Info. Meinst du das unten dargestellte Problem oder etwas anderes in Bezug auf "Fehler bei §timestamp_end§"?

2024.03.13 10:16:23.195 4: DbRep Rep.LogDB1 - multiCmd index >1< start
2024.03.13 10:16:23.206 4: DbRep Rep.LogDB1 - -------- New selection ---------
2024.03.13 10:16:23.206 4: DbRep Rep.LogDB1 - Command: sqlCmd select count(*) from history where device = "SMA_Energymeter" and TIMESTAMP < "§timestamp_end§";
2024.03.13 10:16:23.207 4: DbRep Rep.LogDB1 - Timestamp begin human readable: not set
2024.03.13 10:16:23.207 4: DbRep Rep.LogDB1 - Timestamp end human readable: not set
2024.03.13 10:16:23.275 4: DbRep Rep.LogDB1 - adminCredentials successfully read from file
2024.03.13 10:16:23.276 4: DbRep Rep.LogDB1 - Database Model: MYSQL
2024.03.13 10:16:23.277 4: DbRep Rep.LogDB1 - Database connect - user: root, UTF-8 option set: yes
2024.03.13 10:16:23.280 4: DbRep Rep.LogDB1 - Communication between Client and Server will be compressed
2024.03.13 10:16:23.281 4: DbRep Rep.LogDB1 - SQL execute: SHOW VARIABLES LIKE 'collation_database'
2024.03.13 10:16:23.283 4: DbRep Rep.LogDB1 - Database Character set is >utf8mb4_bin<
2024.03.13 10:16:23.283 4: DbRep Rep.LogDB1 - simple do statement: set names "utf8mb4" collate "utf8mb4_bin"
2024.03.13 10:16:23.284 1: PERL WARNING: Use of uninitialized value $rsn in concatenation (.) or string at ./FHEM/93_DbRep.pm line 7310.
2024.03.13 10:16:23.285 4: DbRep Rep.LogDB1 - SQL execute: select count(*) from history where device = "SMA_Energymeter" and TIMESTAMP < "''";
2024.03.13 10:16:26.749 4: DbRep Rep.LogDB1 - SQL result: 0

LG

[Thowe]

Hallo Heiko,
die Fehlermeldung tritt folgender Definition von at im DEF-Editor auf:

Code Auswählen Erweitern

+*00:01:00 {
  my $cmdhash =
  "{
      1  => { timestamp_end  => 'previous_day_end',
              device          => 'Stromkosten.HH_kWh',
              reading        => 'state',
              autoForward    => '{ ".*" => "Stromkosten.HH_kWh" }',
              cmd            => 'sqlCmd select value from history where device = "Stromkosten.HH_kWh" and timestamp <= §timestamp_end§ order by timestamp desc limit 1'
            },
    }";
    fhem ("set Rep_test_dev multiCmd $cmdhash");
    }
Die Fehlermeldung weist an die Position vom §:

Code Auswählen Erweitern

Unrecognized character \xC2; marked by <-- HERE after estamp <= <-- HERE near column 364 at (eval 2424) line 8.
Ich vermute ein Codierproblem, neu schreiben hat keine Verbesserung gebracht. Hast Du einen Tipp?

Viele Grüße,
Thowe

[betateilchen]

Code Auswählen Erweitern

autoForward    => '{ ".*" => "Stromkosten.HH_kWh" }',
Das ".*" als hash key sieht irgendwie komisch aus.
Hast Du mal versucht, den . und den * zu escapen?

[Thowe]

Hallo betateilchen und Heiko,
ich teste gerne
Zusammenfassung der Ergebnisse:
- in autoForward und cmd darf kein Device-Name mit . enthalten sein
- im cmd mit '....' dürfen keine Anführungszeichen bei der where-clause "" stehen. Mit qq{   ... where device = 'name'  ...} funktioniert es, auch mit dem §Platzhalter§.
Viele Grüße,
Thowe