Beiträge von dewaldo

Ich nutze den Dimmer 2 zwar nicht über MQTT Protokoll, sondern das normale http.

Aber beide Switch-Eingänge können separat ausgelesen werden.

Habe ich bei mir auch so umgesetzt mit IOBroker. Mein Wandtaster ist als One Button konfiguriert zum Schalten und dimmen. Der Switch 2 ist als Detached konfiguriert und wird nur über IOBroker verwendet.

Dort dann so, dass ich im Script prüfe, ob der Bewegungsmelder berücksichtigt werden soll oder nicht und daraufhin den Shelly ansteuert. Z.B. wenn jemand am Wandtaster händisch das Licht einschaltet, lese ich den Zeitstempel im IOBroker aus. Schaltet dann z.B. 20 Sekunden später der Bewegungsmelder aus, weil gerade keine Bewegung mehr stattfindet, schaut IOBroker auf den Zeitstempel und erst, wenn eine Differenz von mindestens 1 Stunde herrscht, wird der Bewegungsmelderausgang wieder berücksichtigt.

Im Shelly selbst steht die automatische Ausschaltzeit ebenfalls auf 1 Stunde.

Lange Rede, kurzer Sinn, per Switch 2 als Detached kannst du den Bewegungsmelder extern auslesen und entsprechend reagieren, Helligkeiten definieren, Zeiten etc. etc...

Der Shelly ist ja stromlos und wenn du den Lichtschalter an der Wand betätigst, muss der Shelly erst mal booten. Der Zustand "Power on" nach Stromausfall ist quasi nur ein Mittel, um festzulegen, ob man nach einem Stromausfall Licht braucht oder ob es definiert AUS sein soll, oder halt den letzten Zustand annehmen soll.

Aber zu erwarten, dass der Shelly bei diesem Power-Up-Zustand alles genau so durchführt, wie beim normalen Betrieb, das würde ich auch nicht erwarten, ganz ehrlich gesagt.

Ich glaube nicht, dass das dem Shelly auf Dauer so gut gefällt, wenn man ihm immer einfach die Versorgungsspannung "kappt", ist jedenfalls nicht im Sinne des Erfinders, ihn so zu betreiben.

Deshalb haben die den bestimmt auch NightMode genannt, und nicht DawnMode

Nein Spaß beiseite, das wäre tatsächlich konsequent, wenn man den NightMode an die Jahreszeit anpassen lassen kann wie bei den anderen Timern auch ...

Mein Eindruck aus der Beschreibung heraus ist, dass die angeschlossene Last zu gering ist und der Shelly ggfs. ohne Nullleiter angeschlossen ist ?

Dann wäre der Spannungsabfall am Shelly zu gering, wenn die Lampe einschaltet, weshalb dieser dann nicht mehr genügend "Saft" hat, sich selbst zu versorgen und abschaltet (und als Folge auch die Lampe aus geht).

Laut dem Wert aus Zeile 67 "Uptime" = 4829 Sekunden bedeutet, der Shelly hat vor 80 Minuten neu gestartet. Ist das Ereignis schon so lange her gewesen, bevor du den Status ausgelesen hast ? Wenn ja, würde das zu meiner "Neustart wegen Spannungsverlust" - Theorie passen.

Alles klar, danke für die Erläuterung, falls ich doch mal in Versuchung käme mit der Cloud, oder jemanden kenne, der jemanden kennt, bei dem es nicht klappt

Ja, wie "Muetze" schon geschrieben hat, die LEDs sind nicht dimmbar, also liegt da die Ursache.

Das merkst du auch am Preis. LED Lampe für 2 Euro, das haut normal nicht hin.

Gute, dimmbare LEDs kosten mal gut das 3 fache.

Und bei Amazon in der Artikelbeschreibung steht auch als letzter Satz:

Dies sind nicht dimmbare LED-Glühbirnen, nicht kompatibel für Dimmern.

Wenn ich das also richtig verstehe, kann das dann tatsächlich die Ursache für das Problem sein, wenn man einen neuen Shelly quasi Hand zu Fuß über das WebUI über die 192.168.33.1 neu einrichtet anstatt unter Nutzung der Smartphone App, dass dann zwar der Shelly grundsätzlich ins heimische WLAN eingebunden ist, aber nicht über die Cloud erreichbar ist, weil dem Shelly die über die App gelieferten Zugangsinformationen dazu dann einfach fehlen ? Oder anders, die Cloud weiß nichts von der Existenz des neuen Shellys und auch, wenn man bei dem übers WebUI die Cloud enabled, nutzt das nix, weil der Bezug zur eigenen Cloud dann fehlt ?

