Rademacher DuoFern USB Stick

Begonnen von Telekatz, 16 August 2015, 16:19:46

Vorheriges Thema - Nächstes Thema

Pfriemler

Ich würde nicht vorschnell alles neu anlernen. Da kann man u.U. mehr kaputtmachen. Gerade wenn es gelegentlich funktioniert und dann wieder nicht, spricht es doch gar nicht für einen generellen Ausfall, den man mit so einer Aktion beheben könnte.

Ursachenforschung wäre in der Tat interessant. Vielleicht bekommst Du auch vermehrt Fehler, weil Du besonders darauf achtest ...

433 MHz ist bei mir in nicht nachvollziehbaren Abständen erheblich gestört. Vom Stick bis zum dauerzickenden Garagentorantrieb in der Blechgarage sind es keine 5 Meter Luftline. Seit kurzem höre ich den Homematic-Neigungssensor von dort auch regelmäßig nicht mehr. Es ist zum Haareausraufen... Stunden oder Tage später tut wieder alles von Zauberhand.

Und ich wiederhole mich: Bei Missing Acks hilft bei mir ein "statusBroadcast" auf den Duofernstick deutlich besser als eine Abfrage auf einzelne Geräte.

Die Investition in einen SDR-fähigen USB-Stick ist sehr empfehlenswert, mehr als 25 Euro muss man nicht ausgeben und kann wunderbar im Frequenzband lauschen.

Überlege mal, was im Zusammenhang mit dem Stromausfall noch war. Blitz in der Nähe?, Überspannung? Evtl. kann es auch die Empfangsleistung des Sticks verschlechtert haben. Schon eine kleine Positionsänderung kann fatal sein.

Jm2c.

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

lestat.le

Na wenn ich ehrlich bin, dann habe ich schon versucht die meisten Geräte neu zu pairen. Ich glaube aber kaum das es Erfolg hatte, da es keine Kommunikation zum Stick gab. Die Statusabfrage vom Stick habe ich schon mehrfach angeschubst. Ohne Erfolg.
Ich möchte nochmal die Ereignis schildern.
Gegen 4 Uhr gab es einen Stromausfall. Der Raspi hing aber an der USV. Allerdings weiß ich nicht ob die USV den Stromausfall bis zum Schluss puffern konnte, da auch das NAS dran hing.
Gegen 6:30 hat meine Frau das Licht in der Küche angeschaltet, über einen Universalaktor. Er liess sich aber schon nicht mehr ausschalten. 8:10 sind alle Rollos nach Plan hochgefahren. 19:15 sind dann auch noch zwei Rollos nach Plan runtergefahren. Ab 20:05 zeigten dann alle Geräte Missing-Ack.

Den Raspi habe ich auch noch in einen anderes Zimmer umgezogen um evtl. Srörungen im HWR auszuschliessen.

Ich hoffe ja immer noch das es der Stick ist aber ich weiß noch nicht wie ich es ermitteln soll.

lestat.le

Im Logfile steht ab und zu:
DOUFERN no ack, request Status
DOUFERN Unknown msg (dann die lange Zeichenkette)
RademacherHomepilot (ist die Bezeichnung vom Stick): Unknown code (dann eine andere lange Zeichenkette)

noom0815

Hallo Telekatz,

gibt es irgendeine Möglichkeit, die Motorgeschwindigkeit der Rollotron 1800 auch für fhem Befehle zu verändern?
Ich würde zur Geräuschreduktion gerne die Motorgeschwindigkeit auf Stufe 1 reduzieren - aber leider gilt die lokale Einstellung nur für Automatikbefehle, manuelle Befehle (somit auch fhem Befehle) werden mit Standardgeschwindigkeit 3 ausgeführt... :'(


Danke und Grüße,
Ian

tomcat.x

Schau mal weiter oben in die Antwort 489 in diesem Thema. Das geht also wohl nur indirekt, indem man Dusk oder Dawn manuell auslöst und das auch aktiviert ist.
FHEM: 6.3 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.10), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

noom0815

Hi tomcat.x,

Danke für den Hinweis. So funktioniert es wenigstens zum Teil...Zwischenpositionen kann man also nicht "langsam" anfahren, aber immerhin... 8)


Grüße,
Ian

Telekatz

Auch up, down und position kann man als Automatikbefehle senden, die ausgeführt werden, wenn timeAutomatic aktiviert ist.

up [timer]
Move the roller shutter upwards. If parameter timer is used the command will only be executed if timeAutomatic is activated.

down [timer]
Move the roller shutter downwards. If parameter timer is used the command will only be executed if timeAutomatic is activated.

