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

[DS_Starter]

Hallo zusammen,

ich habe etwas weiter entwickelt und in der Version 4.1 im Eingangsbeitrag neben einigen kleineren Änderungen am Logging (weniger/andere Ausgaben beim FHEM-Start) auch eine Funktion "deviceRename" und eine neue Rolle ("Agent") eingebaut. Die neue Rolle dient dazu über einen automatisierten Prozess auf Device-Umbenennungen im System zu reagieren und die Device-Namen  in den Datenbanken bzw. DbRep-Definition nachzuziehen und konsistent zu halten.
"deviceRename" dient zum manuellen Umbenennen von Device-Namen in der Datenbank.

Bitte lest dazu die Ergänzungen im ersten Beitrag bzw. hier die Erläuterung zum Autorename:

DbRep Agent - automatisches Ändern von Device-Namen in Datenbanken und DbRep-Definitionen nach FHEM "rename"

Mit dem Attribut "role" wird die Rolle des DbRep-Device festgelegt. Die Standardrolle ist "Client". Mit der Änderung der Rolle in "Agent" wird das Device veranlasst auf Umbenennungen von Geräten in der FHEM Installation zu reagieren.

Durch den DbRep-Agenten werden folgende Features aktiviert wenn ein Gerät in FHEM mit "rename" umbenannt wird:

*  in der dem DbRep-Agenten zugeordneten Datenbank (Internal Database) wird nach Datensätzen mit dem alten Gerätenamen gesucht und dieser Gerätename in allen betroffenen Datensätzen in den neuen Namen geändert.

*  in den existierenden DbRep-Definitionen vom Typ "Client" wird ein evtl. gesetztes Attribut "device = alter Devicename" in "device = neuer Devicename" geändert. Dadurch werden Auswertungsdefinitionen bei Geräteumbenennungen automatisch konstistent gehalten.

Mit der Änderung in einen Agenten sind folgende Restriktionen verbunden die mit dem Setzen des Attributes "role = Agent" eingeschaltet und geprüft werden:

*  es kann nur einen Agenten pro Datenbank in der FHEM-Installation geben. Ist mehr als eine Datenbank mit DbLog definiert, können ebenso viele DbRep-Agenten eingerichtet werden

*  mit der Umwandlung in einen Agenten wird nur noch das Set-Komando "renameDevice" verfügbar sein sowie nur ein eingeschränkter Satz von DbRep-spezifischen Attributen zugelassen. Wird ein DbRep-Device vom bisherigen Typ "Client" in einen Agenten geändert, werden evtl. gesetzte und nun nicht mehr zugelassene Attribute glöscht.

Die Aktivitäten wie Datenbankänderungen bzw. Änderungen an anderen DbRep-Definitionen werden im Logfile mit verbose=3 protokolliert. Damit die renameDevice-Funktion bei großen Datenbanken nicht in ein timeout läuft, sollte das Attribut "timeout" entsprechend dimensioniert werden. Wie alle Datenbankoperationen des Moduls wird auch das Autorename nonblocking ausgeführt.