Heißt das im Umkehrschluss dann, dass man eingerichtete Shellys quasi zwangsweise einmal auf Werkseinstellung setzen muss, wenn man sie über die App und Cloud nutzen will ?

Oder "scannt" die Smartphone App das heimische Privatnetz und erkennt dadurch Shellys und gleicht ab, ob der ein oder andere noch nicht in der Cloud gemeldet ist ?

Hallo khaled,

vielleicht kannst du ja mal die genaue Bezeichnung der Lampen posten, evtl. lässt sich daraus dann etwas erkennen, weil du merkst ja anhand mangelnder Reaktionen aus dem Forum, dass aus deiner Problembeschreibung erst mal nichts grundlegend falsches zu erkennen ist.

Das Thema Summen könnte durch die Kalibrierung kommen, wenn du die Dimmart zwischendurch wechselst, dass die Kalibrierung nicht mehr zur Art des Dimmens passt. Aber wie geschrieben, vielleicht erst mal den Lampentyp angeben ...

Ich habe bei mir gestern Abend auch mal testhalber bei einem Dimmer2 die neue Firmware aufgespielt. Bin ein wenig geteilter Meinung. Ich kam von der 1.9.4. Nach Update wollte er eine Neukalibrierung haben, habe ich entsprechend durchgeführt.

Zuvor stand die Dimmart auf "Trailing edge", weil ich das persönlich lieber mag bzgl. Störgeräuchen usw. (noch aus alten Drehdimmerzeiten geprägt). Mein Setup bei dem Dimmer sind 2 ganz normale, ohmsche Lasten in Form von 2 x 40 Watt Halogenlampen.

Ich habe die Dimmart händisch auf "Trailing edge" gestellt, aber den Haken gesetzt gelassen, dass die Lastart automatisch erkannt wird.

Nach Kalibrierung hat der Dimmer selbst wieder auf "Leading edge" gestellt, was bei rein ohmschen Verbrauchern mit Glühwendel im Prinzip ja auch die bessere Variante ist. Also hab ich das auch so belassen.

Vom Verhalten her stört mich jetzt nur, dass die Helligkeitswerte in % nicht mehr dem Helligkeitsverlauf aus Version 1.9.4 bei Trailing edge entsprechen.

Bei mir setzt z.B. nachts ein IObroker script die Helligkeit im Flur auf 18%. Das war vorher optimal, um nachts nicht geblendet zu werden, aber ausreichend zu sehen. Jetzt mit Leading edge und 1.10.1 sind die 18% viel zu dunkel.

Aber ich passe halt jetzt die Werte im Script an und gut ist, da ansonsten offenbar alles passt. Aber mit dem Update der anderen Dimmer warte ich erst mal noch 1-2 Wochen, bis ich ein bisschen Langzeiterfahrung gesammelt habe..

Und nur, um das richtig zu stellen, ich hatte geschrieben, z.B. VPN Verbindungen könnten da Probleme haben, nicht, dass eine VPN Verbindung die Ursache für das Verhalten bei dir ist.

Bei Kabelanschluss hat man halt in der Regel nur noch IPv6, und hätte ja sein können, dass dadurch die Shellys keine Verbindung zur Shelly Cloud herstellen können. Genauso wie manche VPN Server hier auch nur IPv4 unterstützen und man daher von zuhause im Home Office z.B. keine Verbindung zum Firmennetz aufbauen kann.

Aber du schreibst ja, du hast schon etliche andere Geräte erfolgreich eingebunden, dann scheidet das als Ursache aus.

Aber mal auch für mich zum Verständnis an alle Experten hier:

Wie funktioniert eigentlich die Zuordnung in der Cloud ?

Angenommen, ich habe ein Cloud-Konto bei Shelly und entsprechend mit meiner App auf dem Handy verknpüft. Wie geht das denn datentechnisch von statten, dass ein neuer Shelly weiß, dass er zu "meiner" Cloud gehört ?

Also Schritte sind ja:

1.) Neuer Shelly baut eigenen AP auf.

2.) Man verbindet sich per Smartphone auf diesen AP und ruft das WebUI über die Shelly IO 192.168.33.1 auf.

3.) Dort richtet man den Shelly als WLAN Client ein und gibt ihm die Zugangsdaten zum eigenen WLAN und ggfs. IP, wenn nicht DHCP.

