[geklärt] Problem beim manuellen Stoppen per Taster eines Rollladenaktor

Begonnen von t1me2die, 18 Juli 2018, 12:43:26

Vorheriges Thema - Nächstes Thema

t1me2die

Moin liebe Leute,

ich habe bei mir in der Wohnung 5 HM Rollladenaktoren (HM-LC-BI1PBU-FM) im Einsatz.
Normalerweise fahren meine Rollos "ganz zu" oder "ganz auf", Zwischenpositionen habe ich bisher noch nicht so oft benutzt!
Nun in der Sommerzeit kommt es desöfteren vor, dass ich die Rollos per Taster "manuell" runter fahren lasse und während der Fahrt per Taster stoppe, damit es nicht stock dunkel in der Wohnung ist.

Nun zu meinem Problem:
Wenn ich das Rollo bei ca. 40% (offen) manuell per Taster stoppen möchte, passiert es fast immer, dass das Rollo nicht an dieser Stelle stoppt, sondern es weiter nach unten "rast".
Manchmal geht es komplett zu, manchmal bleibt ein Schlitz von dem Rollo noch offen.
Zwischen 100% - 50% (offen) bleibt es bei Stop Betätigung am Taster auch genau an dieser Stelle stehen.

Meine Frage:
Ist der Aktor im Eimer?
Ist mein Rollladenmotor im Eimer?

Ich hoffe ihr versteht mein Problem, ansonsten könnte ich von diesem Phänomen auch mal ein Video machen.

Gruß
Mathze

frank

hört sich seltsam an, falls ich es richtig verstanden habe.
ich würde ihn erst mal von der netzspannung trennen. sollte sich nichts ändern, würde ich einen werksreset probieren. als letztes würde ich die position mit einem anderen tauschen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

Definiere doch bitte mal Taster.

Ist die Tastwippe direkt am Gerät gemeint? (=> evtl. mechanisches Problem, kenne ich auch, wenn der Aktor recht tief in der Dose sitzt)

Handelt es sich um ein _anderes_ HM-Gerät, das direkt mit allen/dem betreffenden Aktor gepeert ist? (wenn es mal geht, mal nicht => franks Hinweise, ggf. auch mal Batterie am Taster erneuern, sofern vorhanden)

Handelt es sich um was anderes, das von FHEM aus Befehle absetzt? (=>IO-Device mal prüfen, da kommt sich evtl. was funktechnisch in die Quere) Dann wären Infos zum IO und der konkreten Ansteuerung hilfreich....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t1me2die

Moin ihr Zwei, danke für eure Aufmerksamkeit.

Es ist kein FHEM Problem und hat auch nichts mit FHEM zu tun.

Genau, es ist die Tastwippe direkt am Gerät gemeint.
Der Aktor sitzt in einer UP-Dose. Eine "Wippe" fixiert den Rahmen mit dem Aktor und ich betätige den Taster per Finger  :)

Beta-User, du hast mich auf eine gute Idee gebracht, es könnte die "Wippe" sein, die tausche ich nachher direkt mal aus.

Also nochmal zusammengefasst, ich betätige per Tastendruck den Taster nach "UNTEN" um das Rollo runter fahren zu lassen.
Wenn das Rollo nun zu ca. 60% geschlossen ist, drücke ich per Tastendruck den Taster nach "OBEN" um die Abfahrt des Rollos zu stoppen.
In diesem Fall stoppt das Rollo aber nicht, sondern das Rollo rast nach unten (gefühlt wie ein freier Fall).

Gruß
Mathze

Otto123

Hi,

ich würde denken da ist die Bremse im Motor kaputt.
Komischer Fehler.

Oder die wie ist die R-driveTurn eingestellt? Aber das kann eigentlich nicht diesen Fehler verursachen ....

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Ergänzend: Wenn es die Wippe wäre, würde sich das Verhalten beim Stoppen über FHEM anders darstellen. Glaube ich aber eher nicht, sondern vermute wie Otto einen Defekt des Rolladenmotors. Versuchsweise den genannten Registerwert zu erhöhen kann aber eigentlich auch nicht schaden.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t1me2die

