DbLog - Umstellung Betrieb auf SubProcess -> Tester gesucht

Begonnen von DS_Starter, 29 November 2022, 12:54:25

Vorheriges Thema - Nächstes Thema

DS_Starter

Hallo zusammen,

die neue Version ist eingescheckt und morgen früh verfügbar.
Was hat sich geändert ?

* der Plot Editor (DbLog Part) ist überarbeitet und verbessert
* das Attribut noNotifyDev wurde entfernt
* ein neues Attribut plotInputFieldLength für den Plot Editor ist eingebaut
* an der Commandref wurde weitergearbeitet

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

thburkhart

Zitat von: DS_Starter am 21 Februar 2023, 21:23:24
Hallo miteinander,

wie ihr hier nachlesen könnt, habe ich den DbLog Plot Editor Part überarbeitet und das schon lange vorhandene Manko beseitigt, dass man bei Nutzung einer Drop-Down Vorschlagsliste keine Funktion eingeben konnte bzw. eine im gplot-File gesetzte Funktion verloren ging wenn das File gelesen und gespeichert wurde wenn eine  Drop-Down Vorschlagsliste  benutzt wurde.

Rudi hat heute eine neue SVG Version eingecheckt die morgen früh im Update verteilt wird.Diese SVG ist die Voraussetzung für die überarbeitete DbLog Version die ich als 5.8.4 in mein contrib geladen habe.Damit ist nun die Verwendung einer Funktion im SVG Editor sowohl mit  als auch ohne Drop-Down Vorschlagsliste möglich.
Bevor ich einchecke würde ich mich freuen wenn der eine oder andere die Version ab morgen nach einem Update des SVG testen würde.
Grüße,Heiko

Hallo Heiko,
vielen Dank für das Update.
ich habe noch nicht kapiert, was man in das EingabeFeld unter Drop-down-Feld eingeben kann oder sollte.

lg

Thomas
1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

DS_Starter

Zitat
ich habe noch nicht kapiert, was man in das EingabeFeld unter Drop-down-Feld eingeben kann oder sollte.
Man kann eine Funktion eingeben um Werte zur Anzeige zu verändern, z.B.  $val=($val=~"on"?10:1)
Beispiel ist im Wiki zu sehen -> https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

thburkhart

#228
Zitat von: DS_Starter am 27 Februar 2023, 20:18:02
Zitatich habe noch nicht kapiert, was man in das EingabeFeld unter Drop-down-Feld eingeben kann oder sollte.
Man kann eine Funktion eingeben um Werte zur Anzeige zu verändern, z.B.  $val=($val=~"on"?10:1)
Beispiel ist im Wiki zu sehen -> https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen

inzwischen habe ich das dazu verwendet, um die Delta-d  zu berechnen:
define SVG_TUYA_Stromverbrauch10_Delta SVG dblog_THB:SVG_TUYA_Stromverbrauch10_Delta:HISTORY
attr SVG_TUYA_Stromverbrauch10_Delta DbLogExclude .*
attr SVG_TUYA_Stromverbrauch10_Delta alias Stromverbrauch 10 Delta ThomasBüro
attr SVG_TUYA_Stromverbrauch10_Delta fixedrange 30days
attr SVG_TUYA_Stromverbrauch10_Delta room TUYA Stromverbrauch
#  CFGFN     
#  DEF        dblog_THB:SVG_TUYA_Stromverbrauch10_Delta:HISTORY
#  FUUID      6416db2d-f33f-fd5f-cee4-84ec9d20f2b1698a
#  GPLOTFILE  SVG_TUYA_Stromverbrauch10_Delta
#  LOGDEVICE  dblog_THB
#  LOGFILE    HISTORY
#  NAME      SVG_TUYA_Stromverbrauch10_Delta
#  NR        4001
#  STATE      initialized
#  TYPE      SVG
#  eventCount 1
#
setstate SVG_TUYA_Stromverbrauch10_Delta initialized

also unter Verwendung des Ploteditors.

allerdings entsteht im Plotfile ein Doppelpunkt zuviel:

