HTTP TCP Funktion / Befehle mehrfach senden

Antworten
grizzly
Beiträge: 88
Registriert: Mo 6. Nov 2017, 11:31

Sa 8. Sep 2018, 13:10

Hallo,

eine Frage habe ich, für meine eRollo´s nutze ich die Netzwerk Funktion TCP mit der Datenpakete gesendet werden.
Soweit funktioniert das auch "ganz gut"... Jedoch ist es oftmals notwendig, dass die Befehle mehrfach gesendet werden müssen um zu funktionieren... Hier gehen ja oftmals Befehle auf diesem Weg verloren.

Es wäre bei der Neztwerkfunktion sinnvoll die Befehle mehrfach hintereinander senden zu können.
Wenn ich über eine Sczene den Befehl 5-6x den Befehl sende, funktioniert es auch einwandfrei - jedoch kann ich die Sczenen ja nicht weiter Gruppieren wie die Geräte.

Ist es möglich ein entsprechendes Feld in der Netzwerk Konfiguration einzufügen, welches man anhaken kann um die Befehle mehrfach zu senden oder gibt es einen anderen Trick?
paule26
Beiträge: 535
Registriert: Fr 18. Aug 2017, 18:37

Sa 8. Sep 2018, 16:02

Du solltest dir eher Gedanken über dein WLAN machen, als Befehle zigfach zu wiederholen.
Grüße Jürgen
Gruß Jürgen
Heiko
Beiträge: 711
Registriert: Sa 20. Feb 2016, 21:16
Wohnort: Dortmund

Sa 8. Sep 2018, 22:54

Hallo,

Also mit Netzwerk und w LAN habe ich null Probleme.
Das System funktioniert zuverlässiger als 433 oder 866 MHz und infrarot zusammen.

Da stimmt dann etwas mit deinem Netzwerk oder w LAN nicht.

BG Heiko
BG

Heiko
grizzly
Beiträge: 88
Registriert: Mo 6. Nov 2017, 11:31

Di 2. Okt 2018, 12:14

Hallo,

wie meinst du das genau? Ich sende befehlte per "TCP" im HEX-Format an die IP/Port eines qMotion / qConnect... wobei ich meist die Befehle mehrfach senden muss damit diese dann ankommen und die angeschlossenen Rollos reagieren.

Die Befehle kommen per LAN am Adapter (NetCom Mini) an und werden von dort über die RS232 Schnittstelle an denFunkwandler von qMotion (qConnect) geschickt. Die seriellen Einstellungen an dem NetCom wurden entsprechend der Vorgabe von qMotion vorgenommen. Wenn die Befehle über einen PC geschickt werden (qMotion qConnect direkt angeschlossen) werden die Befehle auf Anhieb erkannt.
Nach Rücksprache mit NetCom könnte es an einem Timeout am LM Air liegen.. Jedoch geht die weitere Ursachenforschung ohne konkreten Anhaltspunkt etwas ins Nirvana.. :)

Danke für eure Hilfe.
Benutzeravatar
jbmedia
Administrator
Beiträge: 4446
Registriert: Mi 17. Feb 2016, 13:42

Di 2. Okt 2018, 13:34

Der Timeout des Light-Managers ist auf 3 Sek. eingestellt. Man müsste mal testen, wie es sich verhält, wenn man das TCP Paket von einem Laptop sendet, welcher ebenfalls über WLAN verbunden ist. Es gibt bestimmt ein kleines kostenloses Tool, um solch ein Paket zu verschicken. Damit könnte man kontrollieren, ob der Verbindungsaufbau manchmal länger dauert. Normalerweise ist 3 Sek. für ein lokales Netzwerk schon recht lang.
Wir wünschen viel Spaß mit den Produkten und einen erfolgreichen Tag! Ihr jbmedia Team :)

grizzly
Beiträge: 88
Registriert: Mo 6. Nov 2017, 11:31

Di 2. Okt 2018, 21:09

jbmedia hat geschrieben:
Di 2. Okt 2018, 13:34
Der Timeout des Light-Managers ist auf 3 Sek. eingestellt. Man müsste mal testen, wie es sich verhält, wenn man das TCP Paket von einem Laptop sendet, welcher ebenfalls über WLAN verbunden ist. Es gibt bestimmt ein kleines kostenloses Tool, um solch ein Paket zu verschicken. Damit könnte man kontrollieren, ob der Verbindungsaufbau manchmal länger dauert. Normalerweise ist 3 Sek. für ein lokales Netzwerk schon recht lang.
Hallo!
ich habe dies heute mit dem Tool "Packet Sender" und über ein WLAN Notebook getestet. Dort funktionieren die Befehle umgehend bei dem ersten senden. Sobald diese dann über den JB Media gesendet werden, brauche ich z. T. wieder 4 Wiederholungen bis die Befehle "durchgehen".

Wie wäre hier Abhilfe zu schaffen?

