IPS (6.2) sollte fehlertoleranter werden

Funktionswünsche IP-Symcon
#1

Ich betreibe seit Jahren problemlos einen Pokeys und greife auf diesen mittels Modbus drauf zu.
Nun hat sich auf diesem - wohl selbst verschuldet und ungewollt - die IP Adresse verändert.
Die Reaktion schaut wie folgt aus:

image
image905×20 3.64 KB

Außerdem:
image
image826×49 4.32 KB

Leider ist das auch nicht „selbstheilend“ wenn man den Pokeys wieder auf die richtige Adresse dreht.
Das Ganze wird erst dann wieder Laufend wenn man die Instanz manuell deaktiviert und wieder aktiviert.
Ich würde mir wünschen dass dies ohne manuelles eingreifen wieder gut wird.

Beste Grüße aus Linz,
Hans

#2

Bau dir doch mit einem Script im Event-Manager einen Reconnect

#3

Tatsächlich sollte der Socket sich von alleine „heilen“ wenn die Adresse wieder erreichbar ist. Kannst du das nachstellen, was da schief geht? Denn wenn die Instanz rot markiert ist, versuchen wir periodisch diese neu zu verbinden. Wenn der Fehler sehr lang vorhanden war, dann ist jedoch der nächste Wiederversucht ggf. erst nach 24 Stunden.

paresy

#4

Ich kann das testen - die Adresse war ca. 12h nicht erreichbar - und ich hätte mangels besseren Wissens erwartet dass die relativ zügig nach Wiedervorhandensein erkannt wird.
Ich hab ca. 10 Min. gewartet. War das zu kurz?

#5

Jupp. Wir versuchen mit exponentiell höher werdendem Timeout. Die Formel ist 2^x Sekunden, wobei X die Anzahl der Versuche ist.

paresy

#6

Jetzt wird mir auch klar, warum meine Modbus Instanzen nach einem Verbindungsverlust zu den Wechselrichtern und ESS teilweise nicht wieder kommen.
Kann man den Algorithmus nicht etwas kürzer fassen?
Wenn die Verbindung mal etwas länger weg ist kann man doch nicht wieder 24h warten?
VG Doc

#7
  • an die Stirn klatsch - das erklärt vieles.
    Man lernt echt nie aus.

bb

#8

dies erklärt auch bei mir diverse Instanzen die nicht automatisch reconnecten :wink:
wäre schön wenn man das konfigurierbar machen könnte :slight_smile:

#9

Darüber habe ich mich auch schon so einige Male gewundert, warum die Verbindung zu einem Gerät, welches länger nicht erreichbar war, nicht wiederkommt. 24 h habe ich natürlich nie gewartet…

Ist das ein generelles Verhalten bei Instanzen, die als fehlerhaft markiert sind oder gilt das nur für die I/Os?

#10

Ja toll wäre eine Alarmierung im Fehlerfall - wie mach ich das ?

Der Alarm sollte abfragbar sein.
Und irgendwie auf der Instanz ein Hinweis WANN der nächste Versuch stattfindet (abfragbar) - wobei man das übersteuern können sollte (evtl. auch von einem externen Objekt).
Wünsche wird man ja haben dürfen :slight_smile:

#11

Geht schon immer. Die Instanz nennt sich Event Control und ist immer vorhanden (Kern Instanz).

Die kann bein Zustandsänderung ein Script starten.
Alternativ ist der Zustand über IPS_GetInstance abfragbar.

Geht auch jetzt schon. Ein IPS_Applychanges(InstanzID) würde sofort ein reconnect oder ähnliches herbeiführen.

Immerhin 2 von 3 Wünschen ist jetzt keine schlechte Quote :slight_smile:

Für IOs und Splitter Instanzen.
Michael

#12

Zumindest eine Anzeige welche den nächsten Verbindungsversuch visualisiert wäre gut.

  • und ein bisl erklärenden Text dazu. Is eh so viel ungenutzte weiße Fläche in den Fenstern.
    Weil heute weiß mans noch, nächstes Jahr schon wieder vergessen.

