VQ tcp-Call geht nur jedes zweite Mal

[tholle]

Moin,

ich habe ein extrem komisches Verhalten mit einem VQ der einen TCP-Call zu einem xinetd-Service machen soll.
Der TCP-Call geht komischereweise nur bei jedem zweiten Ausloesen und ich habe keine Ahnung, woran das liegen kann.

Anhand des flankengetrickerten Wischrelais sehe ich, dass TQ des Statusbausteins jedes Mal aktiv ist. Man kann die Ursache also auf jeden Fall auf den VQ eingrenzen (siehe Screenshots).
Auf Empfaengerseite laeuft ein Loggig mit, welches bestaetigt, dass nur jeder zweite Call auch tatsaechlich abgesetzt wird.

Hat jemand eine Idee, warum dieses Verhalten auftritt oder wie man die Ursache noch weiter eingrenzen kann?

Vielen Dank und Gruss,
tholle

[Christian Fenzl]

Ich würde es erstmal mit einem Analogwahlschalter probieren (dass du Analog sendest, ist gewollt?)
Du spuckst auch wirklich „0“ im Statusbaustein aus?

[tholle]

Jupp, analog ist gewuenscht, weil ich Strings an mein Skript uebergebe.
Analogwahlschalter probiere ich und gebe Rueckmeldung.

thx und Gruss,
tholle

[tholle]

Analogwahlschalter geht nicht, weil der scheinbar keine Strings kann. Analogspeicher leider auch nicht.

Nach mehreren Tests kann ich nun sagen, dass ca. 3 von 5 Calls efolgreich abgesetzt werden. Der Loggerbaustein, der ja auch mit TQ haengt, schlaegt bei 5 von 5 mal an.
Das heisst, es ist definitiv der VQ. LAN-Verbindung, evtl.? Falls ja, wie kann ich das vom Miniserver aus eingrenzen? Ich habe ein paar PINGS vom Miniserver aus zu mehreren Netzwerkgeraeten laufen. Die vielleicht mal deaktivieren? Ausserdem kommen ueber LAN noch XAP-Pakete vom LMS.

Gruss,
tholle

[tholle]

Wenn ich die Verbindung von einem anderen Rechner aus via Netcat (nc) nachstelle, klappt der Call in 10 von 10 Faellen. Es liegt also definitiv am Minisverver oder an der Verbindung zwischen Miniserver. hmmm.....

[Christian Fenzl]

Evt. noch probieren mit „Verbindung beim Beenden trennen“ und Backslash n am Ende.
Ein zeilenorientierter Empfänger bekommt sonst nicht mit, dass das „schon alles“ war.

[tholle]

Verbindung nach Senden schliessen, ist/war aktiviert. Leider hat weder \n noch \r etwas gebracht. Verbindung geht weiterhin immer 2-3 Mal, dann einmal nicht, dann wieder 2-3 mal.

[romildo]

Ich würde mal das Flankengetriggerte Wischrelais am Status abhängen und den Minimalen Zeitabstand beim Ausgang auf >0, also z.B. auf 1 setzen.

[tholle]

Wenn du Abstand Wiederholungen [s] meinst, das habe ich gerade probiert. Leider auch keine Besserung. Den Wischrelais hatte ich auch schon deaktiviert. Auch keine Besserung.

[romildo]

Nein, ich meinte die beim Logging, hat vermutlich damit nichts zu tun, aber man weiss ja nie
Was meinst Du mit Wischrelais deaktiviert, er muss schon abgehängt werden.

[tholle]

Ja, natürlich abgehängt vom Stausbaustein.

[romildo]

Ich habe das bei mir mal getestet.
Wie so oft funktioniert der Statusbaustein sehr ungewohnt.
Mach mal in der letzten Statuszeile im Statustext ein Leerzeichen hinein, dann sollte es funktionieren.

Nachtrag: Allerdings ohne Flankengetriggertes Wischrelais

[tholle]

