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:
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:
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:
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! :)
Hallo Jorge3711,
was wo geloggt wird sieht man mit verbose 5.
Dann schau mal bitte was der Abschnitt "New database processing cycle" aussagt:
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
Here it is:
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.
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 ?
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..
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 ....
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.
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 ...
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
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?
+-----------+--------------+------+-----+-------------------+-----------------------------+
| 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!
Hallo Jorge3711,
bei mir habe ich den PK der current auch so aufgebaut wie du angegeben hast:
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
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.
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
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.
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