DBlog zusammenspiel mit SVG Plots

Jorge3711 · 05 April 2017, 21:16:08

Hallo zusammen,

gestern habe ich einen 2. HM-ES-PMSw1-Pl in Betrieb genommen und wollte natürlich die gemessenen Werte in meine Datenbank schreiben lassen. Daher folgendes konfiguriert:

Code Auswählen


attr energie_strom_trockner_Pwr DbLogInclude energy,power
attr energie_strom_trockner_Pwr event-on-change-reading energy,power

Werte kommen in der Datenbank an, Tabelle history.

In einem bestehenden SVG Plot kann ich die Werte aber nicht auswählen. Mir ist bekannt, dass mit den großen Veränderungen Ende letzten Jahres das DBlog Device entsprechend angepasst werden musste um SVG Plots aus der DB zu versorgen. Mein DBlog Device sieht so aus:

Code Auswählen


Internals: 
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32 
   CONFIGURATION ./db.conf 
   DBMODEL    MYSQL 
   DEF        ./db.conf .*:.* 
   MODE       asynchronous 
   NAME       logDB 
   NR         33 
   NTFY_ORDER 50-logDB 
   PID        11991 
   REGEXP     .*:.* 
   STATE      connected 
   TYPE       DbLog 
   VERSION    2.14.4 
   dbconn     mysql:database=fhem;host=localhost;port=3306 
   dbuser     fhemsql 
   Helper: 
     COLSET     1 
     DEVICECOL  64 
     EVENTCOL   512 
     READINGCOL 64 
     TYPECOL    64 
     UNITCOL    32 
     VALUECOL   128 
   Readings: 
     2017-04-05 21:08:27   CacheUsage      15 
     2017-04-05 21:04:13   NextSync        2017-04-05 21:14:13 or if CacheUsage 500 reached 
     2017-04-05 21:04:13   background_processing_time 0.1895 
     2017-04-05 21:04:13   sql_processing_time 0.1283 
     2017-04-05 21:04:13   state           connected 
   Cache: 
     index      62 
     Memcache: 
       48         2017-04-05 21:05:26|Buderus|BDKM|WaterTemp: 51.8|WaterTemp|51.8| 
       49         2017-04-05 21:05:26|Buderus|BDKM|PowerModulation: 69|PowerModulation|69| 
       50         2017-04-05 21:05:26|Buderus|BDKM|SupplyTemp: 31.1|SupplyTemp|31.1| 
       51         2017-04-05 21:05:26|Buderus|BDKM|HC1InputTemp: 26.4375|HC1InputTemp|26.4375| 
       52         2017-04-05 21:05:26|Buderus|BDKM|HC1ReturnTemp: 20.625|HC1ReturnTemp|20.625| 
       53         2017-04-05 21:05:45|energie_strom_haupt_Ch01|CUL_HM|power: 429|power|429| 
       54         2017-04-05 21:05:48|temp.dg.diffmessure.t2|CUL_HM|temperature: 21.3|temperature|21.3|°C 
       55         2017-04-05 21:08:11|temp.dg.diffmessure.t1|CUL_HM|temperature: 21.1|temperature|21.1|°C 
       56         2017-04-05 21:08:22|Buderus|BDKM|WaterTemp: 51.4|WaterTemp|51.4| 
       57         2017-04-05 21:08:22|Buderus|BDKM|PowerModulation: 68|PowerModulation|68| 
       58         2017-04-05 21:08:22|Buderus|BDKM|OutdoorTemp: 11.1|OutdoorTemp|11.1| 
       59         2017-04-05 21:08:22|Buderus|BDKM|SupplyTemp: 32.3|SupplyTemp|32.3| 
       60         2017-04-05 21:08:22|Buderus|BDKM|HC1InputTemp: 27.5625|HC1InputTemp|27.5625| 
       61         2017-04-05 21:08:22|Buderus|BDKM|HC1ReturnTemp: 21.375|HC1ReturnTemp|21.375| 
       62         2017-04-05 21:08:27|energie_strom_haupt_Ch01|CUL_HM|power: 413|power|413| 
Attributes: 
   DbLogSelectionMode Include 
   DbLogType  Current/History 
   asyncMode  1 
   room       Zentrale 
   showproctime 1 
   shutdownWait 2 
   syncInterval 600 
   verbose    2 
   webCmd     listCache:commitCache

Lt. Commandref sollte das Attribut DBLogType auf Current/History gesetzt werden, so wurde es damals auch meine ich im entsprechenden DBlog Weiterentwicklungsthread beschrieben. Wenn ich in die Current Tabelle schaue, fehlen allerdings die Einträge:

