wie verhält sich das nun in V2 mit den Clientsockets?
Wenn ich IPS_ApplyChanges einsetze, sehe ich unter Meldung, dass der Clientsocket sich trennt und danach wieder verbindet. Ich möchte aber, dass sich Clientsocket nur verbindet, wenn…
Sollte Clientsocket schon verbunden sein, dann muss er sich ja nicht erst trennen.
Wie realisiere ich das?
Oder wird zyklisch überprüft, ob eine Verbindung hergestellt werden kann und dann automatisch die Clientsocket-Einstellung bestätigt? D.h., wenn CS auf geöffnet eingestellt war, dann öffnet sich CS auch wieder, wenn der Server wieder (nach offline) erreichbar ist?
Gibt es diesen Automatismus -> Verständnisfrage!
Wenn der CS erkennt*, dass er Offline ist, verbindet er sich so lange neu, bis er es schafft. Die ApplySettings Funktionsweise ist so gewollt.
*Erkennen kann der CS einen „gestorbenen“ Socket aber nur, wenn etwas über ihn gesendet wird. Solltest du also einen Fall haben, wo du nur auf Daten wartest, müsstest du sehen, wie du ein paar „Ping“ Pakete verschicken könntest.
In allen gängigen Modulen von IP-Symcon (FHZ, xComfort, XBee, EnOcean) werden „Ping“ Pakete versendet, sodass der CS sich um alles kümmert. Nur FS10 fällt mir da gerade als Ausnahme ein.
vielen Dank für die Antwort!
Das ist schön, denn dann kann ich mir das Script sparen;)
Nach der kompletten Umstellung und dem intesiven Beschäftigen in den letzten drei Tagen mit V2, erkenne ich langsam die Vorteile der neuen Version:D
Alles Fluchen und Meckern schon fast vergessen…
Da sich meine RS232 --> USB Schnittstellen immer wieder einmal aufgehängt haben bin ich auf Empfehlung hier im Forum auf 4*RS232 --> TCPIP (EX-6034) umgestiegen. Alles funktioniert soweit, nur mit einer Schnittstelle habe ich Probleme mit dem FS10 Wetterempfänger der generell nur Daten empfängt. Der ClientSocket hängt sich auf nach einem IPS_ApplyChanges funktioniert es dann wieder.
Wie ist das „hier zwei Posts oben“ zu verstehen:
Wenn der CS erkennt*, dass er Offline ist, verbindet er sich so lange neu, bis er es schafft. Die ApplySettings Funktionsweise ist so gewollt.
*Erkennen kann der CS einen „gestorbenen“ Socket aber nur, wenn etwas über ihn gesendet wird. Solltest du also einen Fall haben, wo du nur auf Daten wartest, müsstest du sehen, wie du ein paar „Ping“ Pakete verschicken könntest.
In allen gängigen Modulen von IP-Symcon (FHZ, xComfort, XBee, EnOcean) werden „Ping“ Pakete versendet, sodass der CS sich um alles kümmert. Nur FS10 fällt mir da gerade als Ausnahme ein.
Nach welchem Algorithmus und mit welchen Befehlen könnte ich „Ping“ Pakete ausgeben um ein aufhängen des ClientSockets zu verhindern.