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