Beiträge von dewaldo

    Vielleicht mal folgender Ansatz, aber muss ich bei Gelegenheit auch selber mal ausprobieren.

    Über die Debug-App kann man ja auch wunderbar die Bluetooth-Telegramme mitlesen. Die Scripte und Bluetooth-Gateway Funktionalität zielt ja darauf ab, Zustände der Blu-Geräte weiterzuleiten. Vielleicht ist es hier einfach nur so, dass im Beacon Modus eben nicht alle Telegramme gleichwertig sind ? Soll heißen, vielleicht sind die Telegramme im Beacon Modus minimum ein Funkfeuer, wo MAC Adresse und Advertising im Allgemeinen gesendet werden, aber vielleicht sind nur dann im Telegramm auch Nutzdaten, wie z.B. Motion detected, oder Temperaturwerte, Auf/Zu Werte usw, wenn dort tatsächlich Änderungen aufgetreten sind ... Dann würde ein Gateway das Telegramm zwar empfangen, aber keine Daten weitergeben...

    Wie gesagt, nur ein Gedanke, weil ich nicht wüsste, warum ein Gateway, Script etc. sich so unzuverlässig anders verhalten sollte, wenn im Beacon Modus alle Telegramme ansonsten exakt gleich aufgebaut sind wie jene, die durch Ereignisse getriggert werden.

    Muss mal kurz fragen, um das Thema besser nachvollziehen zu können. Wenn ihr hier von "Bluetooth Gateway" redet, dann heißt das, das Blu - Gerät ist per App mit dem jeweiligen Plus-Shelly gekoppelt worden, also verschlüsselte Kommunikation und der Plus-Shelly stellt die Ereignisse vom Blu-Gerät dann in die Cloud zur Verfügung für die Verwendung in Szenen etc. ?

    Lapu-Lapu hat in seiner Signatur, > 50 Shelly ohne Cloud und OpenHAB, daher meine Unsicherheit.

    Ich nutze die Blu-Geräte aktuell noch immer mit dem Blu to MQTT Script auf Basis von mehreren Plus2PM, da gibt es keine Probleme. Hierbei ist im Shelly Plus selbst das Bluetooth Gateway deaktiviert. Hat aber halt den Nachteil, dass alle Telegramme der Blu-Geräte quasi unverschlüsselt sind, aber damit kann ich bei den betreffenden Einsatzgebieten mit leben.

    Im Prinzip hast du ja schon selbst fast alle Möglichkeiten genannt, die man hier hätte.
    Die Ausgangsklemmen mit 2 x Minus und 1 x Plus legen nahe, dass die beiden LED Kreise (KALT + WARM) vom gemeinsamen PLUS - Potential gespeist werden und dann MASSE-SEITIG z.B. per PWM geschaltet bzw. gedimmt werden.
    Offenbar sind die LEDs aber in einem ziemlich großen Cluster in Reihe geschaltet, wenn die zulässige Ausgangslast im Bereich von 120 bis 210VDC liegen muss. Von daher fällt hier der RGBW2 leider raus.
    Es müsste also vermutlich ein dimmbarer Konstantstrom-Treiber her, der für so einen Spannungsbereich ausgelegt ist. Ich kenne zumindest auf Anhieb da keinen und muss auch sagen, bei so hohen Gleichspannungen sollte auch entsprechend Vorsicht geboten sein, zumal für eine Installation im Kinderzimmer.

    Wir haben 2 ähnliche Lampen in den Kinderzimmern, aber ich würde eine solche Modifikation mittels den bestenenden LED-Platinen nicht vornehmen, dann lieber was "Geeigneteres" suchen.

    Ich antworte mal schnell, bevor du den Beitrag noch 10 x postest :/

    Du schreibst, Elektriker hat es fachgerecht installiert, du nennst aber 2 verschiedene Bewegungsmelder, heißt das, du bist dir nicht sicher, oder sind das 2 getrennte Installationen ?

    Es fehlen natürlich etliche Angaben von dir. Z.B. wie der Shelly intern konfiguriert ist bzgl. Button type...
    Grundsätzlich, wenn der PIR hier garkeine Reaktionen hervorruft, liegt meistens die Vermutung nahe, dass der Bewegungsmelder elektrisch nicht direkt kompatibel mit dem Shelly Input ist, sodass der Shelly die Schaltunterschiede nicht erkennen kann und deshalb einfach nicht darauf reagieren kann.

    Testen lässt sich das, indem du am Browser den Status deines Shelly Dimmer2 abfragst. Das geht mittels dem Befehl:

    http://ipdesshellys/Status

    Du erhältst dann eine etwas unübersichtliche Textausgabe, einen sogenannten JSON String. Dieser beinhaltet irgendwo in der Mitte auch die Infos über die beiden Inputs des Shelly.
    Du musst daher in dem String die Stelle suchen, wo steht:
    "inputs":[{"input":0,"event ... ....},{"input":0,"...}]

    Hierbei ist der erste Input entsprechend innerhalb der ersten geschweiften Klammer, der zweite dann im zweiten Block. Die Zahl hinter "input": gibt an, ob der Shelly diesen Input gerade als inaktiv, also WERT 0, oder als aktiv, WERT=1 erkennt.

    Du müsstest also den Status abrufen, dann den Bewegungsmelder auslösen und während dieser ausgelöst ist, nochmal den Status abfragen. Hierbei muss sich die Zahl des Zustands entsprechend ändern. Passiert dies nicht (meist wird dann permanent eine 1 zu sehen sein), dann musst du an der Anbindung zum Shelly was ändern (also wieder Elektriker). Stichwort z.B. Bukowski-Draht oder Trennrelais.

    Mal eine kleine Frage in die Runde...
    Ich nutze schon länger dieses Script, wenn auch in leicht angepasster Form und verwende es, um Shelly Adapter friendly per MQTT an den ioBroker zu senden.
    Nun habe ich bemerkt, dass es nach einem Update des Shelly Adapters immer Warnmeldungen gibt, wenn ein Blu-Gerät ein Telegramm sendet, weil die Script-Version, die das Script eben hat, nicht vom Shelly Adapeter "unterstützt" wird.
    Das ist halt etwas nervig, weil ich jetzt bei allen Plus-Shellys dafür im Script die Versionsnummer ändern muss.

    Gibt es hier vielleicht einen Tipp, was für eine Versionsnummer man dort eintragen kann, dass der Adapter nicht mehr meckert ?

    Ja, eine Kombi aus BluMotion und einem PlusShelly (in der Nähe) sollte das gut abbilden können.
    Aber auch hier ein wenig das Thema "wenn es dunkel ist" nicht so 100% darstellbar. Der BluMotion hat für meinen Geschmack einen viel zu unsensiblen Helligkeitssensor. Der melder schon den Minimalwert von "1", wenn es noch ausreichend hell ist und man eigentlich kein Licht bräuchte... Aber sonst finde ich den Vorschlag mit dem BluMotion auch gut

    Wenn du nur EINE Lampe schalten möchtest, genügt der Shelly Plus 1. Ggfs. kannst du den Shelly 2 Plus nehmen, wenn du z.B. vor hättest, zusätzlich zu einem angeschlossenen Bewegungsmelder auch noch einen Wandtaster o.ä. anzuschließen, weil der Shelly Plus 2PM entsprechend 2 Eingänge besitzt im Gegensatz zum Shelly 1.

    Die Schaltlogik kannst du dann über eine Shelly Szene in der Shelly App (Cloud) umsetzen.
    Einzige Einschränkung ist halt das Thema "wenn es dunkel ist". Hier müsstest du ein Premium Abo nutzen, um z.B. die Sonnenauf- und untergangszeiten verwenden zu können, wann bei Bewegung der Shelly schalten soll. Alternativ müsstest du mit festen Uhrzeiten arbeiten oder ganz banal (so würde ich es machen) einfach den meist vorhandenen Helligkeitssensor des Bewegungsmelders so einstellen, dass der halt nur auslöst, wenn es dunkel ist und auch nur dann die Szene reagiert.

    In der Szene selbst kannst du dann eine Alexa Notification festlegen. Auch hier mit der Einschränkung, als Standardnutzer kannst du max. 3 Szenen erstellen, die eine Alexa Benachrichtung verwenden. Für mehr müsstest du ein entsprechendes Abo bei Shelly abschließen. Damit alles klappt, muss auf Alexa entsprechend der Shelly Skill aktiv und mit deinem Shelly Konto verknüpft sein.

    Ja, das ist ein leidiges Thema mit den Bewegungsmeldern am Input von Shellys.
    Die Shellys reagieren auf einen sehr kleinen Stromfluss am SW Input, um zu erkennen, dass der Eingang aktiv ist.
    Leider gilt das in beide Richtungen, also in Richtung "L" Potential, als auch in Richtung "N" Potential.

    Je nach Beschaltung der Bewegungsmelder - Ausgänge kommt es dabei zu Problemen, dass der Shelly Input auch dann ein "TRUE" meldet, wenn der Ausgang des Bewegungsmelders eigentlich AUS ist.

    Kontrollieren kannst du das, indem du den Status vom Shelly abrufst und schaust, ob du dort einen Unterschied im Zustand siehst, wenn der PIR AUS und wenn der PIR AN ist.

    Statusabfrage am Shelly am Browser über dessen IP:
    http://IPdesShelly/Status

    Als Rückmeldung bekommst du einen JSON string. Und dort gibt es irgendwo in der Mitte die Auflistung der beiden Inputs. Dort werden dann auch mit "0" oder "1" darsgestellt, ob diese gerade aktiv oder inaktiv melden.
    Die Vermutung ist, dass der Eingang, an dem der PIR angeschlossen ist, IMMER 1 meldet, egal, was der PIR macht.

    Falls sich das bestätigt, musst du im Forum mal nach "Bukowski-Draht" suchen. Das ist quasi ein kleiner Draht mit integriertem Vorwiderstand, den man am Input des Shelly vorschaltet. Letztlich reduziert der den Stromfluss etwas, um bei solchen Problemen wieder eine saubere Trennung von 1 und 0 Zuständen zu erreichen. Eine weitere Möglichkeit wäre ein kleines Trennrelais...
    Aber erstmal eines nach dem anderen und erstmal prüfen, ob die STATUS-Ausgang vom Shelly die Vermutung bestätigt.

    WICHTIG! Immer die Browser-Darstellung aktualisieren, wenn der PIR seinen Ausgang ändert, damit auch die dann aktuellen Zustände angezeigt werden.

    Der BluMotion sendet aber in seinem Bluetooth frame auch die Helligkeitsinformation mit, die er über seinen Fotosensor im Moment der Triggerung gemessen hat. Auf den Wert sollte man per Script auf jeden Fall zugreifen können, bzw. anhand dessen eine Fallunterscheidung machen können, ab welchem Schwellwert geschaltet werden soll.

    Bei mir zuhause geht's über ioBroker und aus der Erfahrung raus kann ich sagen, dass der Helligkeitssensor relativ unempfindlich ist. Er liefert offenbar einen INT Wert im Bereich von 1 bis 255, wobei selbst bei 1 die Resthelligkeit noch so hoch ist, dass ich noch nicht zwingend das Licht schalten würde, aber hab es halt so gemacht, dass, wenn Wert < 2, dann Licht an. Damit fahre ich ganz gut.

    Vielleicht kannst du dein Script ja mal posten ...

    ein Double-Shortpush ja eigentlich auf 100% dimmt und nicht ausschaltet. Dafür wären dann 2x Prellen nötig

    Das ist ein guter Gedanke, stimmt.
    Soweit ich das noch in Erinnerung habe, ist das Auswertefenster für den Double-Push 500ms. Daher kommt auch der unschöne Effekt, das Taster 1x gedrückt, das Licht erst mit einer kleinen Verzögerung einschaltet, weil der Dimmer2 noch wartet, ob es beim Single-Push bleibt.
    Da hier im Verlauf auch schon die Entprellzeit auf 250ms gesetzt wurde, was auch nicht geholfen hat, liegt die Vermutung nahe, dass der Ausschalt-Impuls dann mit einer ziemlich großen Verzögerung kommen muss, also > halbe Sekunde nach dem eigentlichen Tastendruck.
    Das ist wirklich etwas seltsam. Wenn die alten Eltako wie im Bild ersichtlich spulen-seitig jetzt abgeklemmt sind, fällt mir jetzt spontan nichts ein, was da noch ursächlich sein kann.
    Man müsste mal die Spannung am SW Input gegen N messen, wenn das Licht an ist, ob das Potential vielleicht irgendwie "verzogen" wird.

    Mmh, vielleicht als kleiner Exkurs, aber verwandt damit eine Frage von mir in Richtung Bewegungsmelder mit Relais.
    Ich habe auch diverse Bewegungsmelder mit Relais, also welche, die meist als "für LED geeignet" bezeichnet werden.
    Diese haben L, N und L* Anschluss, wobei L* einfach der Relais-Schließer Ausgang ist, über den die Dauerphase dann durchgeschaltet wird.

    Mit diesem Grundgedanken sollte so ein Bewegungsmelder keine Probleme an einem Shelly Input machen, tut er aber. Ohne weitere Maßnahmen in der Verschaltung ergibt diese Kombi bei mir bei 3 Installationen einen DAUER-HIGH Pegel am Shelly Input, egal, ob das Relais des Bewegungsmelders gerade schaltet oder nicht und damit habe ich so meine Verständnisprobleme, wenn ich mir den Artikel zur Störanfälligkeit anschaue. Daher, vielleicht kannst du mir hier noch Infos darüber geben, weshalb es bei Bewegungsmeldern dieser Bauart Probleme beim Shelly Input gibt, wo doch nach meinem Verständnis der L* quasi einfach "in der Luft hängt", solange der PIR nicht aktiv ist ?

    Ich vermute da tatsächlich immer noch irgendwelche kapazitiven Geschichten. Wenn da alle Taster der "alten" Stromstoßschaltung separat mit 5 Ader - Leitungen angefahren sind von der Verteilung aus, kommen da schon ganz schön Meter zusammen und die hängt dann komplett parallel am Shelly Input. Ich wollte schon den Vorschlag eines Vorwiderstands am Shelly Input in die Runde werfen, aber da der TE schon von sich schreibt, der Elektriker hat es angeklemmt, hatte ich davon Abstand genommen, so einen Vorschlag zu nennen. Aber vielleicht wäre das ein gangbarer Lösungsvorschlag...

    Laufzeit würde jetzt etwa 2 Tage betragen in dem Screenshot und bei den Input 0 Events steht 339. Das finde ich ziemlich viel für die kurze Zeit, heißt, du hättest 339 mal auf den Taster gedrückt in den 2 Tagen ?
    Ich vermute da noch immer irgendwas prellendes etc. Wobei 250ms debounce schon echt viel ist...

    Hast du dich dann bei Nutzung des PC auch auf den Shelly AP verbunden ?
    Am besten bei sowas immer auch mal versuchen, ob sich der Shelly dann pingen lässt unter der 192.168.33.1, um Verbindungsprobleme als Ursache von vorne herein auszuschließen.
    Ein Punkt wäre noch eine Möglichkeit, aber normal braucht man das nicht zu kontrollieren, aber schadet ja nicht. Und zwar mal in der FritzBox schauen, ob ggfs. ein MAC-Filter aktiviert ist fürs WLAN, sprich neue Geräte sich gar nicht verbinden dürfen, nur die bereits bekannten ...

    Bei der Frage nach den 400V geht es nicht um den Neutralleiter, sondern darum, dass bei der alten Variante mit Stromstoßschalter die Wahrscheinlichkeit besteht, dass man 2 verschiedene Außenleiter hat, z.B. L1, der dann den Shelly versorgt, aber L2, der zum Lampenstromkreis gehört und zwischen denen hättest du dann die 400V, was zu vermeiden wäre.

    Auf dem Bild ja, sieht auf jeden Fall so aus, dass dann wohl der N in den Dosen vorhanden ist, was schon mal gut wäre.
    Dann würde ich meinen 1. Vorschlag von vorhin erstmal nicht zwingend wahrnehmen, aber den 2. schon, also schalten und wenn das Licht wieder von selbst ausgeht, dann den Status des Shelly abfragen, ob man dort sieht, dass er ggfs. neu gestartet ist.

    Du könntest versuchsweise mal ein Gastnetz in der FB einrichten mit einfacher SSID und einfachem Passwort

    Die Idee hatte ich auch schon. Dabei muss nur beachtet werden, dass das Smartphone bzw. das Gerät, auf dem die App läuft, sich dann auch im selben Subnetz befinden muss, sprich, das Handy müsste man in dem Fall mit in das Gäste-WLAN "nehmen", sonst sind die Shellys aus dem normalen Fritz-WLAN nicht erreichbar.

    Und vermutlich wäre es auch notwendig, die Option zu aktivieren, dass die im Gäste-WLAN befindlichen Geräte sich "sehen dürfen"

    Ich bin mir halt nicht so sicher, wenn der Shelly hinter einem der Taster installiert wurde, ob dann die Anbindung wirklich korrekt ist, speziell das Thema Neutralleiter...

    Ein etwas aufwändiger Test, der aber mehr Erkenntnis bringen würde, wäre, wenn du mal bei der kleineren Lampengruppe mit den 5 LEDs im Flur OG alle 5 Lampen aus den Sockeln entfernst und anschließend prüfst, ob du in dem Zustand noch auf das Webinterface des Shellys kommst, der diese Lampen steuert.

    Noch ein Ansatz, der weniger aufwendig ist, wäre, wenn du deine Schaltaktion ausführst, bei der das Licht direkt wieder aus geht und dann musst du unmittelbar danach per Handy, PC, etc. am Browser mal den Status von dem betreffenden Shelly abrufen.
    Das geht mit der Adresse http://IPdesShelly/Status.

    Als Antwort bekommst du einen JSON String und dort findest du auch die Angabe zur Uptime, also wie lange der Shelly seit dem letzten Booten schon läuft. Wenn hier dann eine sehr kleine Zahl von Sekunden steht, wissen wir, dass der Shelly beim Schalten quasi "abschmiert", was ohne Neutralleiter nicht unwahrscheinlich ist je nach Verhalten der Lampen.

    Man müsste jetzt den Elektriker interviewen, was er da wie umgeklemmt hat.
    Schubbie hatte oben den Stromstoßschalter erwähnt, genau das sind diese Eltako im Bild. Zu erkennen ist dort, dass die "Steuerleitungen" abgeklemmt wurden, also die Leitungen, welchen das Relais des Eltako schalten würden.
    Der Lampenstromkreis ist aber eigentlich der, der beim Eltako über die Anschlüsse 1 + 2 läuft. Und dieser Weg von 1 nach 2 muss jetzt vom Prinzip her der Shelly durchschalten.
    Vielleicht habe ich es überlesen, aber wo befinden sich denn räumlich jetzt die 2 Shelly Dimmer2 ?
    Vom Sinn her müssten die ja dann fast auch im Verteiler sitzen ? Hinter einem Taster würde es wenig Sinn machen, weil dort wahrscheinlich kein N vorhanden und man da auch die Verkabelungslogik doch recht viel anpassen müsste...