Beispiel für die Definition eines DbRep-Device als Agent:

                       define Rep.Agent DbRep LogDB
                      attr Rep.Agent devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
                      attr Rep.Agent icon security
                      attr Rep.Agent role Agent
                      attr Rep.Agent room DbLog
                      attr Rep.Agent showproctime 1
                      attr Rep.Agent stateFormat { ReadingsVal("$name","state", undef) eq "running" ? "renaming" : ReadingsVal("$name","state", undef). " »; ProcTime:                               
                      ".ReadingsVal("$name","sql_processing_time", undef)." sec"}
                     attr Rep.Agent timeout 3600


Grüße,
Heiko

[DS_Starter]

Die Version 4.1.2 im Eingangsthread habe ich noch dahingehend verändert dass bei Umbenennung eines Devices dieses Device in der Definition des dem DbRep-Agenten angeschlossenen DbLog-Instanz ebenfalls geändert wird. Dadurch wird das umbenannte Gerät sogleich weiter in der Datanbank geloggt.

Gerne wieder feedback.

VG

[cwagner]

Die Idee des Rename-Agenten ist super, wie auch überhaupt die Idee zu diesem Modul.

Was mir noch nicht gelungen ist, sind RegEx in Device- oder Readingnamen. Ich möchte beispielsweise in allen PID-Devices mit Namen RR_.* (z.B. RR_Bad oder RR_Kueche) einen testweise zehntausendfach protokollierten Parameter mit Namen p_.* (z.B. p_i oder p_p oder p_d)

Christian

[DS_Starter]

Hallo Christian,

auf die Berücksichtigung von RegEX-Ausdrücken in den device/Reading-Selektionsbedingungen habe ich bis jetzt bewußt verzichtet.
Das hängt damit zusammen dass es auch Funktionen wie "delEntries" gibt, die mit Regex-Ausdrücken durchaus Schaden anrichten können bzw. nicht wie gewünscht funktionieren würden. Deswegen muß man bis dato exakte Bezeichnungen angeben.

Da müßte ich noch etwas Aufwand reinstecken um Regex-Ausdrücke ausschließlich bei "unproblematischen"  Selekt-Operationen zu erlauben, sonst nicht.
Ich denke mal darüber nach wie so etwas zu machen wäre ohne Gefahr zu laufen dass sich jemand in einem Moment der Unachtsamkeit seine Daten zerschießt ....

viele Grüße
Heiko

[cwagner]

Moin, Heiko,

den Sicherheitsaspekt kann ich gut nachvollziehen und er hätte für mich auch höhere Priorität...

Danke, dass Du Dich mit dem Thema auseinandersetzen willst.

Christian

[DS_Starter]

Hallo zusammen,

ich habe für das Modul begonnen einen Wiki Eintrag anzulegen. Bisher habe ich die Beschreibungen aus dem Eingangsthread dorthin verlagert und auch schon begonnen Praxisbeispiele zu beschreiben.

Zum Beispiel den Export/Import von Datensätzen mit DbRep:

http://www.fhemwiki.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Datens.C3.A4tze_.28Devices.29_von_einer_Datenbank_in_eine_andere_umziehen_.28Export.2FImport.29

Ergänzung/Beiträge sind herzlich willkommen.

Grüße,
Heiko

[DS_Starter]

Hi Christian, @all,

nun ist es auch möglich SQL-Wildcards in den Selektionen zu verwenden.
Hier die kurzen Hinweise dazu:

Hinweis zur SQL-Wildcard Verwendung:
Innerhalb der Attribut-Werte für "device" und "reading" können SQL-Wildcards, "%" und "_", angegeben werden. Dabei ist "%" = beliebig viele Zeichen und "_" = ein Zeichen.
Dies gilt für alle Funktionen außer "insert", "deviceRename" und "delEntries".
Die Funktion "insert" erlaubt nicht dass die genannten Attribute das Wildcard "%" enthalten, "_" wird als normales Zeichen gewertet.
Die Löschfunktion "delEntries" wertet die Zeichen "$", "_" NICHT als Wildcards und löscht nur Device/Readings die exakt wie in den Attributen angegeben in der DB gespeichert sind.

Die Version ist V4.2 im Eingangsthread.
Gerne wieder Feedback.

VG,
Heiko

[DS_Starter]

Hi @all,

habe die neue Version mit SQL-Wildcards enabled eingecheckt.

Grüße,
Heiko

[DS_Starter]

Hallo zusammen,

es gibt wieder eine Version 4.5 mit neuen Funktionen. Die eingebauten Get-Kommandos liefern diverse Metainformationen der betriebenen Datenbank.
Hier wieder ein Auszug aus der Commandref:

== Get ==

Die Get-Kommandos von DbRep dienen dazu eine Reihe von Metadaten der verwendeten Datenbankinstanz abzufragen. Dies sind zum Beispiel eingestellte Serverparameter, Servervariablen, Datenbankstatus-  und Tabelleninformationen.
Die verfügbaren get-Funktionen sind von dem verwendeten Datenbanktyp abhängig. So ist für SQLite z.Zt. nur "svrinfo" verfügbar.
Die Funktionen liefern nativ sehr viele Ausgabewerte die über über funktionsspezifische Attribute abgrenzbar sind.

Hinweis:
Nach der Ausführung einer get-Funktion in der Detailsicht einen Browserrefresh durchführen um die Ergebnisse zu sehen !



* dbstatus : listet globale Informationen zum MySQL Serverstatus (z.B. Informationen zum Cache, Threads, Bufferpools, etc. ). Es werden zunächst alle verfügbaren Informationen berichtet. Mit dem [[#Attribute | Attribut]] "showStatus" kann die Ergebnismenge eingeschränkt werden, um nur gewünschte Ergebnisse abzurufen.

                   Bespiel:    attr ... showStatus %uptime%,%qcache%   
                   # Es werden nur Readings erzeugt die im Namen "uptime" und "qcache" enthalten

Detailinformationen zur Bedeutung der einzelnen Readings sind [http://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html hier] verfügbar.

* dbvars :  zeigt die globalen Werte der MySQL Systemvariablen. Enthalten sind zum Beispiel Angaben zum InnoDB-Home, dem Datafile-Pfad, Memory- und Cache-Parameter, usw. Die Ausgabe listet zunächst alle verfügbaren Informationen auf. Mit dem [[#Attribute | Attribut]] "showVariables" kann die Ergebnismenge eingeschränkt werden um nur gewünschte Ergebnisse abzurufen.

                   Bespiel:    attr ... showVariables %version%,%query_cache%
                   # Es werden nur Readings erzeugt die im Namen "version" und "query_cache" enthalten

Weitere Informationen zur Bedeutung der ausgegebenen Variablen sind [http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html hier] verfügbar.

* svrinfo : allgemeine Datenbankserver-Informationen wie z.B. die DBMS-Version, Serveradresse und Port usw. Die Menge der Listenelemente ist vom Datenbanktyp abhängig. Mit dem [[#Attribute | Attribut]] "showSvrInfo" kann die Ergebnismenge eingeschränkt werden.

                   Bespiel:    attr ... showSvrInfo %SQL_CATALOG_TERM%,%NAME%
                   # Es werden nur Readings erzeugt die im Namen "SQL_CATALOG_TERM" und "NAME" enthalten

Weitere Erläuterungen zu den gelieferten Informationen sind [https://msdn.microsoft.com/en-us/library/ms711681(v=vs.85).aspx hier] zu finden.

* tableinfo : ruft Detailinformationen der in einem MySQL-Schema angelegten Tabellen ab. Die ausgewerteten Schemata sind abhängig von den Rechten des verwendeten Datenbankusers (default: das DB-Schema der der current/history-Tabelle). Mit dem [[#Attribute | Attribut]] "showTableInfo" können die Ergebnisse eingeschränkt werden.

                   Bespiel:    attr ... showTableInfo current,history
                   # Es werden nur Information der Tabellen current,history angezeigt

Erläuterungen zu den erzeugten Readings sind [http://dev.mysql.com/doc/refman/5.7/en/show-table-status.html hier] zu finden.


Grüße,
Heiko

[DerFrickler]

aktuelle Meldung:

Code: [Auswählen]

errortext
Can't connect to data source 'dbi:' because I can't work out what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix and the DBI_DRIVER env var is not set) at ./FHEM/93_DbRep.pm line 1759.
2016-10-20 17:03:13

[DS_Starter]

Hmm, kann mit der Meldung nicht viel anfangen, bzw. betrifft die Stelle im Coding an der eine DB-Verbindung aufgebaut wird.
Dieses Teilstück ist schon "ewig" nicht geändert und wird auch in jeder Funktion aufgerufen, egal ob diffValue (wie hier) oder eine andere Funktion.
Es ist immer der gleiche Aufruf:

Code: [Auswählen]

eval {$dbh = DBI->connect("dbi:$dbconn", $dbuser, $dbpassword, { PrintError => 0, RaiseError => 1, AutoInactiveDestroy => 1 });};

Kann es bei mir auch nicht provozieren .... läuft alles.

Nach ein bisschen googeln kommt der Fehler wenn der Term "dbi:$dbconn" nicht richtig bedient wird oder ein Schreibfehler, den können wir ausschließen.
Aber "dbi:$dbconn" wird aus dem entsprechenden DbLog-Device abgeleitet. Schau mal was ein list <Dbrep-Device> sagt.
Es muß einen Teil geben der wie hier die dbconn-Variable ausschreibt:

Code: [Auswählen]

     STATE      connected
     TYPE       DbLog
     dbconn     mysql:database=fhem;host=192.168.2.10;port=3306
     dbuser     fhem

Wenn das nicht der Fall sein sollte, konnte diese Variabke nicht von dem DbLog-Device bezogen/abgeleitet werden. In dem Fall schau mal bitte ob dein DbLog-Device ordnungsgemäß funktioniert und mit der DB verbunden ist.
In diesem Umfeld würde ich mal bei dir suchen.

Grüße
Heiko

[DerFrickler]

ich denke ich habe den Verursacher gefunden:

Code: [Auswählen]

Messages collected while initializing FHEM:
configDB: DbLog_meterReading already defined, delete it first

[DS_Starter]

Denke ich auch. Hab grad mal ein Nonsens-Device angelegt, also ein DbRep definiert mit einem DbLog was es nicht gibt.
Dann kommt der Fehler. Aber man sieht auch dass das DbRep-Device auf "disconnected" steht.
Hab mal ein Screenshot angehängt.
Sieht wahrscheinlich bei dir auch so aus.

[DerFrickler]

ja genau, das letzte update hat mir da etwas die config zerschossen.. lässt sich aber leicht reparieren.

[DS_Starter]

Hallo zusammen,

das Ende der Sommerzeit hat es nötig gemacht im Modul Korrekturen einzupflegen.
Bei entsprechenden Zeitselektionen kam es zu falschen/fehlenden Ergebnissen aufgrund der Zeitverschiebung.
Ich habe die neue Version 4.6 im ersten Beitrag eingehängt.
Checke die neue Version heute Abend auch noch ein.

Bitte auch testen, ich hoffe habe alles richtig gefixt.

Grüße
Heiko