FHEM + Plots auf anderer Tabelle als HISTORY zugreifen = ???

[o.l.i]

Hallo FHEM Leute,

ich nutze FHEM mit DBlog und habe bereits Plots kreiert welche auf den Daten in der HISTORY Tabelle basieren. Die wichtigsten Daten in der HISTORY Tabelle werden bei mir strukturiert in andere Tabellen verschoben und aufbereitet und Daten in der History werden älter als 30 Tage gelöscht.
Da die FHEM Plots aber standardmäßig auf die History Tabelle zugreifen, kann ich keine Plots anlegen die auf älteren Daten basieren, da Sie in einer anderen Tabelle verschoben wurden.

Kann ich pro FHEM Plot angeben auf welche Tabelle er die Daten erhält?
Ich hoffe die Kategorie "Anfängerfragen" passt hier. Habe keine naheliegendere Kategorie gefunden

Danke für euren Support,

Oliver

[DS_Starter]

Das müsste m.E. nach funktionieren wenn du deine Tabelle in der SVG Definition an der Stelle des Logfiles angibst. Probiert habe ich es nicht.
Also etwa:

Code Auswählen Erweitern

define <name> SVG <logDevice>:<gplotfile>:<deine Tabelle>

In "Automatisierung" (DbLog) hätte deine Frage gut hineingepasst, oder auch "Frontends/SVG/Plots/logProxy" (SVG).

[betateilchen]

Voraussetzung wäre aber, dass die zusätzliche Tabelle in einer Datenbank liegt, auf die FHEM per DbLog zugreifen kann.

Kann ich pro FHEM Plot angeben auf welche Tabelle er die Daten erhält

Du MUSST sogar immer angeben, aus welcher Tabelle die Daten kommen. Und zusätzlich auch, aus welcher Datenbank (genauer: aus welchem DbLog device) die gewünschte Tabelle stammt.

Da die FHEM Plots aber standardmäßig auf die History Tabelle zugreifen

Diese Behauptung ist schlichtweg falsch. HISTORY wird verwendet, weil es üblicherweise im define des SVG so angegeben ist.

[o.l.i]

Hallo,

danke für eure Rückmeldung.

Ich hatte dies bereits ausprobiert bevor ich diesen Thread geschrieben habe, da dies naheliegend war. Aber leider ohne Erfolg.
D.h. ich habe einen funktionierenden Plot:
define SVG_DBLogging_1 SVG DBLogging:SVG_DBLogging_1:HISTORY

Und eben den Plot, der nicht funktioniert:
define SVG_DBLogging_2 SVG DBLogging:SVG_DBLogging_2:PowerUtil

--> Im FHEM log (loglevel = 5) habe ich für beide Plots die gleichen Einträge. Ich sehe keinen Fehler oder anderen Hinweis dem ich nachgehen könnte.

[DS_Starter]

Ich habe auch inzwischen noch ein bisschen geschaut.
Mir ist eine Stelle aufgefallen, wo eine Begrenzung der nutzbaren Optionen stattfindet.

Ich werde dir eine DbLog Testversion erstellen und melde mich wieder.

[o.l.i]

OK, super. Bin gespannt.

[DS_Starter]

So, in meinem contrib liegt die Testversion.
Zum Download in der FHEMWEB Kommandozeile inklusive der Anführungszeichen angeben und danach FHEM restarten:

Code Auswählen Erweitern

"wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"

Dann musst du die Tabellenangabe in deinem SVG-Device modifizieren indem du "table_" vor deine Tabelle schreibst, also z.B.:

          define SVG_DBLogging_2 SVG DBLogging:SVG_DBLogging_2:table_PowerUtil

Man kann auch TABLE_ oder Table_ schreiben, DbLog versteht das.

Bin gespannt ob es damit läuft.
Bei meinem Test mit Table_history hat es funktioniert.

[o.l.i]

Hallo DS_Starter,

-ich habe ein "update all" mit anschließendem neustart von FHEM gemacht.
-Dann "wget -qO ./FHEM/93_DbLog.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm" mit neustart
-Die neue alternative DB eingetragen: define SVG_DBLogging_2 SVG DBLogging:SVG_DBLogging_2:table_PowerUtil
-FHEM neustart
-Danach im Gplot Editor nochmal das Device:Reading definiert.

--> Es erscheint jetzt gar nichts. Sprich, davor war zumindest ein leerer plot

-die *.PM Datei liegt im FHEM Verzeichnis und deine Änderungen mit der alternativen Table ist auch drin
-Wenn ich im gleichen Plot die DB ändere von :table_PowerUtil auf :history ... dann habe ich sofort ein Plot mit Daten
-Im Log habe ich keine Auffälligkeiten gefunden.

Eine Idee?

[DS_Starter]

Ja, das war wohl nur die halbe Wahrheit. Neue Testversion kommt gleich 

[DS_Starter]

Jetzt DbLog nochmal aus dem contrib ziehen und restarten. SVG wieder so anpassen wie du gemacht hast.

[o.l.i]

