[patch] Korrekter Status FSB61 "closed" statt "stop" bei position=100

[jensb]

Hallo,

mein Eltako FSB61 Rollladenaktor hat beim Zufahren mit Ansteuerung über FHEM als state statt "closed" immer nur "stop" geliefert. Ein paar provisorische Debug-Logs haben gezeigt, dass in der sub EnOcean_Parse die neu berechnete position beim Anhalten wie gewünscht exakt 100 ist, da shutTimeStop und shutTime gleich sind.

Damit man in diesem Zustand "closed" als neuen Status erhält, sollte wie bei "open" vorgangen werden und in Zeile 9961 der aktuellen Modulversion noch ein "=" spendiert werden. Im Ergebnis sieht das dann so aus:

Code Auswählen Erweitern


9961            if($position >= 100) {
9962              $anglePos = $angleMax;
9963              $position = 100;
9964              push @event, "3:endPosition:closed";
9965              $state = "closed";
9966            } else {
9967              push @event, "3:endPosition:not_reached";
9968              $state = "stop";
9969            }


Ich schlage diese Änderung als Bugfix für das Modul vor. Falls mein Problem aber eine andere Ursache hat, würde ich mich über einen Hinweis freuen.

Grüße,
Jens

[klaus.schauer]

Danke für den Tipp; wird geändert.

[Johnnyflash]

Ich würde es begrüßen, wenn in diesem Zuge die Funktionen "up" und "down" für Eltako Aktoren mit settingAccuracy == 1 auch in 1/10 Sekunden Schritten angefahren werden können. Nur so wird eine feinfühligere Verstellung der Lamellen erst möglich, da ja genau diese Funktionen durch den Timer

Code Auswählen Erweitern

my @timerCmd = ($name, "up", $angleTime); aufgerufen werden. Eine mögliche Modifikation der regex hatte ich ja bereits vorgeschlagen:

Code Auswählen Erweitern

if ($a[1] =~ m/^[+-]?\d*[.]?\d+$/ && $a[1] >= 0 && $a[1] <= 255) { Oder spricht etwas gegen diese Änderung?

[jensb]

@klaus.schauer

Danke für die schnelle Rückmeldung und die viele Arbeit, die schon im EnOcean-Modul steckt!

Grüße,
Jens

[klaus.schauer]

Ich würde es begrüßen, wenn in diesem Zuge die Funktionen "up" und "down" für Eltako Aktoren mit settingAccuracy == 1 auch in 1/10 Sekunden Schritten angefahren werden können. Nur so wird eine feinfühligere Verstellung der Lamellen erst möglich, da ja genau diese Funktionen durch den Timer

Code Auswählen Erweitern

my @timerCmd = ($name, "up", $angleTime); aufgerufen werden. Eine mögliche Modifikation der regex hatte ich ja bereits vorgeschlagen:

Code Auswählen Erweitern

if ($a[1] =~ m/^[+-]?\d*[.]?\d+$/ && $a[1] >= 0 && $a[1] <= 255) { Oder spricht etwas gegen diese Änderung?

Wird entsprechend geändert.

[Johnnyflash]

Vielen Dank!

[ch.eick]

Hallo zusammen,

ich habe da auch noch etwas, was mir Probleme bereitet.

FHEM ist auf dem aktuellsten Stand.

Ich betreibe Eltako_FSB61 mit Rollos und habe mit dem Anfahren von bestimmten Positionen eine gewisse Ungenauigkeit.

Meine Istsituation:

1) es sind alle FSB61 im FHEM angelernt.
2) Die Fahrzeit ist am FSB61 mit dem Regler eingestellt, dass es korrekt rauf und runter fährt.
3) Mit einem lokalen Taster fährt das Rolle sauber von Anschlag bis Anschlag und die Zeit vom Regler läuft nahezu gleichzeitig ab.
    Es ist nach dem Stop am Anschlag ein klick vom Relais zu hören.
4) Mit dem closes oder opens Parameter fährt das Rollo ebenfalls sauber bis in den jeweiligen Anschlag.

5) shutTimeCloses ist nahezu synchron mit dem Regler vom FSB61

Und jetzt meine Unstimmigkeiten:

shutTime ist kleiner oder gleich shutTimeCloses

1) Wenn das FSB61 mit "position 0" fährt, fährt es nicht bis in den Anschlag, so wie bei opens
2) Mit "position 100" fährt das Rollo von Oben die entsprechende shutTime

Gibt es eine Einstellmöglichkeit, so dass die Fahrt mit Positionsansteuerung besser passt?

Ich könnte mir vorstellen, dass im EnOcean Modul für das FSB61 bei Ansteuerung von Position 0 oder 100 eine Umsetzung auf closes/opens erfolgt.
Hierdurch würde das Rollo dann garantiert bis in die Endpositionen fahren. Das würde dann einige Ungenauigkeiten kompensieren.

Meine Fahrten von der oberen Endposition nach 50% und die Fahrt von der unteren Endposition nach 50% trifft sich schon ziemlich genau an der selben Stelle. Das habe ich mit der shutTime angleichen können. Für shutTime kann ich leider nur ganzzahlige Dezimalzahlen eintragen.

