Rolladenaktor HM-LC-Bl1PBU-FM Fahrtzeiten und Prozent passen nicht

[hauwech]

Hallo zusammen,
für das Thema gibt es zwar einige Beiträge, aber eine Lösung habe ich nicht rausgelesen. Ich habe neuerdings drei Rolladenaktoren im Einsatz. Die habe ich laut https://wiki.fhem.de/wiki/HomeMatic_Type_Blind konfiguriert.

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        56EE9C
   HMLAN1_MSGCNT 183
   HMLAN1_RAWMSG E56EE9C,0000,3641873E,FF,FFBA,E2A41056EE9C272DDE06019000
   HMLAN1_RSSI -70
   HMLAN1_TIME 2017-07-05 11:32:42
   HmUART1_MSGCNT 181
   HmUART1_RAWMSG 05010045E2A41056EE9C272DDE06019000
   HmUART1_RSSI -69
   HmUART1_TIME 2017-07-05 11:32:42
   HmUART2_MSGCNT 161
   HmUART2_RAWMSG 05000036E2A41056EE9C272DDE06019000
   HmUART2_RSSI -54
   HmUART2_TIME 2017-07-05 11:32:42
   IODev      HmUART1
   LASTInputDev HmUART1
   MSGCNT     525
   NAME       HG_WZ_RL_Fenster
   NOTIFYDEV  global
   NR         25450
   STATE      28
   TYPE       CUL_HM
   lastMsg    No:E2 - t:10 s:56EE9C d:272DDE 06019000
   protCmdDel 1
   protLastRcv 2017-07-05 11:32:42
   protResnd  3 last_at:2017-07-02 09:53:28
   protResndFail 1 last_at:2017-07-02 09:53:33
   protSnd    211 last_at:2017-07-05 11:32:42
   protState  CMDs_done
   rssi_HmUART1 avg:-70.89 min:-89 cnt:46 max:-67 lst:-75
   rssi_at_HMLAN1 max:-63 lst:-70 min:-74 avg:-67.98 cnt:183
   rssi_at_HmUART1 avg:-66.21 min:-85 cnt:181 lst:-69 max:-62
   rssi_at_HmUART2 max:-47 lst:-54 min:-63 avg:-52.61 cnt:161
   Readings:
     2017-07-05 06:28:01   CommandAccepted yes
     2017-07-01 20:35:56   D-firmware      2.11
     2017-07-01 20:35:56   D-serialNr      OEQ0293286
     2017-07-02 10:39:19   PairedTo        0x272DDE
     2017-07-02 10:39:20   R-driveDown     17 s
     2017-07-01 20:36:01   R-driveTurn     0.5 s
     2017-07-02 10:39:04   R-driveUp       17 s
     2017-07-01 20:36:00   R-pairCentral   0x272DDE
     2017-07-01 20:36:01   R-powerUpAction off
     2017-07-01 20:36:01   R-sign          off
     2017-07-02 10:39:19   RegL_00.          02:01 0A:27 0B:2D 0C:DE 15:FF 18:00 00:00
     2017-07-02 10:39:19   RegL_01.         08:00 09:00 0A:00 0B:00 0C:AA 0D:00 0E:AA 0F:05 10:00  30:06 57:24 56:00 00:00
     2017-07-05 11:32:42   deviceMsg       28 (to VCCU)
     2017-07-05 11:32:42   level           28
     2017-07-05 11:32:42   motor           stop:28
     2017-07-05 11:32:42   pct             28
     2017-07-02 09:58:46   powerOn         2017-07-02 09:58:46
     2017-07-05 11:32:42   recentStateType info
     2017-07-05 11:32:42   state           28
     2017-07-05 11:32:42   timedOn         off
   Helper:
     HM_CMDNR   226
     PONtest    0
     cSnd       11272DDE56EE9C020100,11272DDE56EE9C0201C8
     dlvlCmd    ++A011272DDE56EE9C0201C8
     mId        006A
     peerIDsRaw ,00000000
     rxType     1
     supp_Pair_Rep 0
     Ack:
     Dir:
       cur        stop
       rct        up
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +56EE9C,00,01,00
       nextSend   1499247163.28525
       rxt        0
       vccu       VCCU
       p:
         56EE9C
         00
         01
         00
     Mrssi:
       mNo        E2
       Io:
         HMLAN1     -70
         HmUART1    -67
         HmUART2    -54
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       prs        1
     Rpt:
       IO         HmUART2
       flg        A
       ts         1499247162.9524
       ack:
         HASH(0x472ef30)
         E28002272DDE56EE9C00
     Rssi:
       Hmuart1:
         avg        -70.8913043478261
         cnt        46
         lst        -75
         max        -67
         min        -89
       At_hmlan1:
         avg        -67.9890710382514
         cnt        183
         lst        -70
         max        -63
         min        -74
       At_hmuart1:
         avg        -66.2154696132596
         cnt        181
         lst        -69
         max        -62
         min        -85
       At_hmuart2:
         avg        -52.6149068322981
         cnt        161
         lst        -54
         max        -47
         min        -63
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HmUART1
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   devStateIcon up:shutter_open@green down:shutter_closed@blue 9\d.*:shutter_closed 8\d.*:shutter_7 7\d.*:shutter_6 6\d.*:shutter_5 5\d.*:shutter_halfopen 4\d.*:shutter_4 3\d.*:shutter_3 2\d.*:shutter_2 1\d.*:shutter_1 0\d.*:shutter_open
   eventMap   on:down off:up
   expert     2_raw
   firmware   2.11
   group      Rolladen
   model      HM-LC-Bl1PBU-FM
   param      levelInverse
   peerIDs    00000000,
   room       Wohnzimmer
   serialNr   OEQ0293286
   subType    blindActuator
   webCmd     stop:up:90:80:70:60:50:40:30:20:10:down
