HM-LC-Bl1PBU-FM seltsames Verhalten

Begonnen von strauch, 06 Juni 2014, 09:55:03

Vorheriges Thema - Nächstes Thema

strauch

Hallo,

vielleicht kann mir einer das Verhalten des HM-LC-Bl1PBU-FM erklären. Ich hab oft nach einem Neustart von FHEM oder wenn mal Stromausfall war oder ähnliches, das der Rollladen ein Stückchen nach unten fährt.

Ist der Rollladen oben und ich drücke den Knopf zum hochfahren, oder sende den Befehl. Fährt der Rollladen ca. 20cm herunter. Fahr ich den Rollladen einmal komplett runter und wieder rauf, dann macht er das nicht mehr.

Er fährt auch sehr stotternd. So ein wenig wie wenn ich den Rollladen herunterfahre, er bleibt an irgendwas hängen und fährt wieder hoch. Der Schalter denkt ja trotzdem der Rollladen wäre runtergefahren ist er aber nicht. Drücke ich dann auf runterfahren. Fährt er immer so stockend ein Stück runter (weil der Schalter kurz schaltet und dann direkt nicht mehr). Da hilft dann auch nur einmal komplett rauf und wieder runter.

Ich verstehe auch garnicht warum er herunterfährt wenn ich rauf drücke.....

Warum das ganze für mich ein Problem ist, ist folgendes: Wir haben an der Terrassentür eine Fliegengittertür. Fährt der Rollladen ein Stück runter dann hab ich mich ausgesperrt, weil der Rollladen die Fliegengittertür blockiert.

Seltsamerweise macht das auch nur einer von beiden Rollläden, einen Unterschied kann ich nicht feststellen. Jetzt überlege ich wie ich mir behelfen kann. Gibt es eine Möglichkeit FHEM (attribute o.ä.) zu sagen, es soll nur den Befehl senden, wenn er anders ist als hinterlegt. So das ich mit FHEM sooft on drücken kann, solange der schon auf on steht passiert nichts?! Oder müsste ich mir dafür eine Funktion in myutils hinterlegen.

Oder kann man am Schalter irgendwelche register umstellen das soetwas nicht passiert. Ich frag mich eh warum der Schalter immer noch mal auslöst obwohl er eigtl. schon die Position erreicht hat.

Bin für alle hinweise dankbar.

Grüße

strauch
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

Bennemannc

Hallo,

??? warum willst Du in fhem etwas ändern, wenn anscheinend ein mechanische Problem am Rolladen vorliegt. Du sagst die anderen Rollos funktionieren - also hat entweder dieser Schalter einen defekt oder das Rollo. Fhem macht ja für alle Rollos das gleiche (es sei denn Du hast da etwas umgestellt).
Ich könnte mir vorstellen, dass dort ein 'inteligenter' Motor drin ist, erkennt er die Blockade und fährt in die andere Richtung. Das würde solch eine Verhalten erklären.
Ich würde auf jedem Fall zunächst die Ursache für das stotternde Fahrverhalten suchen, bevor ich irgendetwas in fhem "bastel".

Gruß Christoph
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

strauch

Ja natürlich damit hast du Recht. Das Verhalten mit dem stottern kann ich bei beiden Rollläden provozieren, wenn ich die eben blockiere und die in die andere Richtungen fahren.
Ich vermute auch das es normal ist, das wenn er schon oben ist und ich drücke noch mal nach oben, das dann der Aktor nochmal schaltet? Aber irgendwie unnötig. Allein deshalb würde ich gerne in FHEM das ändern, er braucht den Befehl ja garnicht senden, wenn er eh oben ist.

Der eine fährt halt ein Stück runter, das ist weg wenn er einmal komplett rauf und runter fährt. Aber vielleicht hat der Aktor auch wirklich eine Macke.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

SvenJust

Zitat von: strauch am 06 Juni 2014, 10:38:56
Der eine fährt halt ein Stück runter, das ist weg wenn er einmal komplett rauf und runter fährt. Aber vielleicht hat der Aktor auch wirklich eine Macke.
Das Verhalten des Aktors kann ich bestätigen. Der Rollladen fährt bei einem Tastimpuls nur 10% rauf oder runter. Wenn der Rollladen einmal komplett nach unten oder oben gefahren wurde, ist dieses Verhalten weg.