Vielen Dank!
grizzly
Beiträge: 88
Registriert: Mo 6. Nov 2017, 11:31

Fr 30. Nov 2018, 12:07

jbmedia hat geschrieben:
Di 2. Okt 2018, 13:34
Der Timeout des Light-Managers ist auf 3 Sek. eingestellt. Man müsste mal testen, wie es sich verhält, wenn man das TCP Paket von einem Laptop sendet, welcher ebenfalls über WLAN verbunden ist. Es gibt bestimmt ein kleines kostenloses Tool, um solch ein Paket zu verschicken. Damit könnte man kontrollieren, ob der Verbindungsaufbau manchmal länger dauert. Normalerweise ist 3 Sek. für ein lokales Netzwerk schon recht lang.
Ich möchte dieses Problem gerne noch einmal in Erinnerung rufen, ich habe die letzten Wochen intensiv mit dem "Packet Sender" und einer WLAN Verbindung getestet. mit diesem Tool werden die Befehle sofort erkannt und umgesetzt, bei dem Senden über den LMAir kommen diese nur ganz sporadisch (vielleicht bei 2 von 4 Versuchen) durch! Kann es evtl. doch ein Timeout-Problem des LMAir sein??
Der LM Air scheint jedenfalls auf jeden Befehl Versand zu reagieren, da zumindest die LED dann kurz blinkt, jedoch kommen die Befehle nicht an dem Empfänger an... Wie erwähnt, ist das bei dem Tool Packet Sender kein Problem, dort werden die Befehle sofort bei dem ersten Versuch erkannt...

Selbstverständlich wurde der LMAir gemäß Anleitung an der fritz.box eingerichtet (Funkkanal und Sicherheitseinstellungen des WLAN). So langsam bin ich mit dem Latein an Ende und die Anzeichen verdichten sich, dass die Ursache bei dem LMAir zu finden ist.

Bitte um Prüfung, oder soll ich einen neuen Fall öffnen?
Benutzeravatar
jbmedia
Administrator
Beiträge: 4446
Registriert: Mi 17. Feb 2016, 13:42

Fr 30. Nov 2018, 15:06

Der Packet Sender kann auch als Empfänger fungieren. Er zeigt dann alle empfangenen TCP Pakete an, was eine sehr schöne Möglichkeit ist, die TCP Funktion des Light-Managers zu testen. Bei unseren Tests wurden die Pakete vom Light-Manager stets beim ersten Sendevorgang vom Packet Sender einwandfrei angezeigt.

Daher wäre es hilfreich zu wissen, ob dies bei den betroffenen Usern auch der Fall ist. Zum Testen kann man z.B: vorhandene TCP Befehle kopieren und lediglich die IP-Adresse auf die IP des PCs, auf dem Packet Sender läuft, abändern.
Wir wünschen viel Spaß mit den Produkten und einen erfolgreichen Tag! Ihr jbmedia Team :)

grizzly
Beiträge: 88
Registriert: Mo 6. Nov 2017, 11:31

Mo 3. Dez 2018, 08:14

jbmedia hat geschrieben:
Fr 30. Nov 2018, 15:06
Der Packet Sender kann auch als Empfänger fungieren. Er zeigt dann alle empfangenen TCP Pakete an, was eine sehr schöne Möglichkeit ist, die TCP Funktion des Light-Managers zu testen. Bei unseren Tests wurden die Pakete vom Light-Manager stets beim ersten Sendevorgang vom Packet Sender einwandfrei angezeigt.

Daher wäre es hilfreich zu wissen, ob dies bei den betroffenen Usern auch der Fall ist. Zum Testen kann man z.B: vorhandene TCP Befehle kopieren und lediglich die IP-Adresse auf die IP des PCs, auf dem Packet Sender läuft, abändern.
Vielen Dank für die schnelle Antwort. Ich habe es entsprechend getestet. Die empfangenen Pakete werden in diesem Fall auch von dem Packet-Sender alle richtig erfasst. Welchen Hintergrund kann es dann geben, dass die Daten von dem LM-Air nicht ordnungsgemäß an dem betroffenen Empfänger ankommen? Könnte es etwas mit dem "Timeout" zu tun haben? Über den Packet-Sender funktioniert es im WLAN ja einwandfrei :?:
Benutzeravatar
jbmedia
Administrator
Beiträge: 4446
Registriert: Mi 17. Feb 2016, 13:42

Do 6. Dez 2018, 17:36

Das ist schon mal eine wertvolle Information! Es zeigt, dass die Funktion grundsätzlich einwandfrei arbeitet, so dass der Fehler woanders liegen muss.

Wie lange dauert es denn, bis ein Rollladen beginnt, sich zu bewegen, wenn man ein Kommando mit dem Packet Sender absetzt? Startet die Bewegung quasi sofort oder dauert es einige Sekunden?
Wir wünschen viel Spaß mit den Produkten und einen erfolgreichen Tag! Ihr jbmedia Team :)

Antworten