Beiträge von dewaldo

Zitat von KAyAN

etzt ist die Kalibrierung ohne Fehler durchgelaufen aber beim Betätigen der Taster wurde OVERCURRENT PEAK gemeldet und die Beleuchtung hat sich ausgeschaltet.

Also wenn die Kalibrierung schon mal durchgelaufen ist, ist das ja schon mal was.

Wenn es nun das Thema "Strompeak" beim Einschalten ist, evtl. hilft es, wenn du mal die Transition time auf 5000 ms stellst, damit der Dimmer2 die LEDs erstmal "hochfährt".

Ob das ausreicht, weiß ich nicht, aber wäre einen Versuch Wert.

Weiter kannst du mal versuchen, das Licht nicht über die Wandtaster einzuschalten, sondern über das Webinterface des Shelly und da z.B. erstmal die Helligkeit auf 10% zu setzen, ob sich dann per WebInterface das Licht ein und ausschalten lässt.

Der SW Input dient ja dazu, das Relais im Shelly zu steuern. Wenn du darüber deine Lampe entsprechend bestromst, bewirkt eine Änderung am SW Eingang auch eine Änderung des Relais, sodass dann auch die Lampe geschaltet wird.

Was du ja möchtest ist, dass das Signal, was vom Bewegungsmelder kommt, das Relais im Shelly NICHT ansteuert nachts.

Mein Vorschlag wäre eine Kombination aus deiner ersten Verdrahtung plus der Idee von SebMai.

Die Variante von SebMai ist gut, aber kann evtl. mit der Verdrahtung problematisch werden, je nachdem, wie das bei dir vor Ort aussieht.

Ich würde daher an der Verdrahtung erstmal nichts ändern, also Bewegungsmelder bleibt dauerhaft versorgt und schaltet sein Ausgangssignal auf den SW1 Input des Shelly. Und vom Shelly Output geht's zur Lampe, das passt alles.

Was du nun tun must ist, dem Shelly sagen können, dass er während einer gewissen Zeitspanne eben nicht auf den Bewegungsmelder reagieren soll.

Das macht man, indem man im Shelly konfiguriert, dass der Button Type = detached ist. D.h. der Shelly reagiert dann nicht mehr auf Signale am SW Eingang.

Und das kann man per http-Befehl tun. Und um dem Shelly diesen http Befehl z.B. abends um 0:00 Uhr und morgens um 06:00 Uhr zu übermitteln, kannst du den Kanal 2 des Shelly misbrauchen.

Du erstellst ein Schedule im Shelly für den Kanal 2 und sagst, 0:00 Uhr = EIN, 06:00 Uhr = AUS.

(Hinweis: Ich wähle das so herum, weil das Relais 2 dann nur 6 Stunden lang geschaltet wird. Man könnte es auch umgekehrt machen, 0:00 Uhr AUS und 06:00 Uhr EIN, aber dann wäre es halt 18 Stunden bestromt.)

Im Shelly gibt es dann die URL Actions. Dort hast du getrennt für Kanal 1 und Kanal 2 welche.

Du müsstest dann beim Kanal 2, dessen Relais dann ja per Schedule immer ein- und ausschaltet, 2 Actions hinterlegen.

1. Action: Output switched on:

http://localhost/settings/relay/0?btn_type=detached

Sobald nun abends um 0:00 Uhr der Schedule den Kanal 2 des Shelly EIN schaltet, wird diese URL "Output swichted on" ausgeführt und diese deaktiviert den Taster am Eingang SW1, sodass ab dem Moment der Shelly nicht mehr auf den Bewegungsmelder reagiert.

2. Action: Output switched off:

http://localhost/settings/relay/0?btn_type=toggle

Sobald morgens um 06:00 Uhr der Schedule den Kanal 2 wieder abschaltet, wird eben die entsprechend Action "Output switched OFF" ausgeführt. Diese setzt den Button Type des Kanal 1 wieder auf "Toggle", wodurch dieser wieder auf den Bewegungsmelder reagiert und sein Relais schaltet, was die Lampe bestromt.

Mir fällt nur ein, Gartenhaus -> Sommer -> Stauhitze -> schnellere Alterung Kondensatoren...

Vom Shelly 2.5 ist ja bekannt, dass die gerne mal vorzeitig ausfallen, weil die Kondensatoren im Netzteil hinüber sind. Der 2.5er ist auch einer, der im Vergleich zu anderen Shelly, meist wärmer ist im Betrieb und damit auch schneller altert.
Von daher könnte ich mir vorstellen, wenn du schreibst, läuft seit Jahren ..., dass der einfach jetzt ein ähnliches Problem hat.

