Hallo zusammen,
vielleicht eine ganz dumme Frage:
Für das Löschen von Attributen oder Readings gibt es in FHEM ja die Befehle deleteAttr resp. deleteReading.
Gibt es eine ähnliche Möglichkeit auch für Internals?
Hintergrund:
Beim Auslesen eines AEconversion-WR über RS485 kommt es von Zeit zu Zeit zu crc-errors. Diese werden dann in den Status des jeweiligen Gerätes geschrieben. Die Rückmeldungen der Wechselrichter werden beim Schnittstellenmodul AESGI in einen Internal mit Name Antwort geschrieben. Kommt es wie beschrieben zu einem crc-error dann werden alte Einträge anscheinend nicht mehr aus diesem Internal gelöscht, neue Antworten einfach angehängt und der crc-Fehler wird bei jedem neuen Lesevorgang wieder gesetzt. Nun möchte ich über eine DOIF den fehlerhaften Eintrag beim Auftreten des Fehlers löschen und so abfangen.
Oder wäre es allenfalls die bessere Lösung, beim Auftreten des Fehlers die cfg-Datei mit einem rereadcfg neu zu lesen oder mit "shutdown restart" einen Neustart von fhem zu erzwingen. Bis jetzt habe ich das immer zu vermeiden versucht oder das Problem zumindest nur "manuell" damit gelöst...
Ich würde mich eher an den Modulentwickler wenden, dass er dies abfängt, oder ändert. Internals sind Sachen, wo nur er dran arbeiten sollte.
Hallo Amenophis86,
danke für Deine Antwort - leider hat der Modulentwickler bisher auf eine diesbezügliche Anfrage nicht reagiert...
Aus diesem Grund habe ich aktuell als Workaround über ein DOIF eine Abfrage von kritischen Internals implementiert (beispielsweise deutet ein nicht leerer PARTIAL-Eintrag in der AESGI-Instanz darauf hin, dass etwas schief läuft) und rufe bei Bedarf ein "rereadcfg" auf, das alle Einträge rücksetzt.
Ein rereadcfg passiert so ca. zwei Mal täglich, wenn sich die Wechselrichter in den Schlafmodus versetzen oder darauf aufwachen - dann scheinen unvollständige resp. fehlerhafte Telegramme übermittelt zu werden.
Ist es aus Deiner Sicht problematisch, das rereadcfg mit dieser Frequenz aufzurufen?
Wenn du Änderungen vornimmst und diese nicht gespeichert sind bevor der autom. rereadcfg ausgeführt wird, sind die Änderungen weg...
Gruß, Joachim
Ja, danke, das ist sicher so - das heisst, dass Änderungen möglichst nicht dann gemacht werden sollten, wenn die Gefahr für ein autom. rereadcfg hoch ist...
ein reread ist meines Wissens ein "Teilneustart" vom FHEM. Das würde ich nicht o schnell automatisch durchführen lassen (Meiner Meinung nach)
Am liebsten wäre es mir, wenn eine Neuinitialisierung nur der Instanz des AESGI-Moduls möglich wäre (z.B. mit einem reopen oder reset, welches alle Buffer auf den Anfangszustand setzen würde), das hat aber der Entwickler meiner Meinung nach so nicht vorgesehen. Grundsätzlich wäre es wohl auch möglich, die Instanz des Moduls mit einem delete zu löschen und anschliessend mit einem define neu zu definieren und alle Attribute wieder zu setzen, ich bin mir aber nicht so sicher, ob dies wirklich die bessere Lösung zum rereadcfg ist. Oder hat jemand eine andere Idee oder sieht eine andere Möglichkeit, wie eine Instanz eines Moduls wieder auf ihren jungfräulichen Zustand zurückgesetzt werden kann (unabhängig davon, ob der Entwickler eine solche Möglichkeit implementiert hat...)
Auch wenn es trotzdem eine Aufgabe ist, die eigentlich der Modulautor lösen sollte:
Du kannst mal testen, wie sich das device verhält, wenn Du mit "modify" das device mit seiner identischen Konfiguration bearbeitest. Dadurch sollte es komplett neu initialisiert werden.
Ich gebe Dir ja recht, dass das der Modulautor am besten lösen können sollte - nur nutzt mir das im Moment nicht viel... ;)
Ich habe bereits versucht, die Instanz mit defmod zu bearbeiten - daraufhin zeigt meine Instanz zwar an, dass sie neu initialisiert wurde, aber die
beiden Felder Internals "Antwort" und "PARTIAL" bleiben unverändert bestehen.
Das Einzige, was bis jetzt zuverlässig funktioniert hat, war ein "shutdown restart" oder eben ein "rereadcfg", dann wird die Instanz vollständig zurückgesetzt.
Ich werde vielleicht heute Abend mal noch versuchen, ob es tatsächlich geht, wenn ich die Instanz lösche, neu definiere und dann halt die drei vorher gesetzten Attribute neu setze, ich bin mir aber einfach nicht ganz sicher, ob sich mit diesem Vorgehen dann die beiden Instanzen, die auf das problematische Low-Level Schnittstellenmodul aufsetzen, hängen...
ZitatEin rereadcfg passiert so ca. zwei Mal täglich, wenn sich die Wechselrichter in den Schlafmodus versetzen oder darauf aufwachen - dann scheinen unvollständige resp. fehlerhafte Telegramme übermittelt zu werden.
vielleicht wäre es besser die wechselrichter am "einschlafen" zu hindern, bis der modulautor wieder zugegen ist.
Zitat von: leupin am 15 Mai 2018, 12:16:15
Ich habe bereits versucht, die Instanz mit defmod zu bearbeiten - daraufhin zeigt meine Instanz zwar an, dass sie neu initialisiert wurde, aber die
beiden Felder Internals "Antwort" und "PARTIAL" bleiben unverändert bestehen.
Das sollte man mal als Bug für Rudi melden, denn es wäre durchaus sinnvoll, bei der Neuanlage des devices alle vorher vorhandenen internals zu löschen.
So, habe das Problem vorläufig mal wie folgt gelöst:
- mit einem at wird alle 10 Minuten die Anzahl Zeichen im Lesebuffer mit einem set in den Status eines Dummies geschrieben.
- Mit einem DOIF wird überprüft, ob beim Lesen ein crc-error oder ein Überlaufen des Lesebuffers aufgetreten ist (oder-Verknüpfung). Wenn ja, wird in einem weiteren Dummy ein Flag gesetzt, dass die Lowlevel-Schnittstelle (AESGI) und die darauf aufgesetzten Devices zum Auslesen der Daten zurückgesetzt werden müssen.
- Über ein weiteres DOIF werden bei gesetztem Reset-Flag die Instanzen der Lowlevel-Schnittstelle und der aufgesetzten Devices gelöscht (delete) und anschliessend neu definiert und die Attribute neu gesetzt. sowie das Reset-Flag zurückgesetzt.
Tönt etwas kompliziert, aber nur so habe ich ein optimales Timing der Neudefinition der devices hingekriegt, da die ursprünglichen Module leider kein AlignTime-Attribut zur Verfügung stellen, welches eine zeitversetzte Abfrage der Inverter ermöglichen würde...