- √ - sendudp() und c-move

[chg]

Hallo Leute,

nachdem ich nun mit dem WakeOnLan-Macro meine Rechner hochfahren kann, möchte ich auch die Rechner herunterfahren bzw. in den Ruhezustand versetzen können. Dafür ist mir gleich das geniale Tool "c-move" von Alfred Scherff eingefallen. Es wurde ja in erster Linie für den HS erstellt. Soweit ich es verstehe müsste es aber auch mit jedem anderen Gerät funktionieren, welches UDP-Telegramme senden kann. Also eigentlich auch der EibPC!

Leider habe ich es partout mit sendudp() nicht zum laufen bekommen. Ich glaube, dass sendudp() am Ende eines zu sendenden Strings immer noch ein Suffix (Punkt o.ä.) übermittelt.

Mit c-move und HS-IP konnte ich folgendes testen:
Wenn man mit HS-IP den Befehl "DEBUG" an c-move sendet funktioniert der Aufruf des Debug-Fenster (Konfig von HS-IP siehe Screenshot 1).
Wenn man versucht mit dem EibPC und sendudp() den gleichen Befehl zu senden, reagiert c-move nicht darauf.
Im Debug-Fenster von c-move kann man die Unterschiede der gesendeten Telegramme sehen. In Screenshot 2 das Telgramm von HS-IP, welches funktioniert und in Screenshot 3 das vom EibPC/sendudp() welches mit c-move nicht funktioniert (Nach dem Wert 47 folgt eine 0!).
Kann man irgendwie unterbinden, dass sendudp() am Ende noch dieses suffix anhängt!? Oder liegt das Problem wo anders?

Ich denke, die gleichen UDP/TCP-Telegramme wie der HS sie sendet auch mit dem EibPC senden zu können, öffnet uns die Tür zu vielen nützlichen und genialen HS-Tools!

Infos zu c-move:
https://knx-user-forum.de/special/c-...Visu%20Helfer/
Link zu c-move
https://knx-user-forum.de/downloads.php?do=file&id=2

Link zu HS-IP:
https://knx-user-forum.de/downloads.php?do=file&id=1

[enertegus]

Leider habe ich es partout mit sendudp() nicht zum laufen bekommen. Ich glaube, dass sendudp() am Ende eines zu sendenden Strings immer noch ein Suffix (Punkt o.ä.) übermittelt.

UDPSEND (aus Anleitung)
Wenn arg2 bis argN vom Datentyp c1400 sind, werden die terminierenden Nullzeichen der Strings mit übermittelt.

Bisher war das kein Problem - ob Command Fusion, Homecontrol, Googleabfrage etc. da spielt das keine Rolle.

Mit c-move und HS-IP konnte ich folgendes testen:
Wenn man mit HS-IP den Befehl "DEBUG" an c-move sendet funktioniert der Aufruf des Debug-Fenster (Konfig von HS-IP siehe Screenshot 1).
Wenn man versucht mit dem EibPC und sendudp() den gleichen Befehl zu senden, reagiert c-move nicht darauf.

Lt. Deinem Auszug sendet der HS Spaces (0x20) als terminierendes Endzeichen. Das Endzeichen ist oft unterschiedlich bei den verschiedenen Protokolldefinitionen. Hänge doch dieses Spaceszeichen einfach mal an deinen String an, etwa in der Form
Debug=$DEBUG $
Dann sollte das 0x20 vor dem 0x0 kommen und die Sache funktionieren. Wenn nicht melde Dich nochmal. Grundsätzlich könnte man hier auch problemlos am Verhalten von sendudp (und sendtcp) etwas ändern, aber ich denke man kriegt es auch ohne hin.

[chg]

Hi Michael,

Hänge doch dieses Spaceszeichen einfach mal an deinen String an, etwa in der Form
Debug=$DEBUG $
Dann sollte das 0x20 vor dem 0x0 kommen und die Sache funktionieren. Wenn nicht melde Dich nochmal.

Hatte ich probiert es funktioniert aber leider nicht. Es stört offenbar das "terminierenden Nullzeichen" auch wenn es weiter hinten kommt.
Ich hatte auch versucht, das ganze nicht als String zu senden. Da ich damit nicht so firm bin hat dies dann aber totalen murks erzeugt... ;-)

[enertegus]

Hi Michael,
Hatte ich probiert es funktioniert aber leider nicht. Es stört offenbar das "terminierenden Nullzeichen" auch wenn es weiter hinten kommt.
Ich hatte auch versucht, das ganze nicht als String zu senden. Da ich damit nicht so firm bin hat dies dann aber totalen murks erzeugt... ;-)

Bist Du mit der Terminierung sicher? Ggf. mal den Alfred befragen, ob das tatsächlich stimmt.

Du könntest Dir inzwischen folgendermaßen helfen, in dem Du das Telegramm wie folgt schreibst (einfach die Binärdaten mit 0x voran abschreiben).
sendudp(Port,IP,0x44,0x45,0x42,0x55,0x47,0x20)

[chg]

Bist Du mit der Terminierung sicher?

Ziemlich! Hatte viel mit den Leerzeichen experimentiert. Der Einzige unterschied im Debug-Fesnter von c-move war, dass bei Telegrammen vom EibPC immer noch die "0x0" mit dabei war.