Dass er seinen AP aufmacht, kann ich nicht beurteilen, aber wenn er in einem kurzen Zeitraum oft rebootet, wäre das ja so ähnlich wie das Rücksetzen eines Shelly durch mehrmaliges AN / AUS - Setzen der Sicherung im Verteilerkasten bei Shellys, die keinen Taster angeschlossen haben.

Wenn du sonst nix an deinem Setup verändert hast, wäre das leider mein Tipp, Shelly hat einen Netzteildefekt...

Während du jetzt MQTT aus hattest, wie hast du denn in dem Zeitraum die Rollläden verfahren, ausschließlich per Wandtaster und App ?

Und als du MQTT an hattest, aber den Shutter Control Adapter ausgeschaltet hattest, wie hast du da die Rollläden verfahren ?

Ich kann mir weiterhin nicht vorstellen, wie die MQTT Schnittstelle das verursachen sollte, außer durch das Vorgeben von Kommandos an den Shelly.

Der Wechselrichter wird aber wahrscheinlich nur einen potentialfreien Schaltkontakt haben, um "Überschuss" zu signalisieren, oder ist er richtig smart ?

Je nach Wallbox (meine zum Beispiel) kann ich die dann per MQTT auch in der Ladeleistung modulieren. Kannst dann sagen, du hast gerade 4 kW Überschuss, dann soll auch die Wallbox nur mit 4kW laden.

Für so ein Finetuning wäre ein 3EM dann doch sinnvoll, außer du kannst deinen Umrichter über einen Adapter in ioBroker direkt auslesen.

Wobei ich gestehen muss, obwohl das Modulieren der Ladeleistung durch die Wallbox ans Fahrzeug (per PWM) für den Bereich ab 6A pro Phase definiert ist, macht mein ID3 das nicht mit. Ab 10A nach unten ist Schluss, dann beendet das Auto das Laden (warum auch immer). Zum Glück hat der ID3 ja sonst keinerlei Macken

Wenn du zurück bist vom Eis essen

solltest du mal an einem Gerät, was du zur Einrichtung der Shellys verwendest (das, wo die Shelly App drauf läuft), das Bluetooth komplett deaktivieren.

Du hast offensichtlich Shelly PlugS der 2. Generation, also die PLUS Variante, welche auch Bluetooth können. Und wahrscheinlich findet die App diese deshalb über Bluetooth statt über WLAN.

Also Bluetooth AUS und dann nochmal von vorne versuchen. RESET der PlugS machen und dann senden die ein eigenes WLAN, die machen also einen WLAN AP (Access point) auf.

Rest dann wieder wie apreick schon geschrieben hat.

Und der Tipp. Nicht gleich alle 3 PlugS einstecken, erst mal nur einen nach dem anderen.

Zitat von Wienun

Du meinst ich soll die IP von 11 auf 12 Stellen erweitern?

Muß ich im netz suchen wie das geht?

Du bist ziemlich ungeduldig, entschuldige, wenn ich das so einwerfe. Aber anhand deiner Netzwerk-Kenntnisse ist ein Shelly eigentlich nicht das richtige Produkt für dich, da dir wirklich alle Grundlagen fehlen.

Es wird versucht, dir hier zu helfen, aber bitte versuche dann auch, die dir empfohlenen Schritte zu beherzigen und eins nach dem anderen zu machen, sonst endet das nur im Chaos.

Und zur Erläuterung: Eine IP Adresse (v4) hat immer dieselbe Länge, da gibt es nicht 11 oder 12 Stellen.

Hier ist die Rede von ID = Identifkation, nicht IP). Das ist die Nummer, die einen Shelly eindeutig identifiziert, z.B. bei Nutzung über die Cloud.

Vor allem bei den Plug-S gab es lange noch Chargen, die ausgeliefert wurden und werden, bei denen der Shelly eine 6-stellige ID hat, da kann es zu Doppelbelegung in der Cloud kommen.

Und solche Shellys kann man umstellen auf 12-stellige IDs. Als Schlagwort "Shelly longifyID". Darunter findest du, wie das gemacht wird, aber ist aktuell nicht vorrangig.

Die SW Eingänge sind doch ziemlich "empfindlich", weil sie kaum Steuerstrom benötigen und gerne mal durch kapazitive Einkopplungen usw usw. auch false positive reagieren, obwohl kein echtes Schaltsignal anliegt.

Z.B. die bekannten Probleme bei Anbindung eines per Relais schaltenden Bewegungsmelders. Da gibt es z.B. durch das Kondensatornetzteil im Bewegungsmelder Auswirkungen auf den SW Eingang.

Ein echtes Schütz ist auf jeden Fall deutlich sicherer und auch recht günstig, das Geld würde ich investieren.