#6
Wenn die Bremse im Motor einen abbekommen hat, dann müsste das Problem ja immer beim "Stoppen" auftreten oder?

Wenn ich das Rollo während der abwärtsfahrt bei 90%- , 80%-, 70%-Öffnung, ... stoppe, dann klappt es und das Rollo bleibt genau an der gewünschten Stelle stehen.
Erst ab ca. 40%-Öffnung und weniger tritt dieses Phänomen auf!

r-driveTurn steht auf 1 Sekunde (kann mir aber nicht vorstellen, dass das damit irgendwas zu tun hat.

Gruß
Mathze

PS.: Wenn ich das Rollo per "set HM_Rollo_Aktor pct 40" über FHEM setze, fährt das Rollo korrekt auf die gewünschte Stelle und bleibt dann auch stehen.

Beta-User

Klappt den 20% anfahren? Das klingt etwas danach, als wäre es vom Gewicht des abgewickelten Rolladens abhängig...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t1me2die

#8
An das Gewicht habe ich auch schon gedacht, umso mehr das Rollo "geschlossen" ist, desto schwerer sind ja die Lamellen für den Motor.
Laut meiner Voreigentümerin sind die Rollos schon 20-25Jahre alt und von einem Motortausch hat sie nichts erwähnt.
Dementsprechend könnte es tatsächlich an dem Motor liegen. Ich möchte halt erstmal alles soweit ausschließen, bevor ich jemanden beauftragen muss um meine Außenrollos zu öffnen und den Motor zu tauschen. (wohne im 1. Stock und habe solch ein Vorbaurollo wie auf dem Bild)

Würde das aber nicht bedeuten, dass das Rollo bei der abwährtsfahrt ab 40%-Öffnung oder weniger immer in den "freien Fall" geraten würde?
Wenn das Rollo per Tastendruck (oder per "set Rollo on/off") öffne oder schließe fährt es ganz normal hoch / runter im selben Tempo.

Ich werde das Rollo nachher aus dem komplett geschlossenen Zustand (pct 0) einmal per Hand auf ca. 20% fahren lassen und dann per Hand am Taster stoppen.
Selbes werde ich auch via "set Rollo pct 20" probieren.
Ich melde mich nachher mit dem Ergebnis bei Euch.

Gruß
Mathze

zap

Zitat von: t1me2die am 18 Juli 2018, 14:39:07
r-driveTurn steht auf 1 Sekunde (kann mir aber nicht vorstellen, dass das damit irgendwas zu tun hat.

Der Default Wert für die Motorumschaltzeit in einer Homematic CCU ist 0.5 Sekunden. Das ist bei allen meinen Rollläden so eingestellt.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Beta-User

Zitat von: t1me2die am 18 Juli 2018, 14:56:32
Würde das aber nicht bedeuten, dass das Rollo bei der abwährtsfahrt ab 40%-Öffnung oder weniger immer in den "freien Fall" geraten würde?
Na ja, solange der Motor fährt, wird die Bewegung durch den Motor gesteuert. Nur: wenn man eines der Relais umschaltet (also den Strom kurzzeitig wegnimmt, indem man einen Stop oder Stop mit Richtungswechsel durchführt), ändert sich das ja ;) . Ab dann bestimmen andere Faktoren die weitere Bewegung (oder den Stillstand) des Rollos - aber bestimmt kann dir jemand anderes besser erklären, wie die Motoren intern aufgebaut sind bzw. welche Funktionsprinzipien es gibt.
Jedenfalls sollte es bei einem Defekt des Motors oder zugehöriger Teile keinen Unterschied machen, ob du direkt eine Taste am Aktor drückst oder denselben Befehl über FHEM anstößt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t1me2die

Zitat von: zap am 18 Juli 2018, 15:45:11
Der Default Wert für die Motorumschaltzeit in einer Homematic CCU ist 0.5 Sekunden. Das ist bei allen meinen Rollläden so eingestellt.

Das ist korrekt, mir kam bei meinem Rollo aber der Wechsel der Fahrtrichtung "recht" lang vor, sodass ich die Zeit von 0.5 Sekunden auf 1 Sekunde geändert habe.
Habe es jetzt mal wieder auf 0.5 Sekunden zurückgestellt.

@Beta-User, schön beschrieben  :)
Die Frage ist, ob ein "set Rollo pct 20" dasselbe ist, wie während des runterfahrens bei ca. 20% die Taste nach oben drücke um das "Stop" Signal an den Motor zu senden?

