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
{"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:
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
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...
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.
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.
Zitat von: eiten am 23 Oktober 2021, 19:58:59
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.
Zitat von: eiten am 23 Oktober 2021, 19:58:59
Gibts einen Weg zu sehen, welche Module geladen sind?
FHEM Befehl: fheminfo
Nein, 50_SSFile habe ich nicht im Einsatz:
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.
Zitat von: rudolfkoenig am 23 Oktober 2021, 20:03:44
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?
Da stehen jede Menge "Module" in der Liste, die ich noch nie gesehen habe.
Wo kommen denn die ganzen zigbee2mqtt.* und die eBus_.* her?
ZitatHm, und wie meinst Du das?
Z.Bsp. indem man im readingList eines MQTT2_DEVICE FileWrite aufruft.
ZitatRespektive, wie komme ich da weiter?
Ich wuerde in fhem.pl, am Anfang von FileWrite() ein stacktrace() einbauen.
Zitat von: rudolfkoenig am 23 Oktober 2021, 20:26:48
Ich wuerde in fhem.pl, am Anfang von FileWrite() ein stacktrace() einbauen.
Sehr gute Idee!
Zitat von: betateilchen am 23 Oktober 2021, 20:25:41
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...
Also,
mysqldump -u root -p fhem_config |grep FileWrite
hat leider nix ausgespuckt...
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):
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.
das ganze in print() zu packen, ist m.E. überflüssig.
sub
FileWrite($@)
{
stacktrace();
my ($param, @rows) = @_;
my ($err, @ret, $fileName, $forceType, $nl);
loggt völlig unkompliziert ins FHEM Log.
So, da hätt ich nun ein paar, die über Nacht entstanden sind:
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:
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.
Ich glaube da ist configDB der Verursacher, weil manche Readings laenger als 64K sind.
Zitat von: rudolfkoenig am 24 Oktober 2021, 10:25:47
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.
Zitat von: betateilchen am 24 Oktober 2021, 11:09:50
Unabhängig davon würde mich trotzdem interessieren, aus welchem device das reading stammt.
Wie kann ich das herauskriegen?
Ich hätte da eins im Angebot: das retain vom MQTT2_SERVER hat bei mir 75k
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.)
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 ;)