#dblog_THB TUYA_SP11:energy:::delta-d:$val=($val/1000)
#dblog_THB TUYA_SP12:energy:::delta-d:$val=($val/1000)
#dblog_THB TUYA_SP13:energy:::delta-d:$val=($val/1000)
#dblog_THB TUYA_SP16:energy:::delta-d:$val=($val/1000)

erst wenn ich das mit einem Texteditor wie folgt richtigstelle

#dblog_THB TUYA_SP11:energy::delta-d:$val=($val/1000)
#dblog_THB TUYA_SP12:energy::delta-d:$val=($val/1000)
#dblog_THB TUYA_SP13:energy::delta-d:$val=($val/1000)
#dblog_THB TUYA_SP16:energy::delta-d:$val=($val/1000)

erscheinen tatsächlich die richtigen Differenzwerte im Plot.

Etwas lästig. Meine Dummheit oder noch ein kleiner Bug im Plot-Editor?
Passiert immer wenn man im Editor ein write macht; dann sinds auch wieder 3 Doppelpunkte

Gibt es inzwischen auch ein delta-m für Darstellung von Monats-Differenzen?
Gibt es überhaupt eine Beschreibung für die Definition von SVG's ?


Ich suche auch eine Darstellung z.B. von Summenwerten mehrerer Verbraucher nebeneinander als Balken (also anstelle der x-Achse als Zeitachse) für einen Tag, Monat oder Jahr bzw. definierten Zeitraum

viele Grüße und besten Dank

Thomas

die Suchfunktion im Forum geht seit heute nicht mehr? Lesezeichen sind weg?


1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

DS_Starter

Danke für den Hinweis Thomas, das muss ich mir etwas genauer anschauen.
Möglicherweise habe ich etwas übersehen wenn man delta-d nutzen will. Das gehört nämlich nicht zur eigentlichen Funktion $val=($val/1000).

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Hallo Thomas, @all,

ich habe den SVG Editor für DbLog gefixt, sodass die Funktionen delta-d etc. mit abgebildet werden können.
Abhängig ob mit oder ohne Vorschlagsliste gearbeitet wird, stellt sich die Verwendung wie in den Screenshots gezeigt dar.

Wie angekündigt, habe ich in dieser Version alle Setter die auf ..Nbl enden, entfernt.

Die Version 5.8.6 befindet sich zunächst in meinem contrib zum Test.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

thburkhart

Danke, Heiko :-)

was anders..

gibt es von jemand Erfahrungen im Zugriff auf die FHEM-Datenbank (MariaDb) per Connector wie https://www.devart.com/excel-addins/mysql/ zu und von Excel .
oder über ODBC.

Herzliche Grüße

Thomas
1 RASPI4B, 1 RASPI3B, 2 CUL, 2 Jeelink, 60 Tuya-Devices (Schalter, Dimmer, Sensoren, Cameras), 30 HUE-Lampen, 5 MAX! WTs, 16 MAX! HTs, 12 MAX! FKs, 1 Bresser 5in1, 1 OilFox, 8 ALEXA Echos und Dots, FHEM, 5 Tasmota-Devices, SonOff -Bridge, PowerFox, Buderus KM200

DS_Starter

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

detmar

Hallo Heiko,

ich hatte Dir ja schon per Mail geschrieben dass nach einem Update von FHEM ein DbLog-Problem auftaucht.
Meine Umgebung : Raspi mit aktualisiertem BUSTER
Die Version, die den Fehlwer erzeugt : $Id: 93_DbLog.pm 27379 2023-04-01 07:16:52Z DS_Starter $

Die Version $Id: 93_DbLog.pm 26289 2022-08-05 19:15:32Z DS_Starter $ macht den Fehler nicht.

Mein Logfileauszug :

2023.04.03 17:27:11 2: DbLog myDblog5 - Error table history - DBD::mysql::st execute_array failed: Column 'UNIT' cannot be null [err was 1048 now 2000000000] executing 30 generated 30 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at /opt/fhem/FHEM/93_DbLog.pm line 3191.

