Beiträge von dewaldo

Hi zusammen. Das Thema hat mir keine Ruhe gelassen und meinen "Spieltrieb" geweckt. Erst mal ja, ich kann das von dir beschriebene Verhalten bestätigen. Aber ich habe trotzdem eine Lösung gefunden, die einwandfrei funktioniert, gerade getestet.

Und zwar habe ich herausgefunden, dass der shelly die lokalen Action URLs, die ihn selbst triggern, nur dann unterdrückt, wenn die entsprechende Action auch aktiv ist. Und daher habe ich es jetzt wie folgt gelöst und den Mechanismus quasi ausgetrickst.

1.) Bei den Actions für Output Switched off folgende 2 URLs setzen:

http://localhost/settings/actions?index=0&name=out_off_url&enabled=false

http://localhost/relay/0?turn=off&timer=5

2.) Dann unter Output Switched ON folgende URL eintragen:

http://localhost/settings/actions?index=0&name=out_off_url&enabled=true

Das war's.

Kurz zur Erläuterung, was nun passiert:

- Shelly Relay wäre aktuell EIN. Dann wird der Output abgeschaltet, z.B. wegen overpower protection. Dies löst die Action Output Switched off aus. Dadurch wird erst deren url 1 ausgeführt. Diese deaktiviert ab diesem Moment die Action für Output Switched off für zukünftige Events. Anschließend wird die aktuelle Action aber noch fertig abgearbeitet und daher ihre url 2 noch ausgelöst, welche dann den gewünschten Befehl der Einschaltverzögerung mit 5s kommandiert. Damit endet die Action und da ja nun aus Shelly Sicht die Output Switched off Action auf disabled steht, wird das verzögerte Einschalten nicht mehr unterdrückt. Der shelly schaltet nun wie gewünscht nach 5s wieder ein.

- Damit das beim nächsten Mal erneut so abläuft, wird nun beim Einschalten die "Output Switched On" Action getriggert und die URL dort bewirkt entsprechend, dass die Action für Output Switched off wieder scharf geschaltet wird.

"Endlosschleife" hierbei aber in der Art, dass du im WebInterface die Zeit runterzählen siehst für die Einschaltverzögerung und wenn sie 0 erreicht, schaltet der Shelly aber nicht, sondern die Zeit fängt wieder an zu zählen ? Wie sieht denn die Output switched off URL konkret aus ? Würde mich einfach interessieren ...

Mich hatte nur deine Aussage irritiert, dass der Shelly dann SOFORT wieder einschaltet und nicht mit Verzögerung. Das würde ja bedeuten, dass er die Einschaltverzögerung-Action schon "versteht", dass er mit einer OFF-Anweisung EIN-schaltet, aber er würde den Timer-Wert misachten? Das kam mir halt komisch vor, daher hatte ich das geschrieben ...

Zitat von elektroman

Das funktioniert aber in keiner Timer/Action Kombination. Wenn ich mit Timer arbeite, schaltet sich der Shelly sofort wieder ein - egal, was man einstellt oder ihm als timer=xy sendet

Zwar unwahrscheinlich, aber trotzdem die Frage. Du müsstest ja einen "OFF" Befehl verwenden, nicht "ON", um zeitverzögert einzuschalten. Nicht, dass du das verwechselt hast ?

Also "...turn=off&timer=5

Habe den Thread gerade gelesen und es ist selten, dass ein Thread so informativ und strukturiert läuft.

Muss da einfach mal ein kleines Lob an alle Thread-Beteiligten los werden, top!

Wie ist es denn mit dem Nullleiter am Shelly Dimmer2? Ist der vielleicht bei einer Variante dran, bei der anderen nicht ?

Zitat von Jackass

Ich möchte gern das ich eine Push Nachricht bekomme, sobald das Garagentor hoch geht (Nur hoch, nicht runter).

Wenn du aber keinen Magnetkontakt installiert hast und der Shelly hier halt nur den Taster-Impuls simuliert, dann bekommst du eine Pushnachricht, jedes Mal, wenn das Tor gesteuert wird, aber keine Unterscheidungsmöglichkeit, ob sich das Tor daraufhin öffnet oder ob es sich schließt.