Wird z.B eine Fahrt über folgende Punkte gemacht:

1) obere Endposition
2) 50   <== hier markiere ich die Position
3) 100   <== hier passt die untere Endposition
4) 50   <== das passt mit dem markierten 50% Punkt schon recht gut
5) 0     <== Dann bleibt halt oben noch ein Rest des Rollos zu sehen.

Würde man nun die Ansteuerung von "position 0" im Modul umsetzen, dann würde es echt schöner aussehen.

Das ASC Modul, dass ich später nutzen möchte steuert das Rollo über die position oder pct Angabe, was man je nach device auswählen kann.
Somit würde mit position 100 voll geschlossen werden und mit position 0 voll geöffnet

Für Hilfe wäre ich sehr dankbar.

Viele grüße
    Christian

[jensb]

@ch.eick

Bin mir nicht sicher, ob es sich hier um ein technisches Problem oder ein Verständnisproblem handelt, wobei ich das eher als Anwender und nicht als Entwickler beurteile. Möglicherweise habe ich da auch etwas noch nicht richtig verstanden.

Bei einem Rollo meinen sicherlich viele mit der Position die der Unterkante, also der untersten Lamelle. Wenn die Unterkante unten angekommen ist, ist aber bei vielen Rollos das Rollo noch nicht zu, aber die Position ändert sich nicht mehr. Deshalb gibt es auch die beiden Attribute shutTime und shutTimeCloses. Man kann also mit dieser Betrachtung ein Rollo über die Position nicht ganz zufahren.

Anders sieht es aus, wenn man mit der Position die der obersten Lamelle meint. Dann ist das Rollo sehr wohl bei Position 100 ganz zu. Allerdings ist es dann die Unterkante bei Position 50 nicht auf halber Höhe.

Im Endeffekt beobachte ich die gleiche Verhalten, dass du beschreibst. Normalerweise fahre ich aber immer von open oder close auf eine Position und dann zurück. Dadurch wirkt sich das Problem nicht aus.

Soweit ich weiß, wird der FSB61 von FHEM über einen Zeitanteil von shutTime/shutTimeCloses auf eine Position gefahren. Allerdings könnte man den eventuelle Unterschied zwischen den beiden Attributen zusätzlich auswerten, indem man neben der Position der Unterkante noch die Verschlusszeit bzw. den Verschlussfahrweg verwaltet. Wenn man sich aber in die Perspektive der Oberkante versetzt, sollte es keiner Änderung bedürfen.

Grüße,
Jens

[ch.eick]

Hallo Jens,

ich versuche es nochmal exakt auszudrücken.

Kommando Opens

Das Rollo befindet sich in der absoluten oberen Endposition des Motor Endkontaktes umd im FSB61 läuft die maximale Fahrzeit ab.
Dies sollte position 0 entsprechen. Die Fahrt zu position 0 wird jedoch als Fahrzeit berechnet und passt bei der "up" Fahrt nicht,
da ein Rollo durch das Gewicht länger nach oben benötigt.
Mein Vorschlag wäre in diesem Fall dem FSB61 nicht "position 0" sondern "closes" zu senden. Dadurch wäre eine Fehlerkorrektur gegeben.


Kommando closes

Das Rollo fährt bis in die Absolute Endposition des Motor Endkontaktes und im FSB61 läuft die die maximale Fahrzeit ab. Das Relais klickt kurz nach dem Motorstop.
Wird mit "position 100" gefahren, dann erreicht das Rollo durch das Eigengewicht (es geht schneller Zu als Auf) die Absolute Endposition.
Auch hier sollte es besser mit dem Kommando "closes" gefahren werden, da das die sicherere Methode ist.
Also im EnOcean Modul bei Kommando "position 100" durch "closes" ersetzen.

Im FSB61 device scheint die Berechnung durch "shutTime" und "shutTimeCloses" recht gut zu passen. Wenn jedoch die absoluten Endpositionen nicht stimmen, dann summieren sich die Fehlfahrten zu einer willkürlichen Rollo Position.

Bei meinen Tests passte zb. "position 50" von oben nach unten gefahren schon ziemlich exakt zu "position 50" von unten nach oben gefahren. jeweils aus den absoluten Endpositionen gefahren und an der untersten Lamellenkante gemessen. Da sag ich mal, besser geht's nicht.

Ich habe auch bereits im Modul angefangen die Code Stelle zu suchen und den Code zu verstehen (Ich bin kein Programmierer)

Update ich habe es bisher noch nicht geschafft, bei einem reload des original Moduls kommen auch schon perl Errors.

Code Auswählen Erweitern