Davon abgesehen würde ich wahrscheinlich auch die Heizwendel selbst nicht direkt über die Shellys bestromen, weil 2 kW Dauerlast am Shelly Relaiskontakt ist schon viel.

Klar, die sind bis 16A ausgelegt, aber ich setze viele Shellys ein, aber hohe Leistungen habe ich damit noch nie geschaltet und werde ich auch nicht, weil ich denen das auf Dauer nicht zumuten möchte.

Es gibt aber noch mehr Gründe, die dagegen sprechen, die SW Eingänge so zu verwenden:

1.) Die 3 Shellys, die die 3 verschiedenen Außenleiter zur Heizung schalten, müssen ja selbst auch versorgt werden und ich vermute mal, du hast die mit dem Außenleiter versorgt, den sie auch jeweils durchschalten zum Heizelement ?

-> Würdest du nun vom 4. Shelly, der die Pumpe schaltet, dessen Ausgangssignal jeweils auf diese anderen 3 Shelly SW Inputs legen wollen, dann hättest du unterschiedliche Außenleiter von Shelly Versorgung und Shelly SW Input, das sollte man vermeiden!

2.) Dadurch, dass du den Ausgang des Shelly 4 zu allen 3 SW Inputs der anderen verbinden müsstest, wären auch die 3 SW Inputs untereinander verbunden. Da bin ich mir nicht sicher, ob das evtl. Probleme macht.

3.) Die Pumpe, die dein Shelly 4 ansteuert, liegt ja ebenfalls zwischen L und N, wobei N dauerhaft mit der Pumpe verbunden bleibt. Wenn nun der Shelly 4 die Pumpe EIN-schaltet, dann würden auch die anderen 3 Shelly das am SW Input erkennen, so ja dein Gedanke. Das stimmt auch. ABER: Wenn der Shelly 4 nun die Pumpe AUS-schaltet, dann sehen die 3 Shelly SW Inputs immer noch den offenen Kontakt zur Pumpe und da deren anderer Pol durchgehend an N liegt, ist darüber der Stromkreis Richtung N noch gegeben, wodurch auch bei abgeschaltetem Shelly 4 trotzdem alle anderen 3 Shellys den SW Eingang als HIGH erkennen würden.

Die Shelly SW Inputs liegen bei 230V Anwendung auf ca. 110V und nur dann sind sie vom Logikpegel "LOW". Werden sie auf N gezogen oder auf L, ist das jeweils "HIGH".

Deshalb klappt das alleine schon nicht so.

In deiner Skizze hast du rot und blau als Drahtfarben. Farben sagen zwar erst mal nix, aber in der Regel ist ROT=PLUS und BLAU=MINUS.

Wenn das bei dir auch so ist, dann hast du den Shelly verpolt angeschlossen. MINUS muss auf L, PLUS auf die 12V+ bei direkter 12V Versorgung.

Spontan sage ich, alle Lösungen, die auf der Verschaltung von Shellys untereinander beruhen, wären mir für so eine Anwendung zu unsicher, da sie allesamt auf Software-Verhalten beruhen.

Heißt, auch mit der richtigen Verschaltungslogik kann es trotzdem passieren, dass was schief geht.

Ich würde es so machen, dass ich am Shelly, der die Pumpe schaltet, parallel zur Pumpe ein 230V Schütz mit 3 Schaltkontakten anschließen würde.

Wenn dann die Pumpe einschaltet, zieht auch dieses Schütz an. Und über die 3 Schaltkontakte dieses Schützes würde ich die 3 Leitungen führen (L1, L2, L3), die zu den Tauchsiederwendeln gehen.

Dann bist du sicher, dass die 3 anderen Shellys, die die Heizwendel schalten, die Wendel nur dann tatsächlich auch bestromen können, wenn die Pumpe bestromt ist.

So hast du zumindest elektrisch die Shellys aus deiner Unsicherheit draußen.

Was noch bleibt ist, dass du eigentlich auch einen Strömungswächter bräuchtest, der auch wirklich detektiert, dass die Pumpe auch etwas fördert. Bestromt muss ja nicht heißen, dass sie auch korrekt läuft.

Also ich persönlich glaube nicht mehr, dass es an der MQTT Kommunikation liegt.

Was du vielleicht mal noch probieren kannst (hat in einem ähnlichen Thread auch geholfen) wäre, die Zeit und Werteschwelle für die Erkennung des IDLE Zustands des Rollladen-Motors im Shelly anzupassen.

Das wäre im Shelly Webinterface des Plus2PM. Dort im horizontalen Reiter "Settings", also der zu den Cover-Einstellungen gehört.

Dann dort den Punkt "Idle power threshold" mal etwas hochsetzen. Normal steht der auf 2W. Dann z.B. mal auf 5W anpassen.

