[GELÖST] - fhem.save wächst, System wird träge bis es nicht mehr reagiert ....

[traders-banquet]

Ich habe ein Problem und bisher keine Lösung.

Die fhem.save ist bei mir im Log-Verzeichnis von Fhem.
Diese Datei wächst, zuletzt zu einer Größe von 151 MB. Das hatte zur Folge, dass sich das Webfrontend nicht mehr aufrufen lies und auch Ereignisse ( Reaktionen auf Bewegungsmelder ) sehr verzögert ausgeführt wurden.
Es half nur den Fhem Prozess abzuschießen, die fhem.save zu löschen und Fhem wieder zu starten. Ein Versuch eines neustarts habe ich nach einer Stunde abgebrochen, in der Fhem Log stand including fhem.save und nach einer Stunde hatte ich die Geduld verloren und den Prozess beendet, die fhem.save gelöscht und Fhem neu gestartet.
Jetzt habe ich erstmal ein sehr fluffiges System, die fhem.save hatte nach dem ersten abspeichern gerade mal 400 KB. Anweisungen werden sofort ausgeführt, sowie Reaktionen auf Bewegungen über einen Bewegungsmelder werden sofort ausgeführt. Leider hatte FHEM durch diese Aktion sämtliche Zustände vergessen.

Ich frage mich, was kann man tun, damit die fhem.save derart wächst, dass Fhem nicht mehr auf Anfragen ragiert ? Kann man diese Menge, 151 MB ist wahrlich nicht wenig, beeinflussen ? Kollegen haben in der gleichen Datei vielleicht 7-10 MB.
Ich habe in meinem System 14 Fensterkontakte, 10 Heizungsthermostate, 35 Sonoff Geräte mit Tasmota, 6 Zigbee Geräte und ein paar Abfragen der örtlichen Tankstellen, ein paar Unify Geräte ein Nuki .... etc. das war es auch schon.

Hat jemand vielleicht einen Typ für mich, wonach ich suchen kann ? Ich beobachte dieses Phänomen schon seit einem Jahr, doch fand ich im Web bisher keine Hinweise, die mich weiter gebracht hätten.

Vielen Dank für Eure Mühen

[betateilchen]

Wir hatten vor einiger Zeit schonmal so ein Problem, damals waren, wenn ich mich recht erinnere, die retain Daten in MQTT devices (Server?) als Ursache für das übergroße statefile identifiziert.

[betateilchen]

ich habe es gefunden...

ein genauerer Blick in das File hat dann unter anderem offenbart, was Beta-User schon vermutet hat: MQTT retain Müll. Extrem viel davon. Ich hab den mit set <MQTT2_SERVER> clearRetain gelöscht. ...

Tut alles wieder so, wie's soll.

https://forum.fhem.de/index.php/topic,129404.msg1237333.html#msg1237333

Dass es damals um einen Nutzer mit configDB geht, ist dabei nicht relevant.

[rudolfkoenig]

Ich habe fhemdebug mit dem Befehl "sizeInFile" erweitert, das sollte die Suche nach dem Verantwortlichen vereinfachen.

[traders-banquet]

Großartig, mit dem Befehl

Code Auswählen Erweitern

set MQTT2 clearRetain ist das Problem gelöst, meine Datei war schon wieder auf 2,5 MB angeschwollen, also noch vollkommen klein, doch mit dem Befehl sind sie auf 1,5 MB geschwunden. Die Ursache wird in meinem Falle : OpenMQTTGateway_ESP32_BLE sein. Dieses Device entdeckt täglich derart viele Geräte, das ich mich schon mehrfach gefragt habe, wo die alle sein sollen und der Verdacht nahe liegt, das auch in Geräten BLE Devices stecken, in denen dies nicht vermutet wird. Ich werde mich wohl nochmal mit dem OpenMQTTGateway_ESP32_BLE beschäftigen müssen und die white_list verwenden. Bisherige Versuche scheiterten leider immer. Ich wohne ländlich und in BLE Reichweite sind um mich herum 3 weitere Häuser. Ich habe täglich über 250 Geräte, welches das OpenMQTTGateway_ESP32_BLE entdeckt.

Vielen Dank

[frank]

Dieses Device entdeckt täglich derart viele Geräte, das ich mich schon mehrfach gefragt habe, wo die alle sein sollen

vielleicht vorbeiziehende handy/navi von fussgängern/fahrzeugen?

[rudolfkoenig]

Ich habe täglich über 250 Geräte, welches das OpenMQTTGateway_ESP32_BLE entdeckt.

Meine Theorie:
- Android/Apple Telefone wechseln staendig die Bluetooth Adressen, damit man fuer Ladenanbieter/etc nicht verfolgbar wird.
- OpenMQTTGateway kann nicht solche Adressen identifizieren, und stuft sie jeweils als neues Geraet ein.
- OpenMQTTGateway sendet die Daten mit der retain MQTT-Flag an dem MQTT Server weiter. Wenn ich die Diskussion im Internet verstehe, damit angeschlossene HA-Systeme beim Startup alle Daten mitkriegen. Habe keine Option gesehen, um retain abschalten zu koennen.
- MQTT2_SERVER nimmt retain ernst, und speichert Nachrichten mit retain.

