Rademacher DuoFern USB Stick

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

Vorheriges Thema - Nächstes Thema

ETHVH

@Telekatz

Tja, wer lesen kann ist tatsächlich klar im Vorteil.  8)
Hat funktioniert! Dank!

Gruß
ETHVH
FHEM auf Intel NUC i5, Betriebssystem Ubuntu Server, HMLan, viele HM und wenige FS20 Komponenten und vieles mehr. Geiles universelles Hausautomationssystem

Pfriemler

Ich wärme das Thema aus aktuellem Anlass (unerklärlich häufiges Vorkommen) mal wieder auf:

Zitat von: Pfriemler am 18 April 2017, 23:52:14
... Garagentoröffner (SX5) meldet in nicht nachvollziehbaren Intervallen - im Gegensatz zu Gurtwicklern - teilweise kurz nach Beginn der Bewegung (gleich ob sie über Duofern oder über eine Schlüsselfernbedienung angestoßen wurde, rauf wie runter) eine Zwischenposition, ohne jedoch zusätzliche Infos zum aktuellen Bewegungsstatus zu bringen.

@Telekatz: Du hast das reading "moving" ja so spezifiziert, dass eine Steuerung via Duofern dort noch vor der ersten Meldung ein "up" oder "down" liefert und bei einer gemeldeten (Zwischen-)Position dann wiederum "stop". Diese Zwischenmeldungen führen jetzt dazu, dass das Reading moving vorzeitig auf "stop" wechselt, obwohl der Antrieb noch fährt. Das macht eine kurzfristige Warnung über ein Stehenbleiben schwierig (und andersherum muss bei einer gewünschten Fahrt in die Endzustände eine gemeldete Zwischenposition kein Problem sein) - allerdings kann man ein Problem eher daraus ableiten, dass die Readings block, obstacle und lightCurtain etwas liefern.

Einen Verbesserungsvorschlag habe ich daraus nicht, weil ich nicht weiß, wie man es besser machen kann. Der Rolloport-Besitzer muss seine DOIFs, Notifys und Pushovers halt nur entsprechend sorgfältig bauen.

Praktisch bedeutet es für mich, dass ich die Zwischenpositionsmeldung im auswertenden DOIF mittels wait um mindestens 15-20 Sekunden zurückhalten muss, um einen "Fehlalarm" zu vermeiden, wenn das Tor in dieser Warteperiode nicht einen Endstand erreicht.

Deshalb nochmal meine Frage: gibt es aus dem Eintreffen der Statusmeldung des Antriebs über eine Zwischenposition wirklich keine Information, die eine Unterscheidung zwischen echtem Stop und einer noch laufenden Bewegung ermöglicht? Bisher scheint es mir so, dass das zuvor informativ übermittelte Register "motion" mit den Werten "up" oder "down" (als Indikator für eine befehligte Fahrt) beim Eintreffen einer Positionsmeldung auf "stop" gesetzt wird, weil Positionsmeldungen rademachertypisch erst nach dem Stillstand des Antriebs erfolgen (wie ich es von den Rolläden kenne).
Oder wird hier tatsächlich ein "stop" vom Antrieb übermittelt, was in diesem Fall ein Bug wäre?

Wenn weitere Infos (Sniffs) hilfreich sind, kann ich gern versuchen welche zu erzeugen.
"Ä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 ..."

JMC

Hi,

Hat eigentlich jemand über das Modul und Homebridge das Thermostat in HomeKit integriert? Ich komme damit leider nicht wirklich weiter :(
Insbesondere verwirren mich die Zustände Aus/Heizung/Kühlung/Automatisch?!

Viele Grüße
Viele Grüße
JMC

Telekatz

Zitat von: Pfriemler am 29 März 2019, 20:08:32
Deshalb nochmal meine Frage: gibt es aus dem Eintreffen der Statusmeldung des Antriebs über eine Zwischenposition wirklich keine Information, die eine Unterscheidung zwischen echtem Stop und einer noch laufenden Bewegung ermöglicht? Bisher scheint es mir so, dass das zuvor informativ übermittelte Register "motion" mit den Werten "up" oder "down" (als Indikator für eine befehligte Fahrt) beim Eintreffen einer Positionsmeldung auf "stop" gesetzt wird, weil Positionsmeldungen rademachertypisch erst nach dem Stillstand des Antriebs erfolgen (wie ich es von den Rolläden kenne).
Oder wird hier tatsächlich ein "stop" vom Antrieb übermittelt, was in diesem Fall ein Bug wäre?
Das motion reading wird nur intern im Modul berechnet. Kein Aktor übermittelt seine Bewegungsrichtung oder dass er gerade gestoppt hat. Da alle Rolladenaktoren ihr Position erst dann übermitteln, wenn sie gestoppt haben, wird das dann als Stopp Ereignis interpretiert.

Pfriemler

Gut und nicht gut ... es ist also wie ich vermutete, "motion" wird nur modulintern gesetzt.
Zitat von: Telekatz am 07 April 2019, 20:55:19
Da alle Rolladenaktoren ihr Position erst dann übermitteln, wenn sie gestoppt haben, wird das dann als Stopp Ereignis interpretiert.
Im Falle des Garagentorantriebs SX5 ist das nun allerdings irreführend, weil hier regelmäßig Zwischenstände während der Fahrt kommen, allerdings in einem nicht erkennbaren Muster.
"Stopp" ist zumindest in einer Endlage logisch. Wie man das sonst löst, weiß ich nicht. Ich probiere mal was aus...
"Ä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 ..."

megadodopublications

Hallo zusammen,

ich habe bei einem (1) von insgesamt 10 Rollläden das Phänomen, dass er nach dem Schließen laut FHEM noch auf "auf" steht. Alle anderen problemlos.

In wenigen Fällen kann ich mit einem getstatus den korrekten Zustand bekommen. Aber für einen wirklichen Automatik Betrieb ist das kein gangbarer Weg. Mehrfaches Power Cycle hat keine Besserung gebracht.

Frage: kennt jemand dieses Problem (und hat eine probate Lösung parat)?  Auf das Öffnen des Rollladenkastens würde ich gerne verzichten.

Vielen Dank vorab
Ralph.

Pfriemler

Mein Garagentorantrieb SX5 gibt sich gelegentlich sehr unkommunikativ, hier sind es die Schließmeldungen, die regelmäßig ausbleiben, das kann aber auch durch Funkprobleme begünstigt sein.
In der Fehlerbehebungspraxis führt bei mir "getStatus" selten zum Erfolg. Bei mir half, den DUOFERNSTICK einen "statusBroadcast" senden zu lassen. Ich rufe den (ggf. mehrfach) auf, wenn das Tor nach einem von FHEM gesendeten Schließbefehl innerhalb einer bestimmten Zeit keine Schließmeldung liefert. Vielleicht hilft das auch bei Dir.
"Ä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 ..."

megadodopublications


megadodopublications

@Pfriemler:
Danke für den Tip. Problem ist seit Anwendung nicht mehr aufgetreten  :)

