Na dann passt das so doch am besten.
Wie in meinem Beitrag #5 erwähnt, hättest du z.B. auch die Möglichkeit über Tastendruck die Ausschalt-Action des Bewegungsmelders zu deaktivieren, sodass du z.B. sagen kannst, Tastendruck -> Licht an für 30 Minuten, und auch dann nicht ausschalten, wenn der Bewegungsmelder von EIN nach AUS wechselt (halt wenn man mal Dauerlicht haben will). Aber fürs Treppenhaus genügt wahrscheinlich die Variante so, wie du sie schon umgesetzt hast.
Gut, dass du das mit dem Script nochmal erwähnt hast, da wollte ich der Vollständigkeit halber nämlich auch noch drauf hinweisen. Und in Summe verstehe ich so auch die BTHome Integration.
Fazit: Sobald ihr im HA die Shelly Integration benutzt, um darüber BTHome zu nutzen, ist es faktisch dasselbe, wie der Ansatz eines BluToMQTT Scripts auf dem Shelly. Also genauso anfällig, was die Zuverlässigkeit der Übertragungen angeht, weil auch diese Variante halt einen Plus Shelly als Gateway nutzt, was eben leider momentan nicht zuverlässig läuft.
Was ich gemeint hatte im Zusammenspiel mit BTHome und HA ist, dass man ja nicht zwingend einen Shellly als Gateway nutzen muss, sondern zum Beispiel die eigene Bluetooth Fähigkeit eines Raspberry PI 4 oder sowas, und darüber die Bluetooth LE Frames zu empfangen und auszuwerten. Ist natürlich dann aufwendiger oder schwieriger, da man zur Empfangsabdeckung da auch mehr als 1 bräuchte... Gibt dazu auch eigene Projekte, z.B. mal googlen nach "OpenMQTTGateway".
Vom Preis wäre es eher 3:1. mit 80,00 EUR zu 25,00 EUR
Ich hatte aber auch beim letzten Post nur die Kurzform geschrieben ohne den Zusatz Dimmer, von daher bin ich dann auch nicht ganz unschuldig 
Es ging hier aber um den Dimmer, nicht um das Pro - Relais. Ob das dort auch so ist ...
Vorwort: Es gäbe auch noch den Dimmer Pro 1PM. Selbes Gerät, aber nur 1 Kanal.
Aus meiner Sicht:
Pros:
- eine bessere Wartbarkeit
- besseres Wärmemanagement und daraus vermutlich längere Lebensdauer
- Offeneres Setup für spätere Anpassungen (wer weiß, was in 10 Jahren kommt)
- 2 Kanäle erhältlich beim Pro 2PM pro Modul (platzsparend)
Cons:
- keine Phasenanschnittsteuerung möglich, daher ggfs. Beschränkung der dimmbaren Komponenten
- etwas teurer als Shelly Dimmer2 Variante
- aufwendigere und deutlich teurere Verdrahtung, aber im Rohbau, wie Schubbie schon schreibt, würde ich mir für später alle Wege offen halten und von jedem Schaltpunkt aus eine Leitung in die Verteilung ziehen
Hinweis für Pro 2PM:
- Zu beachten ist da auch, dass der zwar 2 Kanäle hätte für unterschiedliche Lampengruppen, jedoch nur 1 Stromkreis bildet, daher macht der nur Sinn, wenn man pro Stromkreis / Raum etc. auch 2 Kanäle nutzen kann.
Ich kenne BTHome jetzt nicht aus eigener Erfahrung, aber das wäre ja quasi dann die Variante über z.B. Raspberry Pi und dessen Bluetooth hardware, damit sollte das eigentlich zuverlässiger laufen, soweit die räumliche Position das Empfangen aller H&T zuverlässig erlaubt.
Einen Mix aus BTHome und Shelly Gateway über MQTT wird vermutlich schwierig zu kombinieren...
Egal, ich probiere es noch mal mit BTHome und dem Mini
Die Anmerkung verstehe ich nicht so richtig. Für mein Verständnis bedeutet BTHome = Kein Shelly Gateway. Welche Rolle spielt da der "Mini" ?
Ja, das ist im Moment ein etwas leidiges Thema, gibt es auch genügend Foreneinträge darüber, dass die Shelly Gateway Funktion offenbar noch nicht so richtig zuverlässig ist und es immer wieder zu Ausfallzeiten bei den Übertragungen kommt. Was ich so mitgelesen habe, gibt es da auch noch keine konkrete Lösung mit Shelly Bordmitteln. Es gäbe die Möglichkeit, über einen Raspberry PI ein Bluetooth MQTT Gateway umzusetzen, das wäre zuverlässig, aber natürlich wieder mehr Aufwand und ggfs. braucht man dann 2 oder 3 davon usw...
Bei mir mit den BluMotion ist die Funktion so ausreichend, aber bei kontinuierlichen Sensoren wie H&T ist das leider noch nicht zufriedenstellend.
Kurz zum Thema "Verschlüsselung". Damit hatte ich nicht die Übertragung per MQTT gemeint, da hängt es nur davon ab, ob deine MQTT Verbindung an sich verschlüsselt, also SSL konfiguriert ist oder nicht. Unverschlüsselt ist das Bluetooth Telegramm an sich, bedeutet ohne explizite Kopplung kann jeder andere in Empfangsreichweite die Werte auch mitlesen. Kann man sich halt überlegen, ob das tragisch ist bei reinen Sensoren... Kritischer sehe ich das z.B. bei einen BluButton. Theoretisch kann man ein solches unverschlüsseltes Advertising frame auch "nachbauen" (per Smartphone App z.B.) und damit den Button simulieren und z.B. ein Garagentor öffnen. Deshalb, sicherheitskritische Anwendung würde ich mit der Scriptlösung nicht umsetzen.
Es sind schon richtige Anmerkungen in deinen Gedanken und die stimmen auch großteils. Ich sehe es so, je mehr Gateways du hast, umso größer die Wahrscheinlichkeit, dass dir auch kein Telegramm "durch die Lappen" geht.
Man muss ein bisschen Aufwand betreiben, um im ioBroker z.B. diese Telegramme ordentlich zu behandeln.
Es gibt hier im Prinzip 2 Grundansätze. Zum Einen kannst du den Shelly Adapter nehmen und im Script die Kompatibilität zu diesem aktivieren, das ist die bequemste, aber auch eingeschränkteste Möglichkeit.
--> Der Shelly Adapter kennt ja z.B. alle Plus-Shellys und jeder dieser Shellys, der per MQTT dann BLU-Informationen liefert, tut dies über einen JSON String, wo alle "Datenpunkte" des Blu-Gerätes drin enthalten sind. Der Shelly Adapter parst diese und sortiert sie und kopiert dann die Daten gemäß der MAC Adresse um auf neue Datenpunkte, wo er z.B. für eine bestimmte Blu-MAC-Adresse dessen Daten verwaltet. Wenn jetzt mehrere Gateways dasselbe Telegramm eines Blu-Gerätes liefern, filtert der Adapter das soweit raus, dass letztlich nur 1 Update der Datenpunkte des Blu-Gerätes erfolgt. Wie genau der das intern macht, weiß ich nicht.
--> Der Adapter ist aber recht beschränkt in seinen Inhalten und ich weiß auch nicht, ob der mit den H&T zurechtkommt.
Der 2. Ansatz ist, einen separaten MQTT Adapter zu nutzen, also nicht Shelly Adapter. Dort bekommt man dann halt keine BLU-Geräte als eigene Datengruppe, sondern sieht nur die Plus-Shellys und deren Daten. Diese haben dann zwar einen Datenpunkt mit BLU, dort findet sich dann aber nur 1 JSON String und keine separaten Datenpunkte für z.B. Bewegung erkannt, Helligkeit, Batterie etc..., sondern man muss selbst diesen 1 Gesamtstring parsen per Script etc. Dafür hat man aber mehr Informationen, die man auslesen kann.
Die BLU-Geräte senden mit jedem Telegramm auch eine Telegramm-ID mit, die sich mit jeder Nachricht immer um 1 erhöht, bzw. beim Überlauf wieder bei 1 anfängt. Das kann man nutzen, z.B., wenn 3 Gateways laufen und man da halt 3 Telegramme empfängt, diese 3 JSON Strings analysieren und schauen, ob die Telegramm ID einer Message gleich oder unterschiedlich ist, um zu filtern, dass es dieselbe Nachricht ist, die von mehreren Gateways übermittelt wurde, oder ob es unabhängige Telegramme waren.
Ich habe beides probiert, bin aber zumindest aktuell beim Shelly Adapter geblieben, weil ich auch viele andere Scripte laufen habe, die mit den Datenpunkten der Plus-Shellys arbeiten und dann müsste ich das alles anpassen... Ich nutze aber aktuell auch nur BluMotion und das läuft für mich so zuverlässig.
Die Variante mit Script ist halt grundsätzlich eine Notlösung im Moment, um per MQTT an die Daten zu kommen. Das ist eine unverschlüsselte Übertragung ohne aktive Kopplung, deshalb ist es halt auch so, dass jedes Bluetooth Gerät, welches Advertising frames schickt, die diese Struktur haben, vom Script erfasst und auf MQTT formatiert übermittelt werden. Klar, in jedem Gateway jetzt per Blacklist die unerwünschten einzutragen ist ein bisschen nervig, aber der Aufwand hält sich eigentlich in Grenzen. Wenn du das am PC machst mit Editor, z.B. Notepad++, und da die Scripte für jeden Plus-Shelly verwaltest, ist das ganz gut zu handhaben würde ich sagen.
Vielleicht findest sich ja jemand, der das Script anpasst und eine Whitelist anstatt Blacklist umsetzt, das wäre glaube ich für die Hausautomation der passendere Ansatz.
Ich merke gerade, dass ich gestern sehr oberflächlich gelesen habe. So ist mir das DC beim i4 entgangen, sowie, dass du eigentlich nach Rahmen gefragt hast und nicht, ob die Teile in eine 55er Dose passen.
Da kann ich aber leider nichts zu sagen, da ich die Shelly Wandtaster so selbst noch nicht eingesetzt habe.
Wie ist das denn aktuell bei dir mit der Bedienung ? Du hast geschrieben, Unterputz sitzen 6-fach Sender, aber die brauchen ja auch irgendwelche Taster ? Je nachdem kannst du ja auch einfach die "Sendeeinheit" gegen i4 austauschen, aber die bestehenden Taster beibehalten ...
Die Custom names dienen nur dazu, dass du beim Broker dann nicht mit der MAC-Adresse hantieren musst, sondern dort dann der MAC-Adresse einen anderen Namen geben kannst und diesen dann "siehst". Trotzdem werden aber alle anderen emfpangbaren MAC-Adressen auch per MQTT weitergegeben, nur eben dann über ihre MAC-Adresse.
Es gibt weiter unten dann noch die "blacklist = ...." Dort könntest du deine anderen H&Ts entsprechend eintragen, damit diese ignoriert werden.
Hinweis: Active scan = true oder false sagt nur etwas über die Art aus, wie nach Geräten gesucht wird, aber nicht, welche ja oder nein ...
War da nicht die Rede von i4 und WLAN ? Blu Switch wäre dann eine Option, wenn in den Gerätedosen kein L + N verfügbar wäre.
Also die Taster passen aber auf jeden Fall in eine normale Gerätedose.
Die hatte ich zwar nicht gemeint, aber im Prinzip ist das nicht so entscheidend.
Der Shelly Plus 2PM benötigt eine Dauerphase + N, also wie der FS20 auch. Und dann hat er theoretisch auch 2 Tastereingänge, die man aber nicht zwingend nutzen muss, wenn man von anderer Stelle aus (z.B. i4) steuern möchte.
Als Ausgang schaltet der Shelly 2PM dann die Phase jeweils an einem der 2 Ausgänge durch (dazu muss er in der Konfiguration als "Shutter" konfiguriert werden. Dies bewirkt, dass der Shelly weiß, dass er damit einen Rollladen steuert und dann sind Ausgang 1 und 2 softwareseitig gegeneinander verriegelt).
Je nach Motor kann es notwendig sein, dass du pro Rollladen dann noch 2 RC-Snubber benötigst, um die induktive Last zu dämpfen, aber das solltest du vorher an einem mal testen (bei mir läuft alles störungsfrei ohne Snubber).
Wenn du da die RSU hast, dann kannst du quasi dort die Shelly Plus 2PM nehmen als 1:1 Ersatz
Dann drücke ich dir die Daumen, dass der GIRA Pulseinsatz hier mit dem Shelly vernünftig arbeitet und dort die HIGH/LOW Zustände sauber erkannt werden. Alternativ würde auch bei der Variante dann ein Trennrelais helfen, wobei je nach Einbausituation dann aber ein durchaus nerviges Klick/Klack im Sekundenbereich die "Chefin" wieder verärgern könnte.
Ja das stimmt natürlich, löten ist da notwendig. Deshalb auch Schrumpfschlauch zur Isolation usw... Ich versuche immer so zu reagieren (zugegeben Bauchgefühl), wie der Fragesteller sein Anliegen formuliert. Meist erkennt man dann schon, ob jemand "weiß, was er tut", oder eher keinen Plan hat. Streng genommen darf ein Laie auch kein fertiges Trennrelais mit Schraubanschlüssen installieren, aber klar, Löten geht natürlich eine Stufe weiter... Und "Shelly Inside" war / ist mir bislang kein Befriff gewesen
Das mit den 11V hat vermutlich 2 Gründe.
1.) Der Shelly Input hat normalerweise ca. die halbe Netzspannung, wenn er offen ist, daher kann der Shelly auch Stromfluss zu L, als auch zu N erkennen. Heißt, 11V sollten es eigentlich nicht sein, das würde der Shelly vermutlich auch als AKTIV deuten, da dann fast N Potential anliegt. Wie gesagt, STATUS Abfrage ist in dem Fall immer eine gute Wahl. Testhalber kann man dann den Input 2 auch mal abklemmen, falls es keine Statusänderung gibt und dann nochmal schauen, ob dann der Input "0" zeigt. Damit wäre z.B. auch geprüft, dass der Shelly selbst in Ordnung ist.
2.) Wenn du mit einem Duspol prüfst, da bin ich mir jetzt nicht sicher, da kann mit Sicherheit Thomas ( thgoebel ) was zu sagen. Der Duspol ist kein Multimeter, heißt, der misst nicht extrem hochohmig und durch den Duspol ziehst du dir den SW Input mit runter, weil über den Duspol dann ein kleiner Strom fließt, von daher ist das ein schlechtes Messmittel für diese Anwendung.
Du hast eigentlich schon alles geschrieben und das passt auch alles genau so. Warum jetzt beim Nachbarn das identische Setup nicht klappt, kann ich nicht sagen. Aber da kann die Leitungslänge und Verlegung eine Rolle spielen, oder auch der Bewegungsmelder selbst. Du hast leider nicht geschrieben, was konkret nicht funktioniert.
Um zu prüfen, ob das Bewegungsmelder-Signal am Shelly ankommt, kannst du am Browser den Status abfragen (http://ipdesshelly/Status). Im Ergebnisstring etwa in der Mitte sind die beiden Inputs aufgeführt, zuerst SW1, dann SW2. Hier steht dann eine Zahl hinter dem Input, eine 0 oder 1, je nachdem, was der Input gerade als Signal sieht. Hier dann mal schauen, ob bei inaktivem Bewegungsmelderausgang eine 0 und bei Bewegung eine 1 kommt. Falls dort durchgehend eine 1 steht, brauchst du das Trennrelais. (HINWEIS: Um die Statusanzeige zu aktualisieren, muss du im Browser die Seite neu laden, sonst tut sich nix)
Wenn bei dir das Ganze ohne funktioniert, würde ich das auch so lassen. Das schlimmste, was passieren kann ist, dass das Licht unabsichtlich an geht, aber das merkt man dann ja.
Wichtig bei der Direktlösung ist halt nur, dass der Außenleiter am Bewegungsmelder und der, der den Shelly und Lampe versorgt, derselbe ist !! Streng genommen muss es sogar der selbe Stromkreis sein. Ist das bei deinem Nachbarn auch gegeben ?
Genau, ich nutze deshalb nur noch ein kleines Trennrelais beim Dimmer2 Input.
Gleichzeitig müsste ich dann auch einen Taster anschließen können, der ebenfalls den Timer startet (der Taster ist im OG und soll das Licht im EG bereits einschalten, bevor man den Sensorbereich des BWM erreicht).
Du kannst natürlich einen Timer starten, indem du als Action ein ... turn=0&timer=300 machst, dann schaltet der Shelly ein und nach 5 Minuten dann aus.
Oder du machst einfach nur ein "turn=toggle" und kannst so ohne Zeitvorgabe einfach am Taster das Licht ein oder ausschalten nach Belieben. Und dann vielleicht im Shelly direkt noch ein AUTO OFF setzen, z.B. auf 3600s, dass das Licht nach 1 Stunde spätestens aus geht (falls es mal vergessen wurde, auszuschalten).
Mir würde noch eine weitere Möglichkeit einfallen, die dann folgende Funktion bietet (ist aber etwas komplexer zu überschauen). Und diese Variante wäre nur mit einem echten Bewegungsmelder umsetzbar, nicht mit einem Präsenzmelder, der ständig Pulse bei Bewegung ausgibt.
- Taster im OG drücken:
-> Licht ein
-> Dadurch wird die Action deaktiviert, auf den Bewegungsmelder zu reagieren, sodass dieser ab dem Moment ignoriert wird
- Licht geht wieder aus (z.B. durch erneutes Drücken des Tasters oder z.B. nach einer AUTO-OFF Zeit):
-> Das Ausschalten des Lichts bewirkt das Reaktivieren der Bewegungsmelder - Action, sodass ab dem Moment dieser wieder berücksichtigt wird. Heißt, tritt danach nochmal eine Bewegung auf, schaltet das Licht auch wieder ein.
Zum Thema Trennrelais verlinke ich mal einen alten Beitrag von mir, wo beschrieben ist, was ich da genommen habe. Ein "echtes" Trennrelais als Kaufteil, da ist man gleich mal 25 Euro los, was für die konkrete Anwendung hier total überdimensioniert ist. Ich hatte dazu kleine Miniturrelais mit 1 Schließer verwendet, siehe Link ...
sag mal, welches Script benutzt du genau?
Ich nutze selbst keinen H&T. Das Script ist auch bei mir das aus dem Forum damals in der Version 1.3. Ich hatte später noch die ID für die Temperatur vom BluMotion geändert, weil die sich nach dem Firmwareupdate des Motion geändert hatte.
Aber stimmt, ich habe mal wieder reingeschaut und das bei mir verwendete Script unterstützt quasi nur "Blu Motion", "Blu Door&Window", "Blu Button". Die H&T waren zu der Zeit noch nicht im Script. Die müsste man dann nachpflegen, bzw. würde es mich wundern, wenn es da keine Version gäbe inzwischen. Die Struktur ist ja quasi bei den ganzen Blu-Geräten ähnlich.
