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 (https://wiki.fhem.de/wiki/HomeMatic_Type_Blind) konfiguriert.
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
Moin
Hast du denn auch den ganzen Artikel gelesen?
ZitatFahrzeiten 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
@pc1246: ich vermute nicht :)
ZitatReadings
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 :)
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.
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
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.
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
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
Zitat von: Otto123 am 06 Juli 2017, 10:57:39
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 :D
Zitat von: hauwech am 06 Juli 2017, 11:10:08
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!)
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.
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
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
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]
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.
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
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
Hallo,
ich habe das mit eventMap geregelt und als webCmd dann einfach die Daten eingegeben.
eventMap 50:Schlitze 19:Lüftung on:auf off:zu
webCmd auf:zu:Schlitze:Lüftung:stop
Damit kommt die ganze Family zurecht.
Gesendet von meinem MI 5s mit Tapatalk
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