Schätze wenn mir das Verhalten bewusst gewesen wäre dann wäre euch der ein oder andere Mecker wegen „hängender Interface“ erspart geblieben.

schöne Grüße
Bernhard

#13

Ich habe gestern mal das OctoPrint Modul zum Testen installiert, welches auch sofort funktioniert hatte.
Heute hatte ich den 3D Drucker wieder neu gestartet/eingeschaltet, aber das Modul hatte sich nicht wieder verbunden, der WS_Client hatte keine Verbindung. Erst nach deaktivieren und aktivieren der Instanz war die Verbindung wieder da.

Ich denke auch hier war der Zeitraum über Nacht schon wieder zu lange für eine zeitnahe Neuverbindung?

Könnt ihr das nicht abkürzen?
Ich denke mehrere Stunden als Intervall für einen Neuversuch eine verlorene Verbindung wieder zu erstellen ist doch nicht zeitgemäß?
Kann man das nicht zeitlich nach oben deckeln oder was ist der Grund für die langen Intervalle?
Verbraucht das zu viele Resourcen?

VG,
Doc

#14

Der default sollte es kürzer sein → was ist der Grund dass das Intervall so hoch gewählt ist?
Evtl. wäre es möglich das Reconnect Intervall selbst pro Instanz (-typ) definierbar zu machen?

#15

ich weiß nicht ob ihr den Kommentar von paresy nur überflogen habt, aber es ist doch eine ansteigende Zeit, also 1. Wiederholung nach 2 Sekunden, 2. Wiederholung nach 4 Sekunden, dann nach 8 , 16, 32, 64 usw. bei de 10. Wiederholung ist man erst bei einer Wartezeit von 17 Minuten , bis dahin ist aber durch die andern Retrys schon 30 Minuten vergangen… wenn 15 mal nicht geklappt hat, dann seid ihr bei 9 Stunden… bis dahin hat es aber über 18 Stunden schon nicht geklappt… Ich seh da gerade das Problem nicht.

#16

Ich kann verstehen, dass dies für einige Anwendungen viel zu lange ist. Ich denke da aktuell an eine Liste, bei der man die Strategie umschalten kann (Immer minütlich oder exponentiell), das maximale Limit einstellen kann (z.B. alle 4 Stunden) und eine List, bei der man je Instanz noch ausnahmen definieren kann. Das würde dann die volle Flexibilität liefern.

paresy

2 „Gefällt mir“
#17

Das ist nett, das du da „investieren“ magst… hätte es aber auch nicht direkt als große Baustelle gesehen, zumal man ja im Notfall per Eventcontrol ja auch selber „Hand anlegen“ kann. (da wären andere Punkte weiter oben auf meiner Wunschliste :smiley: )

#18

Wann wir investieren weiß ich noch nicht, aber zumindest ne Idee haben ist schon mal gut. Zumal das Problem tatsächlich schon öfter vorgekommen ist und insbesondere das Verständnis hinter der Systematik nicht klar ist. Ich weiß auch nicht, ob dies sauber dokumentiert ist.

paresy

#19

Ich möchte aber nicht, das wenn der Drucker mal 18 Stunden ausgeschaltet war, wieder 9 Stunden warten müssen, bis er eine Verbindung zu IPS herstellt. In der Zeit ist er auch bestimmt wieder aus.
Das man das auch alles selber für jede I/O Instanz reinprogrammieren kann ist schon klar,
das sehe ich aber eher als einen Task von IPS im Hintergrund.
Bis letzte Woche war mir noch nicht einmal klar, das die Wartezeit exponentiell ansteigt. Wie soll jemand das dann abfangen?

Für eine Änderung dieses Verhaltens von mit eine klare +1 !
VG Doc

#20

da verwendest du es aber auch falsch. Es geht um das wiederherstellen einer Verbindung die da sein sollte, nicht um den „Serverseitigen“ Aufbau, wenn ein Client gerade wieder „On“ ist. Da hilft wahrscheinlich auch die Veränderung nichts und ist definitiv der falsche Ansatz.