Code Auswählen


MariaDB [fhem]> SELECT DISTINCT(DEVICE) FROM current;
+---------------------------------+
| DEVICE                          |
+---------------------------------+
| Buderus                         |
| temp.dg.diffmessure.t1          |
| temp.dg.diffmessure.t2          |
| energie_strom_waschmaschine_Pwr |
| Robin                           |
| tfk.og.terrasse                 |
| Carsten                         |
| Zelmira                         |
| energie_strom_haupt_Ch01        |
| HMLAN1                          |
+---------------------------------+
10 rows in set (0.00 sec)

MariaDB [fhem]> SELECT DISTINCT(DEVICE) FROM history;
+---------------------------------+
| DEVICE                          |
+---------------------------------+
| Buderus                         |
| Carsten                         |
| HMLAN1                          |
| Robin                           |
| Zelmira                         |
| energie_strom_haupt_Ch01        |
| energie_strom_trockner_Pwr      |
| energie_strom_waschmaschine_Pwr |
| energie_waschmaschine_Pwr       |
| temp.dg.diffmessure.t1          |
| temp.dg.diffmessure.t2          |
| tfk.og.terrasse                 |
+---------------------------------+
12 rows in set (0.00 sec)

Man sieht also, dass in der current Tabelle das neue Device energie_strom_trockner_Pwr nicht auftaucht, sehr wohl aber in der history Tabelle. Fhem ist tagesaktuell.

Wo liegt der Hase im Pfeffer? Für Hinweise dankbar!

DS_Starter · 05 April 2017, 22:21:09

Hallo Jorge3711,

was wo geloggt wird sieht man mit verbose 5.
Dann schau mal bitte was der Abschnitt "New database processing cycle" aussagt:

Code Auswählen


2017.04.05 22:15:26.613 5: DbLog LogDB -> ################################################################
2017.04.05 22:15:26.613 5: DbLog LogDB -> ###              New database processing cycle               ###
2017.04.05 22:15:26.613 5: DbLog LogDB -> ################################################################
2017.04.05 22:15:26.613 5: DbLog LogDB -> MemCache contains 16 entries to process
2017.04.05 22:15:26.613 5: DbLog LogDB -> MemCache contains: 2017-04-05 22:14:52|sysmon|SYSMON|ram: Total: 2010.39 MB, Used: 328.21 MB, 16.33 %, Free: 1682.18 MB|ram|Total: 2010.39 MB, Used: 328.21 MB, 16.33 %, Free: 1682.18 MB|
2017.04.05 22:15:26.613 5: DbLog LogDB -> MemCache contains: 2017-04-05 22:14:52|sysmon|SYSMON|swap: Total: 1293.00 MB, Used: 0.00 MB,  0.00 %, Free: 1293.00 MB|swap|Total: 1293.00 MB, Used: 0.00 MB,  0.00 %, Free: 1293.00 MB|
2017.04.05 22:15:26.613 5: DbLog LogDB -> MemCache contains: 2017-04-05 22:14:52|sysmon|SYSMON|eth0_diff: RX: 0.66 MB, TX: 0.62 MB, Total: 1.28 MB|eth0_diff|RX: 0.66 MB, TX: 0.62 MB, Total: 1.28 MB|
2017.04.05 22:15:26.613 5: DbLog LogDB -> MemCache contains: 2017-04-05 22:14:52|sysmon|SYSMON|stat_cpu_percent: 1.76 0.00 0.59 97.62 0.03 0.00 0.00|stat_cpu_percent|1.76 0.00 0.59 97.62 0.03 0.00 0.00|
2017.04.05 22:15:26.613 5: DbLog LogDB -> MemCache contains: 2017-04-05 22:14:52|sysmon|SYSMON|loadavg: 0.08 0.02 0.01|loadavg|0.08 0.02 0.01|
.......................
.......................
2017.04.05 22:15:26.682 5: DbLog LogDB -> processing event Timestamp: 2017-04-05 22:14:58, Device: SMA_Energymeter, Type: SMAEM, Event: Einspeisung_Wirkleistung_Zaehler: 2339.7883, Reading: Einspeisung_Wirkleistung_Zaehler, Value: 2339.7883, Unit: 
2017.04.05 22:15:26.682 5: DbLog LogDB -> processing event Timestamp: 2017-04-05 22:14:58, Device: Dum.Energy, Type: DUMMY, Event: TotalConsumption: 485.4, Reading: TotalConsumption, Value: 485.4, Unit: W
2017.04.05 22:15:26.690 5: DbLog LogDB -> 16 of 16 events inserted into table history using PK on columns TIMESTAMP,DEVICE,READING
2017.04.05 22:15:26.733 5: DbLog LogDB -> 16 events inserted or replaced in table current using PK on columns DEVICE,READING
2017.04.05 22:15:26.752 5: DbLog LogDB -> DbLog_PushAsync finished