2023.04.03 17:27:12 2: DbLog myDblog5 - Error table history - DBD::mysql::st execute_array failed: Column 'UNIT' cannot be null [err was 1048 now 2000000000] executing 36 generated 36 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at /opt/fhem/FHEM/93_DbLog.pm line 3191.

2023.04.03 17:27:12 2: DbLog myDblog5 - Error table history - DBD::mysql::st execute_array failed: Column 'UNIT' cannot be null [err was 1048 now 2000000000] executing 45 generated 45 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at /opt/fhem/FHEM/93_DbLog.pm line 3191.

2023.04.03 17:27:12 2: DbLog myDblog5 - Error table history - DBD::mysql::st execute_array failed: Column 'UNIT' cannot be null [err was 1048 now 2000000000] executing 51 generated 51 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at /opt/fhem/FHEM/93_DbLog.pm line 3191.

Ich hatte Dir geschrieben, dass der Log durch Modul km200 erzweugt wird. Das war aber falsch. der DbLog myDblog5 schreibt 3 UserReadings ( berechnete Werte aus meinem SolarEdge-Strommessinstrument - über ModbusAttr abgefragt) in die Mysql-Datenbank.
Die Datenbank war generiert mit den Feldattributen NOT NULL . NULL wurde bisher wohl abgefangen und nach Leerstring gewandelt.

Die aktuelle Version von DbLog scheint etwas anderes zu machen.



DS_Starter

#234
Das ist eine Meldung des Datenbanktreibers.
DbLog hat das bisher auch nicht anders behandelt, vllt. ist das Datenbankproblem in der alten Version nicht offensichtlich geworden.

Jedenfalls werden die Tabellen im Standard so definiert:

CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));

(das Script ist im FHEM contrib verfügbar)

Die einzigste Spalte die nicht NULL sein darf ist TIMESTAMP. Alle anderen dürfen NULL annehmen.
Ich denke du könntest das Problem mit diesem Statement lösen:

ALTER TABLE history MODIFY UNIT varchar(32) NULL;

Habe ich aber noch nicht getestet.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

detmar

Das hatte ich mir auch schon überlegt.
Dennoch wäre es interessant zu wissen, warum die alte Version dieses Problem nicht hatte und alles ordnungsgemäß geloggt wurde.

DS_Starter

#236
ZitatDennoch wäre es interessant zu wissen, warum die alte Version dieses Problem nicht hatte und alles ordnungsgemäß geloggt wurde
Sicher, ist aber jetzt müßig darüber zu spekulieren. Wenn die Spalte in der DB NULL nicht zulässt obwohl sie es müsste, muß der Fehler gemeldet werden. Deswegen ist der richtige Weg die Spalte UNIT so zu ändern dass NULL erlaubt ist wie es der Standard vorgibt.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

frober

Hallo Heiko,

seit einiger Zeit stelle ich fest, dass viele Subprozesse nicht 'beendet' werden, die Swap läuft nach einiger Zeit voll und die Auslastung des Arbeitsspeichers nimmt zu:
kurz nach Neustart von Fhem, ich habe schon wesentlich mehr gezählt
  737 mysql      20   0  600M  153M  7036 S  0.0 16.6  8:33.14 /usr/sbin/mysqld
  802 mysql      20   0  600M  153M  7036 S  0.0 16.6  0:53.39 /usr/sbin/mysqld
 7094 mysql      20   0  600M  153M  7036 S  0.0 16.6  0:08.10 /usr/sbin/mysqld
  792 mysql      20   0  600M  153M  7036 S  0.0 16.6  0:20.15 /usr/sbin/mysqld

