blindActor HM-LC-Bl1PBU-FM - großer Fehlerbetrag bei 'set pct'

Begonnen von wkarl, 17 Juli 2014, 09:29:11

Vorheriges Thema - Nächstes Thema

wkarl

Hallo,

aktuell bin ich beim Fein-tunen der installierten Rolllädensteuerungen. Es sind vier Anfahrtspunkte definiert wie aus dem ersten screenshot zu ersehen ist - auf (->off), 20% schließen, 70% schließen, zu (->on). Der zweite screenshot zeigt die angepassten readings DriveDown und DriveUp.
Das Problem ist nun die wiederholbare Genauigkeit der Anfahrtspunkte. Ausgehend von komplett AUF wird auf 20% gefahren, dann auf 70% und wieder zurück auf 20%. Der nun eingenommene Anfahrtspunkt (sollte ja 20% schließen sein) liegt 20cm unter dem ersten 20%-Anfahrtspunkt. Das Fehler auftauchen ist klar, da die Anfahrtspunkte über DriveDown und DriveUp kalkuliert werden. Aber 20cm beim ersten Mal! Selbst für Grobmotoriker etwas viel.
Hat jemand hier ähnliche Erfahrungen und evtl eine Lösung?
Ein workaround wäre mit driveMode jedesmal über die Endpunkte zu fahren (noch nicht getestet). Aber will ich wirklich die Diskussion mit meiner Frau führen warum das Teil jedesmal komplett auf oder zu geht bevor es zum Anfahrtspunkt kommt? Würde ich gerne vermeiden.

Danke schon mal für Eure Unterstützung
walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

frank

ZitatDas Fehler auftauchen ist klar, da die Anfahrtspunkte über DriveDown und DriveUp kalkuliert werden.
ausserdem driveTurn.
wenn ich dein scenario richtig verstehe, ist einmal driveturn enthalten und einmal nicht.

gruss frank
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

wkarl

Hallo Frank,

Nein, driveTurn fällt hier nicht ins Gewicht. Meine Actoren sind so programmiert, dass es nicht möglich ist direkt eine Richtungsänderung durchzuführen (AUF > ZU, ZU >AUF). Es wird immer gestoppt, dann erst ist eine Richtungsänderung möglich.
driveTurn kommt nur zum Tragen, wenn direkt die Richtung geändert wird. Zum Schutz der angesteuerten Technik. Zumindest nach meinem Verständnis.

ciao walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

frank

ZitatZumindest nach meinem Verständnis.
mein verständniss ist folgendes:

1. von 100% offen nach 20% zu (80% offen). hier auch erst wendung plus fahren, da die 100% bestimmt aus einer geschlosseneren position erreicht wurde.

2. wenn danach weiter aufgefahren wird nach 70% zu, muss der motor keine wendung machen, sondern fährt einfach weiter zu.

3. da die jalousie nun hoch gefahren werden soll, muss erst die wendung passieren und dann das hochfahren. sozusagen der schlupf bis die unterkannte der jalousie sich bewegt.

edit.
die "echte" 20% position sollte dann ungefähr zwischen den beiden unterschiedlichen positionen sein. also driveturn etwas erhöhen, sollte die differenz verringern.
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

wkarl

Hallo Frank,

basierend auf Deiner Annahme, dass turnDrive in dem gegebenen Szenario beim Hochfahren zu 20% was 'wegknabst', habe ich turnDrive von 0,5s auf 2s erhöht. Das sollte also erheblich mehr als 20cm Unterschied ergeben. Dem ist nicht so. Es bleibt bei 20cm.
Ich bin weiter der Meinung, turnDrive hat in meinem Szenario keinen Einfluss. Das Problem ist wo anders begraben.

ciao walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

frank

sorry, da muss ich mein verständnis mal neu kalibrieren.

wenn die positionen aber so exakt ungenau eingehalten werden, muss man da irgendwo dran schrauben können.

gruss frank
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

wkarl

Hallo,

es schien, dass das Problem mit den Einstellungen von driveUp und driveDown zu lösen ist. Gemessen und eingetragen habe ich für driveDown=21s und driveUp=22.5s. Die lange Geschichte des empirischen Lernens kürze ich mal ab.
Ich habe 20% als Referenzpunkt festgelegt und einmal vom komplett geöffneten und einmal vom komplett geschlossenen Rollladen angefahren. Die Anfahrpunkte liegen ca 20cm auseinander. Gut, der gemeinsame Punkt muss dann in der Mitte der beiden liegen und habe diesen markiert. Nun habe ich mich iterativ mit driveDown und driveUp an diesen gemeinsamen Punkt angenähert. Das Ergebnis ist nun driveDown=19s und driveUp=25s. Super, Problem gelöst. Vonwegen! Die 19s reichen nicht den Rollladen komplett zu schließen  :o Es bleiben immer ein paar Lammellen geöffnet.

EDIT: Mit den Einstellungen 19s und 25s haben noch einen weiteren Punkt angefahren. Auch er wird ziemlich genau getroffen. Zumindest die Vorgehensweise scheint für leichtere Rollläden (meiner hier ist 3,5mx1,2m) korrekt zu sein.

etwas gefrustet
walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

frank

ZitatEDIT: Mit den Einstellungen 19s und 25s haben noch einen weiteren Punkt angefahren. Auch er wird ziemlich genau getroffen.
dann ist wohl dein fenster zu hoch.  8)

ist die funktion von martin, oder fhem unabhängig?
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

wkarl

Meines Wissens errechnet der Actor über driveUp bzw driveDown den Anfahrtspunkt. Das Problem liegt damit in der Firmware.

ciao walter
FHEM 5.7 & TabletUI 2.2 auf Fedora22 Server auf NUC5i5RYK
CUL 868 > FAST EnergyCam
HMLAN > HomeMatic TCs & VDs, Bewegungsmelder, Schalter, Taster, Steckdosen

martinp876

der Rollo kennt nur Zeiten. Alle Stellungen werden aus diesen errechnet. Falls der Motor schneller hoch oder runter fährt kann man das berücksichtigen.

Ein Problem gibt es somit bei Rollos - insbesondere "dicke" und lange. Der Motor fährt eine konstante rotationsgeschwindigkeit - ist die Rollotrommel voll, fährt der Rollo schneller (eine Umdrehung ist mehr "meter" auf der Geraden).

Der Rollo fährt also "oben" generell schneller als unten.
90% ist also "mehr cm" nach unten als "10% nach oben" - systembedingt.

Jalousien sollte das ziemlich egal sein - die Änderung ist wohl vernachlässigbar. Jedoch ist hier das Wenden der Lamellen wiederum ein Problem. Man müsste eigentlich Höhe und Neigung eingeben.

Probleme kann es geben, wenn die fahrzeiten nicht korrekt eingetragen sind und man an das Ende kommt.

Ob es auch Fehler gibt durch schalten - also dass der motor ein paar hundertstel zum Anfahren braucht - ist mir nicht bekannt, aber möglich.

justme1968

ich meine mich zu erinnern das hier im forum ein codeschnippsel versteckt ist in dem jemand die unterschiedlichen fahrwege anhand der aktuellen position korrigiert und bei sochen problematischen rolläsden eine sehr viel bessere genauigkeit erhalten hat als nur rein zeit basiert. ich finde es aber gerade nicht. vielleicht hast du mehr glück wenn du suchst.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

sash.sc

Dieser Codeschnippsel zur Korrektur würde mich auch interessieren !
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb