Telegrambot Probleme - Nichts verändert, trotzdem Störung

[viegener]

Laufen irgendwelche besonderen Operationen in der Zeit in dieser Nacht?

Gibt es irgendwelche rename operationen ?

[DS_Starter]

Laufen irgendwelche besonderen Operationen in der Zeit in dieser Nacht?

nichts besonderes. FileBackups auf der Synology. Dort liegen alle FHEM Verzeichnisse gemountet auf die VM's der ESXi.

Gibt es irgendwelche rename operationen ?

Das kann ich ausschließen

[DS_Starter]

Aber jetzt fällt mir etwas ein ... ich hatte die vergangene Nacht den regelmäßigen Integritätscheck auf dem Synology Filesystem laufen. Das wäre ein Unterschied zum sonstigen Normalbetrieb.

[viegener]

Da ich gerade nicht so gut auf Synology zu sprechen bin, würde ich sofort dem Verdacht folgen...

Im Ernst, was macht der Integritätscheck und wie könnte das einen Einfluss haben?

Läuft FHEM bei Dir auf der Synology?

[DS_Starter]

Da ich gerade nicht so gut auf Synology zu sprechen bin, würde ich sofort dem Verdacht folgen...

Oh,weshalb das denn ? ...

was macht der Integritätscheck und wie könnte das einen Einfluss haben?

Naja, lt. Hilfe wird nach Dateninkonsistenzen gesucht und bereinigt falls etwas gefunden wird.
Ein Zusammenhang wäre wahrscheinlich weit hergeholt (es läuft ja noch mehr parallel ohne Probs). Ich hatte versucht unterschiede zum sonstigen Betrieb zu finden. Es läuft ja normalerweise wochenlang ohne irgendwelche Sorgen.

Läuft FHEM bei Dir auf der Synology?

Nein, es sind VM's auf ESXi. Aber die Filesysteme der Instanzen (/opt/fhem) liegen auf Syno und sind gemountet. Ist praktisch bzgl. Sicherung usw.

[viegener]

Ich hatte über Wochen Schwierigkeiten mit dem Synology-Support - da sich eine Installation verklemmt hat und die einzige Hilfe, die sie angeboten haben war remote auf mein NAS zu schauen - Befehle für die Lösung oder ein Skript oder was auch immer war nicht möglich.
Am Ende musste ich es quasi neu aufsetzen...

Zum eigentlichen Problem: Ich finde keine Erklärung oder einen Zusammenhang zwischen dem Integritätstest und dem Verschwinden eines Tokens aus der Datei.

Mal so ein paar Ideen:
- Hast Du Devicenamen mit
- Gibt es Ähnlichkeiten zwischen verschiedenen Devicenamen/Tokens in der uniqueID (zur Sicherheit: keine Inhalte aus der Datei hier posten)
- Was sagen die Zeitstempel - Änderungsdaten?

Eigentlich habe ich das Gefühl es könnte mit SMAEM zusammenhängen (auch wenn ich dafür nur Indizien habe):
- SMAEM nutzt die Datei zur Zwischenspeicherung von Werten, das ist zumindestens ungewöhnlich
- SMAEM schreibt die Datei in einem BlockingCall (also in einem separaten call) --> Das kann zumindest theoretisch Chaos geben

Sind die SMAEM-Einträge die letzten in der fehlerhaften Datei? Werden diese Summenwerte nachts geschrieben? Gibt es irgendwelche Auffälligkeiten (z.B. log-eitnräge) zu SMA in der Nacht?

[DS_Starter]

Hallo Johannes,

Am Ende musste ich es quasi neu aufsetzen...

Hmm ... man muß Glück haben an den Richtigen zu kommen. Mit dem Support direkt aus Taiwan, in neuerer Zeit auch aus D, habe ich aber gute Erfahrungen gemacht.

Also inzwischen vermute ich auch das SMAEM-Modul. Es sind zwar keinerlei Auffälligkeiten zu beobachten und ich schreibe auch alle 60 Sekunden in die Datei, nicht nur Nachts. Es muss also eine besondere Situation eintreten. da dieser Fehler nur alle paar Wochen auftritt.
Es ist ja auch so dass setKeyValue zunächst alle Zeilen aus der Datei liest und ggf. verändert wieder reinschreibt. Das würde ja bedeuten setKeyValue  würde mal ein paar Zeilen ignorieren weil es meint das Ende der

Code Auswählen Erweitern