4.) Außerdem aktiviert man auf dem Shelly den Cloudzugriff über das WebUI

Schritte 1 bis 4 kann man ggfs. auch über die Handy Cloud App machen, führt aber zum gleichen Ergebnis.

5.) So, und nun verlässt mich mein Verständnis. Jetzt haben wir ein Handy mit der Cloud App, wo meinetwegen schon 10 Geräte eingebunden sind. Wie läuft das nun ab, dass man das soeben neu hinzugefügte Gerät in die Cloud übernimmt.

Oder anders gefragt, woher weiß denn der neue Shelly, dass er zu "MEINER" cloud gehört ? Der Shelly selbst hat ja bloß Internetzugriff und kann die Shelly Cloud entsprechend erreichen, aber dadurch ist ja noch keinerlei Zuordnung möglich, zu welchem Cloud Account der Shelly denn gehören soll. Woher kommt denn diese Information und Zuordnung ?

Kann es evtl. sein, dass das nur erfolgreich klappt, wenn man die SChritte 1 bis 4 per App macht, dass die App dem Shelly per Netzwerk irgendwie schon die Cloud-ID oder sowas mitteilt ?

Jetifaffe schreibt ja, er hat den Dimmer über das Webinterface aufgerufen und eingebunden.

Kann das eine Ursache sein ?

Nein nein, falsch verstanden.

Also erst mal, es wären NICHT die gleichen Registrierungsdaten, aber so hatte ich das auch nicht gemeint.

Einfach auf den problematischen Shelly einwählen ins WebUI, also bei offenbar die IP 192.168.178.211

Dort im Menüpunkt Internet und Security ganz unten den Punkt CLOUD wählen und dort ENABLE CLOUD. Entsprechend mit YES bestätigen.

Dann kurz warten und dann über Menüpunkt SETTINGS, ziemlich weit unten DEVICE REBOOT.

Und danach sollte innerhalb 5 Minuten das Update erkannt werden, so zumindest bei mir.

Dann führe ich das Update durch und nach dem Update stelle ich die Cloud-Verbindung wieder auf disabled.

Du kannst mal testhalber in den Einstellungen des Shelly die Cloud-Anbindung aktivieren. Ich nutze die Cloud nicht, aber auch bei mir gibt es so etwa 1/3 der Shellys, die kein Firmware-Update machen oder machen lassen, wenn ich die Cloud-Verbindung ausgeschaltet habe, keine Ahnung warum das bei manchen so und bei manchen so ist.

Ich hab es mir angewöhnt, halt dann die Cloud zu aktivieren, Shelly neu zu starten per WebUI und meist innerhalb 5 Minuten zeigt er dann das Update auch an. Danach Cloud dann wieder aus.

Mal ein ganz anderer Ansatz von mir, aber reine Vermutung. Hast du evtl Kabelanschluss als Internetzugang ? Ich habe im Bekanntenkreis nun schon öfter gehört, dass diese Probleme mit manchen Internetplattformen haben, so z.B. auch bei VPN Verbindungen.

Grund hierbei ist, dass manche Kabelanbieter strikt nur noch IPv6 schalten und kein IPv4 mehr.

Ich weiß nicht, wie die Shelly Cloud erreichbar ist, aber es gibt halt manche Anbieter, die noch kein IPv6 unterstützen und dann könnten deine Shellys die Cloud einfach mangels Route nicht erreichen.

Du kannst ja mal mit dem Handy oder Laptop aus deinem heimischen WLAN raus die Internetseite "wieistmeineIP" öffnen, findet man sofort über Google. Und dort wird dir ganz deine öffentliche IP angezeigt. Wenn dort keine IPv4 Adresse auftaucht, sondern nur eine IPv6, wäre das evtl. ein erster Hinweis.

Schubbie.

Ja stimmt, die zulässige Funkauslastung im 868 MHz Band kommt erschwerend noch hinzu., hatte ich gar nicht mehr auf dem Schirm. Das war bei mir damals der Grund, einen begonnenen Ausbau auf FS20 Koponenten nicht weiter zu verfolgen, zum Glück, das System ist inzwischen tot.

Meine Frau ist Baujahr 86, aber auch oldschool mit diesen Dingen. Es soll halt alles funktionieren, aber man (Frau) muss es nicht verstehen, wie.

