Cul-Stick empfängt, sendet jedoch nicht

[Jogi]

Hallo zusammen,
ich werde noch verrückt.
Ich habe mir einen Cul-Stick V3 zugelegt um damit FS20-Steckdosen zu steuern.
Ich habe den Stick nach Anleitungen im Netz installiert und in FHEM eingebunden.
Wahrscheinlich habe ich aber irgendwas falsch gemacht, oder übersehen.
Ich habe den rfmode SLowRF eingestellt (für FS20)
Bei der Definition habe ich unterschieldihce Dinge ausprobiert:
/dev/CUL 1234
/dev/CUL@9600 0000
/dev/ttyACM0@9600 1034 (das ist das, was aktuell drinsteht)

Der Stick empfängt zwar Signale, die ich mit meiner FS20-Fernbedienung sende, aber er sendet keine Signale. Zumindest kommt bei den Steckdosen nichts an.
Wenn ich den Befehl get CUL1 raw V eingebe dann bekomme ich CUL1 raw => V 1.66 CUL868 als Antwort.


Hat jemand einen Tipp, was ich machen kann.
Wenn es eine komplette Anleitung zum flashen und Installieren in FHEM und FS20 gibt, bin ich auch dankbar, da ich nur Anleitungen für Homatic gefunden habe.

[Jogi]

Sorry, es hat sich scheinbar erledigt.
Nachdem ich den Raspi vom Strom getrennt und neu verbunden habe geht es.
Ich hoffe, es bleibt so!

[Zrrronggg!]

Trotzdem paar Anmerkungen:

Ich habe den rfmode SLowRF eingestellt (für FS20)

Braucht's streng genommen nicht, da rfmode SLowRF default ist.

Denkbar wäre das verhalten, wenn du zusätzlich andere Funkschnittstellen hast, diese auch über USB angebunden sind UND du bei deinen FS20 Aktoren keine IOdev festgelegt hast.  Und wenn das so wäre könnte das auch wieder passieren.

Bevor ich erläutere warum also erstmal die Frage: HAST du weitere Funkschnittstellen?

[Jogi]

Ja, ich hab zusätzlich noch einen JeeLink an meinem Raspi.

[Zrrronggg!]

Also meine vage Idee geht in diese Richtung:

FHEM nimmt ohne definiertes IOdef immer die LETZTE definierte Schnittstelle die grundsätzlich geeignet ist, das für den Aktor nötige Command abzusetzen. Ich weiss offen gestanden nicht genau, wie eng "grundsätzlich geeignet" definiert ist.  Ich denke, dass  JeeLink nicht als geeignet für SlowRF herhält.

Problem ist aber folgendes:  Wenn man USB Devices nur "allgemein" definiert, also nicht z.b. über eine Seriennummer oder sowas, dann ist nicht sicher, welches USB Device nach dem Booten vom Rechner an welche Schnittstelle erkannt wird, da die USB Schnittstellen alle gleichberechtigt sind, hier kommts aufs Timing an. Es kann also sein, dass du das CUL zwar korrekt definiert hast, mit der Schnittstelle aber das JeeLink verbunden ist. Dann klappt senden natürlich nicht.

Der Empfang kann je nach Definition perfiderweise aber trotzdem gehen.

Ich gebe zu, ich habe das nicht komplett zu Ende durchdacht, auch weil ich das JeeLink nicht kenn und nicht weiss was du damit machst.

Aber eine Überlegung ob es was in die Richtung sein könnte wäre es ggf Wert.

Versuch z.b. mal das JeeLink auszukommentieren, und auch abzustecken und mach dann PowerCycle des FHEM Hosts und sieh ob's dann geht. (nur als Test)

Siehe auch hier:  https://wiki.fhem.de/wiki/Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden

[Jogi]

Also meine vage Idee geht in diese Richtung:

FHEM nimmt ohne definiertes IOdef immer die LETZTE definierte Schnittstelle die grundsätzlich geeignet ist, das für den Aktor nötige Command abzusetzen. Ich weiss offen gestanden nicht genau, wie eng "grundsätzlich geeignet" definiert ist.  Ich denke, dass  JeeLink nicht als geeignet für SlowRF herhält.

Problem ist aber folgendes:  Wenn man USB Devices nur "allgemein" definiert, also nicht z.b. über eine Seriennummer oder sowas, dann ist nicht sicher, welches USB Device nach dem Booten vom Rechner an welche Schnittstelle erkannt wird, da die USB Schnittstellen alle gleichberechtigt sind, hier kommts aufs Timing an. Es kann also sein, dass du das CUL zwar korrekt definiert hast, mit der Schnittstelle aber das JeeLink verbunden ist. Dann klappt senden natürlich nicht.

Der Empfang kann je nach Definition perfiderweise aber trotzdem gehen.

Ich gebe zu, ich habe das nicht komplett zu Ende durchdacht, auch weil ich das JeeLink nicht kenn und nicht weiss was du damit machst.

Aber eine Überlegung ob es was in die Richtung sein könnte wäre es ggf Wert.

Versuch z.b. mal das JeeLink auszukommentieren, und auch abzustecken und mach dann PowerCycle des FHEM Hosts und sieh ob's dann geht. (nur als Test)

Siehe auch hier:  https://wiki.fhem.de/wiki/Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden

Kann ich die Seriennummer auch nachträglich einpflegen? Wenn "ja", wie geht das?

[bartman121]

....
Siehe auch hier:  https://wiki.fhem.de/wiki/Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden

So

[Jogi]

So

Sorry, da waren die Finger schneller als das Hirn