Soweit ist alles ok, aber die Prozentangaben passen nicht zu den Fahrtzeiten. Mit set pct 50 z.B. gehen die Rolläden auf etwa 90% - fast ganz geschlossen.
Habt Ihr die Fahrtzeiten zurechtgebogen, oder ist vielleicht woanders noch ein Kinken?

Gruß Roland

[pc1246]

Moin
Hast du denn auch den ganzen Artikel gelesen?

Fahrzeiten kalibrieren

Um die Jalousie mit Prozentangaben auf eine bestimmte Position fahren zu lassen, muss der Aktor die Fahrtzeiten kennen um daraus die relativen Positionen erechnen zu können. Dazu müssen 3 Werte manuell mit einer Stoppuhr gemessen werden.

    Fahrtzeit nach oben
    Fahrtzeit nach unten (ist meistens identisch mit der Fahrzeit nach oben bei herkömlichen Jalousiemotoren)
    Wechsel der Fahrtrichtung (min 0.5s um weder den Aktor noch den Rollladenmotor zu beschädigen)

Diese 3 Zeiten werden in Sekunden gemessen und anschließend einmalig mit den folgenden Befehlen eingestellt:

Gruss Christoph

[nils_]

@pc1246: ich vermute nicht

Readings
level numerischer Wert der den Stand des Rollo wiedergibt. Achtung: Der Aktor kennt nicht den Stand des Rollos sondern errechnet diesen aus den Fahrzeiten. Nach einem powerUp wird ein Stand von 50% angenommen.

ansonsten bitte weitere infos liefern

[amenomade]

Man muss auch natürlich mitberücksichtigen, dass die gesamte Fahrzeit nicht nur die Zeit bis der untere Riegel am Boden ist, sondern auch dazu die Zeit von Belüftlungsposition bis zum ganz geschlossen enthält.

Position 50% heisst deswegen nicht, dass die Jalousie mitte des Fensters steht.

[hauwech]

Hast Du denn das "list" gelesen?
Daraus geht hervor, daß R-driveDown/-Up auf 17 s steht. "Fahrtzeiten kalibrieren" habe ich also gemacht. Ich habe die Fahrtzeiten von "Anschalten" bis "Abschalten" gemessen.
Welche Infos kann ich liefern, die nicht im device list stehen?

Gruß Roland

[nils_]

idee zur kontrolle und um auch das zu berücksichtigen was amenomade geschrieben hat.


- bis oben hin fahren
- dann manuell nach unten bis du deine 50% erreicht hast, dabei Zeit messen.

