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

[DS_Starter]

Da habe ich auch lange darüber sinniert und die fhem.pl aber auch die 99_Utils.pm abgesucht. Inzwischen kann ich mir auch vorstellen, weshalb es doch funktioniert haben könnte.

In den besagten Attributen war dokumentiert FHEM Befehle und seit vergangenen Mai (V8.52.7) auch Perl Code zur Ausführung bringen zu können. Im Zuge der Erweiterung hatte ich damals auch eine Syntaxprüfung im Attr eingebaut was vorher nicht der Fall war.
Später wird dieser Code dann mit AnalyzeCommandChain bzw. Perl in der Sub AnalyzePerlCommand ausgeführt (war vor V8.52.7 auch so).
Die Sub stellt intern $mday,$month,$we usw. zur Verfügung. Dadurch klappt es dann bei der Ausführung.

Blöderweise hatte ich aber im Check beim Setzen des Attr nur ein einfaches eval verwendet. Da fehlen die Variablen.

@Thome, wenn du bestätigen könntest DbRep schon ziemlich lange (konkret seit Mai 2023) nicht upgedated zu haben und nun mit dem letzten Update auf diesen Fehler gelaufen bist, hätten wir eine schlüssige Erklärung für das Phänomen.

Ungeachtet dessen schaue ich mal den Check entsprechend anzupassen.

LG

[betateilchen]

Später wird dieser Code dann mit AnalyzeCommandChain bzw. Perl in der Sub AnalyzePerlCommand ausgeführt (war vor V8.52.7 auch so).
Die Sub stellt intern $mday,$month,$we usw. zur Verfügung. Dadurch klappt es dann bei der Ausführung.

Das ist genau das, was ich mit "stehen immer nur temporär zur Verfügung" meinte: immer dann wenn die fhem-internen Analyze...() Funktionen im Spiel sind, deshalb funktioniert es z.B. auch in der FHEM Befehlszeile.

Ok, das mit Deiner zusätzlichen Syntaxprüfung hatte ich nicht berücksichtigt. Aber wenn "nur" das das Problem ist, sollte ein Umbau ohne großen Aufwand möglich sein.


geht

Code Auswählen Erweitern

2023.12.08 17:23:39 3: DbRep dbRep_ub - Entries of /opt/fhem/sqldb/fhemlog.db.history deleted: ub4--w3_/--0
2023.12.08 17:23:39 3: DbRep dbRep_ub - execute command after delEntries: '{Debug $hms}'
2023.12.08 17:23:39 1: DEBUG>17:23:39

Grundsätzlich habe ich dafür lediglich an zwei Stellen (beim Setzen des Attributes und in _DbRep_procCode) das eval durch AnalyzePerlCommand ersetzt. Wobei an der zweiten Stelle ja sogar schon ein AnalyzeCommandChain vorgesehen ist, wenn ... (?)

[DS_Starter]

Bin grad nicht am Rechner ... führt AnalyzePerlCommand das Kommando nicht gleich aus? Beim Attr prüfen sollte nur die Syntax gecheckt aber nicht ausgeführt werden. War vermutlich der Grundd weshalb ich AnalyzePerlCommand nicht im Attr verwendet hatte? Muss ich später mal schauen welche Hirnwindungen ich damals aktiviert hatte. 

[betateilchen]

führt AnalyzePerlCommand das Kommando nicht gleich aus?

Ja, aber ich wollte auch nicht sagen, dass mein Ansatz die tatsächliche Lösung ist. Es sollte nur der Beleg dafür sein, dass Deine Vermutung zur Ursache stimmt.

Eigentlich bin ich mir gar nicht sicher, ob Du die Attributbehandlung überhaupt selbst machen musst. Es könnte sein, dass CommandAttr() in fhem.pl das schon für Dich übernimmt und perlSyntaxCheck() aufruft. In diesem Fall würde sogar ggf. das globale Attribut zum Abschalten dieser Prüfung greifen. Aber das habe ich jetzt nicht geprüft.

Schau es Dir einfach in Ruhe an.


Noch ein bisschen rumgetestet:

Code Auswählen Erweitern

perlSyntaxCheck("Debug $hmms")
liefert:

Code Auswählen Erweitern

Global symbol "$hmms" requires explicit package name (did you forget to declare "my $hmms"?) at (eval 5196) line 1.

Code Auswählen Erweitern

perlSyntaxCheck("Debug $hms")
liefert nichts, auch keinen Eintrag im Log, wird also nicht ausgeführt, sondern nur geprüft.

[DS_Starter]