Das Thema mit der Mindestlast glaube ich nicht so richtig, eher, dass es die Kombination ist, dass L durch den Sensorschalter nicht direkt über das Relais geschaltet ist und dadurch der SW Input am Shelly den Schaltzustand nicht korrekt erkennt.

Ich würde man hingehen und das Webinterface vom Shelly1 aufrufen. Dort siehst du oben rechts das POWER-Symbol, mit dem du das Shelly Relais ein- und ausschalten kannst.

Und innerhalb dieses Symbols gibt es einen kleinen senkrechten Strich oben. Wenn dieser Strich blau dargestellt wird, heißt das, der SW Input wird aktuell als HIGH erkannt. Ist er weiß, entsprechend LOW. Ich vermute, dass egal, ob der IR Sensor gerade geschaltet hat oder nicht, der Strich am Shelly IMMER blau sein wird, d.h. der Shelly den Schaltwechsel nicht erkennt.

Es gab hier außer den Standardlösungen "Trennrelais" auch noch die Maßnahme, einen Widerstand vor den SW Input zu setzen, aber hier in dann Thomas thgoebel der Experte und kann die Theorie vielleicht noch genauer erläutern. Zumindest war das bei mir auch bei allen Bewegungsmeldern so, wie es Krauskopp weiter oben auch schon erwähnt hatte.

Zitat von Rudolf Nagy

Interessant ist, daß es bei dir in Echtzeit geht. Wie überträgst Du den Schaltbefehl an den zweiten Dimmer ? über DDD also direkt vonb Shelly zushelly oder über MQTT über eine Rule im iO Broker ?

Bei mir läuft es über ioBroker, der innerhalb einer Linux VM auf einem Synology NAS (DS220+) läuft.

Im ioBroker ist die Shelly Adapter installiert und alle Shellys laufen bei mir über MQTT.

D.h. ich habe etliche Scripte laufen und eines davon reagiert auf den SW2 Input eines Dimmer2, an den dort halt ein Bewegungsmelder angeschlossen ist.

Und das Script steuert dann entsprechend einen weiteren Dimmer2 an. Ich habe auch noch weitere Bewegungsmelder, die an einem Wemos D1 mini über TASMOTA und MQTT angebunden sind, funktioniert genauso mit den Scripten. Verzögerungen sind dort immer < 1s.

Über DDD habe ich aber auch schon gemacht und das geht eher sogar noch einen Tick flotter als den Zwischenschritt über das ioBroker Script.

Mit OpenHab habe ich leider keine Erfahrungen, aber das wirkt auf mich so, als würde dort z.B. der Status gepollt statt als "Event" geupdated. Vielleicht lässt sich das umstellen...

Aber am besten erläuterst du nochmal genauer, wie du die Shellys eigentlich eingebunden hast ?

Du schreibst, per MQTT fx siehst du den Status sofort, per Openhab erst später. D.h. deine Shellys kommunizieren auch im Openhab mittels MQTT ?

Weil du kannst ja nur 1 MQTT Broker verwenden mit entsprechendem Port, also entweder MQTTfx oder halt Openhab. Nicht, dass du in Openhab dann die http-Schnittstelle verwendest und dort z.B. nur alle 15s den aktuellen Status "pollst" ?

Da gibt es leider nicht viel, was du tun kannst, außer tatsächlich mal einen Bypass auszuprobieren.

Der Sonoff benötigt halt weniger Versorgungsleistung als der Shelly und ist zugelassen bis zu einer Mindest-Anschlussleistung hinunter auf 3W. Ein Shelly ist halt mit seinen Mikroprozessor und permanenter WLAN Kommunikation einfach leistungshungriger und dies resultiert halt in einem höheren Standby-Strom, der dann leider ausreicht, deine LEDs im Standby sichtbar flackern zu lassen.

Und nun schreibe ich den Beitrag, den ich wahrscheinlich schon 5x geschrieben habe, einfach sicherheitshalber:

iamsholly:

Betreibst du ein übergeordnetes System, z.B. ioBroker ?