Ganz unten siehst du wieviel events in die current eingetragen wurden, oder ob da etwas schief ging.
Ansonsten lösche dir mal den Inhalt der Current und lasse ihn neu aufbauen. Das geht ja fix.

Grüße
Heiko

Jorge3711 · 05 April 2017, 22:44:46

Here it is:

Code Auswählen


2017.04.05 22:40:30 5: DbLog logDB -> ################################################################
2017.04.05 22:40:30 5: DbLog logDB -> ###              New database processing cycle               ###
2017.04.05 22:40:30 5: DbLog logDB -> ################################################################
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains 13 entries to process
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains: 2017-04-05 22:38:28|Buderus|BDKM|WaterTemp: 47.4|WaterTemp|47.4|
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains: 2017-04-05 22:38:28|Buderus|BDKM|PumpModulation: 0|PumpModulation|0|
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains: 2017-04-05 22:38:28|Buderus|BDKM|PowerModulation: 0|PowerModulation|0|
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains: 2017-04-05 22:38:28|Buderus|BDKM|OutdoorTemp: 10.3|OutdoorTemp|10.3|
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains: 2017-04-05 22:38:28|Buderus|BDKM|SupplyTemp: 33.2|SupplyTemp|33.2|
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains: 2017-04-05 22:38:28|Buderus|BDKM|HC1InputTemp: 29.125|HC1InputTemp|29.125|
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains: 2017-04-05 22:38:28|Buderus|BDKM|HC1ReturnTemp: 29.0625|HC1ReturnTemp|29.0625|
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains: 2017-04-05 22:38:30|energie_strom_haupt_Ch01|CUL_HM|power: 3651|power|3651|
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains: 2017-04-05 22:38:45|energie_strom_trockner_Pwr|CUL_HM|energy: 39.4|energy|39.4|
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains: 2017-04-05 22:38:45|energie_strom_trockner_Pwr|CUL_HM|power: 1913.25|power|1913.25|
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains: 2017-04-05 22:40:04|energie_strom_trockner_Pwr|CUL_HM|energy: 81.2|energy|81.2|
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains: 2017-04-05 22:40:04|energie_strom_trockner_Pwr|CUL_HM|power: 1582.02|power|1582.02|
2017.04.05 22:40:30 5: DbLog logDB -> MemCache contains: 2017-04-05 22:40:12|energie_strom_trockner_Pwr|CUL_HM|power: 0|power|0|
2017.04.05 22:40:30 5: DbLog logDB -> DbLog_PushAsync called with timeout: 1800
2017.04.05 22:40:30 5: DbLog logDB -> Start DbLog_PushAsync
2017.04.05 22:40:30 5: DbLog logDB -> Primary Key used in fhem.history: none
2017.04.05 22:40:30 5: DbLog logDB -> Primary Key used in fhem.current: none
2017.04.05 22:40:30 5: DbLog logDB -> processing event Timestamp: 2017-04-05 22:38:28, Device: Buderus, Type: BDKM, Event: WaterTemp: 47.4, Reading: WaterTemp, Value: 47.4, Unit:
2017.04.05 22:40:30 5: DbLog logDB -> processing event Timestamp: 2017-04-05 22:38:28, Device: Buderus, Type: BDKM, Event: PumpModulation: 0, Reading: PumpModulation, Value: 0, Unit:
2017.04.05 22:40:30 5: DbLog logDB -> processing event Timestamp: 2017-04-05 22:38:28, Device: Buderus, Type: BDKM, Event: PowerModulation: 0, Reading: PowerModulation, Value: 0, Unit:
2017.04.05 22:40:30 5: DbLog logDB -> processing event Timestamp: 2017-04-05 22:38:28, Device: Buderus, Type: BDKM, Event: OutdoorTemp: 10.3, Reading: OutdoorTemp, Value: 10.3, Unit:
2017.04.05 22:40:30 5: DbLog logDB -> processing event Timestamp: 2017-04-05 22:38:28, Device: Buderus, Type: BDKM, Event: SupplyTemp: 33.2, Reading: SupplyTemp, Value: 33.2, Unit:
2017.04.05 22:40:30 5: DbLog logDB -> processing event Timestamp: 2017-04-05 22:38:28, Device: Buderus, Type: BDKM, Event: HC1InputTemp: 29.125, Reading: HC1InputTemp, Value: 29.125, Unit:
2017.04.05 22:40:30 5: DbLog logDB -> processing event Timestamp: 2017-04-05 22:38:28, Device: Buderus, Type: BDKM, Event: HC1ReturnTemp: 29.0625, Reading: HC1ReturnTemp, Value: 29.0625, Unit:
2017.04.05 22:40:30 5: DbLog logDB -> processing event Timestamp: 2017-04-05 22:38:30, Device: energie_strom_haupt_Ch01, Type: CUL_HM, Event: power: 3651, Reading: power, Value: 3651, Unit:
2017.04.05 22:40:30 5: DbLog logDB -> processing event Timestamp: 2017-04-05 22:38:45, Device: energie_strom_trockner_Pwr, Type: CUL_HM, Event: energy: 39.4, Reading: energy, Value: 39.4, Unit:
2017.04.05 22:40:30 5: DbLog logDB -> processing event Timestamp: 2017-04-05 22:38:45, Device: energie_strom_trockner_Pwr, Type: CUL_HM, Event: power: 1913.25, Reading: power, Value: 1913.25, Unit:
2017.04.05 22:40:30 5: DbLog logDB -> processing event Timestamp: 2017-04-05 22:40:04, Device: energie_strom_trockner_Pwr, Type: CUL_HM, Event: energy: 81.2, Reading: energy, Value: 81.2, Unit:
2017.04.05 22:40:30 5: DbLog logDB -> processing event Timestamp: 2017-04-05 22:40:04, Device: energie_strom_trockner_Pwr, Type: CUL_HM, Event: power: 1582.02, Reading: power, Value: 1582.02, Unit:
2017.04.05 22:40:30 5: DbLog logDB -> processing event Timestamp: 2017-04-05 22:40:12, Device: energie_strom_trockner_Pwr, Type: CUL_HM, Event: power: 0, Reading: power, Value: 0, Unit:
2017.04.05 22:40:30 5: DbLog logDB -> 13 of 13 events inserted into table history
2017.04.05 22:40:30 5: DbLog logDB -> DbLog_PushAsync finished