Ich hatte das Glück, dass ich vor 8 Jahren bei der Hausrenovierung schon einen Eigenbau fürs Licht überall gebastelt hatte (Atmega Microkontroller mit Phasenanschnitt). Die Elektronik konnte quasi genau das, was jetzt der Shelly Dimmer2 kann, außer natürlich einer SmartHome Anbindung. Aber die Steuerung AN/AUS/Dimmen war dort genauso gelöst per Wandtaster.

Jetzt habe ich nach und nach alles durch die Shelly Dimmer 2 ersetzt und meine Frau muss sich nicht umgewöhnen (außer evtl. an die hohe Latenz des Shellys beim einfachen Einschalten)

Aber um beim Thema zu bleiben, ich würde mich da SebMai anschließen, Bastellösungen kann klappen (bei mir ja auch 8 Jahre lang), aber da baut man sich so viele Fehlerquellen und Unsicherheiten ein, abgesehen von einer nicht zugelassenen Installation. Ich hatte jetzt Glück, dass das alles so lange störungsfrei lief, aber fühle mich trotzdem wohler jetzt, wenn alles aus fertigen "Kaufteilen" besteht.

Ich wollte gestern hier eigentlich noch den Drehtaster von ELV vom homematic IP System für 50 Euro nennen, aber dazu wäre dann eine entsprechende homematic Zentrale Typ CCU3 und IObroker von Nöten, dann könnte man per Drehtaster das Licht schalten und Dimmen, aber dafür noch 2 zusätzliche Komponenten im Gesamtwert von gut 200 Euro + viel Zeit zum Einrichten, nur um per Drehknopf das Licht zu dimmen... Stünde in keinem Verhältnis von Kosten, Aufwand zu Nutzen + vermutlich Latenzeffekte, die dann noch mehr Frust erzeugen würden...

Was evtl. noch ein Kompromiss wäre, und ich hoffe, dass ich das hier nenne darf, es gibt von einer Firma "TESSAN" einen Drehdimmer für 30 Euro, der auch ins WLAN eingebunden werden kann und per APP bedient werden kann, also ähnlich dem Shelly Dimmer.

Aber da kenne ich die Protokolle nicht, die da übers WLAN verwendet werden, aber ich vermute, da wird dann ein Cloud-Zwang mit verbunden sein, da auch Alexa von Haus aus unterstützt wird.

Torsten81:

Habt ihr evtl. elektrische Rollläden ? Die haben normal oder zumindest meistens auch Taster für rauf und runter.

Der Dimmer 2 kann auch statt mit 1 Taster mit 2 Tastern gesteuert werden, dann ist explizit einer für heller, der andere für dunkler. Je nachdem könnte man dort die gleichen Tastereinsätze nehmen wie bei den Rollläden und darüber die Frau zumindest über das Argument der Einheitlichkeit überzeugen ?

Frauen regieren die Welt

Wüsste ich im Moment auch keine direkte Lösung.

Muss es unbedingt ein DREH-Dimmer sein oderkKann sich deine Frau nicht an einen Wand-TASTER gewöhnen zum Dimmen ? Das wäre die vernünftigste Lösung, weil direkt vom Dimmer2 unterstützt.

Einzige Möglichkeit, die mir momentan noch einfallen würde, wenn es unbedingt ein Drehdimmer sein muss, dass man einen Dimmereinsatz umbastelt, dass dieser nur noch eine Poti-Funktion hat und das Widerstandssignal ggfs. an einen dahinter verbauten Shelly 1 mit Sensor-Erweiterung anzuschließen, z.B. als Temperaturfühler.

Über iobroker könntest du das auslesen und wüsstest, wie der Dimmerknopf steht und könntest mit dieser Info einen Shelly Dimmer2 fernsteuern. Dann hättest du alle Möglichkeiten per App und per Knopf, aber es wäre eine Bastellösung und setzt irgendein zentrales System wie iobroker voraus.

Aber da kämen dann Effekte wie Latenzen zum Tragen, die das Einstellen per Drehschalter glaube ich nicht intuitiv werden lassen.

Also ich sehe mometan nur die "TASTER" Variante als zielführend...

Wie hell muss der Motor den maximal leuchten ?

Sorry, aber viel mehr "Hilfe" wirst du glaube ich hier nicht zu dem Thema bekommen.

Kondensatormotor-> Drehzahl hängt von Frequenz ab. Dimmer nutzt dir da gar nix, erzeugt dir bloß alle möglichen Induktionseffekte, kein Wunder, dass es dann knallt.

Also, ich kann fast nur hoffen, dass deine Frage nicht wirklich ernst gestellt ist...

