Welches Modul schreibt Dateien mit diesem Inhalt?

[betateilchen]

Moin werte Entwicklerkollegen!

Welches Modul schreibt den untenstehenden Inhalt in eine Textdatei?
Und warum gibt es irgendwann mehr als 20.000 (!) dieser Dateien im System?

Quelle: https://forum.fhem.de/index.php/topic,123609.0.html

Code Auswählen Erweitern


{"ebusd/global/running":"true","ebusd/global/signal":"true","ebusd/global/updatecheck":"\u0022version 21.2 available\u0022","ebusd/global/version":"\u0022ebusd 21.1.v21.1-12-
gccfc025\u0022","zigbee2mqtt/EG_Bad_Fenster1/availability":"offline","zigbee2mqtt/EG_Bad_Klima/availability":"online","zigbee2mqtt/EG_Essen_Rauchmelder/availability":"online","
zigbee2mqtt/EG_Gang_Klima/availability":"online","zigbee2mqtt/EG_OD_Garagentor/availability":"online","zigbee2mqtt/EG_Putzschrank_Router/availability":"online",
"zigbee2mqtt/OD_Garage_Lichtschalter/availability":"online","zigbee2mqtt/OG_Bad_FensterL/availability":"offline","zigbee2mqtt/OG_Bad_FensterR/availability":"online",
"zigbee2mqtt/OG_Bad_Klima/availability":"online","zigbee2mqtt/OG_Eltern_Fenster1/availability":"offline","zigbee2mqtt/OG_Eltern_Klima/availability":"online",
"zigbee2mqtt/OG_Erik_Klima/availability":"online","zigbee2mqtt/OG_Erik_Storen/availability":"offline","zigbee2mqtt/SYS_zigbee_Router1/availability":"online",
"zigbee2mqtt/SYS_zigbee_Router2/availability":"online","zigbee2mqtt/UG_Vorplatz_Klima/availability":"online","zigbee2mqtt/UG_Vorplatz_Rauchmelder/availability":"online",
"zigbee2mqtt/UG_Waschkueche_Klima/availability":"online","zigbee2mqtt/bridge/config":"{\u0022commit\u0022:\u002210fe61d\u0022,\u0022coordinator\u0022:{\u0022meta\u0022:
{\u0022maintrel\u0022:1,\u0022majorrel\u0022:2,\u0022minorrel\u0022:7,\u0022product\u0022:1,\u0022revision\u0022:20201026,\u0022transportrev\u0022:2},\u0022type\u0022:
\u0022zStack3x0\u0022},\u0022log_level\u0022:\u0022info\u0022,\u0022network\u0022:
{\u0022channel\u0022:25,\u0022extendedPanID\u0022:\u00220xdddddddddddddddd\u0022,\u0022panID\u0022:6756},\u0022permit_join\u0022:false,\u0022version\u0022:
\u00221.17.1-dev\u0022}","zigbee2mqtt/bridge/devices":"[{\u0022definition\u0022:null,\u0022endpoints\u0022:{\u00221\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:
{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u002210\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:
[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u002211\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:
[\u0022ssIasAce\u0022],\u0022output\u0022:[\u0022ssIasZone\u0022,\u0022ssIasWd\u0022]},\u0022configured_reportings\u0022:[]},\u0022110\u0022:{\u0022bindings\u0022:
[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u002212\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:
{\u0022input\u0022:[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u002213\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:
[\u0022genOta\u0022],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u00222\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:
[],\u0022output\u0022:[]},\u0022configured_reportings\u0022:[]},\u0022242\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:
[]},\u0022configured_reportings\u0022:[]},\u00223\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},
\u0022configured_reportings\u0022:[]},\u00224\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},
\u0022configured_reportings\u0022:[]},\u002247\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},
\u0022configured_reportings\u0022:[]},\u00225\u0022:{\u0022bindings\u0022:[],\u0022clusters\u0022:{\u0022input\u0022:[],\u0022output\u0022:[]},
\u0022configured_reportings\u0022:[]},\u00226\u0022:


[CoolTux]

Die Einträge kommen von zigbee2mqtt.

https://www.google.com/search?q=%22Indicates+if+the+contact+is+closed%22&oq=%22Indicates+if+the+contact+is+closed%22&aqs=chrome..69i57.7089j0j7&client=tablet-android-google&sourceid=chrome-mobile&ie=UTF-8