Die SyncDb erzeugt sekündlich Events, das war vorher nicht:
Eventmonitor
2023-04-08 10:21:17 DbLog syncdb notify_processing_time: 0.0019
2023-04-08 10:21:17 DbLog syncdb notify_processing_time: 0.0004
2023-04-08 10:21:17 MQTT2_DEVICE MQTT2_Netzfrequenz Differenz: -0.003
2023-04-08 10:21:18 DbLog syncdb notify_processing_time: 0.0004
2023-04-08 10:21:18 DbLog syncdb notify_processing_time: 0.0005
2023-04-08 10:21:18 FS20V KS300_Einstrahlung dbvalue: 233
2023-04-08 10:21:18 FS20V KS300_Einstrahlung 233 W/m²
2023-04-08 10:21:22 DbLog syncdb notify_processing_time: 0.0004
2023-04-08 10:21:22 DbLog syncdb notify_processing_time: 0.0004
2023-04-08 10:21:22 MQTT2_DEVICE MQTT2_Rollo_Esszi_West temperature: 55.00
2023-04-08 10:21:22 DbLog syncdb notify_processing_time: 0.0004
2023-04-08 10:21:22 DbLog syncdb notify_processing_time: 0.0004

Def:
defmod syncdb DbLog ./dbsync.conf aaaaaa:bbbbbb
attr syncdb asyncMode 1
attr syncdb cacheEvents 2
attr syncdb devStateIcon devStateIcon .*active:10px-kreis-gelb connected:10px-kreis-gruen .*disconnect:10px-kreis-rot
attr syncdb insertMode 1
attr syncdb room System->DbLog
attr syncdb showNotifyTime 1
attr syncdb showproctime 1
attr syncdb syncEvents 1
attr syncdb verbose 1
Der Sync wird über ein at angestoßen und hast sonst eigentlich nichts zu tun.

LG
Bernd
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

DS_Starter

#238
Morgen Bernd,

zum Attr showNotifyTime  gibt es diesen Hilfeeintrag:

ZitatshowNotifyTime [1|0]

    Wenn gesetzt, zeigt das Reading "notify_processing_time" die benötigte Abarbeitungszeit (in Sekunden) für die Abarbeitung der DbLog Notify-Funktion.
    Das Attribut ist für Performance Analysen geeignet und hilft auch die Unterschiede im Zeitbedarf der Eventverarbeitung im synchronen bzw. asynchronen Modus festzustellen.
    (default: 0)

    Hinweis:
    Das Reading "notify_processing_time" erzeugt sehr viele Events und belasted das System. Deswegen sollte bei Benutzung des Attributes die Eventerzeugung durch das Setzen von Attribut "event-min-interval" auf z.B. "notify_processing_time:30" deutlich begrenzt werden.


Der Hinweis ist der richtige Hinweis für dich.  ;)

Jedes DbLog Device hat genau einen permanent mitlaufenden Subprozess. Dieses Prozess verbraucht deutlich weniger Speicher als der Hauptprozess. Die PID des Subprozesses siehst du im Internal SBP_PID des Devices und kannst sie damit zuordnen.

Alle anderen Subprozesse die du feststellst können z.B. durch BlockingCall erzeugt werden oder anderen Modulen stammen die Subprozess verwenden. Die BlockingCall Prozesse sind nur temporär und werden beendet. Das sind vermutlich die, welche du während des Starts siehst.

Alle internen Vorgänge in DbLog laufen über den zugeordneten Subprozess. D.h. auch solange der nicht signifikant Speicher verbaucht, hat das DbLog-Device auch keinen Anteil an deinem "Swap" Problem.

LG,
Heiko

PS: ich bekomme immer wieder mal keine Mails dass in den Threads geantwortet wurde seit der Forum Umstellung. Deswegen dauern meine Antworten manchmal...
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

frober

Hallo Heiko,

die Hilfe zu showNotifyTime kenne ich soweit. Bin mir aber ziemlich sicher, dass von der Umstellung die Events nicht da waren. Die SyncDB hat ja nichts zu tun, außer wenn sie zum 'Sync' getriggert wird, daher verwundert es mich.
Das attr lösche ich jedenfalls.

Ich habe nur zwei DbLogs, eins davon remote.
OK, DbRep erstellt dann auch Subprozesse von DbLog?
Die meisten DbReps laufen bei mir nicht parallel und doch zähle ich nach längerer Betriebszeit von Fhem immer mehr Subprozesse von DbLog.

Von DbRep hatte ich auch immer wieder timeouts im Log. Kann es sein, dass bei einem timeouts der Subprozesse nicht beendet wird?

LG
Bernd
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...