Zitat...Jedenfalls sollte es bei einem Defekt des Motors oder zugehöriger Teile keinen Unterschied machen, ob du direkt eine Taste am Aktor drückst oder denselben Befehl über FHEM anstößt...
Wenn ich die Taste nach "UNTEN" drücke, fährt das Rollo bis es komplett geschlossen ist bzw. genau solange wie ich "driveDown" angegeben habe.
Wenn ich während des runterfahrens irgendwann nach "OBEN" drücke, sollte der Aktor ja nur ein "Stop" an den Motor senden.
Dieser Ablauf wäre auf FHEM Ebene für mich ein "set Rollo off" und an der gewünschten Stelle ein "set Rollo stop" (im übertragenden Sinne), sprich sozusagen 2 Befehle an den Aktor.

Wenn ich nun aber ein "set Rollo pct 20" mache ist das für mich ein Befehl, außer dieser Befehl beeinhaltet automatisch ein "Stop".

Ich werde es gleich ausprobieren und berichten, ggf. mache ich noch ein Video und lade es hoch.
(Verdammt schwierig dieses Problem so zu beschreiben, damit es Außenstehende verstehen ohne es "live" gesehen zu haben!)

Danke für Eure Zeit  :)

Gruß
Mathze

Beta-User

Du solltest mal im Event-Monitor verfolgen, was da genau an Events kommt, wenn du was über die Tasten bzw. über FHEMWEB anstößt:
Ist der Rollo beim runterfahren weiter unten als die 20%, wird (verkürzt gesagt) erst ein stop durchgeführt - genau wie beim "Gegentaster", dann gewartet und schließlich nach oben gefahren (das macht der Aktor intern automatisch). Kommt er erst von oben, wird eben bei 20% ein schlichtes motor:stop durchgeführt - nicht anders, wie wenn nur der Taster gedrückt wird. Der einzige Unterschied ist der, dass der STATE bei einer "FHEM-Fahrt" ein "set_.." ist, bis der Stop-Event verarbeitet ist ;) .

So lassen sich z.B. auch automatische Fahrten von manuellen unterscheiden: kommt ein motor:(up|down) ohne "set_..." im STATE des Aktors, ist es eine lokal oder über gepeerten Taster veranlaßte :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

t1me2die

#13
Ich habe nun zwei Videos gemacht.

Beim 1. Video sieht man ganz schön, wie das Rollo sich kurz im "freien Fall" befindet und nach kurzer Zeit stoppt.
https://streamable.com/0bw2y

Beim 2. Video keinerlei Probleme.
https://streamable.com/7fk2j

Wenn ich via FHEM ein "set Rollo pct 35" oder 40 ausführe (genau an dieser Stelle passiert dieser "freie Fall", wenn ich per Tastendruck ihn auslöse), dann gibt es auch keine Probleme.

Gruß
Mathze

Beta-User

Gerade am 2. Video (7fk2j) kann man m.E. ein Problem erkennen, ca. bei sek. 22: Rollo fährt hoch, wird durch runter-Taste gestoppt und fällt dann kurzzeitig nach unten, bis er wirklich zum stehen kommt...

Jedenfalls kommt der Tastenbefehl im Inneren des Aktors an, erst ab da wird es "komisch". Allerdings kann ich nicht sagen ob das ein Problem des Motors ist, der Kombination der internen Aktorlogik mit der Motortype oder ob irgend was intern in dem Aktor hakt :( . Vielleicht kennt das ja sonst jemand. Ist das bei allen Rolläden dasselbe bzw. ähnlich? Schon immer? Wann hast du umgestellt?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files