Beiträge von BlackLotus

VPN/Proxy erkannt

Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.

    Die gehen bei mir überhaupt nicht ??

    Bist Du ganz sicher, dass es sich dabei um genau dieselben Leuchtmittel handelt? Die Philips MASTER LEDbulbs sind aus dem Geschäftskunden-Sortiment von Philips und ich musste die extra online bestellen, da ich sie im normalen Handel (Baumarkt, usw.) nirgends gefunden habe.

    Ansonsten: Kalibrierung durchgeführt? Einstellung auf Trailing Edge? Shelly "Dimmer" oder "Dimmer 2"? Und was bedeutet "gehen nicht" genau? Gehen gar nicht an? Gehen an, aber lassen sich nicht dimmen? Und welches Leuchtmittel-Modell hast Du genau (Watt, Fassung, Farbe, Form, Lumen, klar/matt, usw.)?

    Die offizielle Empfehlung ist, für jegliche LED Leuchten Trailing Edge zu benutzen. Das ist besser für beide, Leuchte und Dimmer.

    Danke für den Tipp, ich habe mittlerweile umgestellt und habe somit folgende LED-Birnen an einem Dimmer 2 mit N und nun auch mit Trailing Edge erfolgreich in Betrieb:

    - Philips MASTER LEDbulb 14-100W 927 A67 E27 matt DimTone / 871869670711100 / 70711100 / 2700K-2200K / 1521lm / Dimmbar / Ra 90 / 25'000h

    - Philips MASTER LEDbulb 9-60W 927 A60 E27 matt DimTone / 871869969564400 / 69564400 / 2700K-2200K / 806lm / Dimmbar / Ra 90 / 25'000h

    Dank dem guten Farbwiedergabeindex von Ra 90 (= CRI 90) ist das Licht für eine LED-Birne recht angenehm, auch wenn es noch nicht ganz gleichwertig zu einer Glühbirne ist. Für den Aussenbereich oder "versteckt" hinter einem Milchglas/Papier-Kugel/usw. aber ganz OK.

    Ich hab mittlerweile 3 "inkompatible" Bewegungsmelder wie folgt über ein Finder 13.31.8.230.4300angeschlossen und es funktioniert soweit seht gut:

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Bei den BWMs handelt es sich um 2x B.E.G. RC plus next 230° und 1x eine ca. 30 Jahre alte Steinel Leuchte mit eingebautem BWM, welche ich neu verkabelt habe (BWM-Teil und Lampen-Fassung haben nun komplett getrennte Anschlüsse).

    Channel 1 mit Funktion: Dauer-Licht über die Shelly App

    - Standardmodus Power An: AUS

    - Schaltflächentyp: Detached Switch

    - Application Settings -> Input State -> Add input state identifier to the power button: DEAKTIVIERT

    Channel 2 mit Funktion: Licht vom BWM geschaltet, die "Kontrolle" (Nachlaufzeit, Rückmeldungen über Blinken, etc.) bleibt dabei vollständig beim BWM

    - Standardmodus Power An: SWITCH

    - Schaltflächentyp: Toggle Switch

    - Application Settings -> Input State -> Add input state identifier to the power button: AKTIVIERT

    Ich habe auch Versuche gemacht, die Nachlaufzeit über den Shelly zu steuern, dabei verliere ich jedoch einige Fernbedienungs-Komfort-Funktionen (z.B. Dauer-Aus über die IR-Fernbedienung) des B.E.G. BWMs, welche ich gerne erhalten möchte (und die nicht mehr verfügbar sind, wenn man den B.E.G. auf 1-Sekunden-Impulse umstellt). Auch gibt der B.E.G. über Blink-Signale Rückmeldungen, wenn man ihn mit der IR-Fernbedienung programmier/einstellt, was ich eben auch beibehalten wollte.

    Ich werde das Setup vermutlich noch um ein paar BWMs und Leuchten ergänzen und dann über eine SmartHome-Software-Lösung (auf einem Raspi oder so) eine "super-smarte" Ansteuerung (mehrere BWMs an unterschiedlichen Shellys schalten zusammen unterschiedliche Leuchten, Leuchten- und/oder BWM-Gruppen, etc.) programmieren. Leider sind ja die Möglichkeiten für solche Advanced BWM-Setups mit der Shelly-Firmware und/oder der Shelly-Cloud alleine etwas sehr beschränkt.

    Zum Schluss noch eine Anregung/Idee für diejenigen, welche gerne die Nachlaufzeit mit dem Shelly steuern möchten, jedoch Probleme haben weil der BWM selbst eine Mindest-Nachlaufzeit (z.B. minimal eine Minute) hat und/oder den L'-Ausgang dauernd eingeschaltet lässt, solange eine Bewegung registriert wird (wodurch "Activation Switch" mit Off-Timer nicht mehr gut funktioniert).

    => Mit einem Eltako MFZ61DX-UC "Analog einstellbares Multifunktions-Zeitrelais" eingestellt auf die Funktion "TI = Taktgeber mit Impuls beginnend" und einer kürzer als der Shelly-Off-Timer eingestellten Zeit (Einstellbar sind 0.5 Sekunden bis 1 Stunde) könnt ihr den L'-Ausgang des BWMs zu einem Impuls-Signal konvertieren und den "Activation Switch" dadurch laufend triggern.

    Folgende LED-Birnen habe ich an einem Dimmer 2 mit N und Leading Edge erfolgreich in Betrieb:

    - Philips MASTER LEDbulb 14-100W 927 A67 E27 matt DimTone / 871869670711100 / 70711100 / 2700K-2200K / 1521lm / Dimmbar / Ra 90 / 25'000h

    - Philips MASTER LEDbulb 9-60W 927 A60 E27 matt DimTone / 871869969564400 / 69564400 / 2700K-2200K / 806lm / Dimmbar / Ra 90 / 25'000h

    Müsste vielleicht bei Gelegenheit mal gucken, ob es mit Trailing Edge auch geht und/oder was es für einen Unterschied macht. Ich hab einfach Leading Edge genommen, da dies der Default (oberer Eintrag im Dropdown) war und funktioniert hat.

    I ran into the same issue on my Shelly 2.5. After some investigation of the cloud APIs and JavaScript i think this might be a bug and thus opened the following ticket T-20037569 with Allterco:

    Zitat

    Myself and some other users (see Shelly 1 application and Input State (German)) ran into a strange bug where some of our Shellys (Shelly 2.5 in my case, Shelly 1 for other users from the linked threads) would not show the "Add input state identifier to the power button" checkbox in the "Application Settings".

    I was able to investigate it and work around the issue (just for myself) by doing some browser devtool HTTP magic. I basically POSTed devices_data={"DEVICE_ID":{"input_state":true}} to the cloud /interface/device/bulk_update endpoint. From that point onward the "Add input state identifier to the power button" setting appeared and also stayed visible even when i disabled the option.

    This leads me to believe this is actually a bug that occurs when the device is completely missing the input_state property (instead of it being either true or false) in the device entry returned by the cloud /interface/device/get_all_lists HTTP endpoint. Not sure under which conditions the device entry will end up in that state, but for me it occured on 1 of my 3 Shelly 2.5 devices. For another user it occurred on 5 of his 13 Shelly 1 devices.

    I believe the actual bug in the code is in https://my.shelly.cloud/assets/js/modu…ice_settings.js in the init_input_state_events() function which does a "device.hasOwnProperty('input_state')" check. So if the input_state property is completely missing (for whatever unknown reason), the user will not be able to ever activate that option.

    Obviously another option to fix this would be to make sure that the input_state property is always there (for the devices that support it).

    I will try to keep you updated on Alltercos response.