[gelöst ]DBlogging logt trotzdem Werte

Begonnen von Aladin222, 27 April 2019, 10:28:44

Vorheriges Thema - Nächstes Thema

Aladin222

hi @all,

ich habe folgende Konstellation mit der ich Probleme habe :

Im Keller läuft ein Raspberry mit GPIO4 Temperatürfühlern !
Mit Fhem2Fhem bekomme ich die Werte zum Haupt-Fhem gesendet :

list der Temperaturfühler auf dem Remote Fhem im Keller ( Raspberry )
list Aussen

Internals:
   DEF        28-00000557f7da
   FUUID      5cc318df-f33f-8aa5-e419-04d800ed61e8e6dc
   NAME       Aussen
   NR         43
   NTFY_ORDER 50-Aussen
   STATE      T: 11.25
   TYPE       GPIO4
   READINGS:
     2019-04-27 10:06:13   failures        0
     2019-04-27 10:16:23   state           T: 11.25
     2019-04-27 10:16:23   temperature     11.25
   fhem:
     interfaces temperature
Attributes:
   DbLogExclude .*
   model      DS18B20
   room       GPIO4

list Keller
Internals:
   DEF        28-0000055410a4
   FUUID      5cc318e0-f33f-8aa5-a0d6-490537d172e67939
   NAME       Keller
   NR         44
   NTFY_ORDER 50-Keller
   STATE      T: 18.562
   TYPE       GPIO4
   READINGS:
     2019-04-27 10:06:13   failures        0
     2019-04-27 10:18:26   state           T: 18.562
     2019-04-27 10:18:26   temperature     18.562
   fhem:
     interfaces temperature
Attributes:
   DbLogExclude .*
   model      DS18B20
   room       GPIO4

list Jacuzzi
Internals:
   DEF        28-00000554757c
   FUUID      5cc318de-f33f-8aa5-e1c4-4c36084220643643
   NAME       Jacuzzi
   NR         42
   NTFY_ORDER 50-Jacuzzi
   STATE      T: 29.875
   TYPE       GPIO4
   READINGS:
     2019-04-27 10:06:12   failures        0
     2019-04-27 10:19:24   state           T: 29.875
     2019-04-27 10:19:24   temperature     29.875
   fhem:
     interfaces temperature
Attributes:
   DbLogExclude .*
   model      DS18B20
   room       GPIO4


Auf der Hauptinstanz im Wohnzimmer bekomme ich alle Daten in die entsprechenden dummy´s :
list Aussentemperatur
Internals:
   CFGFN      /opt/fhem/FHEM/10_Fhem2Fhem.cfg
   FUUID      5cc32fbb-f33f-9117-f214-aad0f054a5a56aa4
   NAME       Aussentemperatur
   NR         812
   STATE      11.187 °C
   TYPE       dummy
   READINGS:
     2019-04-27 10:21:26   state           11.187
Attributes:
   DbLogExclude .*
   group      ChlorTimerdosierung
   room       Chlordosierung,Test
   stateFormat state °C

list Kellertemperatur
Internals:
   CFGFN      /opt/fhem/FHEM/10_Fhem2Fhem.cfg
   FUUID      5cc32f47-f33f-9117-6226-87ce385b3c15f33d
   NAME       Kellertemperatur
   NR         810
   STATE      18.562 °C
   TYPE       dummy
   READINGS:
     2019-04-27 10:22:30   state           18.562
Attributes:
   DbLogExclude .*
   room       Temperaturen,Test
   stateFormat state °C

list Jacuzzitemperatur
Internals:
   CFGFN      /opt/fhem/FHEM/10_Fhem2Fhem.cfg
   FUUID      5cc32fe4-f33f-9117-6266-f07a49d40f2e5692
   NAME       Jacuzzitemperatur
   NR         814
   STATE      29.812 °C
   TYPE       dummy
   READINGS:
     2019-04-27 10:22:29   state           29.812
Attributes:
   DbLogExclude .*
   group      ChlorTimerdosierung
   room       Chlordosierung,Test
   stateFormat state °C


Überall habe ich DbLogExclude .* gesetzt ! Also dürfte in der Datenbank nichts ankommen , oder ?
Geloggt wird aber Aussen und Keller ! Vom Jacuzzi kommen keine Werte ,passt dort also !
Ich verstehe nicht ,warum die Werte geloggt werden ! Zumal es die Werte des Remotesystems sind .... Von den dummy´s Aussentemperatur,Kellertemperatur,Jacuzzitemperatur kommt, wie gewollt, nichts in der Datenbank an.

