CUxD/CUL: Problem beim Senden von Befehlen an FS20 Aktoren

[Stefan59]

Moin Zusammen,

seit ca.2 Monaten betreibe ich eine Raspberrymatic auf einem Raspberry 4B mit HM- & HMiP-Geräten
und zusätzlich noch einige meiner FS20-Geräte (Sender & Aktoren) über CUxD und CUL USB-Stick von Busware mit aktueller Firmware.
SW für Raspberrymatic und CUxD sind auf dem Stand von heute (22.Juni 2020)

Die FS20-Aktoren werden über Programme zusammen mit HM-Aktoren geschaltet.
Die FS20-Sender schalten ebenfalls per Programm auch HM-Aktoren.
Das hat auch alles reibungslos funktioniert bis ich vor zwei Tagen unplanmäßige Schaltvorhänge bei einigen HM-Aktoren feststellte.
Bei der Suche nach der Ursache fand ich im CUxD-Terminal heraus, dass für gesendete Schaltbefehle an die FS20-Aktoren gleichzeitig ein Empfangssignal mit demselben Switchcode erscheint:
z.B Befehl zum Ausschalten eines FS20-Aktor über Programm oder direkt über die WebIU:

Sende-Befehl : 16:30:59 [ttyACM0] <-- FFxx52200
Empfangs-Befehl : 16:31:00 [ttyACM0] --> FFxx522001D

Dies interpretiert der Cul-Stick/CUxD als Empfang einen Sendebefehl eines FS-20-Senders und schaltet die in dem jeweiligen HM-Programm verknüpften (HM-) Aktoren.
Da ich zuvor schon häufiger die gesendeten und empfangenen Signale im CUxD-Terminal untersucht haben, kann ich mit Sicherheit sagen, dass dieses Verhalten bisher nicht auftrat.

Hat jemand eine Idee was dahinter stecken könnte?

VG Stefan

[dondaik]

der gesendete string ist für mich kein "ein" befehl .... und rückantworten gibt FS20 nicht... oder da wird das signal einer fs20-fb empfangen. ( oder bewegungsmelder usw ... )
die längd dr beiten strings ist auch nicht gleich.

[Stefan59]

Hallo,
dass FS20 Aktoren keine Rückantwort geben ist zwar schade aber ebenso bekannt.
Umso sonderbarer ist das geschilderte Verhalten, wenn ein Aktor per Programm oder WebUI einen Schaltbefehl bekommt. Der Aktor schaltet und der CUL empfängt quasi wie ein Echo das selbe Signal zurück.
Es wird kein FS20-Sender betätigt und ein Bewegungsmelder kommt auch nicht in Frage.
Dies passiert, wie gesagt, seit 2 Tagen. Davor war alles ganz normal

[dondaik]

dann mal suchen warum der erste befehl nicht vollständig ist ....

[Stefan59]

Verstehe nicht, was an dem ersten Befehl nicht vollständig ist (die sahen/sehen immer so aus).
Und was das mit dem zweiten Befehl zu tun haben kann.

[dondaik]

dann vergleich doch einfach mal die längen ... und beim "einschalten" kenne ich bei FS20 keinen befehl der eine "0" am ende hat.
zum test was passiert sende dann mal den befehl direkt vom terminal ab ... ob dann auch ein echo komme ?

[Stefan59]

Also die zwei zusätzlichen Stellen sind bei Befehlen, die der CUL-Stick empfängt immer vorhanden, es sind immer 11 Stellen. Die Sendebefehle haben bei mir immer nur 9 Stellen.
Und ja, die Einschaltbefehle haben am Ende natürlich '11', die Ausschaltbefehle '00'.

Über WebUI gesendet mit einem anderen FS20-Aktor (Einschalten/Ausschalten)
09:56:55 [ttyACM0] <-- FFxx52111
09:56:58 [ttyACM0] <-- FFxx52100
09:56:58 [ttyACM0] --> FFxx521001C
Das fragliche Empfangssignal kommt mit dem Ausschaltbefehl.
Über Terminal gesendet
09:58:48 [ttyACM0] <-T FFxx52111
09:58:49 [ttyACM0] --> FFxx521111F
09:59:00 [ttyACM0] <-T FFxx52100
Hier kommt das Empfangssignal mit dem Einschaltbefehl.

[uwe111]

Hallo Stefan,

Deine Befehle sind richtig. Empfangsbefehle sind immer um 2 Zeichen (1 Byte) länger als Sendebefehle, weil im letzten Byte die Empfangsfeldstärke übergeben wird. Aber das war schon immer so.

Warum Dein CUL plötzlich alle gesendeten Befehle erneut empfängt, weiß ich auch nicht.
Nutzt Du einen FS20 Repeater?

Was passiert, wenn Du einen Befehl im CUxD-Terminal an eine neue, unbekannte Adresse sendest? Also z.B. F12345611
Wird der Befehl dann auch empfangen?

Viele Grüße

Uwe

[Stefan59]

Hallo Uwe,

vielen Dank für Deine Erläuterungen zur Bedeutung des zusätzlichen Bytes und den Hinweis mit dem Repeater.
Ja, ich nutze (noch) einen FS20 Repeater, der aber demnächst stillgelegt wird, da der schlecht erreichbare FS20 Aktor durch einen HM-Aktor ausgetauscht wird (bin nur noch nicht dazu gekommen).
Offen gesagt, hatte ich den Repeater für einen Moment auch in Verdacht, diesen aber wieder verworfen, da der Repeater schon seit Inbetriebnahme des CUL's vorhanden war, und ich bisher nie die beschriebenen Effekte gesehen habe.
Ich werde ihn heute Abend mal 'vom Sender nehmen' und schauen was passiert (oder nicht passiert).

Wenn ich Befehle direkt im CUxD-Terminal eingebe, tritt der Effekt auch auf. In meinem letzten Post (10:12 Uhr) sind das die Befehle mit dem 'T'
(<-T FFxx52111).

VG
Stefan

[Stefan59]

Hallo Uwe,

Dein Tipp mit dem Repeater hat weiter geholfen.
Ohne Repeater kamen gestern keine ungewollten Empfangssignal mehr am CUL-Stick an.
Allerdings hat der kritische FS20-Aktor auch nicht mehr geschaltet.
Ich habe jetzt den Repeater an einer anderen Stelle platziert und der Spuk ist offenbar vorbei.
Der Aktor schaltet auch wieder, was bedeutet, dass der Repeater am neuen Platz noch den Funk vom CUL-Stick empfängt aber das vom Repeater weitergeleitete Signal nicht mehr bis zurück zum CUL reicht.
Funk ist schon eine Welt für sich....
Danke also für Deine Hilfe!

VG
Stefan