Falsches position-reading nach Start/Stopp per Funkschalter

[dw82]

Hallo,

zwecks Rollladenelektrifizierung habe ich ein Eltako FAM14 mit einigen FSB14 und EnOcean Funkschaltern in Betrieb genommen. Der FHEM-Rechner ist per FGW14 an den Eltako-RS485-Bus angebunden. Im Prinzip klappt alles auch ohne Probleme. Die Konfiguration des FSB14 entspricht exakt den Wiki-Angaben, also

define Rollladen EnOcean <Busadresse>
attr Rollladen IODev FGW
attr Rollladen  devStateIcon ...
attr Rollladen  eventMap ...
attr Rollladen  manufID 00D
attr Rollladen  model FSB14
attr Rollladen  room Rollläden
attr Rollladen  shutTime 28
attr Rollladen  shutTimeCloses 34
attr Rollladen  subDef <in FSB14 eingelernte Adresse>
attr Rollladen  subType manufProfile
attr Rollladen  webCmd ...

und FHEM wurde soeben per "update" nochmal auf die neueste Version gebracht.
Wenn ich nun einen Rollladen per Funkschalter starte und anschließend vor Erreichen der Endlage wieder stoppe, erkennt FHEM dank Bestätigungstelegrammen auch zuverlässig, dass zunächst der Rollladen gestartet und dann wieder gestoppt wurde und zeigt das im state-reading korrekt an. Allerdings wird nach dem Stoppen das position-reading nicht korrekt geupdatet. Mal gibt's gar kein Update, mal ändert sich der Wert zu wenig, mal zu viel und manchmal sogar in die falsche Richtung.
Wenn ich hingegen den Rollladen per FHEM starte und stoppe, wird das state-reading korrekt geupdatet. Mir ist ferner aufgefallen, das beim Starten des Rollladens per FHEM das state-reading während der Fahrt auf 0 (auf) bzw. 100 (ab) springt, während es sich beim Steuern per Funkschalter, wenn überhaupt, nur beim Stoppen verändert.
Der Fehler passiert daher vermutlich beim Starten per Funkschalter (bzw. genauer gesagt beim Auswerten des Bestätigungstelegramms des FSB14). Dafür spricht insbesondere, dass das state-reading auch korrekt geupdatet wird, wenn ich per FHEM starte und per Funkschalter stoppe, umgekehrt hingegen nicht.
Hat jemand eine Idee, wo der Fehler liegen könnte. Oder ist FHEM schlichtweg nicht in der Lage, das position-reading auf Basis von Bestätigungstelegrammen korrekt zu updaten?

Vielen Dank.

[klaus.schauer]

Die Position kann nur dann "richtig" berechnet werden, wenn die Fahrbefehle über Fhem erfolgen. Aus den Quittungstelegramme lassen sich nur begrenzte Rückschlüsse auf de Position ziehen. Im Forum wurden schon mehrfach "Speziallösungen" diskutiert. Vielleicht ist eine der Lösungen für den beschriebenen Anwendungsfall brauchbar.

Von der Firma AWAG http://www.awag.ch/ gibt es einen Rolloaktor, der das EEP D2-05-00 nutzt. Bei diesem EEP erfolgt eine korrekte Rückmeldung der Position.

[dw82]

Dass position-reading und Rollladenposition die Synchronisation verlieren können, wenn der Rollladen angesteuert wird, wenn er bereits am Endanschlag ist, ist klar. Allerdings muss es ja programmatisch möglich sein, wenn ein Bestätigungstelegramm nach Rollladenstart kommt, dies genauso zu behandeln, als wenn der Rollladen per FHEM gestartet wurde.
Ich habe mir daher mal die "10_EnOcean.pm" Source-Datei angeschaut  und ein paar Debug-Ausgaben gemacht. Dabei ist mir aufgefallen, dass es einen Code-Abschnitt zum Updaten der Position gibt, der jedoch bei Bestätigungstelegrammen, bei denen die EnOcean_get Funktion mit "?" als cmd-Parameter aufgerufen wird, bisher nicht ausgeführt wird. Nachdem ich das durch Auskommentieren einer if-Abfrage geändert habe, funktioniert es nun einwandfrei. Allerdings klappte danach das Positionsupdate nach Ansteuerung mit FHEM nicht mehr. Nachdem ich jedoch nun die Code-Zeilen auskommentiert habe, die das merkwürdige Springen des position-readings auf 0 bzw. 100 bei Ansteuerung durch FHEM ausgelöst haben, klappt nun alles einwandfrei, wie ich es mir vorstelle.
En Detail habe ich mir den Code natürlich nicht angeschaut, da er ziemlich umfangreich ist, und vielleicht funktioniert der Code durch diese Änderung in anderen Szenarien nicht mehr. Da es aber vielleicht doch ein Bug sein könnte und Sie ja der Maintainer der "10_EnOcean.pm" Source Datei sind, habe ich mal meine Änderungen in den Anhang gepackt.

[klaus.schauer]

Die Änderungen haben leider Nebenwirkungen. Der Aktor sendet, z. B. je nach Einstellung der Laufzeit in Fhem und dem Gerät selbst, die "Stop"-Meldung nicht zuverlässig. Deshalb werden die readings "position" teilweise unabhängig davon gesetzt. Die "?" if-Abfrage wird benötigt, damit beim Aktualisieren der Benutzeroberfläche die letzten Positionsdaten nicht überschrieben werden.

Die Positionsberechnung ist teilweise sehr trickreich und leider nicht perfekt, da die Rückmeldungen des Aktors, die auch noch mit dem Herstellungsdatum variieren, nicht brauchbar sind. Ich habe deswegen der halbwegs richtigen Anzeige der Fhem-Steuerbefehle den Vorrang eingeräumt, ein Kompromiss eben.