Immer noch gleiches Spiel.

-Deine Datei mit dem neuen Timestamp wurde gezogen
-DB Eintrag: define SVG_DBLogging_2 SVG DBLogging:SVG_DBLogging_2:table_PowerUtil
-FHEM neustart

-> Kein Plot zu sehen.
-Mit Änderung auf :history kommt sofort der Plot mit Daten

[DS_Starter]

Dann setze im DbLog bitte verbose=4 und rufe dein SVG auf.
Es sollte im Log eine Ausschrift wie diese erscheinen:

2023.08.14 17:38:53.592 4: DbLog LogDB1 - ################################################################
2023.08.14 17:38:53.594 4: DbLog LogDB1 - ###                  new get data for SVG                    ###
2023.08.14 17:38:53.594 4: DbLog LogDB1 - ################################################################
2023.08.14 17:38:53.595 4: DbLog LogDB1 - main PID: 24760, secondary PID: 4343
2023.08.14 17:38:53.598 4: DbLog LogDB1 - Executing SQL: SHOW VARIABLES LIKE 'collation_database'
2023.08.14 17:38:53.600 4: DbLog LogDB1 - SQL result: collation_database utf8_bin
2023.08.14 17:38:53.601 4: DbLog LogDB1 - Database Character set is >utf8_bin<
2023.08.14 17:38:53.602 4: DbLog LogDB1 - simple do statement: set names "utf8" collate "utf8_bin"
2023.08.14 17:38:53.602 4: DbLog LogDB1 - Created new DBHU for PID: 4343
2023.08.14 17:38:53.603 4: LogDB1 - PID: 4343, Processing Statement:
SELECT
                      DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'),
                      DEVICE,
                      READING,
                      VALUE
                       FROM fhemtest1.history WHERE 1=1 AND DEVICE = 'MyWetter' AND READING = 'temperature' AND TIMESTAMP >= STR_TO_DATE('2023-08-14 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2023-08-15 00:00:00', '%Y-%m-%d %H:%i:%s') ORDER BY TIMESTAMP
2023.08.14 17:38:53.620 4: LogDB1 - PID: 4343, rows count: 32


Das FROM... sollte natürlich jetzt deine Tabelle enthalten.

EDIT: probiere bei die auch mal     define SVG_DBLogging_2 SVG DBLogging:SVG_DBLogging_2:table_HISTORY

[o.l.i]

-table_history funktioniert
-table_history2 (DB gibt es nicht) hat die gleichen Auswirkungen wie table_PowerUtil. Sprich, kein Plot sichtbar.

Bezügl. Log. Ich habe nur das FHEM log aber kein DB log. Ist dies ein Filelog was ich dann erst definieren muss? Habe im Netz auf die Schnelle dazu nichts passendes gefunden.

[DS_Starter]

Die Ausschriften sind aus dem FHEM Log, kein Filelog.

-table_history funktioniert

Schonmal gut.

[DS_Starter]

In der Zwischenzeit habe ich eine Tabelle histclone als Kopie der history in meiner DB angelegt.
Wenn ich die SVG Definition entsprechend anpasse in:

   

Code Auswählen Erweitern

defmod SVG_LogDB1_5 SVG LogDB1:SVG_LogDB1_5:table_histclone
wird es tadellos ausgeführt und im Log sieht man es auch:

2023.08.14 19:36:38.098 4: LogDB1 - ################################################################
2023.08.14 19:36:38.101 4: LogDB1 - ###                  new get data for SVG                    ###
2023.08.14 19:36:38.102 4: LogDB1 - ################################################################
2023.08.14 19:36:38.102 4: LogDB1 - main PID: 24760, secondary PID: 6856
2023.08.14 19:36:38.106 4: LogDB1 - Executing SQL: SHOW VARIABLES LIKE 'collation_database'
2023.08.14 19:36:38.108 4: LogDB1 - SQL result: collation_database utf8_bin
2023.08.14 19:36:38.109 4: LogDB1 - Database Character set is >utf8_bin<
2023.08.14 19:36:38.110 4: LogDB1 - simple do statement: set names "utf8" collate "utf8_bin"
2023.08.14 19:36:38.111 4: LogDB1 - Created new DBHU for PID: 6856
2023.08.14 19:36:38.112 4: LogDB1 - PID: 6856, Processing Statement:
SELECT
                      DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'),
                      DEVICE,
                      READING,
                      VALUE
                       FROM histclone WHERE 1=1 AND DEVICE = 'MyWetter' AND READING = 'temperature' AND TIMESTAMP >= STR_TO_DATE('2023-08-14 00:00:00', '%Y-%m-%d %H:%i:%s') AND TIMESTAMP <= STR_TO_DATE('2023-08-15 00:00:00', '%Y-%m-%d %H:%i:%s') ORDER BY TIMESTAMP
2023.08.14 19:36:38.162 4: LogDB1 - PID: 6856, rows count: 36

Kann es sein, dass deine Alternativtabellen keine Leserechte für den Datenbankuser (im config-File) gewähren?