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

Anbindung von FS20-Komponenten, ELV-Wetterstationen, EnOcean und DMX an HomeMatic

Moderator: Co-Administratoren

Antworten
Stefan59
Beiträge: 9
Registriert: 30.04.2020, 17:59
System: Alternative CCU (RaspberryMatic etc.)

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

Beitrag von Stefan59 » 22.06.2020, 17:17

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
Beiträge: 11564
Registriert: 16.01.2009, 18:48
Wohnort: Steingaden
Hat sich bedankt: 554 Mal
Danksagung erhalten: 96 Mal

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

Beitrag von dondaik » 22.06.2020, 17:49

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.
-------
!!! der download der handbüchern auf den seiten von eq3 und das lesen der tips und tricks kann das hm-leben sehr erleichtern - das nutzen der suche nach schlagworten ebenso :mrgreen: !!!
wer schreibfehler findet darf sie behalten.

Stefan59
Beiträge: 9
Registriert: 30.04.2020, 17:59
System: Alternative CCU (RaspberryMatic etc.)

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

Beitrag von Stefan59 » 22.06.2020, 21:49

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
Beiträge: 11564
Registriert: 16.01.2009, 18:48
Wohnort: Steingaden
Hat sich bedankt: 554 Mal
Danksagung erhalten: 96 Mal

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

Beitrag von dondaik » 22.06.2020, 22:39

dann mal suchen warum der erste befehl nicht vollständig ist ....
-------
!!! der download der handbüchern auf den seiten von eq3 und das lesen der tips und tricks kann das hm-leben sehr erleichtern - das nutzen der suche nach schlagworten ebenso :mrgreen: !!!
wer schreibfehler findet darf sie behalten.

Stefan59
Beiträge: 9
Registriert: 30.04.2020, 17:59
System: Alternative CCU (RaspberryMatic etc.)

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

Beitrag von Stefan59 » 23.06.2020, 08:59

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
Beiträge: 11564
Registriert: 16.01.2009, 18:48
Wohnort: Steingaden
Hat sich bedankt: 554 Mal
Danksagung erhalten: 96 Mal

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

Beitrag von dondaik » 23.06.2020, 09:24

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 ?
-------
!!! der download der handbüchern auf den seiten von eq3 und das lesen der tips und tricks kann das hm-leben sehr erleichtern - das nutzen der suche nach schlagworten ebenso :mrgreen: !!!
wer schreibfehler findet darf sie behalten.

Stefan59
Beiträge: 9
Registriert: 30.04.2020, 17:59
System: Alternative CCU (RaspberryMatic etc.)

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

Beitrag von Stefan59 » 23.06.2020, 10:12

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.

Benutzeravatar
uwe111
Beiträge: 4133
Registriert: 26.02.2011, 22:22
Danksagung erhalten: 39 Mal
Kontaktdaten:

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

Beitrag von uwe111 » 23.06.2020, 11:47

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
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 2.4.4, RFD-Monitor, Vellemann K8055, SSH KeyDir

Stefan59
Beiträge: 9
Registriert: 30.04.2020, 17:59
System: Alternative CCU (RaspberryMatic etc.)

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

Beitrag von Stefan59 » 23.06.2020, 13:08

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
Beiträge: 9
Registriert: 30.04.2020, 17:59
System: Alternative CCU (RaspberryMatic etc.)

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

Beitrag von Stefan59 » 24.06.2020, 11:20

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

Antworten

Zurück zu „CUxD“