Rademacher DuoFern USB Stick

[regenerat]

Hallo Telekatz,

danke für Deine Antwort.
Die hoch/runter bestätigung hatte ich erhalten, auch einen Reset des Sticks hatte ich bereits probiert.

Der entscheidende Tipp war das mit dem IODev.
Ich hatte den Rolladen nicht per define angelegt.
Da der Rolladen schon per Autocreate vorhanden war, dachte ich, ich muß ihn nur noch pairen, und später evtl. noch umbennen.
Das per Autocreate angelegte Objekt hatte aber keinen IODev.
Ich habe dann eben den Rolladen per define nochmal angelegt, er war dann halt zweimal da.
Er hat aber unter dem manuel angelegtem Objekt direkt funktioniert.
Das Autocreate Objekt habe ich dann gelöscht.

Habe ich grundsätzlich was falsch gemacht?
Wie hätte ich eine IODev in das Autocreated Objek bekommen?

Schönen Gruß
Ronald

[Telekatz]

Das IODev wird bei mir immer automatisch eingetragen. Auch per Autocreate. Ohne dass ich das irgendwie konfiguriert hätte.

[regenerat]

OK, das die IODev eigentlich auch bei einem autocreated Objekt automatisch angelegt wird
erklärt zumindest warum ich in so ein Problem gelaufen bin.
Das war halt noch kein Thema in diesem Thread.
Da muß bei mir irgendwas anders sein, zumindest bei meinem Rolladenmotoren.
Dank dem guten Hinweis bin ich aber trotzdem weiter gekommen.
Danke nochmal.

[tomspatz]

SO jetzt habe ich das Modul auch sauber am laufen.
VIELEN DANK dafür.

Im Event Monitor ist ja alles zu sehen, die einzelnen DUOFERN devices legen ja auch logs an.
Ist es möglich diese ins fhem Logfile zu packen?


LG
Tom

[jfhem]

Hallo zusammen und vielen Dank an Telekatz für das hervorragende Modul!

Gegenwärtig habe ich ca. 20 Rollladenaktoren (Duofern Troll Comfort), mehrere Universalaktoren, zwei 1-10Volt Dimmaktoren, sowie den Umweltsensor eingebunden. In den meisten funktioniert das System tadellos. Leider hat das System jedoch gelegentlich Aussetzer der Form "MISSING STATUS" bzw. "MISSING ACK" - insbesondere werden nicht alle der Rollladenaktoren bei einem Neustart erkannt. Diese Fehler treten nicht beim Betrieb mit dem Homepilot 2 auf. Ein erneutes Pairing in fhem funktioniert in der Regel. 

Ist es möglich, dass die Probleme mit der relativ großen Anzahl an Aktoren im Zusammenhang stehen (z.B. zu viele Kommandos in einem Zeitintervall)?

Des Weiteren frage ich mich, ob es möglich ist, den genauen Weg eines Aktors über andere Aktoren bis zum Stick festzulegen (da die einzelnen Aktoren ja eine Repeaterfunktion besitzen)?

Vielen Dank in Voraus

[Pfriemler]

... Leider hat das System jedoch gelegentlich Aussetzer der Form "MISSING STATUS" bzw. "MISSING ACK" - insbesondere werden nicht alle der Rollladenaktoren bei einem Neustart erkannt.

Das passiert bei mir sogar mit nur zwei Rollotrons, gibt sich aber auch in ein paar Stunden oder nach der ersten Benutzung eines Rollotrons auch ohne erneutes Pairing. System-Grundrauschen?

[Telekatz]

Leider hat das System jedoch gelegentlich Aussetzer der Form "MISSING STATUS" bzw. "MISSING ACK" - insbesondere werden nicht alle der Rollladenaktoren bei einem Neustart erkannt. Diese Fehler treten nicht beim Betrieb mit dem Homepilot 2 auf.

Betrifft das immer die gleichen Aktoren und werden, wenn das auftritt, alle Aktoren gleichzeitig angesteuert? Haben die betroffenen Aktoren den Befehl trotzdem ausgeführt?

Des Weiteren frage ich mich, ob es möglich ist, den genauen Weg eines Aktors über andere Aktoren bis zum Stick festzulegen (da die einzelnen Aktoren ja eine Repeaterfunktion besitzen)?

Das lässt sich nicht beeinflussen.

[jfhem]

In der Regel sind es dieselben zwei Aktoren. Wenn ich diese jedoch am Schalter direkt bediene (Troll Duofern Comfort), so wird der aktuelle Zustand vom Stick empfangen - nur eben nicht umgekehrt.