Too many arguments for main::EnOcean_setPID at ./FHEM/10_EnOcean.pm line 2780, near "'')"
Too many arguments for main::EnOcean_setPID at ./FHEM/10_EnOcean.pm line 2799, near "'')"
Too many arguments for main::EnOcean_setPID at ./FHEM/10_EnOcean.pm line 2814, near "'')"
Too many arguments for main::EnOcean_setPID at ./FHEM/10_EnOcean.pm line 2838, near "'')"
Too many arguments for main::EnOcean_setPID at ./FHEM/10_EnOcean.pm line 2857, near "'')"
Too many arguments for main::EnOcean_setPID at ./FHEM/10_EnOcean.pm line 2871, near "'')"
Too many arguments for main::EnOcean_setPID at ./FHEM/10_EnOcean.pm line 2897, near "'')"
Too many arguments for main::EnOcean_setPID at ./FHEM/10_EnOcean.pm line 2916, near "'')"
Too many arguments for main::EnOcean_setPID at ./FHEM/10_EnOcean.pm line 2931, near "'')"
Too many arguments for main::EnOcean_setTeachConfirmWaitHash at ./FHEM/10_EnOcean.pm line 3223, near "$hash)"
./FHEM/10_EnOcean.pm has too many errors.


Und bei shutdown reload von fhem auch noch eine Meldung, die ich bisher nicht beseitigen konnte

Code Auswählen Erweitern


2019.04.27 17:39:14 2: EnOcean Cryptographic functions are not available.

Die folgenden libs sind installiert/aktuell
apt-get install libcrypt-rijndael-perl
apt-get install libcrypt-random-source-perl



Zusammenfassend ist es eine Gerätespezifische Korrektur für den FSB61.

Ich habe natürlich auch verstanden, dass position 50 nicht die Hälfte der Glasscheibe ist, sondern die Hälft der Fahrzeit von "shutTime".
Bisher habe ich auch nur mit "opens/closes" die Rollos gefahren, jedoch möchte ich jetzt noch eine Beschattung nach Sonnenstand integrieren.
Ach soll noch eine Sichtschutzposition für den Bade/Pool Betrieb integriet werden. IM ASC kann man ja auch noch vor dem totalen schließen eine
etwas geschlossene Position anfahren.

Viele Grüße
     Christian

[jensb]

Ob man Position 100 mit closes und 0 mit opens ersetzen kann wäre eine Frage an Klaus.

Wer die Postion feinstufig bidirektional ändern will, würde sich trotz dieser Anpassung mit der bisherigen Genauigkeit zufrieden geben müssen. Wie du selbst ausgeführt hast, wirken sich Schwerkraft und Reibung bei Auf und Ab unterschiedlich aus. Selbst wenn man für Auf und Ab unterschiedliche Fahrzeiten heranzieht und die hohe Zeitauflösung des FSB61 nutzt wird das nicht beliebig genau, da die Faktoren nicht konstant sein müssen. Ein Rollo hat halt keinen Positionsencoder - ohne den gibt es keine absoluten Positionen.

Grüße,
Jens

[ch.eick]

Hallo Jens,

vielen Dank für Deine Rückmeldung. Eventuell meldet sich Klaus ja noch dazu. Ich habe im Code die Position für meine Änderung noch nicht gefunden, oder durch die Error Meldungen beim reload wird mein Code nicht geladen. Ich bin halt kein Programmierer
Wenn ich sicher wäre, das mein Code geladen würde, könnte ich mich schon irgendwie durchhangeln und eine Änderung einbauen. Meine Debugging Meldungen ziehen jedoch leider nicht, oder sind an der falschen Stelle.

Viele Grüße
     Christian

[jensb]

Wenn du FHEM neu startest, wird immer das Modul geladen, dass im FHEM-Unterverzeichnis liegt. Ist allerdings ein Perl-Fehler im Code, wird das Laden nicht erfolgreich abgeschlossen und FHEM deaktiviert das Device. Die Fehlermeldungen, die in diesem Fall die Beim Neustart ins FHEM-Log geschrieben werden, können helfen, den Fehler zu finden und zu beheben.

Grüße,
Jens

[ch.eick]

Hallo Jens,

beim "shutdown restart" konnte ich keine Fehlermeldungen feststellen. Die Meldungen treten beim "reload" des Moduls auf. Ich möchte ja nicht bei jeder Codeänderung direkt das gesamte FHEM neu starten was bei meiner Konfiguration auf einem RPI 2 dann doch etwas länger dauert.
Somit bleibt mein Debugging issue noch bestehen und ich hoffe, das Klaus sich eventuell noch zu Wort meldet.

Viele Grüße
      Christian

[jensb]

Na dann hast du ja so auf jeden Fall deine Version aktiviert. Natürlich ist es unschön, wenn man ein Modul nicht mir reload aktualisieren kann. Aber mit einem "produktiven" FHEM zu entwickeln ist ohnehin nicht empfehlenswert. Falls du doch Spaß am Programmieren bekommst, solltest du dir noch eine Mini-Server zulegen - dafür habe ich den OrangePi.

Grüße,
Jens

[ch.eick]

Hallo jens,

man macht ja immer die gleichen Fehler, aber ich habe zumindest eine frische Datensicherung vorher gemacht. Normalerweise mach ich das in einer Solaris Zone, aber wie das immer so ist müsste man ja auch beides aktuell halten

Gruß
   Christian