Bei mir tritt das Verhalten auf, wenn der Aktor stromlos war und der Rollladen nicht ganz oben oder unten stand.
FTUI, Raspberry PI/SSD, CUL CC1101, HMLAN, 10x HM-LC-Bl1PBU-FM, HM-LC-Sw4-WM (KWL Pluggit P300), HM-WDS30-OT2-SM (Sonnensensor), HM-Sec-SCo, LW-12 Wifi LED, CUL Selbstbau nanoCUL 433 (IT), Arduino (S0-Stromverbrauch), OW DS2480 (OWX_ASYNC) 8x DS18B20, MQTT (Fröling P4), MYSENSORS (Roto Rollläden)

Bennemannc

Hallo,

also zunächst mal - fhem bzw. der Schalter weiß nicht wo der Rolladen steht. Nach eine Stromausfall erst recht nicht. Wenn einmal rauf und runter gefahren wurde weiss der Actor wo der Rolladen sein sollte ! Ob er dort angekommen ist kann der Actor nicht prüfen, da er hierfür keine Rückmeldung bekommt. Er geht einfach davon aus, das die Fahrzeit richtig eingestellt ist und nach dieser Zeit das Rollo an der Endposition ist. Dieses würde das eigentümliche Verhalten vor der ersten Komplettfahrt erklären.
Das ein "auf" Befehl bei offenem Rollo das Rollo abwärts fahren lässt konnte ich bis jetzt nicht beobachten. Das könnte daran liegen, das der Endschalter sehr eng eingestellt ist. Das Rollo versucht auf zu fahren, was der Schalter anscheinend kurz zulässt, bekommt dann aber eine Motorblokade und fährt zur Behebung dieser in die andere Richtung - eben nach unten. Ich würde mal testen, ob das immer noch so ist, wenn der obere Endschalter etwas früher anspricht.

Gruß Christoph
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

strauch

Zitat von: Bennemannc am 06 Juni 2014, 11:01:33
Das ein "auf" Befehl bei offenem Rollo das Rollo abwärts fahren lässt konnte ich bis jetzt nicht beobachten. Das könnte daran liegen, das der Endschalter sehr eng eingestellt ist. Das Rollo versucht auf zu fahren, was der Schalter anscheinend kurz zulässt, bekommt dann aber eine Motorblokade und fährt zur Behebung dieser in die andere Richtung - eben nach unten. Ich würde mal testen, ob das immer noch so ist, wenn der obere Endschalter etwas früher anspricht.

Ahhh sehr guter Gedanken, will heißen ist nicht mal das Problem des Homematic Schalters sondern vom eigtl. Rollladenmotor. Puhh ich wüsste gar nicht wo man da irgendwo rankommt oder was einstellen kann.

Aber kann man denn trotzdem dem Homematic Schalter "abgewöhnen" das wenn er denkt er wäre oben, das er noch mal nach oben hin das "Relais" öffnet. Klar bei einem Stroamusfall geht der Aktor ja davon aus auf 50% zu stehen.

Der WAF ist so gerade sehr gering und ich überlege wie ich dieses Verhalten abfangen kann, oder ich müsste irgendwie mit einem Kontakt prüfen wo der Rollladen wirklich steht.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

Bennemannc

Hallo,

also bei direkt gepeerten (auch intern gepeerten) Devices (Schalter / Actor) wird das schwer. Hier kann fhem ja nicht eingreifen, da der Befehl ja direkt von Schalter an den Actor geht. Der Schalter weiß ja noch nicht einmal den Zustand des Actors. Wenn das Rollo beispielsweise auf fährt, bekommt der Schalter nur mit "Actor hat auf Befehl bekommen und bestätigt". Wenn ich dann noch einmal Auf drücke, sendet der Schalter den gleichen Befehl noch einmal. Dieser wird wieder vom Actor bestätigt - was der Actor dann macht bekommt der Schalter nicht mit. Fhem ist bei all dem außen vor und lauscht nur mit. Diese "mitgelauschten" Informationen können in Fhem natürlich weiter verarbeitet werden (notify o.Ä.) aber den Befehl unterdrücken geht nicht und im nachhinein eine Stop zu senden macht auch nicht viel Sinn - da ist das Kind ja sozusagen schon in den Brunnen gefallen.
Auch wenn in diesem Fall der Schalter zusammen mit dem Actor in einem Gehäuse sitzen - es besteht ein "internes" peering.
Vielleicht hat Martin eine Idee ...