[eiten]

Ganz spontan klingt das für mich nach MQTT, irgendwie. Von den Modulen, in denen ich ein FileWrite gefunden habe, habe ich folgende im Einsatz:

• 01_FHEMWEB
• 10_MYSENSORS_DEVICE
• 50_TelegramBot
• 91_eventTypes
• 98_weekprofile

Ich hoffe, ich hab keines übersehen. Gibts einen Weg zu sehen, welche Module geladen sind? Ich habe in der configDB noch ein Feld hinzugefügt, das automatisch den Timestamp setzt. Vielleicht kann ich ja dann was in den Logfiles korrelieren...

[rudolfkoenig]

zigbee2mqtt sollte nicht ohne Weiteres in der Lage sein, Daten in configDb anzulegen, und die MQTT Module verwenden kein FileWrite.
Ich tippe auf eine Benutzerkonfiguration.

[betateilchen]

zigbee2mqtt und generell MQTT ist die falsche Fährte. Der Dateiinhalt ist reines JSON.

Aktuell habe ich DelayedShutdown() aus 50_SSFile.pm im Verdacht. scheint nicht die Ursache zu sein.

Ich habe in der configDB noch ein Feld hinzugefügt, das automatisch den Timestamp setzt. Vielleicht kann ich ja dann was in den Logfiles korrelieren...

Falls Du 50_SSFile.pm in Gebrauch hast: Schau mal, ob Du nach jedem FHEM-Restart eine weitere Datei in der Datenbank hast.

[betateilchen]

Gibts einen Weg zu sehen, welche Module geladen sind?

FHEM Befehl: fheminfo

[eiten]

Nein, 50_SSFile habe ich nicht im Einsatz:

Code Auswählen Erweitern

System Info
ConfigType: configDB
SVN rev: 25104
OS: linux
Perl: 5.30.0
uniqueId: 193...

Modules Model Count
DLNARenderer 2
DOIF
FHEM 14
DbLog
MYSQL 1
EDIPLUG
SP2101W 1
FHEMWEB 3
HMinfo 1
HTTPMOD 2
zigbee2mqtt_daemon_updates 1
HTTPSRV 1
HUEBridge 1
HUEDevice 2
ZB-CL01 1
LST001 2
LLC020 1
InfluxDBLog 1
MQTT 1
MQTT2_CLIENT 1
MQTT2_DEVICE 5
zigbee2mqtt_light_rgbcct_rgb 1
eBus_bai_jsonmap 1
zigbee2mqtt_bridge 1
zigbee2mqtt_light_dimmer 1
tasmota_basic_state_power1 2
SHSW-1 6
eBus_daemon_splitter 1
zigbee2mqtt_ContactSensor 4
zigbee2mqtt_plug 1
zigbee2mqtt_smokeDetector 2
zigbee2mqtt_TempHumSensor 7
zigbee2mqtt_router_only_device 2
zigbee2mqtt_Wireless_Button 3
tasmota_2channel_split 5
SHSW-25 4
zigbee2mqtt_Shutter_Switch 1
shelly1 1
MQTT2_SERVER 1
MQTT_DEVICE 3
MYSENSORS_DEVICE 4
OctoPrint 1
SSCam
User Define - 1
SVG 3
SamsungAV 1
Shelly
shelly1 2
TelegramBot 1
Twilight 1
WUup 1
Weather
wundergroundAPI 1
WeekdayTimer 4
allowed 2
at 5
autocreate 1
cmdalias 3
configDB
MYSQL 1
dewpoint 2
dummy 9
eventTypes 1
fronthemDevice 1
gassistant 1
notify 11
readingsGroup 4
telnet 1
watchdog 2
weblink 7

Dabei habe ich gemerkt, das FHEM mein Timestamp-Feld nicht mag, mit dem in der Datenbank wills nich starten.

[eiten]

zigbee2mqtt sollte nicht ohne Weiteres in der Lage sein, Daten in configDb anzulegen, und die MQTT Module verwenden kein FileWrite.
Ich tippe auf eine Benutzerkonfiguration.

Hm, und wie meinst Du das? Respektive, wie komme ich da weiter?

[betateilchen]

Da stehen jede Menge "Module" in der Liste, die ich noch nie gesehen habe.

