Beiträge von marwis

    Mal schaun....

    OK, ich bin bisschen weiter gekommen, aber ne Lösing ist es nicht wirklich, was ich da gemacht habe, da es nicht wirklich mit 0.1 sev timing-Auflösung arbeitet (Motor Indktivität oder was auch immer.)

    Zunächst einmal. es stimmt nicht, wie von mir weiter oben behauptet, dass duration in Verbindung mit go nicht geht. Nur muss der richtige Befehl lauten: http://192.168.179.xxx/rpc/Cover.Open?id=0&duration=0.4 (das es sich beim ShellyPlus 2m um ein Gen2 device handelt. Und natürlich geht es auch mit MQTT statt http request.

    Für die, die sich mit FHEM auskennen: DIe Lösung, die ich umgesetzt habe, ist im FHEM Forumsbeitrag https://forum.fhem.de/index.php?msg=1281701 beschrieben. Bei Fragen bitte gern dort weiter diskutieren.

    Gruss Franz

    Ich hab es vor 2 Tagen als Ticket #46483 gemeldet. Bisher noch keine Antwort.

    Ich bin gerade dabei, mittels FHEM (und MQTT) die Lamellenwinkelsteuerung zu implementieren. Das scheint im Prinzip aussichtsreich, da in der 1.0.0-beta5 firmware auch Parameter wie status_last_direction und status_move_timeout geliefert werden. Der Name des letzteren ist etwas irrführend, denn er liefert anscheinend die Dauer der letzten Motoraktivierung. Mit den Informationen kann man dann denn Lamellenwinkel sozusagen 'mitkoppeln' und damit die Winkelsteuerung implementieren.

    (Für diejenigen, die sich mit FHEM auskennen, hier die Definition des entsprechenden userreadings:

    Code
    slat_angle:status_move_started_at.* {
    my $angle_now   = ReadingsVal("$NAME","slat_angle",0);
    my $movedir     = ReadingsVal("$NAME","status_last_direction",""); 
    my $movetime    = ReadingsVal("$NAME","status_move_timeout",60); 
    my $slatchange = 100*$movetime/AttrVal("$NAME","full_slat_time",1); 
    min(100,max(0,$angle_now + ($movedir eq "open"?1:-1) * $slatchange));
    }

    Das device-attribut full_slat_time ist die vom Nutzer zu ermittelnde Gesamtzeit für eine Lamellendrehung. Die Implementierung des entsprechenden Befehls "set <device> slat_angle <xxx>" gehe ich als nächstes an.)

    Das große ABER dabei: im Moment kann die beta firmware nur Fahrschritte in Einheiten von 1% auf der 0-100% Skala ausführen. Bei meinem Test-Raffstore ist die Gesamtfahrzeit ca. 50 sec, also habe ich nur 0.5 sec Auflösung für den Winkel, bei einer gesamten Lamellendrehzeit von ca. 1.6 sec. Das ist besser als nix, aber immer noch viel zu grob.

    Mit dem duration Parameter im http-request hätte man 0.1 sec Auflösung. Ich hoffe, dass er in der 1.0.0 firmware nicht nur erhalten bleibt, sondern auch über einen entsprechenden MQTT Befehl verfügbar ist.

    Noch besser wäre natürlich, die Winkelsteuerung direkt in der firmware für alle Nutzer zur Verfügung zu stellen. Dass es gehen müsste, zeigen ja die obigen Überlegungen.

    Ich werde dafür ein feature-request auf allterco loslassen und die Nummer dann hier einstellen.

    Mal schaun....

    Moin Bruno!

    Ich habe heut einen ShellyPlus2pm erfolgreich installiert, um ein Raffstore zu steuern. Für die Feineisntellung des Winkels (die von allterco leider immer noch nicht unterstützt wird) habe ich Deine HTTP-requests getestet.

    Mit http://192.168.179.xxx/roller/0?go=open kann ich in der Tat den Raffstore fahren, aber bei http://192.168.179.xxx/roller/0?go=open&duration=0.4 bekomme ich die Meldung "Use offset or duration, not both!". Das ganze getestet mit firmware 1.0.0-beta5.

    Vielleicht hast Du eine Idee?

    Edit:

    Hab jetzt auf firmware 0.14.1 ge-backdated. Da funktioniert es.

    Scheint ein Fehler in der neuesten Beta zu sein.

    Zusatzfrage: Wie gebe ich solche Rückmeldungen am besten an die Entwickler?

    Die Quintessenz dieses threads ist für mich:

    1. ein vernünftiger Betrieb von Raffstores mit dem Shelly 2.5 Shutter-Modus scheitert an

    a) Latenzzeiten, die eine Winkeleinstellung über die manuellen Schalter bis zur Nutzlosigkeit erschweren

    b) zu geringer Zeitauflösung bei automatischem Betrieb, so dass keine zuverlässige Winkeleinstellung erreicht wird

    2. im Relais-Modus ist ein vernünftiger Betrieb möglich, erfordert aber Programmierarbeit vom Anwender

    Ich würde Weg 2 gehen, wenn im Relais-Modus auf firmware-Ebene ein gleichzeitiges Aktivieren beider Relais verhindert wird, z.B. durch einen konfigurierbaren Interlock, der von Allterco aber implementiert werden müsste. Ich habe einen entsprechenden 'feature request' an shelly-support geschickt. Mal sehen, was passiert (ich fürchte jedoch, das nichts passiert).

    Da die Hoffnung aber zuletzt stirbt:

    Gibt es aus Sicht erfahrener Nutzer Argumente, die bei Vorhandensein eines Interlocks gegen den Relais-Mode für Rollladenmotoren sprechen?

    P.S.:
    Wieso ist dieser thread eigentlich als 'erledigt' markiert?

    Hat hier vielleicht jemand den Homematic Jalousie Aktor und kann berichten, wie das dort gelöst ist? Das soll dort prima funktionieren, Shelly müsste eigentlich nur deren Logik dann 1:1 kopieren.

    Ich nutze vier HM-IP BBL Jalousieaktoren für die Steuerung von Raffstores. Softwareseitig funktionieren sie hervorragend, allerdings musste ich die vorhandenen Up-Down Schalter durch einen Wipptaster ersetzen. Das war WAF-mäßig suboptimal, da die Winkelverstellung mit einem Up-Down Schalter reproduzierbarer und damit einfacher ist: Man lässt die Finger auf dem Schalter und kann dann sofort stoppen, wenn innerhalb der ca. 2 sec Lamellenkippzeit der richtige Winkel erreicht ist. Bei einem Wipptaster muss man zwischendurch kurz loslassen, das machts träger. Alternativ (das ist die 'offizielle' Homematic Empfehlung) kann man zwar durch langen Tastendruck die Lamellen in einer Art "Stotterbetrieb" verstellen und loslassen wenn's OK ist. Das braucht aber immer mind. 2 Versuche bis der Winkel stimmt. WAF-Minderung!

    Aber die Frage war ja, wie Homematic das gelöst hat. Nun ja, ganz einfach: Sowohl die Gesamtfahrzeiten (getrennt für Rauf und Runter) als auch die Lamellenkippzeit kann man mit 10 msec Auflösung angeben (oder durch eine Kalibrierfahrt ermitteln lassen).