Unglaublich! Tatsaechlich geht's jetzt! 15/15 aufeinanderfolgenden Versuchen erfolgreich.
Vielen Dank! Du hast mal wieder sehr geholfen.

Ist das Problem mit dem Statusbaustein denn allgemein bekannt? Ich habe ziemlich viel davon im Einsatz und hin und wieder verhalten sich tatsaechlich einige "eigenartig". Ich werde diesen Workaround bei den auffaelligen Kandidaten auch einsetzen.

[romildo]

Antwort auf #7.1
Ich bin da nicht sicher aber ich vermute, dass da ständig irgendwas seitens Loxone geändert wird.

Beispiel bei meinen Tests:
Bedingung AI1 == 1, Statustext: Buero Kueche
Bei Bedingung erfüllt im Statusbaustein und Wert an TQ erfolgte nur eine TCP-Ausgabe. Danach gab es immer nur eine, wenn die Bedingung nicht mehr erfüllt war.
Also:
AI1 Ein -> TCP-Textausgabe: Buero Kueche
AI1 Aus -> keine Ausgabe
AI1 Ein -> keine Ausgabe
AI1 Aus -> TCP-Textausgabe: Buero Kueche
AI1 Ein -> keine Ausgabe
AI1 Aus -> TCP-Textausgabe: Buero Kueche
AI1 Ein -> keine Ausgabe
AI1 Aus -> TCP-Textausgabe: Buero Kueche

Es ist auch so, dass der TCP-Ausgang den Text bis zur nächsten Änderung beibehält.
Wenn bei der Bedingung im Statusbaustein der Statustext leer ist, dann scheint dies keine Änderung für den TCP-Ausgang zu sein.
Das kann folgendermassen bewiesen werden.
Man nimmt einen Statusbaustein mit folgendem Inhalt:
Zeile 1: Bedingung AI1 == 1, Statustext: Hallo
Zeile 2: leer
Virtueller Eingang 1 an AI1
TCP-Ausgang an TQ
Zusätzlich Virtueller Eingang 2 an TCP-Ausgang
Wenn nun der Eingang 1 auf 1 wechselt wird an TQ der Text Hallo angezeigt und auch über den TCP-Ausgang ausgegeben.
Wenn der Eingang 1 auf 0 wechselt geschieht nichts, an TQ liegt jetzt auch nichts mehr an.
Wird in diesem Status der Eingang 2 zwischen aus und ein hin und her gewechselt wird sowohl bei ein wie auch bei aus über den TCP-Ausgang der Text Hallo ausgegeben.

[tholle]

Klasse Analyse! Wirklich top!
Der Statusbaustein ist dann aber sehr schlampig programmiert.
Denn, wenn keine Bedingung erfuellt ist, soll/muss AQ und TQ in jedem Fall 0 sein, sonst macht die letzte Zeile, die ja immer da ist und nicht geloescht werden kann, keinen Sinn.

Gruss,
tholle

Edit:// Ich habe gerade einmal versucht, das zu testen, so wie du es beschrieben hast. Allerdings kann ich nicht sehen, was in VQ gerade steht. Wie siehst du das denn?

thx und Gruss,
tholle

[tholle]

Top! Vielen Dank! Damit laesst sich zukuenftig besser debuggen.

[romildo]

Bitte gerne.
Wenn Du zwischen dem Virtuellen Eingang 2 und dem TCP-Ausgang auch noch einen Analogspeicher, mit offenem AI, hängst, dann kann so, über einen Trigger an Tr der Text aus dem Statusbaustein gesendet werden.
Auch hier die Besonderheit, dass bei einem leeren Statustextfeld der letzte Text gesendet wird, also sozusagen dieser, welcher gespeichert wurde

[tholle]

Das hatte ich gestern in meiner Verzweiflung sogar so gebaut. Hatte aber auch keine Besserung gebracht. Aber da war das Wissen um des leeren Statustextfeldes auch noch nicht vorhanden.