Habe eine Lösung implementiert und eingecheckt.
perlSyntaxCheck hat den Check abgedeckt. Allerdings kamen bei der Übergabe von $name, $hash wiederum Fehler und dadurch wäre die lt. commandref beschriebene Syntax nicht mehr gegeben. Deswegen habe ich eine etwas andere Lösung gewählt.
Wahrscheinlich werde ich die Variablenübergabe nochmal ändern und dafür %evalspecials einsetzen, muß ich testen ob das in dem Kontext klappt.
Möglicherweise schon am WE, mal schauen.

@Thome, morgen früh ist das Update verfügbar. Damit sollte dein use case wieder funktionieren.

Grüße,
Heiko

[Thowe]

Hallo Heiko,
vielen Dank für die schnelle Reaktion: Die globalen Variablen funktionieren wieder! Das spart Code im Perl-Konstrukt.
Übrigens: Der Syntax-Check hatte dafür gesorgt, dass das betreffende Attribut komplett gelöscht wurde. Genial, ansatzweise selbstheilender Code bzw. Konfiguration
Viele Grüße,
Thowe

[DS_Starter]

 
schönes WE.

[betateilchen]

Übrigens: Der Syntax-Check hatte dafür gesorgt, dass das betreffende Attribut komplett gelöscht wurde.

Nein, er hatte dafür gesorgt, dass das Attribut erst gar nicht angelegt wurde...

[Thowe]

Das ist eine Sichtweise. Die andere ist, dass das Attribut mit $mday bereits jahrelang funktioniert hatte, bis es weg war. Auskommentieren in fhem.cfg hätte auch gereicht.

[betateilchen]

Auskommentieren in fhem.cfg hätte auch gereicht.

Nein.

Dazu muss man wissen und verstanden haben, wie das Speichern einer Konfiguration in FHEM funktioniert.

Vereinfacht gesagt: es wird nicht die bestehende Konfigurationsdatei verändert, sondern immer eine neue Konfigurationsdatei aus dem gerade laufenden FHEM erzeugt. Dabei werden nur die aktuell definierten devices mit ihrem "define" und allen zugehörigen "attr" (der vorhandenen (!) Attribute) gespeichert.

Es wird beim Speichern der Konfiguration nichts gelöscht. Das Attribut war zum Zeitpunkt des Speicherns einfach nicht (mehr) vorhanden, weil es beim letzten FHEM Start nicht angelegt wurde.

[Thowe]

Danke für die Erläuterung.
Ich möchte auf noch ein Problem hinweisen:
Im Konstrukt lt. FHEM-Editor

Code Auswählen Erweitern

attr test_rep executeAfterProc {if($mday==1) {fhem("set test1 1;;set test2 2")} else {fhem("set test3 3")} }
wird der Befehl

Code Auswählen Erweitern

set test2 2nicht mehr ausgeführt. In fhem.cfg stehen als Befehlstrenner ;;;;. Wie soll das Escapen funktionieren?
Nach einem Rollback 93_DbRep.pm auf einen Versionsstand vom 17.02.23 funktioniert es.
Viele Grüße, Thowe

[DS_Starter]

Danke für den Hinweis.
Schaue ich mir an. Wollte ohnehin wegen des letzten Themas die Ausführungsroutine noch einmal in Ruhe überprüfen.

LG

[betateilchen]

Bei mir funktioniert das problemlos.

Code Auswählen Erweitern

attr logRep executeAfterProc { if($mday==17) {fhem("set test1 1;;set test2 2")} else {fhem("set test3 3")} }

liefert im Log:

Code Auswählen Erweitern

2023.12.17 10:49:50 3: DbRep logRep - execute command after dump: '{ if($mday==17) {fhem("set test1 1;set test2 2")} else {fhem("set test3 3")} }'
2023.12.17 10:49:50 3: set test1 1;set test2 2 : Please define test1 first
Please define test2 first

Dass dabei zwei Fehlermeldungen kommen, ist logisch, da es bei mir weder test1 noch test2 gibt.
Aber ausgeführt werden beide set Befehle.

[betateilchen]

In fhem.cfg stehen als Befehlstrenner ;;;;. Wie soll das Escapen funktionieren?

In meiner Konfiguration stehen nur zwei Semikolon.

Code Auswählen Erweitern

search result for device: logRep in version: 1
--------------------------------------------------------------------------------
define logRep DbRep logMetallDb
attr logRep executeAfterProc { if($mday==17) {fhem("set test1 1;;set test2 2")} else {fhem("set test3 3")} }


[Thowe]

Hallo ihr Sonntagsarbeiter, das ist der feine Unterschied, auf den ich hinweisen wollte. Früher waren für Perl-Inline-FHEM-Kommandos zwei ,,escapete" Semikolons notwendig. Oder muss ich schreiben: Sie wurden korrekt verarbeitet. Mit dem Syntax-Check ist dem offensichtlich nicht mehr so.
Danke für die Analyse.