Bisher gab es in MQTT2_SERVER keine Moeglichkeit, retain Messages zu filtern.
Ich habe die Funktion des ignoreRegexp MQTT2_SERVER Attributes erweitert: ab sofort werden zutreffende Nachrichten nicht  gespeichert (falls retain gesetzt ist), noch an andere Clients weiterverteilt.

[rob]

Vielen Dank an Euch. Anfang Oktober war mein statefile auf 154MB angeschwollen. Dachte ich hab was verwurstet und mich nicht getraut mich zu outen.
Seitdem ermittle ich die Größe bei jedem save und zeige das grafisch an, um ein Gefühl zu bekommen, wie schnell das geht. Bisher aber bei niedlichen 660KB.

Retain klingt sehr plausibel. Meine Kameras senden nämlich Snapshots bei MotionDetection und das steht leider auch im retain drin (bisher nur im Ganzen abschaltbar). Seit Oktober sind die ausgeschaltet, was das niedliche statefile erklären würde.

Würde auch ein "hideRetain 1" hier helfen? Oder wird das hidden Reading trotzdem ins statefile geschrieben? Hab ich so konkret nicht aus der commandref herausgelesen.

[kroman]

Ich werde mich wohl nochmal mit dem OpenMQTTGateway_ESP32_BLE beschäftigen müssen und die white_list verwenden. Bisherige Versuche scheiterten leider immer.

Ich habe die whitelist im OpenMQTTGateway so gesetzt - funktioniert wunderbar.

Code Auswählen Erweitern


set mqtt2server publish -r home/OMG1/commands/MQTTtoBT/config {"white-list":["xx:xx:xx:xx:xx:xx","yy:yy:yy:yy:yy:yy","zz:zz:zz:zz:zz:zz"]}


[rudolfkoenig]

Würde auch ein "hideRetain 1" hier helfen?

Nein. Wie der Name schon sagt, es verhindert nur die Anzeige.
Statt im RETAIN Reading werden die Daten im .RETAIN gespeichert.

[Steigerbalett]

Meine Theorie:
- Android/Apple Telefone wechseln staendig die Bluetooth Adressen, damit man fuer Ladenanbieter/etc nicht verfolgbar wird.
- OpenMQTTGateway kann nicht solche Adressen identifizieren, und stuft sie jeweils als neues Geraet ein.
- OpenMQTTGateway sendet die Daten mit der retain MQTT-Flag an dem MQTT Server weiter. Wenn ich die Diskussion im Internet verstehe, damit angeschlossene HA-Systeme beim Startup alle Daten mitkriegen. Habe keine Option gesehen, um retain abschalten zu koennen.
- MQTT2_SERVER nimmt retain ernst, und speichert Nachrichten mit retain.

Bisher gab es in MQTT2_SERVER keine Moeglichkeit, retain Messages zu filtern.
Ich habe die Funktion des ignoreRegexp MQTT2_SERVER Attributes erweitert: ab sofort werden zutreffende Nachrichten nicht  gespeichert (falls retain gesetzt ist), noch an andere Clients weiterverteilt.

Danke.
Ich habe, nachdem FHEM bei mir faktisch eingefroren war und auch nicht mehr starten wollte, nach langer suche auch die MQTT Retain Nachrichten als Übeltäter ausfindig gemacht. Aber nachdem das Thema hier im Forum bisher unter meinem Radar lief hab ich das per per regelmäßigem löschen der Daten für mich mehr schlecht als recht erledigt...

[betateilchen]

Verständnisfrage:
In welchen Fällen ist es überhaupt sinnvoll, dieses reading in das statefile zu schreiben?

[rob]

Ja, spannende Frage. Inbes. wenn jmd. das Rading aus der Anzeige ausblendet, doch weiterhin bei jedem Save/ Restart weiterhin mitschleift. Ggf. zum Triggern. Aber was macht da Sinn?

Btw.: Bei den MQTT2-Devices gibt es das klasse Feature "periodicCmd" womit man aufräumen kann. Als workaround könnte man ein Device auserwählen und den Server mit aufräumen.
Ich hab aber ein at auf Verdacht angelegt, um retain darüber periodisch zu säubern.

[rudolfkoenig]

In welchen Fällen ist es überhaupt sinnvoll, dieses reading in das statefile zu schreiben?

Laut RFC:

Code Auswählen Erweitern

Retained messages do not form part of the Session state in the Server, they MUST NOT be deleted when the Session ends [MQTT-3.1.2.7].

Aus diesem Grund habe ich, ohne laenger nachzudenken, Nachrichten mit retain persistiert.

Im Fall eines gewoehnlichen(!) MQTT-Servers kann man mit solchen Nachrichten neu hinzugekommenen Subscribern mitteilen, welche Publisher ueberhaupt mitmachen, oder deren aktuellen Status liefern, ohne dass die Sender einzeln gefragt werden muessen.

Falls der MQTT Server nur fuer FHEM verwendet wird, ist Retain vermutlich sinnlos.
Ich schlage vor Retain per Voreinstellung zu ignorieren, im Sinne von nicht speichern.

[betateilchen]

Danke für die Erklärung.

Ich schlage vor Retain per Voreinstellung zu ignorieren, im Sinne von nicht speichern.

Das wäre auch mein nächster Vorschlag gewesen 


--