Gruß Christoph
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

strauch

Ich will den Druck auf den Schalter auch gar nicht abfangen, weil dann ist ja eine Person da die den Effekt sieht und ausgleichen kann. Eher automatisch durch FHEM generierte Befehle z.B. durch ein notify/threshold. Was ich aber auch noch mal überprüfen muss ist, was tatsächlich passiert wenn FHEM neustartet.
Irgendwie hab ich immer im Hinterkopf das es in FHEM ein Attribut geben soll, das nur Befehle gesendet werden, wenn der Zustand des Aktors anders ist. Also ist der Schalter auf on, wird nur gesendet wenn ein off gesendet werden soll. Aber ich finde dazu nichts in der commandref oder im Wiki, vielleicht bilde ich mir das auch nur ein :-).
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

tpm88

Hallo,

ich empfehle mal folgenden Beitrag von Martin zu lesen - er hat speziell das Verhalten des Aktors nach einem Stromausfall dort genau beschrieben:

http://forum.fhem.de/index.php/topic,22477.msg159175.html#msg159175

Gruss
Tobias
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

Bennemannc

Hallo,

also ich mache etwas Ähnliches. Die Rollos werden aus fhem per sunrise/sunset gefahren. Wenn eine Türe offen steht (ist mit Kontakt überwacht) wird eben dieses Rollo nicht gefahren. Das war für mich ausreichend. Als kleines I-Tüpfelchen habe ich dann noch einen Notify auf den Kontakt gemacht, der wenn das Rollo unten ist und die Türe geöffnet wird, das Rollo selbständig hoch fährt.

Gruß Christoph
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

strauch

Jepp genauso mach ich das auch. Zusätzlich hab ich noch einen Beschattung bei Sonne.

@Tobias danke das werde ich mal lesen.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

stromer-12

Ich habe den HM-LC-BL1-FM und da steht nach einen Stromausfall im Reading "Motor" "err:50".
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

strauch

Also inzwischen kann ich den Rollladen gar nicht mehr ganz rauf oder runter fahren. Da muss wohl wirklich Anfangs und Endposition neu eingestellt werden :-(. Mal herausfinden was wir für einen Hersteller haben.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

Bennemannc

Hallo,

das verstehe ich nicht ganz. Normalerweise verstellen sich die Endanschläge nicht einfach. Um diese nachzustellen ist bei den meisten Rollos auf der Seite des Motors zwei Imbusschrauben. Mit denen kann man die Endpunkte einstellen. Man muss dazu natürlich den Kasten aufmachen.
Kann es sein, das Du etwas verstellt hast oder zu lange drückst ? Wenn ich etwas zu lange drücke, fährt das Rollo nur jeweils 10% in die gedrückte Richtung. Nur mit einem sehr kurzen Tastendruck wird bis zur Endposition gefahren. Die Länge des Tastendruckes kann man nWm in den Registern einstellen.

Gruß Christoph
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

strauch

Ich muss mal schauen, ich werde am Wochenende mal den normalen Schalter anschließen und das testen. Der Rollladen bleibt immer an der gleichen Stelle stehen. Ich hab auch schon mal die Sicherung rausgenommen um alles Stromlos zu machen.
Er fährt auf jeden Fall auch nicht runter wenn ich ihn jeweils auf on oder off stelle per Interface. Ich hab auch schon versucht komplett rauf und runter zu fahren und hab immer gewartet bis der Homematic schalter nach der eingestelleten Zeit abschaltet damit er denkt, er wäre oben oder unten.
Ich höre ja das Relais vom Homematic Schalter klacken wenn er stoppt oder startet, das tut er an dieser Stelle nicht. Auch eine absichtliche Blockierung ändert nichts an der Stelle.
Irgendwas ist da einfach faul. Jetzt muss ich mal die "Probleme" ausschließen bzw. die Ursache eingrenzen.
Um den Rollo einzustellen müsste ich ja erst mal den Rollladenkasten öffnen. Aber ich glaube dann lass ich die Fensterjungs kommen und das mal anschauen.
Aber danke für deine schnellen Antworten und Hilfen.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.