Korrekter Status FSB61 bei lokaler Bedienung "open_ack"

Begonnen von TOtto, 13 Mai 2018, 20:56:36

Vorheriges Thema - Nächstes Thema

TOtto

Das Thema "open_ack" mit den Eltako Rolladenaktoren wurde schon mehrfach angesprochen und vielleicht etwas umständlich mit DOIF gelöst.
Grundsätzlich wird der Status versendet wenn länger nach oben gefahren wird, als die am Aktor per Drehschalter eingestellte Zeit oder eben beim hochfahren am lokalen Steuereingang. Damit befindet sicher der Aktor sicher in Position "0". Deshalb wäre es doch einfacher das Problem in 10_EnOcean.pm direkt zu lösen (grüne Zeile):
...
    } elsif ($st eq "manufProfile" && $manufID eq "00D") {
      # Eltako shutter
      if ($db[0] == 0x70) {
        # open
        push @event, "3:position:0";
        push @event, "3:anglePos:" . AttrVal($name, "angleMin", -90);
        push @event, "3:endPosition:open_ack";
        $msg = "open_ack";
      } elsif ($db[0] == 0x50) {
        # closed
        push @event, "3:position:100";
        push @event, "3:anglePos:" . AttrVal($name, "angleMax", 90);
        push @event, "3:endPosition:closed";
        $msg = "closed";
...

Vermutlich muss der rote Teil ebenso ergänzt werden, damit bei Lamellenrollos der Winkel richtig ist (kann ich aber nicht testen).
Mir fehlt leider der Überblick zu dem Modul um Nebenwirkungen zu beurteilen.

Kann die Änderung so übernommen werden?

Grüße
Thomas

hexenmeister

Da wäre ich seher dafür! :)
und wenn man noch die Motoranlaufzeit einstellen könnte...  ::)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

klaus.schauer

Ich kann sehr gut nachvollziehen, dass die Auswertelogik für die Eltako Rolloaktoren zur Berechnung der Lage und Wickelstellung nicht optimal ist. Mehr ist aber nicht herauszuholen, leider. Wie ich schon mehrfach in den letzten Jahren beschrieben habe, gibt es Nebenwirkungen zwischen den unterschiedlichen Versionsständen.

Ich empfehle deshalb immer wieder auf andere Produkte auszuweichen z. B. von AWAG oder PEHA, die andere EEP verwenden und brauchbare Rückmeldungen zur Lage und Wickelstellung liefern. Bei mir leisten die Aktoren von AWAG seit Jahren hervorragende Dienste.

TOtto

Das Eltako das Verhalten über die verschiedenen Versionen ändert habe ich auch schon festgestellt. Da ich diese bereits habe, muss ich versuchen damit zurechtzukommen. Den Anspruch auf eine exakte Stellung habe ich mit den Aktoren schon aufgegeben. Aber zumindest die obere Endlage sollte korrekt von fhem übernommen werden, wenn diese als Status vom Aktor versendet wird. Nichts anderes würde diese Änderung machen.

Es kann dann auf Lösungen wie unter https://forum.fhem.de/index.php/topic,87316.0.html beschrieben verzichted werden.

M@ik

Zitat von: thomas.otto am 14 Mai 2018, 21:27:03
Das Eltako das Verhalten über die verschiedenen Versionen ändert habe ich auch schon festgestellt. Da ich diese bereits habe, muss ich versuchen damit zurechtzukommen. Den Anspruch auf eine exakte Stellung habe ich mit den Aktoren schon aufgegeben. Aber zumindest die obere Endlage sollte korrekt von fhem übernommen werden, wenn diese als Status vom Aktor versendet wird. Nichts anderes würde diese Änderung machen.

Es kann dann auf Lösungen wie unter https://forum.fhem.de/index.php/topic,87316.0.html beschrieben verzichted werden.
Hallo,
das mit der korrekten Positionsmeldung bei den Eltako-Aktoren ist sich nicht ideal. Ich habe dies nun mit dem DOIF gelöst und es funktioniert ganz gut. Klar nicht zu 100% genau, aber für meine Ansprüche ausreichend.

Gruß, M@ik

hexenmeister

Ich würde ja gerne auch einen anderen Aktor nehmen, jedoch brauche ich etwas für den RS485 Bus und auf Hutschiene. EnOcean-Funk verwende ich nicht. Da bleibt mWn nur FSB14.
Welche Nebenwirkung kann denn das Setzen von Position auf 0 bei open_ack haben?
Wie aufwendig wäre es, Motoranlaufzeit-Einstellung einzubauen? Meine Velux-Motoren werden über Polwender im Testmodus verwendet (um den doofen Steuergerät loszuwerden) und brauchen über eine halbe Sekunde, bis sich was bewegt. Wäre ja auch egal, aber wenn man 2-3 Mal Position ändert, ohne ganz nach oben oder unten zu fahren, stimmen die Werte soweit nicht, dass es keine sinnvolle Steuerung über FHEM mehr möglich ist, bevor man Endpunkte anfährt :(
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

M@ik

@Klaus
Was könnten die Nebenwirkungen sein? Die du oben angesprochen hast?

Gruß, M@ik

klaus.schauer

Die vorgeschlagene Ergänzung habe ich eingearbeitet. Sie wird aber nur wirksam, falls das neue Attribut
attr <device> model Eltako_FSB_ACK
gesetzt wird. Bitte mit Entwicklerversion testen, siehe Anlage.

hexenmeister

Eine gute Idee, die Einstellung gefahrlos für alle zur Verfügung zu stellen. Danke, werde ich testen :)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

TOtto

Vielen Dank für die Änderung. Kann ich bei mir bestätigen.

Dazu noch eine grundsätzliche Frage:
Der Eltako-Aktor versendet nicht nur den Status "open_ack" $db[0] == 0x70 bei erreichen der Endposition. Weshalb gibt es nicht eine ähnliche Logik "closed_ack" bei versenden von $db[0] == 0x50. Damit wäre eine Unterscheidung möglich, ob die Postion des Rolladen über die Fahrzeiten ermittelt wurde (und damit zumindest bei Eltako fehlerbehaftet ist) oder ob der Aktor aktiv eine Endlage bestätigt hat.