Und als letztes noch unter dem Settings-Menüpunkt "Idle confirm period" den Wert erhöhen. Steht normalerweise auf 0,25s. Einfach mal auf 1s erhöhen.

Der Shelly scheint nach dem Abschalten der Last diese Zeit zu überwachen. Im anderen Thread war es so, dass nach dem Stopp des Rollladens in einer Zwischenposition diese Idle confirm period zu kurz war, sodass der Shelly trotz Stopp noch eine Restleistung gesehen hat, die über dem Idle power threshold lag. Folge ist dann, dass der Shelly darin ein Fehlverhalten sieht und z.B. keine direkte Richtungsumkehr mehr zugelassen hat.

Ebenso könnte ich mir gut vorstellen, dass er intern die aktuelle Position in dem Moment auch als ungültig setzt.

Versuch ist es Wert ...

Im ioBroker hängt es davon ab, wie du die Shellys ausliest.

Falls du wegen den Shelly Plus z.B. den Shelly Adapter verwendest und den dann über MQTT den Datenaustausch machen lässt, dann musst du im Shelly in dessen Einstellungen unter MQTT Settings die Optionshäkchen setzen für "RPC status notification over MQTT" und "Generic status update over MQTT".

Wenn du die 2 aktivierst, solltest du anschließend auch die entsprechenden Datenpunkte im ioBroker sehen und Updates der Werte bekommen.

Ah, ok. Ich hatte das nie selbst verwendet. Ich dachte Cycle bedeutet, dass er so lange rauf und runter dimmt, bis man dim=stop setzt.

Na dann korrigiere ich meine Aussage und erkläre auch diese Maßnahme für sinnfrei.

Ja, vor allem ist es dann auch wieder inkonsequent umgesetzt. dim=up funktioniert ja weiterhin OHNE step - Parameter, aber dim=down nicht. Das ist ja mal relativ sinnfrei.

Dim=cycle kann man sich ja irgendwo noch erklären, dass Alterco vermeiden will, dass ein Shelly endlos rauf- und runter dimmt, aber den step-Parameter als zwingend notwendig festzulegen verstehe ich nicht.

Zitat

dim=down in Verbindung mit &step=x?

Nein, ohne den Parameter step. Ich war bislang der Meinung, wenn man den step-Parameter weglässt, dass der Dim-Befehl dann so ausgeführt wird, als hätte man "step=100" mit angegeben ?

Beispiel URL Verhalten wie folgt:

Wenn ich die Helligkeit auf 1% stelle und führe dann:

http://192.168.178.50/light/0?dim=up

aus, dann dimmt das Licht von 1% langsam hoch auf 100%.

Wenn ich anschließend dann

http://192.168.178.50/light/0?dim=down

ausführe, passiert gar nichts. Licht bleibt auf 100% einfach an. Hier hätte ich erwartet, dass es wie bei dim=up entsprechend auf 1% herunter dimmt.

Zitat von LuckyLuke_23

Aktive WLAN-Geräte dürfen untereinander kommunizieren, mit Haken. Also jetzt wieder aktiv.

Aber das kann ja nicht die Ursache gewesen sein ??

Ursprungsausgang war ja, ohne Verschlüsselung geht es, mit Verschlüsselung nicht.

Oder ist die FritzBox dann so, dass sie bei offenem WLAN auch gleich die Kommunikation untereinander erlaubt ? Glaube ich nicht.

Nachtrag:

Ich habe gerade mal ausprobiert, ob sich vielleicht ein dim=cycle wieder eingeschlichen hat, aber leider nicht.

ABER: Was bei mir gerade ebenfalls nicht mehr geht, ist dim=down.

Dim=up funktioniert ordnungsgemäß, aber dim=down tut überhaupt nichts. Lediglich, wenn ich das Licht AUS schalte, während Brightness=100 ist, und dann dim=down aufrufe, schaltet der Shelly ein, aber springt sofort auf 1%. Ich vermute da einen Zusammenhang mit demselben Bug...

Fix wurde eingespielt und funktioniert wieder. Vielen Dank für die schnelle Reaktion

Auch von mir Bestätigung. Meine Dimmer2 laufen allesamt im OneButtonMode und bei mir gleiches Fehlverhalten

Nachtrag: Wie Schubbie geschrieben hat, springt der Dimmwert dann sofort auf 1% aber Shelly ist noch EIN geschaltet.

Das Licht geht schlagartig aus, auch, wenn man z.B. mit einer Transition time auf 5000ms arbeitet.

Bei Setzen per WebInterface oder MQTT z.B. von 100% auf 1% wird die Transition time eingehalten.

Alles klar, vielen Dank