Zurzeit löse ich dieses Problem, indem ich die Aktoren per Homepilot in den Anmeldemodus bringe, und anschließend unter FHEM erneut paire (ich habe zwei Rademacher-Sticks).

Wie bereist zuvor erwähnt tritt dieses Problem nicht bei einer Steuerung mit dem Homepilot 2 auf.

[Telekatz]

Wieso musst du die Aktoren neu pairen? Dass ein Aktor einfach so das Pairing zum Stick verliert habe ich noch nie erlebt.

"MISSING ACK" kommt, wenn der Aktor einen Befehl nicht bestätigt weil er z.B außerhalb der Funkreichweite ist. Aber selbst ein ungepairter Aktor würde den Empfang des Befehls bestätigen und kein "MISSING ACK" verursachen.

Wie bereist zuvor erwähnt tritt dieses Problem nicht bei einer Steuerung mit dem Homepilot 2 auf.

Steht der Homepilot am selben Ort, wie der Stick für FHEM?

[jfhem]

Ja, steht am selbem Ort.

[roadghost]

Hi Telekatz,

ich habe da ein echt "geniales" Problem.

Es hat zwar nichts mit deinem Modul zu tun, da du dich aber sehr mit dem Rademacher DuoFern-Stick beschäftigt hast, erhoffe ich mir von dir ggf. einen Lösungsansatz.

Beschreibung:

Ich betreibe mein FHEM seit ein paar Wochen auf einem NAS, auf dem NAS läuft eine Virtuelle Maschine mit Debian 8, auf der VM läuft FHEM.

Alles funktioniert soweit.

Jetzt hatten wir vor 4 Wochen einen Stromausfall im Ort, bei dem ist das NAS natürlich unkontrolliert abgestürzt und eine HDD hat sich dabei verabschiedet.

Ich habe die HDD ersetzt und die Daten wiederhergestellt, alles läuft wieder so wie vorher.

Um mich in Zukunft gegen Stromausfälle abzusichern, habe ich mir eine AEG Protect NAS USV gekauft. Die USV wird per USB ans NAS angeschlossen. Laut QNAP ist die USV mit der NAS kompatibel.

Jetzt kommt der Stick ins Spiel:

Das NAS erkennt die USV nur dann, wenn der Rademacher Stick N I C H T mit am USB-Hub hängt. Ich habe 2 verschiedene HUB´s, etliche varianten des ansteckens, Neustarts des NAS versucht - nix hilft.

Wenn ich den Rademacher abstecke und das NAS neu starte, wird die USV erkannt, wenn ich dann den Stick anschließe wird die USV nach 5 Sekunden nicht mehr erkannt.

Wenn ich dann den Stick wieder entferne erkennt das NAS die USV nicht, erst nach einem Neustart des NAS wird die USV wieder erkannt.

Des weiteren löst der Stick noch ein anderes komisches Problem aus, es kommt vor dass andere, an USB angeschlossene Geräte wie ein HM-CFG-USB oder ein CUL 433 MHz oder ein Jeelink, kurzzeitig nicht mehr vom NAS erkannt werden und die zuweisung der USB-Geräte an die VM dabei verloren geht. FHEM verliert in diesen Fällen natürlich auch die Verbindung zu dem Device.

Hasst du eine Idee was das seien könnte ??

Hat der Stick ne Macke oder ist da einfach eine inkompatibilität gegeben ?? An meinem Raspberry PI konnte ich dieses verhalten vorher nicht beobachten, dort wird aber auch jeder USB-Buchse eine eigene ID zugeordnet, beim NAS läuft das irgendwie anders.

Gruß

Veit

[Telekatz]

Schon mal einen aktiven USB Hub getestet? Klingt nach Problemen mit der Spannungsversorgung.

[roadghost]

Hi,

bisher nicht - aber kann ich ja heute mal probieren.

Was mich dabei jedoch stutzig macht ist, dass dieses Phänomen auch auftritt wenn ich den Rademacher z.B. in eine USB 3.0 stecke, und die USV in eine USB 2.0 stecke.

Soweit ich weiß ist die Stromversorgung von USB 3.0 höher (1 Ampere) als die von USB 2.0 ?!

Ich teste mal ein aktives HUB.

Gruß

Veit

[roadghost]

Update:

Auch mit einem aktiven HUB ergibt sich die genau gleiche Situation.

Rademacher angesteckt = USV wird nicht mehr erkannt.

Hat jemand noch eine Idee ??

Hat jemand einen Rademacher-Stick herumliegen den ich mir zum Testen mal borgen könnte ??

Gruß

[Telekatz]

Probier doch mal, ob ein anderes Gerät mit FTDI Chip die selben Probleme verursacht, wie der Duofern Stick.
Verwendet die USV eventuell auch einen FTDI Chip?