Multiple TCP Requests

[Jambala]

Hallo Zusammen,

bei mir kommt immer mehr Bedarf an TCP Requests auf:

Wetter aktuell
Wetter Forecast
Rheinpegel
Verkehrsinformationen
Status Wärmepumpe
Status Dolby-Surround Verstärker
(Fritzbox)

Bisher senden die Makros einfach irgendwann ihren Request los und überprüfen lediglich bei dem Response ob dieser von der richtigen IP Adresse und IP Port kommt.

Das funktioniert bisher ganz gut.

Da das Risiko von Kollisionen aber steigt, frage ich mich nun, ob es nicht sinnvoller ist in jedem einzelnen TCP Request Makro ein Busy Flag zu setzen.

Die anderen Makros dürften dann erst nach einer vorher definierten unterschiedlichen Verzögerung nach Busy = AUS aktiv werden.

Ist dies der sinnvollste Weg Kollisionen zu vermeiden?

Hat jemand schon einmal Versuche in diese Richtung unternommen?

Viele Grüße

Michael

[enertegus]

Das funktioniert bisher ganz gut.
Da das Risiko von Kollisionen aber steigt, frage ich mich nun, ob es nicht sinnvoller ist in jedem einzelnen TCP Request Makro ein Busy Flag zu setzen.

Was genau soll denn kollidieren? So wie das gemacht ist, passt das und vermeidet dies per se.

[Jambala]

Ich habe aber bereits im Wunderground Buffer einen Datensatz meiner Wärmepumpe und umgekehrt gesehen.

So ganz 100% scheint mir das in der Praxis nicht automatisch zu laufen.

Wie ist denn sichergestellt, dass der zeitgleiche Response von zwei externen Servern nicht im TCP Buffer zusammenläuft?

[enertegus]

Ich habe aber bereits im Wunderground Buffer einen Datensatz meiner Wärmepumpe und umgekehrt gesehen.

Wenn ein Paket eintrifft, wird jedes readtcp-Objekt befüllt, also hier

if event(readtcp(IP, Port, Buffer1) ) and IP==Wetter ... { Wetter }
if event(readtcp(IP, Port, Buffer2) ) and IP==WP ... { Wärmpepumpe}

wird immer Buffer1 = Buffer2 sein. In der Auswertung muss man nun die Buffer in die entsprechende Schlange schreiben. So sind die Makros gecodet.

Explizit würde nicht schreiben:

if event(readtcp(IP, Port, Buffer) ) then {
if IP==Wetter ... { Wetter }
if IP==WP ... { Wärmpepumpe}
} endif

einfach nur wegen der Übersicht, wobei der zweite Code weniger CPU in Anspruch nimmt.

[Jambala]

Dann muß ich einmal detaillierter suchen warum die Daten sich manchmal vermischen.

Bisher habe ich die Logik wie von Dir beschrieben aufgebaut:

if event(readtcp(Wunderground_Port_Connected, Wunderground_IP_Connected, Wunderground_Conditions_xmlRawData)) \\
and Wunderground_TCP_ConnectionState == 0u08 \\
and Wunderground_Port_Connected == Wunderground_Port \\
and Wunderground_IP_Connected == Wunderground_IP then ...

Diese Logik hilft aber auch nicht weiter, wenn an einen Server zwei unterschiedliche Requests gestellt werden, wie z.B. Wunderground Actual und Forecast Request.

[enertegus]

Diese Logik hilft aber auch nicht weiter, wenn an einen Server zwei unterschiedliche Requests gestellt werden, wie z.B. Wunderground Actual und Forecast Request.

Das versteh ich nicht so recht. Wenn Du zwei Anfragen stellst, dann sind es doch auch zwei Antworten, oder geht das durcheinander?

[Jambala]

Wenn ich bei Wunderground Actuals und Forecast mit zwei verschiedenen Makros abgefragt habe (beide mit der Startbedingung cycle(1,0)), dann hat das bei mir Chaos in den Datensätzen ergehen.

Daraufhin habe ich beide Makros zu einem verheiratet und die beiden Abfrageprozesse mit einem Busy_Parameter voneinander abgegrenzt.

Dies läuft mehrere Tage problemlos durch, bis dann auf einmal keine Daten mehr kommen.