Wo kommen denn die ganzen zigbee2mqtt.* und die eBus_.* her?

[rudolfkoenig]

Hm, und wie meinst Du das?

Z.Bsp. indem man im readingList eines MQTT2_DEVICE FileWrite aufruft.

Respektive, wie komme ich da weiter?

Ich wuerde in fhem.pl, am Anfang von FileWrite() ein stacktrace() einbauen.

[betateilchen]

Ich wuerde in fhem.pl, am Anfang von FileWrite() ein stacktrace() einbauen.

Sehr gute Idee!

[eiten]

Wo kommen denn die ganzen zigbee2mqtt.* und die eBus_.* her?

Da ist irgendwie die Einrückung verloren gegangen. Das sind die Attribute Templates von zigbee2mqtt...

[eiten]

Also,

Code Auswählen Erweitern

mysqldump -u root -p fhem_config |grep FileWrite
hat leider nix ausgespuckt...

Code Auswählen Erweitern


sub
FileWrite($@)
{
  print("FILEWRITE\n");
  print(stacktrace());
  my ($param, @rows) = @_;
  my ($err, @ret, $fileName, $forceType, $nl);

  if(ref($param) eq "HASH") {
    $fileName = $param->{FileName};
    $forceType = $param->{ForceType};
    $nl = $param->{NoNL} ? "" : "\n";
  } else {
    $fileName = $param;
    $nl = "\n";
  }
  $forceType = "" if(!defined($forceType));


Scheint zu funktionieren (war jetzt über ein Web-Kommando):

Code Auswählen Erweitern

FILEWRITE
2021.10.23 20:51:43 1: stacktrace:
2021.10.23 20:51:43 1:     main::FileWrite                     called by (eval 1022) (1)
2021.10.23 20:51:43 1:     (eval)                              called by fhem.pl (1160)
2021.10.23 20:51:43 1:     main::AnalyzePerlCommand            called by fhem.pl (1189)
2021.10.23 20:51:43 1:     main::AnalyzeCommand                called by fhem.pl (1116)
2021.10.23 20:51:43 1:     main::AnalyzeCommandChain           called by ./FHEM/01_FHEMWEB.pm (2779)
2021.10.23 20:51:43 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (1006)
2021.10.23 20:51:43 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (598)
2021.10.23 20:51:43 1:     main::FW_Read                       called by fhem.pl (3895)
2021.10.23 20:51:43 1:     main::CallFn                        called by fhem.pl (773)


Ich füg noch den Dateinamen zur Ausgabe, und dann mal schauen, was da steht wenns wieder passiert.

[betateilchen]

das ganze in print() zu packen, ist m.E. überflüssig.

Code Auswählen Erweitern


sub
FileWrite($@)
{
stacktrace();
  my ($param, @rows) = @_;
  my ($err, @ret, $fileName, $forceType, $nl);


loggt völlig unkompliziert ins FHEM Log.

[eiten]

So, da hätt ich nun ein paar, die über Nacht entstanden sind:

Code Auswählen Erweitern

FILEWRITE 7c3a031e77b30bd48ac0c832f295c74c
2021.10.23 21:55:31 1: stacktrace:
2021.10.23 21:55:31 1:     main::FileWrite                     called by configDB.pm (560)
2021.10.23 21:55:31 1:     main::cfgDB_SaveState               called by fhem.pl (1599)
2021.10.23 21:55:31 1:     main::WriteStatefile                called by (eval 8936) (1)
2021.10.23 21:55:31 1:     (eval)                              called by fhem.pl (1160)
2021.10.23 21:55:31 1:     main::AnalyzePerlCommand            called by fhem.pl (1189)
2021.10.23 21:55:31 1:     main::AnalyzeCommand                called by fhem.pl (1116)
2021.10.23 21:55:31 1:     main::AnalyzeCommandChain           called by ./FHEM/90_at.pm (197)
2021.10.23 21:55:31 1:     main::at_Exec                       called by fhem.pl (3427)
2021.10.23 21:55:31 1:     main::HandleTimeout                 called by fhem.pl (695)
[...]
FILEWRITE 2be94b32512af4df0979fe3bec7ee301
2021.10.23 22:10:31 1: stacktrace:
2021.10.23 22:10:31 1:     main::FileWrite                     called by configDB.pm (560)
2021.10.23 22:10:31 1:     main::cfgDB_SaveState               called by fhem.pl (1599)
2021.10.23 22:10:31 1:     main::WriteStatefile                called by (eval 10869) (1)
2021.10.23 22:10:31 1:     (eval)                              called by fhem.pl (1160)
2021.10.23 22:10:31 1:     main::AnalyzePerlCommand            called by fhem.pl (1189)
2021.10.23 22:10:31 1:     main::AnalyzeCommand                called by fhem.pl (1116)
2021.10.23 22:10:31 1:     main::AnalyzeCommandChain           called by ./FHEM/90_at.pm (197)
2021.10.23 22:10:31 1:     main::at_Exec                       called by fhem.pl (3427)
2021.10.23 22:10:31 1:     main::HandleTimeout                 called by fhem.pl (695)
Also schön alle 15 Minuten. Das und der Output passt wunderbar mit diesem Device zusammen:

Code Auswählen Erweitern

Internals:
   COMMAND    {WriteStatefile}
   DEF        +*00:15:00 {WriteStatefile}
   FUUID      5c9baf4e-f33f-9f51-9a11-59fbe01ae62e107c
   NAME       at_FHEM.saveState
   NR         21
   NTM        10:25:31
   PERIODIC   yes
   RELATIVE   yes
   REP        -1
   STATE      Next: 10:25:31
   TIMESPEC   00:15:00
   TRIGGERTIME 1635063931.17978
   TRIGGERTIME_FMT 2021-10-24 10:25:31
   TYPE       at
   READINGS:
     2021-10-24 10:10:31   state           Next: 10:25:31
Attributes:
   comment    Source: https://forum.fhem.de/index.php/topic,87811.msg802344.html#msg802344

Ist definitiv das WriteStatefile, damit kann ich die Einträge auch manuell erzeugen.

[rudolfkoenig]

Ich glaube da ist configDB der Verursacher, weil manche Readings laenger als 64K sind.

[betateilchen]

Ich glaube da ist configDB der Verursacher, weil manche Readings laenger als 64K sind.

Das glaube ich jetzt auch 

Readings, die länger als 64k sind, werden von configDB automatisch als Datei weggeschrieben und entsprechend referenziert.

Da muss ich mir wohl Gedanken über einen sinnvollen Lösch-Algorithmus machen. Auf die Idee, dass jemand alle 15 Minuten ein statefile erzeugt, bin ich bei der Implementierung des Auslagerns nicht gekommen.

Unabhängig davon würde mich trotzdem interessieren, aus welchem device das reading stammt.

[eiten]

Unabhängig davon würde mich trotzdem interessieren, aus welchem device das reading stammt.

Wie kann ich das herauskriegen?

[eiten]

Ich hätte da eins im Angebot: das retain vom MQTT2_SERVER hat bei mir 75k

[betateilchen]

Kannst Du bitte mit der configDB.pm testen, die ich gerade in SVN eingecheckt habe?

Wenn Du nach der Installation der Datei einen Neustart machst und danach ein "Save config" ausführst, sollten danach die alten Dateien verschwunden sein.
Das erste "Save config" kann bei Deinen über 20.000 Dateien ein bisschen dauern, also nicht die Geduld verlieren.

Der Mechanismus zum Löschen solcher Dateien ist an das Speichern der Konfiguration gebunden. Bevor das neue statefile in die Datenbank geschrieben wird, werden alle vorher verhandenen Auslagerungsdateien gelöscht.

(Das Schreiben des statefile alle 15 Minuten halte ich - nebenbei gesagt - für absolut sinnfrei.)

[eiten]

Naja, die alten Einträge habe ich mit einem SQL-Befehl gelöscht. Hat EWIG gedauert, ich dachte schon MariaDB sei abgestürzt   .
Neu funktioniert super, keine Dateien mehr!

Das häufige SaveState habe ich gemacht, weil ich gewisse Schalter habe, die extrem selten geschaltet werden (Sommer/Winterbetrieb, Auto/Manuell der Aussenlichtsteuerung), welche aber dazwischen keine Events erzeugen. Habe das aber in der Zwischenzeit über dummys gelöst und die Familie angewiesen, den Server zwecks Bodenreinigung nicht mehr auszustecken