Gerade entdeckt, dass es mit diesem Plugin mittlerweile funktioniert: https://github.com/cubi1337/homebridge-shelly-ds9
Allerdings wurden meine 2PMg3 zunächst nicht per mDNS gefunden. Nachdem ich auf diesen KNX aktiviert (und wieder deaktiviert, denn ich nutze das nicht) hatte, ging's dann aber auch mit mDNS.
Gibt's für den 2PM Gen3 schon eine Homekit-Anbindung?
Die mir bekannten Homebridge-Plugins unterstützen ihn noch nicht. Man könnte als Workaround ein generisches MQTT-Plugin nehmen, aber das wäre schon sehr mühsam manuell zu konfigurieren – und wer weiß, wie gut dass am Ende wirklich funktioniert. Oder hat das jemand schon mal durchgespielt und könnte die Zuordnung der ganzen Topics netterweise hier teilen?
So, jetzt habe ich auch endlich ein erstes funktionierendes 2PM Gen3 zum Testen. Erster Eindruck ist ganz gut, aber die Einstellungen noch etwas unklar:
Was bewirkt "precise slat position" (ein/aus)? Ich bemerke von dieser Einstellung keinerlei Effekt und in der Anleitung fehlt eine Beschreibung dazu. Weiß jemand was dazu?
Und meint "Step" das, was ich denke (bzw. wie ich die Anleitung interpretiere), also wenn hier z.B. "25" steht, dann geht es 4 Taster-Schritten zu 25% von 0% bis 100% Winkel (unter der Annahme, dass die richtigen Zeitspannen eingestellt sind, denn der Shelly kann ja den Winkel nicht messen)? Ich habe da mal 100% eingetragen und dann die Auf/Ab-Zeiten solange justiert, bis jeweils eine ganze Umdrehung für einen einzelnen Tasterdruck rauskam. Dann habe ich für die alltägliche Bedienung einen kleineren Wert eingestellt (10...20), damit man in mehreren Schritten verschiedene Winkel ansteuern kann. Das passt allerdings bei vielen kleineren Schritten nicht mehr so recht, da schießt es dann mit dem Winkel wieder übers Ziel hinaus, d.h. geht schon in die auf/ab-Bewegung über ... vermutlich, weil der Motor immer etwas nachläuft und nicht exakt symmetrisch anläuft?
Schließlich: Gibt es für das 2PM Gen3 schon ein kompatibles HomeBridge Plugin? Ich kriege da " [Shelly NG] [shelly2pmg3-xxxx] Unknown device of model "S3SW-002P16EU" discovered." angezeigt.
Neues Gerät ist da und geht problemlos.
Das Relais sollte hörbar schalten.
Die Schraubklemmen sind mit 0,4Nm Anzugsmoment vorgegben, das ist nicht viel und viele übertreiben das und dann ist die Lötverbindung hin..
Ich traue mir durchaus zu, die Lötverbindung der Klemme gelockert zu haben (wer hat schon einen so kleinen Drehmomentschlüssel), aber das erklärt ja leider nicht, wieso das Relais nicht mehr geht und wieso das Teil offline ging und nur durch Factory-Reset wieder zu beleben war.
Aber gut, ich schick's jetzt einfach zurück, leider hat es etwas Lieferzeit (bei amazon, aber anderswo zahle ich viel Porto für hin+her).
Das ein Eingang auf einen Schalter nicht reagiert oder dass das Relais die Spannung nicht mehr schaltet, kann vorkommen..Schraubklmmen zu fest angezogen und Lötverbindung getrennt.
Damit meinst Du jetzt aber die Lötverbindung der Klemme selbst, oder? Aber dann müsste ja das Relais noch hörbar schalten.
Weshalb der Shelly 2PM Gen3 etwas schwerer zu öffnen ist, als andere Shellies, ist hier zu lesen:
Oh, danke, genau diese Bilder hatte ich heute vergeblich gesucht, nachdem ich sie vor Wochen schon mal gesehen hatte. Ja, das wird dann wohl eher nichts mit dem Öffnen ohne sichtbare Spuren. Wenn dann drunter das Relais wirklich kaputt ist oder die Platine einen Riss hat, lohnt die Reparatur eh nicht ... soll ich da jetzt auf bloß eine schlechte Lötstelle hoffen? Ich neige doch eher zum Umtausch.
Habe heute meinen ersten 2pm Gen3 installiert, aber irgendwas ist dabei schiefgegangen ... alles angeschlossen an Taster und Jalousie, kurz getestet (mit der App neues Gerät konfiguriert), schien alles zu gehen, also Sicherung raus, dann den ganzen Krempel in die Schalter-Dose hineineingequetscht - und dann ging nicht mehr viel: Gerät war blieb nach Wiedereinschalten der Sicherung dauerhaft offline und nur noch der eine Taster löste sein Relais (Jalousie runter) aus, die andere Richtung ging nicht (mehr? Bin mir leider nicht 100% sicher, ob sie anfangs ging).
Also alles wieder rausgeholt, aber in der Verdrahtung war absolut kein Fehler zu finden (auch nichts abgerissen, was ja beim reinschieben gerne mal passiert ... es ist ja bei weitem nicht mein erster Shelly).
Mittlerweile habe ich ihn immerhin wieder online - dafür war ein Factory Reset nötig und dann natürlich neue Einrichtung. Aber es bleibt dabei, dass ich sowohl per Taster als auch per App nur das eine Relais zum klacken bringe (die Jalousie ist jetzt nicht mehr angeschlossen), das andere bleibt stumm. Egal ob Jalousie-Modus ("cover") oder als zwei Einzelgeräte.
Ich neige nun dazu, das Teil umzutauschen gegen ein neues ... Das Gehäuse geht leider nicht so leicht auf, um mal nach dem Rechten zu schauen, ohne Garantieansprüche zu verwirken (oder doch?). Deshalb hier meine eigentliche Frage: Ist der Defekt eines Relais schon bei Auslieferung häufig oder ein bekannter alter Hut?
Oder kann ich das tatsächlich erst selbst irgendwie bewirkt haben, alleine durch das Gezerre an den Kabeln und das Festziehen der Klemmen, also was halt so an rein mechanischem Stress auf das Ding so einwirkt in einer vollgestopften Dose? (Ich denke ja, sowas muss das Teil abkönnen)
Elektrisch gesehen wurde es definitiv nur korrekt betrieben (und auch nur ein paar Minuten), das ist sicher. Und falsche Einstellungen sollte es nach dem Factory-Reset ja keine mehr geben oder?
FW-Version ist die 1.4.99, also diese werkseitige, für die es noch kein Update gibt.
Irgendwelche Vorschläge, was ich vor oder statt dem Umtausch noch versuchen sollte?
Der oberste Link der verlinkten Google-Suche führt (zum aktuellen Zeitpunkt, das ist aber dynamisch) in der Tat genau im Kreis wieder hierhin zurück, ist also eher wenig hilfreich. Aber weiter unten findet sich z.B. der hier. Hier haben offenbar Leute die Winkelsteuerung schon benutzt, wenn auch mit Problemen bei der Zeitsteuerung. Ok, soweit so gut - dann ist es zumindest rudimentär schonmal vorhanden! 
Wie ist es mit der manuellen Steuerung per Taster? Das war mit dem 2.5 ziemlich dürftig, da er so träge reagiert. Da kriegt man höchstens ein bis zwei verschiedene Winkel hin, dann ist entweder ganz auf oder ganz zu. Ist das beim 2pm 3rd besser? (Ich meine gelesen zu haben, dass schon der ältere 2pm hier besser war, aber das alleine war mir nie den Versuch wert)
Im Ernst? Nachdem Shelly uns das Feature schon für die allerersten 2.5er jahrelang versprochen, aber nie geliefert hatte, und es jetzt zwei HW-Generationen später für den 2pm 3rd nun sogar schon explizit bewirbt, haben die das in der FW immer noch nicht fertig? Das wäre ein starkes Stück.
Hat jemand das Teil schon und kann mal zumindest in der Web-Oberfläche nachschauen (es setzt ja den 2pm nicht jeder für Jalousien ein, gibt ja auch andere Einsatzzwecke)?
Hat schonmal jemand mit dem neuen Teil die beworbene Steuerung des Lamellenwinkels bei Raffstores ausprobiert?
Ja, dieses BTHome - das ist in der Tat die gesuchte die BLE-API. Danke fürs Aufspüren!
Das mit dem Observer in der anderen API hatte ich gesehen, aber diese Formulierung dort
When enabled via the
observer.enableconfiguration flag, the device will run a constant passive Bluetooth LE scan and relay received advertisement packets to Shelly Cloud service, to enable scene triggers.
ist nicht 100% eindeutig, da sie sich ganz speziell auf die Weiterleitung von BLE Paketen an die Cloud bezieht. Die brauchen wir ja nicht (oder höchstens im Alarmfall). Das permanente Scannen wäre aber in der Tat erforderlich, nur eben keine besonders stromhungrige WLAN-Weiterleitung von beliebigen BLE-Paketen.
Wenn Du es konkret mit dem Smoke schon getestet hast, ist es dadurch aber abschließend geklärt.
(Vom Ergebnis her natürlich schade!)
Unter dem Link finde ich aber gerade nichts zum Bluetooth Interface. Da sind nur die IP-basierten Protokolle beschrieben (insbesondere hier https://shelly-api-docs.shelly.cloud/gen2/General/RPCChannels), soweit ich das sehe. Vielleicht bin ich aber auch nur zu blind, es zu sehen ...
Ob der Smoke das BLE (immerhin steht LE ja für Low Energy) wirklich komplett ausmacht - gibt es dazu schon gesicherte Erkenntnisse? Es gibt ja BLE-Scanner Apps fürs Handy, hat ein Smoke-Besitzer damit schonmal probiert, ob der "sichtbar" ist?
Ist die Bluetooth API eigentlich öffentlich dokumentiert? Konnte bislang nichts finden, auch generell nicht bei den BLE-fähigen Shelly, nicht nur Shelly plus smoke - aber bei dem wäre es wohl am interessantesten ...
edit by 66er:
unnötiges Vollzitat des letzten Beitrages entfernt. Bitte unterlassen, siehe Forenregeln
Ja, nur die spannende Frage ist, ob er das besser macht als der "original" Qubino Flush Shutter ZMNHCD1, mit dem ich es hier im Haus frustriert aufgegeben habe, irgendwas reproduzierbar zu steuern, v.a. mit den Tasten direkt am Schalter. Und den ich für ein FW-Upgrade ausbauen und einschicken musste ... danach gingen dann ein Feature besser und ein anderer schlechter ...
Also v.a. die beworbenen "Over-the-air Firmware-Updates" mit einem (beliebigen?) 3rd-party-Z-wave-Gateway würde ich gerne erstmal sehen, bevor ich da nochmal einen Versuch wage. Immerhin sind die Teile mit Shelly-Branding etwas billiger als die originalen damals.
Warum sollte es Neuigkeiten geben.
Weil Shelly es seit Jahren immer wieder "halb-öffentlich" für die jeweils nächste Version versprochen hat (z.B. in Antworten auf Feature-Request-Tickets usw). Es wäre ja auch in Ihrem ureigensten Interesse, das Anwendungsspektrum nochmal deutlich zu erweitern. Es muss irgendeinen Hardware-bezogenen Grund geben, dass sie es offenbar aufgegeben haben. Neue HW nährt daher neue Hoffnung.
Okay, das könnte funktionieren (hat dann aber natürlich diese leichte Verzögerung drin und ich kenne Leute, die hektisch zu schalten anfangen, wenn sich binnen 100ms nichts rührt 
), ist mir aber etwas zu unsicher für Zeiten, wo länger niemand zu Hause ist, der notfalls den Oszillator stoppt. Das müsste ich erstmal länger testen, wenn ich (zumindest nachts) ein paar Wochen am Stück daheim bin.
Für den nächsten Urlaub nehme ich lieber die erste Lösung.
Das heißt also, z.B. "turn=on&timer=1" bedeutet, dass 1s nach Empfang des Kommandos eingeschaltet wird?
Aber wieso "On und off muss dann umgedreht werden." ? Mit oder ohne Verzögerung, die Lichter sollen ja nicht im Wechsel an sein.
Für ersten Fall könntest du versuchen, dass du es nochmals in den vorherigen Zustand versetzt und hinter die Actions "&Timer=1" (ohne ") setzt. On und off muss dann umgedreht werden.
Was bewirkt das? In der Doku steht "A one-shot flip-back timer in seconds", aber nicht, was vor und nach der Verzögerung passiert.
Also das wäre dann nach Deiner Beschreibung mit on/off über Kreuz sowas (wieder mit Button Type = edge):
OUTPUT SWITCHED ON URL:
http://<Adresse anderer Shelly>/relay/0?turn=off&timer=1
OUTPUT SWITCHED OFF URL:
http://<Adresse anderer Shelly>/relay/0?turn=on&timer=1
Das verstehe ich aber nicht.
Das sieht nach einer sehr guten Idee aus, auch erste Tests verliefen vielversprechend.
Es deckt nur zwei eher exotische Fälle nicht so ab, wie die ursprüngliche Lösung:
- wenn das WLAN oder Stromnetz beim "edge-type"-Shelly ausfällt, lässt sich mit dem Schalter am anderen gar nichts mehr schalten, also auch nicht das lokale Licht.
- wenn man auf dem "detached-type"-Shelly per Webinterface das Licht einschaltet, dann geht das andere nicht mit an.
Die Einschränkungen sind aber so minimal, dass ich damit wohl allemal besser fahre als mit dem Oszillator-Risiko.
Ich habe zwei Shelly-1, die im Prinzip jeweils eine Lampe schalten (in Wahrheit ist es etwas komplizierter, siehe hier, sollte aber für das Problem hier keine Rolle spielen). Jeder der beiden hat Action-URLs wie folgt:
OUTPUT SWITCHED ON URL:
http://<Adresse anderer Shelly>/relay/0?turn=on
OUTPUT SWITCHED OFF URL:
http://<Adresse anderer Shelly>/relay/0?turn=off
Und dazu Button Type auf "Edge", Power on default Mode = OFF.
Wenn also eine Seite EIN schaltet, geht die andere mit. Und wenn man per API irgendwas schaltet, macht das nächste manuelle Schalterumlegen rückgängig (wegen "edge"). Soweit so gut - funktioniert im Prinzip einwandfrei.
Aber es gibt nun doch ein in der Praxis selten auftretendes (aber wenn man es darauf anlegt leicht reproduzierbares) Problem:
Wenn die beiden Lichter eingeschaltet sind und ich dann an einem Shelly-Taster AUS und schnell (aber erst nachdem die lokale Lampe ausging) wieder EIN schalte, dann fängt das Gesamtgebilde an zu oszillieren! Meistens hilft nur noch die Sicherung, um es wieder zu stoppen.
Ich vermute es liegt an Verzögerungen im Netz (die gekoppelten Shellys sind übrigens in verschiedenen WLANs) und stelle mir das so vor:
Ich sende der Gegenseite AUS, und diese tut das und sendet AUS zurück, was normalerweise nichts bewirkt. Wenn ich aber beim Eintreffen des "Echos" lokal schon wieder angeschaltet habe, schaltet das Echo ihn gleich wieder aus, was einen AUS-Befehl in die andere Richtung auslöst. Währenddessen läuft aber das manuelle ausgelöste AN bereits rüber zur Gegenseite und schaltet diese ein, kurz bevor dann das AUS eintrifft usw. usf. ==>> Geflacker ohne Ende.
Gibt es dafür eine Lösung (ohne die funktionierende Grundfunktion) zu ändern?