Geht nur in die history. Die current habe ich vorher geleert (DELETE * FROM current WHERE DEVICE IS NOT NULL;) und die ist immer noch leer.

DS_Starter · 05 April 2017, 22:57:07

Ja das ist zu sehen. Mein Attribut ist auch auf "Current/History" gestellt und funktioniert natürlich wie man an meinem Log sieht.
Was passiert wenn du nur auf Current stellst ?

Icebear · 05 April 2017, 22:59:25

Hallo,

lustigerweise hatte ich genau das selbe auch schon. In der History waren Werte in der Current nicht .... Am nächsten Morgen waren plötzlich werte auch in der Current ...
Wird das eventuell verzögert ?
Aufgefallen ist mir das, da ich ne sql anweisung gebaut hab, was mir leichen aus der der Current löscht (einträge die lang nicht aktualisiert wurden) und über ne zweite Anweisung alle History einträge gelöscht habe, wo es kein gegenstück in der current gibt. So brauch ich nur eine Tabelle säubern und die zweite säubert sich quasi selbst..

DS_Starter · 05 April 2017, 23:06:43

Hallo icebear,

verzögert wird da nichts. Wird alles in dem Lauf der Subroutine in die DB gebracht.
Ich hatte jetzt auf ein fehlendes Commit getippt, aber das würde man sehen. Komisch ....

Jorge3711 · 05 April 2017, 23:27:53

Jetzt wird es dubios, zumindest für mich. Nachdem ich die current gelöscht hatte und den Verbose 5 Output geliefert hatte, fiel mir auf, dass das DBlog Device auf DBLogType = history steht!? Geändert habe ich das aber nicht. Aufgefallen ist es mir zusätzlich, weil Du fragtest, was passiert wenn ich auf Current stelle (es loggt in die Current).

Current noch mal gelöscht, DBLogType auf Current/History gestellt und Daten generiert und anschließend per Commit in die DB geschrieben. Diesmal landeten die Daten auch in der Current und History. Und, oh wunder, die Daten bzw. das neue Devicereading ist im SVG Plot selektierbar.

Bevor ich den Thread eröffnete ist mir außerdem aufgefallen, dass ich im SVG Plot bei der Auswahl im Dropdown mehrfache Einträge für ein und dasselbe Devicereading fand.

Icebear · 05 April 2017, 23:31:44

ich werde morgen mal verbose 5 und nen device löschen inklusiv aller db einträge und neu anlegen ... schauen was passiert bei den ersten events ...

