Ich weiß dass ich mit meiner Socket-Unzufriedenheit recht allein bin auf weiter Flur Die meisten User nutzen scheinbar Sockets, die 24/7 aktiv und verbunden sind. Meine Geräte hingegen, die nur bei Bedarf eingeschaltet werden, bereiten wegen des Backoffs im automatischen IPS-Reconnect immer wieder Probleme.
Kriegen wir nicht eine Möglichkeit hin, die Meldung „Warning: Socket ist nicht verbunden“ über das Event Control o.ä. abzufangen? Ich würde eben spätestens wenn diese Meldung kommt, einfach ein „Open false+true“ auf den Socket ausführen wollen - das klappt dann ja i.d.R. zuverlässig.
Oder anders ausgedrückt: derzeit ist es so, dass wenn ich eine Schaltaktion auslöse und diese wegen fehlerhaftem Socketstatus scheitert, kein Socket-Reconnect versucht wird - es wird einfach auf der Backoff-Zeit beharrt. Das sollte nicht sein… spätestens beim zweiten Versuch die Schaltaktion auszulösen, muss vorher ein Reconnect(-Versuch) stattgefunden haben.
Btw: die genannte Fehlermeldung bitte auch von diesem schrecklichen „Denglisch“ befreien
Ich habe auch ein I/O Modul, dass nur bei Bedarf eingeschaltet wird. Da das Einschalten per Zigbee Steckdose, auch aus IPS erfolgt, habe ich ein Script mit dem Status der Steckdose verknüft.
$CSID1 = 51294 ; // ID des Client Socket
IPS_Sleep(3000);
IPS_SetProperty($CSID1,"Open",$_IPS['VALUE']);
IPS_ApplyChanges($CSID1);
Das funktioniert in meinen Kontext nicht, da es kein „Steckdose an“ gibt. Und es bleibt ja leider auch eine Krücke.
Anderer Anwendungsfall, den ich durchaus auch schon erlebt habe: Homematic-CCU ist mal kurzzeitig (aus irgendwelchen in der Infrastruktur bedingten Gründen) nicht erreichbar. Zyklisch versucht IPS korrekt, die Verbindung wiederherzustellen. Wenn ich innerhalb dieses Zyklus versuche eine Lampe einzuschalten, scheitert dies verständlicherweise. Aber auch ein zweiter und dritter Versuch die Lampe einzuschalten, bleibt erfolglos. Würde einfach direkt beim ersten Fehler ein Reconnect versucht, hätte sich das Problem deutlich schneller erledigt.
Ich habe mir eine Funktion „SendSocket_Own“ geschrieben, welche ggf. prüft ob der Socket offen ist, falls nein ihn öffnet, wartet und nochmal sendet.
Zudem kann man über EventControl den Status der Instanz doch abfragen. Dazu ein Script „IO Instance Status Change“ anlegen und über die Kern Instanz EventControl dem Socket zuordnen.
Tobias, dein Ansatz ist genau richtig. Aber mal ehrlich, das muss doch nativ aus IPS ohne eigene Funktionen gehen.
Homematic und Modbus beispielsweise nutze ich ja komplett ohne Skriptfunktionen die ich mit „_own“ abwandeln könnte.
Das derzeitige EventControl nutzen wie von dir beschrieben funktioniert nicht. Das EC reagiert nur, wenn sich der Status des Sockets ändert. Leider nicht, wenn etwas auf den Socket geschrieben werden soll und dies fehlschlägt. Genau darauf zielt mein FeatureRequest ab.
Das Problem ist natürlich vorhanden und ich würde mich auch über die oben beschriebene Funktionalität freuen. Bevor eine Fehlermeldung geworfen wird sollte ein reconnect versucht werden und optional eine Info-Meldung kommen um eventuelle Fehler (jedes mal reconnect) erkennen zu können.
Das der Socket klemmt, ist seit ca. 10 Jahren bei mir immer wieder ein Problem. Da ja eigentlich alles an Kommunikation über Client-Sockets läuft wäre es echt gut das würde mal grundlegend überarbeitet.
hast du das irgendwo mal nachstellbar beschrieben? Denn aktuell sind mir dort (außer dem sehr speziellen Problem bei ika mit dem seriellen Port) keine Probleme bekannt.
@paresy nein das verwechselst du. Es geht hier weder um serielle Ports noch um was Spezielles bei mir Der zickende Serialport ist eine andere Baustelle, an die ich mich gewöhnt hab. Daran wirst du nichts tun können.
Hier geht es um Netzwerk-Sockets und grundsätzliche Fehlerbehandlung übers EventControl.
ich weiß Ich wollte auch eher Tobias auffordern ein eigenes Thema zu eröffnen, wenn er mit den Sockets generelle Probleme hat - ich hatte dies zumindest so verstanden
Für deinen Fall: Was hältst du davon, wenn man im Event Control ausnahmen definieren kann, für die das Backoff nicht greift? Diese würden dann mit einem von dir definierbarem Intervall überprüft? (Min. 10 Sek würde ich trotzdem als sinnvoll erachten)
Die Variante mit dem automatischen Reconnect sobald eine Anfrage kommt ist sicherlich eine coole Idee - die Realisierung aber ein sehr komplexes Thema welches wir nicht zwischendurch angehen können. Und wie aktuell im Wünsche Forum zu sehen gibt es sehr viele Dinge die wir anfassen wollen - da sehe ich aktuell keine Zeit für
Wir können das Thema -falls gewünscht- sogar etwas weitreichender fassen:
Wir hatten vor einigen Monaten hier ja schon das Thema, dass in jedes gute Hausautomations-Skript eine Fehlerbehandlung gehört und Befehle nicht einfach „fire and forget“ abgesetzt werden sollen:
Die hier genannten Ansätze sind voll zu unterstützen. Aber es ist doch nicht pragmatisch, jedes bspw. „HM_WriteValueBoolean“ auf false-Ergebnis zu kontrollieren, nur um dann einmal den Socket zu resetten. Das sollte vollautomatisch gehen bzw. ich sollte die Möglichkeit haben, diese Fehler global in einer Art EventControl abzufangen… da dann gerne mit eigenem Skript drauf reagieren: Socket-Reset und gleichzeitig eine Prowl oder Mail an mich absetzen usw.
Für deinen Fall: Was hältst du davon, wenn man im Event Control ausnahmen definieren kann, für die das Backoff nicht greift? Diese würden dann mit einem von dir definierbarem Intervall überprüft? (Min. 10 Sek würde ich trotzdem als sinnvoll erachten)
Ich frag mal naiv: dann könnte ich aber auch einfach zyklisch ein Skript alle 10 Sekunden laufen lassen, welches den Socket-Status prüft und dann ggf. den Socket resettet, oder? Wäre mein absoluter Notfall-Plan, da ich hier auch immerhin schon ca. 10 Sockets habe, die das betrifft. Da kommt ja schon was zusammen. Oder übersehe ich was? Der „eventbasierte“ Ansatz (bei Auftreten des ersten „Nicht-Verbunden“-Fehlers wäre mir lieber. Zyklisch bzw. im Backoff würde ich dann noch zusätzlich ca. alle 5 oder 10 Minuten prüfen um.
Hi paresy.
Ich hatte das Thema kürzlich nochmal im Discord, unter Anderem mit Nall-chan recht ausführlich besprochen… gedanklich sind wir uns da einig, dass das Problem a) zwar kaum Jemanden betrifft (weil die Meisten Ihre Socket-Verbindungen 24/7 stehen haben oder Ihre Instanzen „sauber“ nach Zeitplan aktivieren oder deaktivieren können), aber auch b) dass das Problem existent ist und derzeit kaum zu Umschiffen.
Die Variante mit dem automatischen Reconnect sobald eine Anfrage kommt ist sicherlich eine coole Idee - die Realisierung aber ein sehr komplexes Thema welches wir nicht zwischendurch angehen können.
Verstehe ich voll. Dennoch eine Rückfrage: unabhängig von dem „automatischen Reconnect“ (welcher ja scheinbar ohnehin den wenigsten Usern einen Mehrwert bringt):
Macht diese Art der „Fehlerbehandlung“ nicht aber generell Sinn? Mir knirschen halt die Zähne, wenn ich sehe, dass IPS eine Meldung wirft; ich aber scheinbar absolut keine Chance habe auf diese Fehlermeldungen eventbasiert und programmatisch zu reagieren. Das gilt ja für sämtliche Fehlermeldungen die mal so auftreten könnten. Letztlich muss ich mich also drauf verlassen, dass „Fire&Forget“ kein Problem ist - weil meine Infrastruktur gefälligst immer einwandfrei zu sein hat.
Ist das wirklich so komplex zu Entwickeln? Es würde ja völlig reichen, wenn die Error-Ausgabe eines Skriptbefehls, bspw. „Warning: Socket ist nicht verbunden“ schonmal einfach ins Log geschrieben wird - derzeit wird sie einfach nur ausgegeben und taucht sonst nirgendwo mehr wieder auf.
Wenn ich dann noch irgendwie prüfen könnte: if ($IPS['aktuelleLogmeldung') == "Warning: Socket nicht verbunden" { ... }
…dann wären meine Sorgen ja schon erledigt Ist zwar nur Quasi-Eventbasiert, würde aber funktionieren.
Sonst fiele mir nur ein, ohne Längere Backoffs zu arbeiten - wie du schon geschrieben hast. Aber: Der Grund weswegen das Backoff eingeführt wurde, ist ja richtig: damit das Log nicht zu oft mit Verbindungsversuchen vollgemüllt wird. Hier müsste man also „rückwärts gedacht“ dann die Verbindungs-Fehlermeldungen im Log unterdrücken können.
das scheint für die Modbusse und andere Client-Socket-basierende Schnittstellen eine Möglichkeit zu sein! Danke für den Denkanstoss. Ich teste das im Dauereinsatz!
Wie mache ich das aber beim Homematic-Socket? Welches XXX funktioniert hier bei XXX_SendText?
Oder hilft hier nur das „testweise“ Schalten eines Blindaktors?
if(@HMWriteValueBoolean(...) === false) {
Und aber trotzdem bitte mal die Fehlerbehandlung mit in die mittelfristige Roadmap nehmen… „abfangen“ kann ich mit XXX_SendText die Fehler (z.B. bei Schaltbefehlen) nicht - ich kann nur durch zyklischen künstlichen Nonsens-SendText den Fehler provozieren und damit abfangen! Reicht mir erstmal - geht aber schöner
Die meisten User nutzen scheinbar Sockets, die 24/7 aktiv und verbunden sind. Meine Geräte hingegen, die nur bei Bedarf eingeschaltet werden, bereiten wegen des Backoffs im automatischen IPS-Reconnect immer wieder Probleme.
Ich wollte auch eher Tobias auffordern ein eigenes Thema zu eröffnen, wenn er mit den Sockets generelle Probleme hat - ich hatte dies zumindest so verstanden 