Virtueller Eingangsbefehl - springt kurz auf 0 bei erneutem Empfang von Werten

[saschx]

Ich habe folgendes Problem. Ich sende an den MS einen UDP Befehl von meinen Fensterkontakten den ich mit xxx\v erkenne. Der Wert kann nur 0 oder 1 sein. Geschlossenes Fenster bedeutet Wert 1. Jetzt kann es aber passieren (ist auch so gewollt) das der Befehl erneut mit 1 gesendet wird ohne das sich am Fensterkontakt etwas ändert. In der Protokollierung im MS sehe ich aber das der Wert des Virtuellen Eingangs kurzzeitig auf 0 geht und dann gleich wieder auf 1. Das Verhalten ist aber schlecht wenn der FeKo an der Alarmanlage hängt. Mir ist auch bewusst das ich vor die Alarmanlage noch eine Ausschaltverzögerung hängen kann (was ich auch momentan mache), ich wollte trotzdem mal fragen ob einer eine bessere Lösung dafür hat, also das der Wert gar nicht erst auf 0 springt!?

[Labmaster]

Nur mal ne blöde Frage,
wenn der Wert nur 0 und 1 sein kann , warum ist dann der Eingang statt Digital auf Analog gestellt mit einem Wertebereich von 0 bis 100 ?

[saschx]

Weil ich die Erfahrung machen musste das bei Konfiguration als Digitaleingang nur ein kurzer Impuls ausgegeben wird und der Eingang dann gleich wieder auf AUS steht.

[romildo]

Das macht er aber nicht von sich aus. Dann wird vermutlich auch eine 0 gesendet.
Kannst Du das Senden beeinflussen?

[saschx]

Ja den kann ich beeinflussen und der schreibt auch ein LOG. Auch im MS UDP Monitor sehe ich keine Nachricht mit einer 0.

[romildo]

welche Protokollierung meinst Du genau?
Sofern der Port und das xxx nur einmal vorhanden ist, kann ich das bei mir nicht nachvollziehen.

[saschx]

Mein Programm welches die UDP Strings sendet schreibt auch ein LOG mit. Mein Programm hat bei Start den Status aller 53 GPIO-Ports von meinem Loxberry als einzelne UDP Message übertragen. Hierbei ist es jetzt passiert das der MS jeden UDP Eingang einmal auf 0 und gleich wieder auf 1 gesetzt hat. Wenn ich in einem Testprogramm nur einen Port übertrage habe ich auch das Verhalten wie du, nämlich das sich an dem UDP Eingang im MS nichts verändert (so wie es ja sein soll).
Jetzt habe ich das ganze mal umgebaut und sende meine Ports in mehreren Gruppen, das sieht dann folgendermaßen im Logfile aus:

07.06.2018 14:18:58: Sende Nachricht:intIOPort12@0;intIOPort13@0;intIOPort14@ 0;intIOPort15@0;intIOPort16@0;intIOPort17@0;intIOP ort18@0;intIOPort19@0;intIOPort20@0;intIOPort21@0; intIOPort22@0;intIOPort23@0;
07.06.2018 14:18:58: Sende Nachricht:IOPort1@0;IOPort2@0;IOPort3@0;IOPort4@0; IOPort5@0;IOPort6@0;IOPort7@0;IOPort8@0;IOPort9@0;
07.06.2018 14:18:58: Sende Nachricht:IOPort10@0;IOPort11@0;IOPort12@1;IOPort1 3@1;IOPort14@1;IOPort15@1;IOPort16@1;IOPorttest@1;
07.06.2018 14:18:58: Sende Nachricht:IOPort17@0;IOPort18@0;IOPort19@0;IOPort2 0@0;IOPort21@0;IOPort22@0;IOPort23@0;IOPort24@0;IO Port25@0;
07.06.2018 14:18:58: Sende Nachricht:IOPort26@0;IOPort27@0;IOPort28@0;IOPort2 9@1;IOPort30@1;IOPort31@1;IOPort32@1;

und so kommt es auch im MS UDP Monitor an. Verbesserung an der Stelle ist jetzt das er nicht mehr alle UDP Eingänge kurz von 1 auf 0 switched, allerding bleibt das alte Verhalten bei einem Port (IOPort16) bestehen und ich kann mir einfach nicht erklären wieso.

Erwartet denn der MS nach jeder UDP Message ein bestimmtes Abschlusszeichen?

[saschx]

Nach ewigem Suchen ist mir mein Fehler jetzt doch plötzlich ins Auge gestochen. Bei mir gab es die 2 Bezeichnungen IOPortXX und intIOPortXX. Wenn ich für die Befehlserkennung IOPortXX\v benutze reagiert er natürlich auch auf eine Nachricht mit dem Inhalt intIOPortXX und setzt dessen Statuswert. Danach kam dann gleich die Richtige Nachricht mit IOPortXX und hat den Eingang dann wieder richtig auf 1 gesetzt. Habe mein Programm jetzt geändert und es gibt nun intIOPortXX und extIOPortXX, damit klappts.
Ich danke trotzdem allen die sich mit mir Gedanken gemacht haben ;-)

[romildo]

Ich denke, ich habe das noch nicht ganz verstanden.
In der ersten "Gruppe" sendest Du ein Port16@0 und in der Dritten ein Port16@1
Dann muss doch der Eingang auch zuerst mal auf 0 und danach auf 1 wechseln.

[saschx]

ja in der ersten Gruppe war es ein intIOPort16@0. Habe den Fehler jetzt auch bemerkt, s.o.

[romildo]

Ja, das deckt sich dann auch mit meiner Vermutung

War wohl wieder etwas zu spät

[saschx]

Danke dir trotzdem

[Christian Fenzl]

Die UDP-Messages dürfen zudem nicht länger als ~255 Zeichen sein. Deswegen ist Splitten eine gute Idee.