DBLog:

2019-04-27 10:30:37 Keller GPIO4 T: 18.562 T 18.562
2019-04-27 10:30:37 Keller GPIO4 temperature: 18.562 temperature 18.562 °C
2019-04-27 10:31:37 Keller GPIO4 T: 18.562 T 18.562
2019-04-27 10:31:37 Keller GPIO4 temperature: 18.562 temperature 18.562 °C


Jetzt hoffe ich sehr das jemand von euch da eine Idee hat  ;)

OiledAmoeba

Wie sieht dein DbLog Device aus?
Bei mir steht DbLogSelectionMode Exclude/Include in den Attributen, klappt einwandfrei. Hab aber ehrlich gerade die commandref nicht im Kopf, obs daran liegt...

Gesendet von meinem VTR-L09 mit Tapatalk

Gruß
Florian

Jail auf XigmaNAS (freeBSD); CCU2 mit CULv3, nanoCUL868 und JeeLink-Clone; div. FS20-Komponenten; andFHEM; div. hm- und hmip-Komponenten; div. IT+

Aladin222

Hmmm , ja bei mir auch 🤔

List DBLoging
  Internals:
   CFGFN      /opt/fhem/FHEM/01_DB-Logging.cfg
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION /opt/fhem/db.conf
   DEF        /opt/fhem/db.conf .*:.*
   FUUID      5c462d39-f33f-9117-3974-1cad2018f994ff4e
   FVERSION   93_DbLog.pm:v4.1.0-s19251/2019-04-23
   MODE       asynchronous
   MODEL      MYSQL
   NAME       DBLogging
   NR         62
   NTFY_ORDER 50-DBLogging
   PID        30667
   REGEXP     .*:.*
   STATE      connected
   TYPE       DbLog
   UTF8       0
   dbconn     mysql:database=fhem;host=localhost;port=3306
   dbuser     fhemuser
   HELPER:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     OLDSTATE   connected
     PACKAGE    main
     READINGCOL 64
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
     VERSION    4.1.0
   READINGS:
     2019-04-27 11:39:38   CacheUsage      0
     2019-04-27 11:39:38   NextSync        2019-04-27 11:40:08 or if CacheUsage 500 reached
     2019-04-27 11:39:38   background_processing_time 0.0288
     2019-04-27 11:39:38   sql_processing_time 0.0190
     2019-04-27 11:39:38   state           connected
   cache:
     index      2631
Attributes:
   DbLogExclude .*
   DbLogSelectionMode Exclude/Include
   DbLogType  Current/History
   asyncMode  1
   icon       HutschIcon3
   room       DBLog
   showproctime 1
   verbose    0 

DS_Starter

Hallo zusammen,

grundsätzlich verabeitet ein DbLog-Device nur die Events seiner eigenen FHEM-Instanz. Im Eventmonitor wäre mit einem Filter zu prüfen welche es sind bzw. welche überhaupt vorkommen. Es dürfen nur die der Dummies sein.
Dann würde ich dir vorschlagen im DbLog Device die Attribute

verbose4Devs = Aussen,Keller
verbose = 4


zu setzen. Dann siehst du ob/welche Events von Aussen,Keller empfangen und verarbeitet werden. Eigentlich dürften diese Events der remoten FHEM Instanz nicht auf der lokalen FHEM-Instanz erscheinen. Hast du eventuell auf der remoten Instanz im Keller auch ein DbLog laufen welches auf die gleiche Datenbank loggt ?

Weiterhin kannst du im DbLog das Attribut

excludeDevs = Aussen,Keller

setzen. Damit unterdrückst du das Loggen dieser Devices absolut ohne Rücksicht auf irgendwelche anderen Filter und Excludes/Includes.
Mit diesen Möglichkeiten kannst du dich mal an die Problematik rantasten.

LG,
Heiko
Proxmox+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

Aladin222

Hallo DS_Starter ,

erstmal vielen Dank für deine Antwort !!!