Deine Frage zu dem Schalten ab 17 Uhr. Du kannst per URL Action die eigentliche BMW Input Action aktivieren bzw. deaktivieren wie folgt:

http://localhost/settings/actio…l&enabled=false

http://localhost/settings/actio…l&enabled=falsetrue

Nur bräuchtest du jetzt eine Netzwerkquelle, die dir diese Botschaft entsprechend um 17 Uhr an den Shelly schickt mit "true" und morgens entsprechend die "false". Einfach wäre es natürlich per iobroker scripts etc.

Alternativ würde ggfs. ein Handy dafür genügen. Z.B. per llama automate und URL shortcuts. Würde dann allerdings nur klappen, wenn das Handy im die Zeit im Netz ist.

Könnte mir auch vorstellen, dass man eine FritzBox so konfigurieren kann, dass sie entsprechende http requests zeitgesteuert absetzt und so den Shelly BWM Input aktivieren und deaktivieren kann, aber mit dem AVM home automation HTTP Interface kenne ich mich nicht aus.

Hallo root-2k,

ich hatte ein ähnliches Problem mit meinen Dimmer2, die ich in den Fluren verbaut habe. Dort habe ich Bewegungsmelder, die eigentlich nur die Phase per Relaiskontakt durchschalten und dieses Signal habe ich auf den SW2 des Dimmer2 gelegt. Und da war es dann auch so, wenn der BWM geschaltet hat, ging das Licht an, aber wenn das Relais des BWM abgeschaltet hat, blieb der Licht einfach an.

Ich hatte bei mir kein 30s timeout oder so, sondern einfach eine URL action, die das Licht bei input2 False eben abschaltet.

Ich habe bei mir noch eine iobroker Umgebung laufen und dort konnte ich dann sehen, dass trotz abschaltendem BWM der Logikpegel am SW2 Eingang weiterhin auf TRUE blieb.

Der Dimmer2 hat ja eine seltsame Ausgangsbeschaltung für die SW-Eingänge und offenbar kommt es bei mir bei diesen Konstellationen zu Schwingungen, sodass der Dimmer2 sich selbst stört, sobald das Licht an ist, also der Dimmer seinen Ausgang aktiv hat.

Abhilfe haben bei mir Trennrelais gebracht.

Hier ein Auszug aus dem damaligen Thread:

die Relais sind von der Firma SCHRACK, Typ RT114-AC230.

Kosten 3,30 Euro / Stück und sind LxBxH 30x13x16 mm groß.

Habe mir dazu noch Schrumpfschlauch genommen und schrumpfe sie dann darin ein, sodass da nur noch 3 Strippen rauskommen, die man dann direkt mit den Shellys bzw. Schaltaktoren etc. verbinden kann.

3 Strippen-Belegung wie folgt:

1x Nullleiter

1x Phase Schaltsignal (also z.B. die geschaltete Phase eines Bewegungsmelder-Ausgangs)

1x Phase Ausgang zum SW-Eingang des Shellys.

Funktion:

- Das Schalt-Signal des Bewegungsmelders ist Phase.

Dieses geht dann an einen der Pole der Relaisspule und parallel nochmal an den den Pol1 des Relais-Schließer-Kontakts.

- Nullleiter entsprechend am 2. Pol der Relais-Spule.

- Und am Ausgang des Relais-Schließers Pol2 ist der Draht angebunden, der von dort direkt zum Shelly SW Eingang geht.

Wenn nun das Relais in Ruhestellung ist, hängt der Relais-Schließerausgang Pol2 in der Luft und somit ist das Potential am SW-Eingang des Shelly ebenfalls potentialfrei und dieser "sieht" nur das offene Stück Leitung bis zu diesem Kontaktausgang, also wie bei einem nicht betätigten Taster.

Kommt nun vom Bewegungsmelder die geschaltete Phase, dann wird die Relaisspule bestromt, das Relais zieht an und schaltet dadurch dieses Phasenssignal, das vom Bewegungsmelder kommt, über den Relais-Schließerkontakt Pol1 durch zum Pol2, der dann zum Shelly SW Eingang geht. Dieser "sieht" dann also auch L-Potential.

Schaltet der Bewegungsmelder ab, fällt auch das Relais ab, der Schließer öffnet wieder und der SW-Eingang hängt wieder frei in der Luft.

Mit dieser Beschaltung schaltet der Shelly dann sauber das Licht aus, wenn der BWM abschaltet.