position <value> [timer]
Set roller shutter to a desired absolut level. If parameter timer is used the command will only be executed if timeAutomatic is activated.

noom0815

Hallo Telekatz,

das wäre top - allerdings bekomme ich es leider nicht hin, trotz aktivierter timeAutomatik...
Wie genau lautet der Syntax von [timer]? Kannst Du vielleicht ein Beispiel posten?
Anscheinend mache ich hierbei einen Fehler...

Danke für Deine Hilfe,
Ian

Telekatz


noom0815

#789
Oh man - diese Variante habe ich nicht probiert ::)

Vermutlich die einzige - wäre aber auch nicht darauf gekommen, dass so auszuführen...DANKE für den Hinweis!

lestat.le

Ich wollte mich nochmal melden.
Die Rademacher Komponenten funktionieren nun alle wieder.
Durch den Stromausfall, der ca. 45 Minuten dauerte, haben tatsächlich alle Aktoren Ihre Pairingsdaten vergessen.
Ich hatte zwar bereits am Dienstag versucht, durch stromlosmachen der Komonenten, ein neues Pairing anzuschubsen, allerdings hatte ich da keinen Erfolg. Vielleicht hatte ich den Strom zu kurz weggenommen?
Gestern Abend hatte ich auch hier in einem post gelesen, das der Stick selber keine Pairingdaten speichert. Somit hatte ich dann doch die Aktoren in Verdacht und kappte die Stromzufuhr der Komponenten für ca. 20 Sek. Danach konnte ich per RemotePair alle Aktoren erneut an den Stick anlernen.
Bin sehr erleichtert.
Es bleibt noch ein Fragezeichen, denn immerhin konnte ich ab und an die Rollos zur Fahrt bewegen obwohl das Pairung zum Stick ja eigentlich nicht mehr vorhanden war.
Die gedachte Backupvariante im Störfall mit dem Handsender unabhängig von Fhem die Rollos zu fahren ist somit auch teilweise gestorben, denn auch hier ist das direkte Pairung Handsender/Aktor durch den Stromverlust aufgehoben wurde. Hilft also nur wenn sich der Raspi oder Fhem verabschiedet.

VG



BlauzahnK

Hallo Community,

vielen Dank an Alle, die sich an diesem Modul beteiligt haben bzw. immer noch daran beteiligen.
Ich wende mich jetzt an Euch, da ich ein für mich nerviges Problem habe.

Ich setze das Modul in zwei Systemen mit Raspi's ein. Beide Systeme funktionieren gut.
Ein System hat nur RolloTrons, das andere nur Rohrmotor-Aktoren. Nach einem <shutdown restart>
oder einem Neustart/reboot vom Raspi, hat im 1. System der DUOFern-Stick am Ende ein "state initialized"
und die RolloTrons haben ihren jeweiligen aktuellen Status.

Im 2. System werden beim Initialisieren (ich vermute) für jedes Reading ein cmd abgesetzt, das von
dem angesprochenen Aktor mit einem kurzen Auf/Ab oder auch nur Ab bestätigt wird. Bei 6 Aktoren und
nicht gezählten ca. 8 - 10 set_cmds ein nerviges Geklicke und Bewegungsgeräusch.
Der Status des Sticks am Ende ist "state CMDs_done".

Wie gesagt, danach funktionieren beide Systeme gut.

Meine Frage(n):
- Weiß jemand, woran es liegen könnte, dass die Systeme sich unterschiedlich verhalten
und
- wie kann ich das Absenden der cmd's bei der Initialisierung abstellen/verhindern,
  denn es würde eine Abfrage der Aktor-Stati reichen (set getStatus)
 
Ich hoffe, es gibt eine Lösung

Gruß BlauzahnK

Telekatz

Bei der Initialisierung wird kein Befehl abgesetzt, der durch eine Motorbewegung bestätigt werden würde. Triggert da eventuell irgend ein notify?
Ansonsten mach mal ein LOG vom Stick.

BlauzahnK

Hallo Telekatz,

hier das log als Dateianhang, da 558 Zeilen (ich hoffe verbose 4 reicht). Ich kann auch im Vergleich mit dem 1.System keine Ursache sehen, nur den Unterschied feststellen, dass dort nicht so viele "snd's" sind.

Ich hoffe, du erkennst was.

Telekatz

Aus dem Log ist nicht ersichtlich, wer die Befehle absetzt. Aber es ist nicht die Initialisierungsroutine des Sticks, die läuft normal durch. Es sind auch nicht nur Befehle zum verändern von Readings, sondern auch Fahrbefehle.
Verwendest du notify, trigger oder andere Module zum steuern der Rollläden?