foreach my $l (@old) { -Schleife erreicht zu haben.

Wie dem auch sei, ich habe heute Vormittag SMAEM so umgeschrieben, dass ich ein eigenes CacheFile benutze und nicht mehr uniqueID dafür nutze.

Ich werde das jetzt testen (kann natürlich wieder ein paar Wochen dauern) und das neue Release auch noch im SMAEM-Thread https://forum.fhem.de/index.php/topic,51569.msg636808.html#msg636808  einstellen.

Falls sich Stargazer nochmal meldet oder dir ein andere User ähnliches berichtet, kannst du ihn auch auf diese Thread verweisen sofern er SMAEM einsetzen sollte.

schönen Feiertag,
Heiko

[viegener]

Hallo Heiko,
soviel Aufwand wollte ich jetzt nicht verursachen, es war wie gesagt nur eine Vermutung.

Trotzdem noch eine Frage: Warum verwendest Du in SMAEM eine separate Datei / uniqueIdi und speicherst die Daten nicht in Readings (auch diese können ja normalerweise gespeichert werden und überleben einen Neustart)?

[DS_Starter]

Hallo Johannes,

soviel Aufwand wollte ich jetzt nicht verursachen, es war wie gesagt nur eine Vermutung.

soviel war das nicht    Und wenn es damit erledigt sein sollte war es ja auch ein Erfolg.

Warum verwendest Du in SMAEM eine separate Datei...

Die Readings überleben einen Neustart, das stimmt. Aber nur wenn sie auch im stateFile stehen. Wenn FHEM aber nach einer längeren Laufzeit mal  bei einem Nutzer abstürzen sollte, kann es durchaus passieren, dass im statefile nicht der letzte gemessene Zählerstand ist. Dann gibt es mehr oder weniger große Differenzen. Ich habe hier im Forum auch schon gelesen dass die User gern mal das statefile löschen wenn sie auf Fehlersuche sind.

Diese Differenzmessung wird auch deshalb verwendet, um einen Stromausfall (die Zähler im SMA Meter werden dann zurückgesetzt) tolerieren zu können. Es sind also alles Fehlerpräventionen.

VG
Heiko

[viegener]

Die Readings überleben einen Neustart, das stimmt. Aber nur wenn sie auch im stateFile stehen. Wenn FHEM aber nach einer längeren Laufzeit mal  bei einem Nutzer abstürzen sollte, kann es durchaus passieren, dass im statefile nicht der letzte gemessene Zählerstand ist. Dann gibt es mehr oder weniger große Differenzen. Ich habe hier im Forum auch schon gelesen dass die User gern mal das statefile löschen wenn sie auf Fehlersuche sind.

OK, verstanden. Ich habe für den Fall die Möglichkeit eingebaut automatisch ein "save" anzustossen, wenn sich die Readings verändern (Über Attribut gesteuert). Ich sehe immer das Problem bei separaten Dateien, dass bei einem Restore / Wiederaufsetzen solche Dateien gerne übersehen / vergessen werden.

Generell würde mich aber vor allem interessieren ob das Problem damit gelöst wäre, aber ich weiss das kann einige Zeit dauern bis wir das glauben können.

[DS_Starter]

Ich sehe immer das Problem bei separaten Dateien, dass bei einem Restore / Wiederaufsetzen solche Dateien gerne übersehen / vergessen werden.

Wahrscheinlich ist es unmöglich jeden erdenklichen Fall abzufangen, aber wir versuchen halt ehrgeizig das Beste zu erreichen. 

Ja, dann warten wir es mal ab was da raus kommt. Gut wäre auch wenn sich stargazer melden würde und evtl. bestätigen dass er auch SMAEM einsetzt.
Wenn nicht, würde ich fast an ein generelles Problem glauben ... reines Bachgefühl. Denn in den Routinen setkeyValue bzw. FileWrite gibt es ja auch diverse Checks um das File sauber zu öffnen/schreiben.

Bis später mal ...

Heiko

[KernSani]

@viegener: Da du schon drin bist ist es eigentlich egal, aber: Ist das noch eine Anfängerfrage?

[viegener]

@KernSani - Inzwischen wohl nicht mehr - aber es wäre schon interessant zu sehen ob es andere gibt, die auch das problem haben (vielleicht gibt es ja doch einen Fehler in meinem Modul und er tritt einfach nur selten auf) - Leider kann man den Fall aber auch noch nicht als gelöst zu den Akten legen

[Stargazer]

Hallo zusammen,

ich hatte wieder das Problem.
Vor ca. 10 Tagen. Wieder den token eingespielt und seitdem wieder gut.

Das was derzeit Heiko's und mein System gleich nutzen ist das SMAEM.
Es liegt ja sehr nahe, dass es daran liegt. Bei mir laufen die FHEM Instanzen ebenfalls auf VM's (Workstation Pro).


Bin ja echt mal gespannt, was dein umgeschriebenes Exemplar in der Zeit so macht.


VG

André

[viegener]

Na das ist doch mal ein deutliches Indiz - also würde ich jetzt auch erstmal darauf warten ob die Änderung an SMAEM das Problem löst