Ja ,dachte ich auch , das jede Fhem Instanz ihr eigenes Log Device verarbeitet :-(

Ich habe mal beide Vorschläge von dir umgesetzt ...

Ausschnitt aus dem Logfile

2019.04.28 19:39:29 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:29 4: DbLog DBLogging -> ###              start of new Logcycle                       ###
2019.04.28 19:39:29 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:29 4: DbLog DBLogging -> number of events received: 1 for device: Aussentemperatur
2019.04.28 19:39:29 4: DbLog DBLogging -> check Device: Aussentemperatur , Event: state: 13.062
2019.04.28 19:39:29 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:29 4: DbLog DBLogging -> ###              start of new Logcycle                       ###
2019.04.28 19:39:29 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:29 4: DbLog DBLogging -> number of events received: 1 for device: Aussen
2019.04.28 19:39:29 4: DbLog DBLogging -> check Device: Aussen , Event: T: 13.062
2019.04.28 19:39:29 4: DbLog DBLogging -> added event - Timestamp: 2019-04-28 19:39:29, Device: Aussen, Type: GPIO4, Event: T: 13.062, Reading: T, Value: 13.062, Unit:
2019.04.28 19:39:29 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:29 4: DbLog DBLogging -> ###              start of new Logcycle                       ###
2019.04.28 19:39:29 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:29 4: DbLog DBLogging -> number of events received: 1 for device: Aussen
2019.04.28 19:39:29 4: DbLog DBLogging -> check Device: Aussen , Event: temperature: 13.062
2019.04.28 19:39:29 4: DbLog DBLogging -> added event - Timestamp: 2019-04-28 19:39:29, Device: Aussen, Type: GPIO4, Event: temperature: 13.062, Reading: temperature, Value: 13.062, Unit: °C
2019.04.28 19:39:29 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:29 4: DbLog DBLogging -> ###              start of new Logcycle                       ###
2019.04.28 19:39:29 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:29 4: DbLog DBLogging -> number of events received: 1 for device: Kellertemperatur
2019.04.28 19:39:29 4: DbLog DBLogging -> check Device: Kellertemperatur , Event: state: 17.937
2019.04.28 19:39:29 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:29 4: DbLog DBLogging -> ###              start of new Logcycle                       ###
2019.04.28 19:39:29 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:29 4: DbLog DBLogging -> number of events received: 1 for device: Keller
2019.04.28 19:39:29 4: DbLog DBLogging -> check Device: Keller , Event: T: 17.937
2019.04.28 19:39:29 4: DbLog DBLogging -> added event - Timestamp: 2019-04-28 19:39:29, Device: Keller, Type: GPIO4, Event: T: 17.937, Reading: T, Value: 17.937, Unit:
2019.04.28 19:39:29 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:29 4: DbLog DBLogging -> ###              start of new Logcycle                       ###
2019.04.28 19:39:29 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:29 4: DbLog DBLogging -> number of events received: 1 for device: Keller
2019.04.28 19:39:29 4: DbLog DBLogging -> check Device: Keller , Event: temperature: 17.937
2019.04.28 19:39:29 4: DbLog DBLogging -> added event - Timestamp: 2019-04-28 19:39:29, Device: Keller, Type: GPIO4, Event: temperature: 17.937, Reading: temperature, Value: 17.937, Unit: °C
2019.04.28 19:39:59 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:59 4: DbLog DBLogging -> ###      New database processing cycle - asynchronous        ###
2019.04.28 19:39:59 4: DbLog DBLogging -> ################################################################
2019.04.28 19:39:59 4: DbLog DBLogging -> MemCache contains 19 entries to process
2019.04.28 19:39:59 4: DbLog DBLogging -> DbLogType is: Current/History
2019.04.28 19:39:59 4: DbLog DBLogging -> AutoCommit mode: ON, Transaction mode: ON
2019.04.28 19:39:59 4: DbLog DBLogging -> Insert mode: Array
2019.04.28 19:39:59 4: DbLog DBLogging -> 19 of 19 events inserted into table history
2019.04.28 19:39:59 4: DbLog DBLogging -> insert table history committed by autocommit
2019.04.28 19:39:59 4: DbLog DBLogging -> 19 of 19 events updated in table current
2019.04.28 19:39:59 4: DbLog DBLogging -> insert / update table current committed by autocommit
2019.04.28 19:40:27 4: DbLog DBLogging -> ################################################################
2019.04.28 19:40:27 4: DbLog DBLogging -> ###              start of new Logcycle                       ###
2019.04.28 19:40:27 4: DbLog DBLogging -> ################################################################
2019.04.28 19:40:27 4: DbLog DBLogging -> number of events received: 1 for device: Aussentemperatur
2019.04.28 19:40:27 4: DbLog DBLogging -> check Device: Aussentemperatur , Event: state: 13.062
2019.04.28 19:40:27 4: DbLog DBLogging -> ################################################################
2019.04.28 19:40:27 4: DbLog DBLogging -> ###              start of new Logcycle                       ###
2019.04.28 19:40:27 4: DbLog DBLogging -> ################################################################
2019.04.28 19:40:27 4: DbLog DBLogging -> number of events received: 1 for device: Aussen
2019.04.28 19:40:27 4: DbLog DBLogging -> check Device: Aussen , Event: T: 13.062
2019.04.28 19:40:27 4: DbLog DBLogging -> added event - Timestamp: 2019-04-28 19:40:27, Device: Aussen, Type: GPIO4, Event: T: 13.062, Reading: T, Value: 13.062, Unit:
2019.04.28 19:40:27 4: DbLog DBLogging -> ################################################################
2019.04.28 19:40:27 4: DbLog DBLogging -> ###              start of new Logcycle                       ###
2019.04.28 19:40:27 4: DbLog DBLogging -> ################################################################
2019.04.28 19:40:27 4: DbLog DBLogging -> number of events received: 1 for device: Aussen
2019.04.28 19:40:27 4: DbLog DBLogging -> check Device: Aussen , Event: temperature: 13.062
2019.04.28 19:40:27 4: DbLog DBLogging -> added event - Timestamp: 2019-04-28 19:40:27, Device: Aussen, Type: GPIO4, Event: temperature: 13.062, Reading: temperature, Value: 13.062, Unit: °C
2019.04.28 19:40:32 4: DbLog DBLogging -> ################################################################
2019.04.28 19:40:32 4: DbLog DBLogging -> ###      New database processing cycle - asynchronous        ###
2019.04.28 19:40:32 4: DbLog DBLogging -> ################################################################
2019.04.28 19:40:32 4: DbLog DBLogging -> MemCache contains 2 entries to process
2019.04.28 19:40:32 4: DbLog DBLogging -> DbLogType is: Current/History
2019.04.28 19:40:32 3: [Freezemon] myFreezemon: possible freeze starting at 19:40:30, delay is 2.374 possibly caused by: tmr-LW12_updateStatus(LEDlight) tmr-RESIDENTStk_DurationTimer(rr_Timo_DurationTimer) tmr-RESIDENTStk_DurationTimer(rr_Karina_DurationTimer) tmr-RESIDENTStk_DurationTimer(rr_Aladin212_DurationTimer) tmr-RESIDENTStk_DurationTimer(rgr_Bewohner_DurationTimer) tmr-FHEM::SMAPortal::delcookiefile(Sonnenstrom) tmr-ENIGMA2_GetStatus(wzReceiver) tmr-HOMEMODE_GetUpdate(Home) tmr-DbLog_execmemcache(DBLogging) tmr-SONOSPLAYER_SimulateCurrentTrackPosition(Sonos_Wohnzimmer) tmr-CUL_HM_procQs(N/A) tmr-ModbusTCPServer_Poll(SolarLogServer) tmr-SONOS_IsSubprocessAliveChecker(Sonos) tmr-PRESENCE_StartLocalScan(iPhone_Karina) tmr-PRESENCE_StartLocalScan(iPhone_Timo) tmr-PRESENCE_StartLocalScan(iPhone_Aladin212)
2019.04.28 19:40:32 4: DbLog DBLogging -> AutoCommit mode: ON, Transaction mode: ON
2019.04.28 19:40:32 4: DbLog DBLogging -> Insert mode: Array
2019.04.28 19:40:32 4: DbLog DBLogging -> 2 of 2 events inserted into table history
2019.04.28 19:40:32 4: DbLog DBLogging -> insert table history committed by autocommit
2019.04.28 19:40:32 4: DbLog DBLogging -> 2 of 2 events updated in table current
2019.04.28 19:40:32 4: DbLog DBLogging -> insert / update table current committed by autocommit


list DBLogging

Internals:
   CFGFN      /opt/fhem/FHEM/01_DB-Logging.cfg
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION /opt/fhem/db.conf
   DEF        /opt/fhem/db.conf .*:.*
   FUUID      5c462d39-f33f-9117-3974-1cad2018f994ff4e
   FVERSION   93_DbLog.pm:v4.1.0-s19251/2019-04-23
   MODE       asynchronous
   MODEL      MYSQL
   NAME       DBLogging
   NR         62
   NTFY_ORDER 50-DBLogging
   PID        30667
   REGEXP     .*:.*
   STATE      connected
   TYPE       DbLog
   UTF8       0
   dbconn     mysql:database=fhem;host=localhost;port=3306
   dbuser     fhemuser
   HELPER:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     OLDSTATE   connected
     PACKAGE    main
     READINGCOL 64
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
     VERSION    4.1.0
     REDUCELOG:
       DBLogging
       reduceLogNbl
       10
       average
   READINGS:
     2019-04-28 19:46:08   CacheUsage      0
     2019-04-28 19:46:08   NextSync        2019-04-28 19:46:38 or if CacheUsage 500 reached
     2019-04-28 19:46:08   background_processing_time 0.0207
     2019-04-28 11:00:00   reduceLogState  reduceLogNbl finished. Rows processed: 0, deleted: 0, updated: 0, time: 0.00sec
     2019-04-28 19:46:08   sql_processing_time 0.0124
     2019-04-28 19:46:08   state           connected
   cache:
     index      37757
Attributes:
   DbLogExclude .*
   DbLogSelectionMode Exclude/Include
   DbLogType  Current/History
   asyncMode  1
   excludeDevs Aussen,Keller
   icon       HutschIcon3
   room       DBLog
   showproctime 1
   verbose    4
   verbose4Devs Aussen,Keller


Leider werden die Werte für Aussen und Keller immer noch fleißig in die Datenbank geschrieben ! Ich verstehe es nicht :-(

DS_Starter

Das ist natürlich raffiniert.  :)
Ich glaube jetzt bin ich dahinter gekommen. Das Verhalten hängt wahrscheinlich mit der speziellen Funktion von FHEM2FHEM zusammen.
Die Events der remoten Installation werden 1:1 übertragen als ob sie lokal entstünden. Aber das Attribut excludeDevs zieht nicht weil die lokal angelegten Dummies nicht genauso heißen wie die remoten Devices und somit nicht existent sind. Gleiches gilt dann für das Attribut DbLogExclude. Das kann nicht wirken und auf remote Devices kann man nicht zugreifen.

Du müsstest im Eventmonitor die Events von den remoten Devices Keller, Aussen sehen wenn FHEM2FHEM arbeitet.

Also müsstest du m.M. nach die lokalen Dummies genauso nennen wie die remoten Devices. Dann sollten die Filter funktionieren und das Attribut DbLogExclude  im lokalen Dummy auch wirken.

Grüße,
Heiko
Proxmox+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

Aladin222

#6
Hmmm, ok Heiko, das probiere ich natürlich morgen mal aus .
Aber was mich trotzdem wundert , ich habe 3 GPIO Temperaturfühler am Raspi !
Der vom Jacuzzi ist genauso eingebunden wie Aussen und Keller . Der Temp.Fühler Jacuzzi macht alles wie gewollt und wird auch nicht geloggt ....

Mit den Dummies hatte ich so gelöst, damit ich auf der Hauptinstanz die Werte im state der Dummies sehen kann ... ich schau mir das aber morgen nochmals an und probiere deinen Ansatz aus !
Danke dafür

Gruss

René

[edit]
.....verdammt ! 😂
Heiko, du hast recht ! Konnte doch nicht bis morgen warten 😂
Ein list Jacuzzi auf dem Hauptsystem gab überraschender Weise ein Ergebnis !!!
Ein Bild vom Jacuzzi welches ich irgendwann mal als Weblink mit eingebaut hatte !
Habe nun zum Test einfach noch 2 dummies auf dem Haupt-Fhem erstellt ( Keller & Aussen ) ... schwups ,so wie es aussieht ,werden keine Werte mehr in die Datenbank geschrieben ....yeahhh 👍

Danke dir 🍻

DS_Starter

#7
ZitatDer vom Jacuzzi ist genauso eingebunden wie Aussen und Keller . Der Temp.Fühler Jacuzzi macht alles wie gewollt und wird auch nicht geloggt ....
Ja ich weiß, dafür habe ich noch keine Erklärung und ist mir auch etwas mystisch.
Wenn meine Theorie stimmt, sollte auf jeden Fall nichts geloggt werden wenn du FHEM2FHEM auf disable setzt.
Dann dürfen auch keine Einträge im Eventmonitor mehr erscheinen.
Proxmox+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

Aladin222

Sry hatte meinen Beitrag editiert ....über deinem !

Stelle es nun auf gelöst 😂 Danke