(einfach die Binärdaten mit 0x voran abschreiben).
sendudp(Port,IP,0x44,0x45,0x42,0x55,0x47,0x20)

So ähnlich hatte ich es probiert. Nur die letzte "0x20" hatte ich nicht gesetzt. Werds nacher daheim Testen. Danke!

[chg]

Jetzt versteh ich es überhaupt nicht mehr!?

Die Telegramme sehen nun im c-move Debug-Fenster genau gleich aus.... c-move zeigt die Telegramme vom EibPC also an... reagiert aber nicht auf diese!

Ich glaub ich muss mal bei Alfred anfragen...

[enertegus]

Jetzt versteh ich es überhaupt nicht mehr!?

Immerhin deckt sich das mit meiner Erfahrung, dass das Nullzeichen nicht stört.

Die Telegramme sehen nun im c-move Debug-Fenster genau gleich aus.... c-move zeigt die Telegramme vom EibPC also an... reagiert aber nicht auf diese!

Hast Du auch den richtigen Port eingestellt? Gibt es da vielleicht Probleme? Wie geht es denn weiter, beobachte doch mal das ganze Programm. Gibt es eine Doku zu c-move?

[chg]

Hast Du auch den richtigen Port eingestellt? Gibt es da vielleicht Probleme? Wie geht es denn weiter, beobachte doch mal das ganze Programm. Gibt es eine Doku zu c-move?

Port ist der gleiche, welchen ich mit dem HS-IP Tool verwende. Es kommt ja beim c-move auch was an sonst würde im Debug-Fenster nicht stehen.

Hab das Help-File vom c-move mal angehängt. Mehr Doku konnte ich nicht finden. Ebenso nochmal screenshots mit meinen Einstellungen.

Hab Alfred Scherff mal eine PN gesendet.

[AScherff]

Moin,

bin gerade auf der Ski-Piste - deshalb nur kurz ;-)

c-move reagiert auf UDP-Telegramme. Der Port muss in c-move eingestellt werden. Bekannte Telegramme werden ausgeführt. Jede Software die UDP Telegramme senden kann, ist somit in der Lage Aktionen auszuführen - also auch der eibPC.

Den Unterschied, den ich sehe, wenn UDP-Telegramme aus dem eibPC gesendet werden sind sie scheinbar mit Null (0) Terminiert; die erwarten aber keine Terminierung. In 'C' mag es üblich sein, Strings zu terminieren. Im Datenverkehr nicht zwingend, weshalb bei UDP-Telegrammen auch oft die Möglichkeit vorhanden ist, sie mit CR, LF oder CR/LF abzuschliessen.

Übrigens - ja die Telegramme werden von c-move empfangen aber falsch interpretiert, da es z.Bsp. ein Telegramm DEBUG[&h0] nicht kennt sondern das Telegramm DEBUG .

[enertegus]

Hab das Help-File vom c-move mal angehängt. Mehr Doku konnte ich nicht finden. Ebenso nochmal screenshots mit meinen Einstellungen.

Was mir schon mal auf die Schnelle auffällt: Das Trennzeichen ist parametrierbar. Also anstelle von 32 könntest Du einfach 0 angeben, dann wäre das schon mal erledigt.

[enertegus]

Port ist der gleiche

@Alfred: Muss bei c-move der Sender und Empfängerport immer der gleiche sein, oder bezieht sich die Angabe auf den Empfangsport.

[AScherff]

Was mir schon mal auf die Schnelle auffällt: Das Trennzeichen ist parametrierbar. Also anstelle von 32 könntest Du einfach 0 angeben, dann wäre das schon mal erledigt.

Das ist das "Trennzeichen" von HS-IP mit dem mehrere Telegramme hintereinander getrennt durch das "Trennzeichen" in einem String gesendet werden können.

So wie ich das sehe können c-move und eibPC nur zusammenarbeiten:

• das Terminierungszeichen im eibPC entfernt werden kann
• das senden der 0-Terminierung im eibPC parametriesierbar gemacht wird
• das in c-move 0-Terminierungen akzeptiert werden

letzteres kann ich gern ab nächster Woche liefern....

[AScherff]

Muss bei c-move der Sender und Empfängerport immer der gleiche sein, oder bezieht sich die Angabe auf den Empfangsport.

Sende- und Empfangsport müssen immer gleich sein, sonst wird ggf. auf einem Port gesendet auf dem der Empfänger nicht "horcht"...

In c-move wird der Empfangsport - also auf dem "gehorcht" wird eingestellt...

[enertegus]

das Terminierungszeichen im eibPC entfernt werden kann

Das hat chg ja probiert - und es geht, wenngleich dann die bytes einzeln geschickt werden müssen.

das senden der 0-Terminierung im eibPC parametriesierbar gemacht wird

ja, das wird zu überlegen.

das in c-move 0-Terminierungen akzeptiert werdenletzteres kann ich gern ab nächster Woche liefern....

das wär natürlich super!

[AScherff]

letzteres kann ich gern ab nächster Woche liefern....

ich korrigiere mich mal...

Habe das gerade eingebaut und als Version 3.9.41 auf den Update-Server geladen. Also einfach mal updaten und probieren...