Wenn ja, es gab/gibt, falls du dort den Shelly Adapter verwendest, die Option, Firmwareupdates automatisch zu installieren.

Da gab es immer mal wieder solche Phänomene, dass der Adapter einen Shelly dann zum Update getriggert hat, dies aber fehlgeschlagen ist und das dann quasi wie eine Art Dauerschleife zur Folge hat, dass der Adapter sieht, oh, neues Update verfügbar, also hopp, bitte updaten. Update schlägt fehl, Shelly bootet dabei neu. Später prüft der Adapter wieder und sieht, oh, Update verfügbar ... usw...

"Detached" musst du über das Webinterface vom Shelly einstellen. Also im Browser z.B. am Handy im gleichen WLAN wie der Shelly:

http://IPdesShelly

Dort dann bei Settings ... BUTTON TYPE .... Detached Switch auswählen.

Diese Einstellung hat nur den Zweck, dass der Shelly nicht durch Störungen usw. auf ein Signal auf seinem SW Eingang reagiert. Da ist ja nichts angeschlossen, kein Taster etc.

Und um sicher zu gehen, dass der Shelly hier nicht irgendwas schaltet, ohne dass man es per App tut, soll man den Button Type halt auf Detached stellen. Das bedeutet, dass das Signal des SW Eingangs nicht den Schaltzustand des Shelly Relais beeinflusst.

Und die Auto Off - Zeit kannst du ebenfalls im WebInterface einstellen. Diesmal aber nicht unter "Settings", sondern unter dem Menüpunkt "Timer".

Wichtig ist, dass du Masse und +24V nicht verwechselst beim Anschluss O und I, also dass du dort wirklich die Masse schaltest, nicht die +24V, sonst wird der Torantrieb vermutlich nicht reagieren.

Vielen Dank für die Messung. Wobei es natürlich bisschen ungünstig ist, dass du als Verbraucher eine Glühbirne verwendet hast. Das hatte ich ja oben schon als Scherz angebracht, dass ich dann Glühbirnen benutzen muss wegen des niedrigen Kaltwiderstands. Da fällt dann ja am Leuchtmittel im Standby quasi garkeine Spannung mehr ab, dann kann auch kein Mehrverbrauch daher kommen. Aber ist auch wirklich genug jetzt

Da sie schreibt, dass das Dimmen per App funktioniert, muss der braune Draht am OUT auf jeden Fall direkt über die Lampe führen, von daher meine Annahme, dass der Output parallel zum Stromstoßrelais geklemmt wurde. Das erklärt auch, dass man in der App natürlich nicht sieht, wenn per Taster über Stromstoßrelais das Licht angeschaltet wird und erklärt ebenso, dass es sich natürlich über die App dann auch nicht mehr ausschalten lässt.

Aber beim letzten Satz stimme ich zu, was den "Elektriker" betrifft.

Oh ha,

also mein erster Eindruck anhand deiner Beschreibung ist: Im Flur 4 Taster, es brummt beim gedrückt halten, da schließe ich auf Stromstoßrelais, was also vor der Shelly Installation im Betrieb war.

Und anhand des Bildes, was du gepostet hast, muss ich die Hände über dem Kopf zusammenschlagen. Das wirkt auf mich so, als wurde der Shelly einfach parallel als Aktor zum bestehenden Stromstoßrelais an die Lampe angebunden. Am Shelly selbst sind beide SW-Eingänge nicht belegt. Diese müssen normal als Schalter- bzw. Tastereingänge verwendet werden.

So wie es jetzt ist kannst du per Wandtaster das Stromstoßrelais ein/ausschalten, was das Licht vermutlich dann zwischen AUS und VOLLE HELLIGKEIT hin und her schaltet.

Und wenn das Licht aus ist, kannst du per App über den Shelly auch dimmen.

Das geht so beim besten Willen nicht und auf lange Sicht wird das den Shelly vermutlich auch zerschießen !

Ja, ich habe aus dem Grund auch bislang keine einzige Installation OHNE N. Das Gästebad Erdgeschoss ist mein einziges Sorgenkind, da war ich damals leider nicht vorausschauend genug, in die Schalterdose den N mitzuführen, weil ich dachte, hey, ist nur Gäste-WC... Aber die Kids nutzen es viel und lassen permanent das Licht an ...