Marsupilami

Hallo zusammen,

ich habe da mal eine Frage zum Reading "runningTime" des DuoFern Umweltsensors:

Die Angabe soll vermutlich in Sekunden sein, bei mir verhält es sich aber so, als wäre es 1/10 Sekunden, also bei 100 dann 10 Sekunden (und Einstellen über die FHEM Oberfläche geht nur von 0 bis 100, ja klar, mit einem setreading kann ich auch größere Werte setzen. Ist das aber so gewollt).

Ist das ein Denkfehler meinerseits, oder ist da was bei meinem Umweltsensor falsch konfiguriert?

Danke vorab
Siggi

Telekatz

Das Reading runningTime ist in Sekunden. Habs gerade nochmal am Homepilot ausprobiert. Keine Ahnung, was bei deinem Umweltsensor anders konfiguriert ist.

lestat.le

#776
Hallo,

lezte Woche hat ein Universalaktor Missing Ack gezeigt. Hatte ich mich gewundert aber nach einem Reboot von Fhem war es wieder ok. Gestern hatte ich dann in der Nacht einen Stromausfall. Der war auch recht lange. Als erstes hing wieder der Universalaktor aber der Rest ging. Gestern Abend zeigten dann alle Devices Missing ACK oder Missing Status.
Im Einsatz habe ich Rohrmotoren, Universalaktoren, Gurtwickler und einen 6-Handsender.
Interessanterweise funktioniert auch der Handsender mit den Rohrmotoren nicht mehr. Dabei dachte ich, die Rohrmotoren kommunizieren direkt mit dem Handsender, unabhängig von Fhem.
Die Gurtwickler und die Rohrmotoren konnte ich dann dennoch nochmal per Fhem fahren aber heute morgen dann wieder nicht und es kommt auch wieder Missing Ack.
Ist doch merkwürdig das sporatisch mal kommunizert werden kann.
Meine Installation der Duoferngeräte ist schon eine Weile her und ich bin nicht mehr so fit in dem Thema.
Kennt jemand von euch so eine Situation, das gleich alles aussteigt?
Woran erkenne ich das die Geräte tatsächlich gepaired sind?
Als nächstes würde ich die Devices Stromlos machen und über remotepair versuchen neu anzulernen.
Oder habt Ihr eine Idee?


lestat.le

#777
Jetzt gerade sind alle Rollos gefahren bzw. waren ansprechbar. Auch die Universalaktoren. Ohne das ich irgendetwas in fhem verstellt habe. Leider funktionierte die Kommunikation nur einmal. Nun wird wieder Missing Ack gezeigt. Der Handsender geht immer noch nicht.

Telekatz

Eventuell ein Störsender auf 433 MHz in der Nähe. Schon mal die Batterie des Handsenders getauscht?

lestat.le

Batterien vom Handsender sind nicht getauscht. Ich hab ihn allerdings zum testen an einen Rollotron angelernt. Das ging soweit. Störsender wäre eine Möglichkeit. Komisch ist das es nach dem Stromausfall losging. Aber evtl. nur ein Zufall. Ich habe am Raspi noch HM, Zwave und einen Jetlink. Allerdings ist das schon seit mind. 2 Jahren so. Hatte jetzt am Setup nichts mehr groß geändert, da die Hausautomation so weit ok war.
Rademacher Duofern war bis jetzt sehr robust und zuverlässig und hab es daher seit 2 Jahren nicht mehr beachtet. Jetzt erwischt es mich kalt.
Könnte der Duofernstick defekt sein?
Sorry für die Fragen. Wenn es bei euch noch nicht aufgetreten ist, dann könnt ihr auch nur raten.
Leider hängen meine Aussenrollos komplett dran und auch etwas Beleuchtung. Das macht mich etwas nervös.
Auch ist es knifflig an die Rohrmotoren zu kommen, um diese in den Anlernmodus zu schicken.
Einen Rollotron habe ich vorhin am Gerät in den Anlernmodus geschickt aber nur 3 bis 5 Kommunikation mit dem Stick bricht es wieder ab-Missing Ack
Die Bearbeitungszeit am Stick kommt mir auch langsam vor. Zumindest im Vergleich zu HM.
Ich hatte auch ein Backup vom Raspi probiert, aber auch da die selben Probleme.
Leider fehlt mir die Idee wie ich ermitteln kann, ob ein Störsignal anliegt. Einen großen Sendemast haben wir hier aber Dvb-t oder lte dürfte oberhalb von 433MHz liegen.