- nochmal nach oben
- wieder manuell nach unten fahren, dieses mal ca. 8.5s fahren lassen, und gucken wo er stehen bleibt.

[Otto123]

Ihr müsst Bedenken, das der Aktor etwas Sicherheitsaufschlag macht. Also 20 sec eingetragen und der Aktor "fährt" ca. 22 sec. Ich habe die Zeit nicht exakt im Kopf aber irgendetwas zwischen 1,5 und 3 Sekunden.

ich würde das aber nicht weiter nach korrigieren! Diese Zeit braucht man als Sicherheit, damit die Endabschaltung auch wirklich greift. Sonst fährt man immer auf die Zwischenposition und es stimmt nix mehr. Und die Aufschiebung der Behänge ist der größte Einfluss.

Ich bin da mittlerweile pragmatisch und fahre einfach "auf die Hälfte" mit auf 35 % 

Gruß Otto

[hauwech]

Ok, dann schließe ich mich der pragmatischen Lösung an, das ist eh' nur ein kosmetisches Problem.
Aber die Idee von Nils probiere ich noch.

Gruß Roland

[nils_]

Ich bin da mittlerweile pragmatisch und fahre einfach "auf die Hälfte" mit auf 35 % 

so ähnlich mache ich das auch. empirisch ermittelte persönliche mitte

Ok, dann schließe ich mich der pragmatischen Lösung an, das ist eh' nur ein kosmetisches Problem.
Aber die Idee von Nils probiere ich noch.

ist ja auch nur für die ermittlung der werte bzw. damit man/du sieh(s)t wie dann das rollo wirklich steht.


ich hab in meinen fahrzeiten auch noch zusätzlich eine sekunde sicherheitsaufschlag mit drin. ich will halt sicher sein das es komplett zu bzw. offen ist (abschalten tut ja letztlich der motor). dadurch "verschieben" sich natürlich die zwischenpositionen immer ein bisschen (das ist mir persönlich nicht wichtig!)

[Pfriemler]

Eben erst gefunden (war etwas abgehängt die letzten Tage) ...

In der Diskussion vermisse ich noch, dass sich bei einem Rolladen auch die Geschwindigkeit ändert. Je mehr Rolladen schon oder noch auf der Welle ist, desto schneller fährt er. Der Effekt ist umso ausgeprägter, je dünner die Welle und je dicker der Panzer ist.

Das wird eine reine Fahrzeitberechnung nie berücksichtigen können, außer sie berechnet die Fahrzeiten entsprechend nichtlinear. Könnte man reale Zwischenpositionen auf die errechnete Position mappen, würde das als Interpolationsgrundlage reichen. Aber auch meine Rademacher-Rollotrone beherrschen das nicht. Es wäre interessant zu wissen, ob das andere Hersteller anbieten.

[hauwech]

Die Tatsache, daß das Verhältnis zwischen Fahrtwegen und -zeiten nichtlinear ist, macht die Sache knifflig, zumal Hoch- und Runterfahren entsprechend berücksichtigt werden müßte, um z.B. eine 50% Position von oben oder von unten zu treffen. Da wirds wohl kaum eine Lösung geben, die für alle verschiedenen Rolladengeometrien gleichermaßen paßt.
Wenn ich mal Langeweile habe - im Winter? - mache ich mir vielleicht mal Gedanken, ob man mit User readings eine Mappingtabelle bauen und nutzen kann, um die Sache Gäste-kompatibel zu machen. Wahrscheinlich bleibe ich aber bei der pragmatischen Mappingtabelle im Kopf.

Gruß Roland

[martinp876]

Nun die Berücksichtigung der Rolle ist nicht so schwer. Warum auch. Die winkelgeschwindigkeit als konstant vorausgesetzt steigt der Umfang linear zum Radius. Du musst den min und max Radius kennen. Das Verhältnis ist die Änderung der Geschwindigkeit. Recht simpel.
Schwieriger is5 schon zu prüfen wie genau der Motor fährt. Nach unten wird er gezogen. Nach oben muss er ziehen.
Je nach Motor kann das Auswirkung haben. Auch könnte das anfahren ein Problem sein. Das dauert, da ist der Motor langsamer. Die Position ist voraussichtlich anders wenn du von 0 auf 90 auf einmal oder 18 mal 5% fährst.