Aber bisher versuche ich es noch mit "Erziehung" in den Griff zu kriegen

Zitat von Thiemo Stolz

wenn ich nicht alle Dosen senken muss, sondern den Taster einfach an die Wand kleben würde.

Diesen Satz deute ich so, dass du aber durchaus an den gewünschten Stellen neben den Fenstern schon Dosen sitzen hast mit entsprechender Stromzuführung, um dort dann einen Shelly Plus 2 PM einzubauen ?

Weil wenn dem so ist, würde ich dir zu den entsprechenden Shelly "Wall switches" raten. Die gibt es bis zu 4-fach Ausführung (und sind extra dafür ausgelegt, mit minimalem Bauraum innerhalb der Dose auszukommen. Das sind quasi Taster, die nur für das Schalten geringer Lasten ausgelegt sind, halt zum Ansteuern eines Shelly SW Inputs zum Beispiel.

Wenn du aber neben deinen Fenstern aktuell gar keine Dose hast und das so gemeint war, dass du den Shelly irgendwo in der Zuleitung zum neuen Rollladen "verstecken" willst, dann wüsste ich so keine direkte "Nur Shelly"-Lösung. Gehen würde sowas z.B., wenn du ZigBee, also Batterie-betriebene Schalterlösungen, einsetzt in Kombination mit einem Broker-System, welches halt ZigBee verarbeitet und dann den Shelly ansteuert. Oder über Bluetooth, wie von Devil erwähnt, aber da habe ich selbst keine Erfahrungen mit.

Nachteil bei der Shelly-Button Lösung ist halt, dass du da nur 1 Button hast und darüber per Logik festlegen musst, was denn wann passiert.

z.B. 2x kurz drücken = Rolladen rauf, 3x kurz drücken = Rolladen zu, 1x kurz drücken = Rollladen Stopp.

Sowas ist halt weniger intuitiv als eine Anordnung mit 2 Tastern für rauf und runter, wo man einfach nur tippen muss.

OK, einverstanden, führt ansonsten jetzt auch zu weit. Jedenfalls danke für deine Rückinfos zu dem Thema.

Na ja, aber auch, wenn der Step-Down Wandler weniger Verluste hat, wenn eingangsseitig eine geringere Spannung liegt, kann es ja in Summe nicht sein, dass der Gesamtverbrauch gleich ist.

Angenommen, ein angeschlossenes LED Leuchtmittel "glimmt" so vor sich hin durch den kleinen Strom, der halt im Standby darüber fließt. Dann wird hier trotzdem eine kleine Menge Energie umgesetzt, zusätzlich zu der, die der Shelly benötigt. Vielleicht hattest du meine Annahme auch falsch verstanden. Ich meinte nicht den Shelly selbst im Verbrauch, sondern die Standby-Stromaufnahme der Gesamtinstallation aus Shelly mit Leuchtmittel, wenn kein N und kein Bypass installiert wird, dass hier dann mehr Standby-Verluste sind. Und da war meine Frage, ob es da Erfahrungswerte gibt, was in Summe hier mehr verbraucht wird.

Ja, das finde ich auch. Speziell dieses Verhalten kann ich ehrlich gesagt auch garnicht nachempfinden, warum man gerade das unterbindet. Wie geschrieben, sollte man hier echt eine Endloschleife gebastelt haben, merkt man das als Anwender sofort und wer solche Actions einsetzt, der kapiert das auch sofort. Ist wie mit allem, möglichst alle Freiheiten nehmen, die zu einer Fehlbedienung führen könnten, auch auf Kosten von sonstigem Nutzen. Mir fällt da nur der Spurhalteassistent bei meinem Auto ein, der verursacht viel mehr Probleme und kostet mich viel mehr Nerven, als er mir je in irgendeiner Weise genutzt hätte. Aber nein, hier darf nicht jeder Nutzer entscheiden, ob er ein solches System nutzen möchte, nein, es wird per Gesetz zwangsaktiviert...

Sorry, vielleicht etwas OT, aber musste mal raus...