Knallt es dann?
Nein. Die Shelly sind intelligent genug, nur einen der beiden Ausgänge zu aktivieren.
Hab's gerade (mit einem ShellyPlus2pm) ausprobiert: Wenn der 'ab' Schalter eingeschaltet ist und die Jalousie fährt gerade, schaltet der per WLAN aktivierte 'auf' Schalter den 'ab' Motor aus, bevor er den 'auf' Motor einschaltet.
Ich habe mehre Shelly1 in Wechselschaltungen so verbaut, wie in diesem Anschlussdiagrammdargestellt. Da es keine Spar-Wechselschaltung ist, muss lediglich beachtet werden, dass der Shelly in der Dose sitzt, von der die geschaltete Phase zum Verbraucher geht.
'Nach außen' ist keine Veränderung sichtbar, d.h. beide Schalter sind vorhanden und wie vorher bedienbar.
Für die Ersteinrichtung des Shelly musst du ja sowieso (z.B. per Handy ) über seinen Access-Point gehen, der im Werkszustand aktiv ist (IP-Adresse ist 192.168.33.1). Und so wird man die Shellies einen nach dem anderen einrichten. Aber wie du sie dann ohne WLAN im Haus sinnvoll einsetzen willst, ist mir nicht klar.
Gelegentliche WLAN Ausfälle sind natürlich kein Problem. In der Zeit sind sie halt nur nicht ‚smart‘, die Schalter funktionieren weiter.
Die Plus2PM hat eine Beta bekommen die die Lamellenstellung wie bei der Gen3 bietet.
Danke! Habe das jetzt nach einigen Verständnisproblemen auch a) gefunden und b) hinbekommen.
Damit ist meine Bastellösung obsolet. (Das Bastewln hatte trotzdem Spaß gemacht...)
Sorry, meine Bl[in|ö]dheit: Hab immer nur unter Settings gesucht, aber nie auf den Kanal geschaut, geschweige denn geklickt.
Bin halt fast nie über das WebUI unterwegs (und mit der App sowieso nicht)
Dank an alle.
Ah, man braucht die Shelly-App? Ich hab immer nur das Webinterface zum konfigurieren benutzt, da taucht der Punkt nicht auf. Steuern mach ich über FHEM. (Will nicht für jede Hardware-Familie ne eigene App nutzen müssen).
Wo finde ich denn die mqtt/rpc Doku? Da war ich auf der offiziellen Shelly Seite noch nicht fündig.
Danke jedenfalls!
Das hatte ich probiert. Aber bei mir sehen die Menüs nach dem Update auf firmware 1.5.0 beta1 genauso aus wie vorher. Von Kippsteuerung nichts zu finden. Muss man da noch irgendwo was aktivieren?
Bei mir sehen die Menüs nach dem Update auf firmware 1.5.0 beta1 genauso aus wie vorher. Von Kippsteuerung nichts zu finden. Und alles auf Englisch übrigens.
Hi, ich möchte die 2pm Gen 3 für Raffstores einsetzen.
Soll ich besser kombinierte Hoch/Runter Taster oder Schalter (geteilter Schalter, gegenseitige Verriegelung) verwenden?
Für Rollos waren Schalter ja okay, aber bei den Raffstores bin ich mir nicht sicher. Kleine Winkeländerungen sind mit Tastern leichter einzustellen?
Aber wie verfahre ich den Raffstore dann schnell, reicht hier ein Antippen?
Kann mir jemand das Bedienkonzept von Raffstores mit Taster und dem Shelly 2pm Gen3 erklären?
Hallo!
Ich bin gerade in diversen Foren unterwegs um zu sehen, ob es Neues bei den Shellies gibt. Habe selbst vor 1,5 Jahren erstmals ein Shelly Plus 2pm eingesetzt, neben schon länger benutzten Homematic Schaltern für 4 andere Raffstores.
Zu Deiner Frage (kombinierte Hoch/Runter Taster oder Schalter (geteilter Schalter, gegenseitige Verriegelung?): ich hatte bauseits einen geteilten Schalter mit gegenseitiger Verriegelung und habe dann den Shelly in der Dose dahinter verbaut (bisschen frickelig, ging aber).
Das manuelle Bedienen ging vorher und nachher gleich gut, alles lässt sich sehr exakt einstellen. Das jetzt ein Shelly dahinter sitzt merkt keiner, und das ist erstmal gut so. Ich würde also an Deiner Stelle diese mechanisch gegenseitig verriegelt Bedienung nehmen. Ist auch WAF-mäßig optimal, m.M.n.
Die programmierte Steuerung mache ich über MQTT in FHEM. Und jetzt das allerbeste: ich habe dem Shelly beigebracht, auch die Lamellenwinkelsteuerung zu übernehmen, und alles kann auch vom Handy super bedient werden. Man muss also nicht unbedingt die Gen3 hardware kaufen, die das jetzt angeblich kann (aber siehe hier). Gen2 kann das genauso gut, und ich finds eigentlich ein bisschen frech von den Shellisten, den Leuten jetzt zu erzählen, dass sie sich wieder was Neues kaufen müssen, um die Winkel anzusteuern (nachdem ursprünglich angekündigt war, dass Gen2 das nach firmware update auch können soll).
Natürlich ist meine Lösung erstmal nur etwas für bastel-affine Leute, aber ich will damit sagen, dass die hardware das prinzipiell kann, und dass ich persönlich nicht verstehe, warum die Shelly Ingenieure dass angeblich nicht hinkriegen.
Ich habe gerade mein Shelly Plus 2pm (2.Gen) auf die 1.5.0 beta aktualisiert. Wo finde ich denn die 'Kippsteuerung'? Oder gibt es die nur bei 3.Gen Geräten?
(Dann wäre aber der thread in diesem thread-Pfad SHELLY->SHELLY RELAIS 2.GEN->Shelly PLUS Line->Shelly PLUS 2PM an der falschen Stelle)
Ich habe im Web-Interface eines Shelly Plus 2pm (cover mode) unter 'Diagnostics' das 'Enable Debug Logs' geklickt, nur um dann später irgendwo in den Shelly Dokus zu lesen, dass man sich gut überlegen solle, das zu tun, da es Nachteile hat (z.B. Lebensdauer des Flash-Speichers wird verkürzt).
Ein 'Disable Debug Logs' button taucht aber nirgendwo auf.
Was ist der Weg, das 'Debug Logs' zu deaktivieren?
Gefunden habe ich dann (nach etwas Suchen) den Befehl http://192.168.188.208/rpc/Sys.SetConfig?config={"debug":{"level":0}}
Damit scheint das Debuggen in der Tat zu stoppen.
War das nun richtig, oder habe ich den 'Disable Debug Logs' button irgendwo übersehen?
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
Ticket beim Hersteller 🤗
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:
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?
Hast Du die action Befehle mal zum Test in einem browser eingegeben? Funktionieren sie da?
--Sorry, war zu langsam, SebMai war schneller --
FHEM (auf Raspberry)
Homematic (mit FHEM und pivCCU)
ESPEasy (mit FHEM)
Shelly (mit FHEM/MQTT)
SmartVISU (als FHEM FrontEnd)
MotionEye (auf Raspi W Zero)
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).