Die aktoren sind schlicht ungenau. Ohne Messung wird es nicht wirklich präzise

[Pfriemler]

Wir haben jetzt mit zwei Effekten zu tun:
a) Das Mapping von theoretischer und tatsächlicher Rolladenposition: Messung an Rolladenwelle und Panzer ist unpraktisch - aber drei Zwischenpositionen sollten genug Basis für eine mathematisch überschauliche Berechnung liefern, deren Parameter jeder selbst einfach bestimmen und programmieren könnte... Theoretisch müsste man nur die Aktorwerte bei 25, 50 und 75% realem Behang und dem Aufsetzen des Panzers (bevor sich die Schlitze in den Lamellen schließen) ermitteln und dem Aktor mitteilen. Das ist das hier ursprüngliche Problem und wäre mit minimalem Aufwand ohne Zusatzhardware, allein per Firmware, realisierbar.

[WUNSCHDENKEN]

b) Ungenauigkeitseffekte durch die von Martin genannten Effekte würden - ohne Positionsgeber - auch die nach a) interpolierenden Aktoren betreffen. Das ließe sich aber ebenfalls mit ein wenig Rechenaufwand verringern. Unterschiedliche Fahrtzeiten auf- und abwärts auf die Zielpunkte ließen sich auch ausmessen und berücksichtigen, ebenso wie Anfahr- und Bremszeiten. Die mechanischen Anfahrzeiten sind aus meiner Erfahrung vernachlässigbar, aber manche Motoren brauchen eine Denkpause bevor sie nach Einstromung loslaufen (bei meiner Markise ist das seltsamerweise so).
Das ist dann einmal eine Stoppuhrorgie ...

Wo ein Wille ist, wäre auch ein Weg.

[/WUNSCHDENKEN]

[martinp876]

Ich muss relativieren. Da der aktor Drive up und down unterscheidet kann man durch einfaches messen der Fahrzeiten und setzen der Register eine eventuelle Verzögerung in eine Richtung durch den aktor berücksichtigen lassen.
Man kann auch einstellen nach wie vielen Fahrten ohne Stop der aktor einmal an den Anschlag fährt und dann in die Position. Das kann man auch jedes mal machen lassen.
Die Berücksichtigung der Rolle dicke ist nun kein wirkliches Problem.
Ich allerdings muss nicht genau nach 50% fahren. Mir ist es wichtig immer die selbe Position zu erreichen.

[DGH77]

Was ich mich immer frage, wenn jemand unbedingt 50% = Rolladen genau in der Mitte des Fensters haben möchte:
Was soll denn dann 0% sein? Unterstes Element berührt gerade die Fensterbank? Wäre von der linearen denkweise ja logisch, aber wie soll man dann die Schlitze komplett schließen? Oder 1/4 der Schlitze oder 3/4 der Schlitze?
Oder soll 0% wirklich ganz zu sein? Aber wo wechselt die lineare Höhe dann in die Verstellung der geöffneten Schlitze?
Für mich ist alles andere, als % = % der Fahrzeit völlig unparaktikabel, außer der Aktor hätte 2 Parameter für a) %-Höhe des untersten Elements und b) %-Öffnung der Schlitze

Gruß DGH77

[hauwech]

Hallo DGH77,
niemand hat von "genau in der Mitte" gesprochen. Aber wie erklärst Du Deiner Familie, wenn beim Drücken auf "50%" - mit den gemessenen Fahrtzeiten - nur ein 10cm Spalt offen bleibt - Stichwort WAF -?

Gruß Roland

[DanielGab]

Hallo,
ich habe das mit eventMap geregelt und als webCmd dann einfach die Daten eingegeben.

Code Auswählen Erweitern


eventMap 50:Schlitze 19:Lüftung on:auf off:zu


Code Auswählen Erweitern


webCmd auf:zu:Schlitze:Lüftung:stop


Damit kommt die ganze Family zurecht.


Gesendet von meinem MI 5s mit Tapatalk

[martinp876]

 Also die Fahrzeit stimmt? Das ist das a und o .
Dass du auf 100 fährst - klackt dann das Rollo oder erst lange danach? Dann solltest du die Zeit korrigieren