DS_Starter · 05 April 2017, 23:43:16

ZitatUnd, oh wunder, die Daten bzw. das neue Devicereading ist im SVG Plot selektierbar.

Naja, das sollte so sein

ZitatBevor ich den Thread eröffnete ist mir außerdem aufgefallen, dass ich im SVG Plot bei der Auswahl im Dropdown mehrfache Einträge für ein und dasselbe Devicereading fand.

Die Kombinationen werden einfach aus der Current-Tabelle gelesen. Die waren dann entsprechend vorhanden. Wir haben inzwischen auch primary key Unterstützung eingebaut was auch doppelte Einträge verhindern hilft. (in dem Optimierungsthread)

Ich habe dein Problem zum Anlass genommen um im verbose 5 Log noch mit auszuschreiben welcher DbLogTyp erkannt und abgearbeitet wird. Dann erkennen wir das schneller. (stelle die Version dann auch in dem angegeben Thread bereit)

Grüße
Heiko

Jorge3711 · 06 April 2017, 09:48:47

Zitat von: DS_Starter am 05 April 2017, 23:43:16
Die Kombinationen werden einfach aus der Current-Tabelle gelesen. Die waren dann entsprechend vorhanden. Wir haben inzwischen auch primary key Unterstützung eingebaut was auch doppelte Einträge verhindern hilft. (in dem Optimierungsthread)

Hm, und auf was setzte ich den PK in der CURRENT, so?

Code Auswählen


+-----------+--------------+------+-----+-------------------+-----------------------------+
| Field     | Type         | Null | Key | Default           | Extra                       |
+-----------+--------------+------+-----+-------------------+-----------------------------+
| TIMESTAMP | timestamp    | NO   |     | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| DEVICE    | varchar(32)  | NO   | PRI | NULL              |                             |
| TYPE      | varchar(32)  | YES  |     | NULL              |                             |
| EVENT     | varchar(512) | YES  |     | NULL              |                             |
| READING   | varchar(64)  | NO   | PRI | NULL              |                             |
| VALUE     | varchar(32)  | YES  |     | NULL              |                             |
| UNIT      | varchar(32)  | YES  |     | NULL              |                             |
+-----------+--------------+------+-----+-------------------+-----------------------------+

Nur die Kombination aus Device und Reading ist ja wirklich eindeutig, da es bestimmte Readings ja für mehrere Devices geben kann. Bin jetzt nicht so der DB Experte

Danke für die Unterstützung!

DS_Starter · 06 April 2017, 19:52:34

Hallo Jorge3711,

bei mir habe ich den PK der current auch so aufgebaut wie du angegeben hast:

Code Auswählen


ALTER IGNORE TABLE `current` ADD PRIMARY KEY (DEVICE, READING);

Kleine Ergänzung ... wie ich sehe hast du in deiner DB noch die alten Feldlängen verwendet. Die sind mittlerweile per Standard:

Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32

viele Grüße

Jorge3711 · 06 April 2017, 21:37:25

Habe mir erlaubt, die Information mit dem PK im Wiki zu DbLog zu verewigen: https://wiki.fhem.de/wiki/DbLog#Datenbank Ich hoffe das passt so.

DS_Starter · 07 April 2017, 14:22:51

Hallo Jorge3711,

danke

, Unterstützung ist immer wilkommen. Die PK-Unterstützung gibt es natürlich auch für die history-Tabelle.
In dem Thread https://forum.fhem.de/index.php/topic,65860.0.html wird über all diese Dinge diskutiert und JoeAllb ist ganz eifrig auf der Suche nach Performance steigernden Indexkombinationen.
Bezüglich der neuen Funktionalitäten ist ohnehin noch viel im Wiki nachzuholen, wie gesagt, Hilfe ist immer wilkommen.

Grüße
Heiko

Phill · 29 September 2017, 10:00:05

Bezüglich der aktualisierten Feldlängen. Selbst nach einem Update stehen bei mir in den Scripten

Zitatdb_create_mysql.sql und db_create_sqlite.sql

noch die alten Feldlängen. Nur

Zitatdb_create_postgresql.sql

ist korrekt.

DS_Starter · 29 September 2017, 11:00:06

Hallo Phill,

das contrib-Verzeichnis deiner FHEM-Installation wird mit dem update-Prozess nicht aktualisiert.
Du musst dir die Scripte aus dem SVN-contrib ziehen. Dafür gibt es veschiedene Möglichkeiten.

Eine einfache ist die Seite https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog

auszurufen und sich dort die Inhalte zu kopieren/herunterzuladen.

Grüße
Heiko