ich lese Daten von einem Solax Hybrid Wechselrichter via Modbus TCP aus. Es passt alles soweit, allerdings nimmt der Wechselrichter einmal pro Stunde sowas wie eine Zwangstrennung vor und die spammt mir ganz schön die Logs voll.
Gibt es eine Möglichkeit bei der Schnittstelle seitens Symcon Timeout oder generelle Fehler zu unterdrücken? Die Trennung ist leider nicht immer genau stündlich. Die Wandert Stunde etwas weiter. So habe ich im Log halt immer stehen
17.05.2025, 23:02:10 | Client Socket | Fehler beim Lesen: Connection reset by peer
18.05.2025, 00:02:23 | Client Socket | Fehler beim Lesen: Connection reset by peer
18.05.2025, 01:02:27 | Client Socket | Fehler beim Lesen: Connection reset by peer
18.05.2025, 02:02:53 | Client Socket | Fehler beim Lesen: Connection reset by peer
18.05.2025, 03:03:02 | Client Socket | Fehler beim Lesen: Connection reset by peer
18.05.2025, 04:03:22 | Client Socket | Fehler beim Lesen: Connection reset by peer
Und in der Fehlerlog stehen dann immer die ersten Werte die abgerufen werden. Der Rest kommt dann wieder.
17.05.2025, 23:02:11 | TimerPool | PV Powermeter Modbus (UpdateTimer): GridPower X1 (Wechselrichter): Zeitüberschreitung beim Warten auf Antwort
18.05.2025, 00:02:06 | TimerPool | PV Powermeter Modbus (UpdateTimer): PvPowerDC2: Zeitüberschreitung beim Warten auf Antwort
18.05.2025, 00:02:15 | TimerPool | PV Powermeter Modbus (UpdateTimer): GridPower X1 (Wechselrichter): Zeitüberschreitung beim Warten auf Antwort
18.05.2025, 00:02:24 | TimerPool | PV Powermeter Modbus (UpdateTimer): GridPower X1 (Wechselrichter): Zeitüberschreitung beim Warten auf Antwort
Die Abfrageverzögerung liegt bei 7 Sekunden. Die Wartezeit bis zum Timeout steht wieder auf 2 Sekunden. Zwischenzeitlich hatte ich die mal auf 60. Hatte allerdings auch nichts gebracht. Da es sich aber auch um Meldungen handelt die ich nicht weiter beobachten muss, würde ich sie gern unterdrücken können.
Gleiches Problem habe ich auch an einem WR.
Wenn die Sonne untergeht schaltet er sich aus.
Ich schließe den Socket wenn der WR nicht mehr über Ping erreichbar ist aber selbst das liefert zahlreiche Fehler, die die „wirklichen Fehler“ im System einfach verschleiern
Gleiches Thema bei TCP-Sockets oder auch SNMP.
Es gibt Geräte, bei denen „aus“ ein valider Zustand ist oder bei denen man weiß, dass sie nicht 100% zuverlässig antworteten aber man das bewusst in Kauf nimmt.
Tausende Fehlermeldungen im System helfen da einfach nicht weiter
Vorschlag:
Vielleicht kann man entscheiden ob man die Fehlermeldung im Log haben will oder eine Statusvsariable „Verbindungsfehler“ in der Instanz nutzen möchte.
Darauf könnte man ohnehin einfacher triggern um dann gezielt zu warnen oder eine Aktion auszuführen.
Hättet ihr evtl. eine Idee, wie man dies cleverer erkennen kann? Denn ganz deaktivieren ist auch nicht so ganz optimal. Außerdem würden zumindest die Verbindungsabbrüche vom Client Socket auch noch im Log auftauchen.
Eine Option im Socket „Unterdrücke Verbindungsmeldungen“. Dazu vielleicht die Möglichkeit ein Script oder eine Variable anzugeben - falls man eventuell Zeitverzögert darauf reagieren will.
Mit aktivierter Funktion pausiert die Schnittstelle alle Anfragen oder lädt die zuletzt empfangenen Werte erneut. Das unterdrückt dann ja die Fehler mit Timeout. Die Meldung Reset by peer bleibt auch in diesem Fall aus. Symcon setzt stattdessen auf die angegebenen Möglichkeiten. Anschließend wird 3 Minuten probiert eine neue Verbindung herzustellen (1x pro Minute) und wenn das nicht klappt kommt der Ablauf so wie jetzt. Die Schnittstelle geht auf Störung, die Variablen melden Timeout.
Wenn ich das richtig verstehe ist Connection reset by peer sogar eine aktive Meldung vom Busteilnehmer. Darauf kann man ja entsprechend reagieren.
Gibts bei Modbus sowas wie KeepAlive Pakete auf die man reagieren kann? Oder wird das über die übliche Kommunikation gelöst? Dann könnte man in firebusters Situation ja auch reagieren. Fällt das KeepAlive weg oder die Pakete bleiben ohne Rückmeldung bei aktivierter Einstellung, reagiert Symcon ebenfalls wie oben.
Ich habe zum Testen mal die automatische Abfrageintervalle auf 0 Sekunden gesetzt und den Timeout auf 120 Sekunden. Jetzt frage ich die Instanz mit Script und 30 Sekunden Timer ab.
Es kommen keine Zeitüberschreitungen mehr. Dafür jetzt neue End of File Meldungen.
24.05.2025, 14:01:00 | Client Socket | Fehler beim Lesen: Connection reset by peer
24.05.2025, 14:02:31 | Client Socket | Fehler beim Lesen: End of file
24.05.2025, 15:01:02 | Client Socket | Fehler beim Lesen: Connection reset by peer
24.05.2025, 15:02:33 | Client Socket | Fehler beim Lesen: End of file
Wie beschrieben über eine Statusvariable könnte man den Verbindungsstatus ausgeben und dann auch darauf reagieren wenn wirklich was kaputt sein sollte.
Selbst der Neustart vom ClientSocket wären schön wenn man die unterdrücken könnte.
Ich habe in einer Installation ne ganze Reihe TVs die sehr unzuverlässig Antworten. Das weiß ich und fange das auch auf anderer Weise ab. Das Log selbst wird dadurch aber einfach unbrauchbar.
Ein Spezialschalter wie beim Variablenwatch könnte da auch helfen aber blendet natürlich gleich alle Geräte aus, auch die, von denen man den Status gerne im Log hätte.
Aus Entwickler-Sicht wäre es schön wenn man den Status in der Geräte-Instanz komplett selbst verarbeiten kann wenn der Socket „kaputt“ ist.
