Eco Mode sollte man aktuell nicht nutzen. Das hat bei mir dauerhaft geholfen.
Das dachte ich auch. Ein paar Tage ging auch alles gut. Gestern hat sich der erste Plus2PM und heute morgen der zweite "aufgehangen". Entweder funktioniert die Leistungsmessung nicht mehr oder er verliert seine Kalibrierung. Zwar hat das Abschalten des eco-Mode dazu geführt, dass die Aussetzer des Plus2PM weniger wurden, die vollständige Fehlerfreiheit konnte ich damit allerdings nicht erreichen. 
Das klingt exakt so wie meine Probleme mit den plus 2pm. Rolladen fährt 2-3 Mal anstandslos rauf und runter, bleibt dann aber beim nächsten mal auf ca. 10% hängen. Erst ein reboot bringt ihn wieder zurück zu normal. Problem scheint die Leistungsmessung zu sein. Die stürzt irgendwie ab und der Shelly denkt dann der Motor hat sich abgeschaltet.
Hast du mittlerweile eine Lösung für dein Problem? Hast du z.b Mal RC snubber verbaut? Frage mich gerade ob das Problem durch Spannungsspitzen beim Schalten ausgelöst wird.
Hat der alte Shelly 2.5 an deinen Motoren dasselbe Problem?
Hallo zusammen,
bis heute hat sich ja offensichtlich bei der Behebung dieses Fehlers nichts getan. Die Fehlerbeschreibungen decken sich eins zu eins mit meinem Problem.
Ich habe ebenfalls die Leistungsmessung in Verdacht: Tritt der Fehler auf, sieht man über das WebUI sehr schön, dass die Leistungsmessung nicht funktioniert.
Ich werde jetzt noch den Eco-Mode Tipp probieren und mal schauen ob der Fehler bei deaktiviertem Eco-Mode weiterhin auftritt.
Edit sagt am 26.09.22: Bei deaktiviertem Eco-Mode sind die Probleme bei der Leistungsmessung bisher nicht mehr aufgetreten.
OT: Generell habe ich das Gefühl, dass die Leistungsmessung bei der Plus-Serie nicht sehr zuverlässig funktioniert. Ich hatte bis vor wenigen Tagen einen Plus1PM im Einsatz, der ständig in den Overpower-Protectionmode gesprungen ist. Und das, obwohl der angeschlossene Verbraucher in Spitze nur 600 Watt zieht. (Und ja, der Overpower-Grenzwert war hoch genug definiert 
)
Jaaa genau..
Verträgt der Shelly sich mit einem Trafo und das LED band auch? also wäre das so möglich?
Der RGBW2 lässt sich nur mit einem Trafo betreiben (12V oder 24V). 230V Netzspannung sind für ihn tötlich. Dein Netzteil muss also entweder 12V oder 24V liefern und dein LED-Streifen für 12V oder 24V ausgelegt sein.
Natürlich kannst du das Netzteil in deine Unterverteilung packen, den Shelly, wenn du magst, auch. So habe ich das auch gemacht.
Wichtig ist, dass du vorher die Leitungslänge vom Trafo zum LED-Streifen und den Strombedarf des LED-Streifens ermittelst. Danach richtet sich dann der Leitungsquerschnitt deiner Leitung vom Trafo zum LED-Streifen und die Stromstärke in Ampere, die dein Trafo liefern muss.
Sehr hilfreich ist diese Seite hier: https://www.led-studien.de/einsteiger-infos/
Gruß,
Sascha
Dein Anwendungsfall ist typisch für den Shelly Flood, dafür wurde er gemacht.
Allerdings denke ich auch, dass die Lösung des Problems beim Wäschetrockner gesucht werden muss. Wenn sich die Luftfeuchtigkeit durch den Trockner so stark erhöht, dass sich Kondenswasser auf den Fliesen (dem Boden) bildet, dann stimmt da was nicht.
Sascha Ich sehe keine Formatierungen der Nachricht... und Parsmode steht ja auf default. Dann haut er die Formatierungen "im Eingabeformat" mit der Meldung raus - zumindest bei mir...
Das sollte nur ein Denkanstoß und der Hinweis darauf sein, dass der Telegramm Adapter ohne Warnung den Dienst versagt, wenn er etwas senden soll, mit dem er nichts anzufangen weiß.
Hallo Patrick,
wird denn der debug ausgegeben?
Ich würde als erstes das Fragezeichen aus dem Objektnamen der Variablen entfernen. Ich finde Sonderzeichen an dieser Stelle kritisch.
Enthält deine Telegramm-Nachricht irgendwelche Formatierungen?
Ich habe festgestellt, dass der Telegramm-Adapter im Parsmode "HTML" nur wenige Formatierungen kennt und zulässt. Sobald eine Formatierung enthalten ist, mit der er nichts anfangen kann, unterbindet er den Versand der Nachricht kommentarlos.
Das wären meine beiden ersten Anhaltspunkte.
Gruß,
Sascha
Hallo Patrick,
die Lösung steht bereits in deinem Screenshot: Bitte benutzen Sie ioBroker.iot.
Installiere bitte den "iot Adapter". Mit dem "cloud Adapter" wird das nicht (mehr) funktionieren.
Gruß,
Sascha
VORSICHT! hier ist ioBroker in Verwendung. Da gab es Adapter Probleme mit COAP/Http. Deswegen die Frage von mir, welche Adapterversion in Verwendung ist.
Hallo harrym,
aktuell läuft der Shelly Adapter in Version 3.3.4.
hallo Sascha
So wie es aussieht geht deine 12v versorgung in die knie und kann dadurch den shelly nicht ausreichend versorgen. Kannst du auf eine andere spannung ausweichen?
Hallo Albatros L-39,
die 12 V Stromversorgung sollte für den Shelly eigentlich ausreichen. Das Netzteil liefert 15 W und bis 1,25 A. Wenn's nicht anders geht, könnte ich den Shelly auch mit 230 V betreiben.
Hallo zusammen,
hat außer mir noch jemand Probleme mit dem Shelly 1 im 12 Volt Betrieb bezüglich der Stabilität der WLAN Verbindung?
Mein Shelly verliert alle paar Minuten die Verbindung und meldet sich dann Sekunden später wieder an.
Die Verbindungsqualität ist hervorragend. Daran sollte es also nicht liegen.
Lieber Gruß,
Sascha
Bei mir läuft der ioBroker auf einer Synology DS218+ mit 10GB Arbeitsspeicher (die läuft ohnehin 24/7) in einer VM. Bisher problemlos und performant.
Das ist der Block:
Wenn's aber auch mit deiner Lösung funktioniert, um so besser.
Das Forum hat meine Bilder gefressen. 
Hab die gerade leider nicht zur Hand, deshalb schriftlich:
Entferne mal bitte die beiden "Aktuelle Zeit ist größer als/kleiner als"-Blöcke ...
... und ersetze sie durch einen "Aktuelle Zeit ist zwischen"-Block. (Solltest du über das Dropdown-Menü des "Aktuelle Zeit-Blocks" ändern können.)
Mit der Konstellation die Du gewählt hast, hatte ich schon öfter Probleme.
Vielleicht löst das dein Problem.
Direkt im H&T, ansonsten macht er ja DHCP.
Sollte man dem Router dann nicht auch mitteilen (DHCP-Reservierung), dass der Client (H&T) ab sofort eine statische IP-Adresse nutzt?
Wenn ich deinen "AVR-Trigger" erstmal außen vor lasse und dein Script bis dahin nachbaue, funktioniert es bei mir problemlos.
Gib deinen Switches eindeutige Namen, dann lassen sie sich besser unterscheiden und dein Blockly wird (für andere) nachvollziehbarer.
Welchen Switch schaltet denn dein AVR-Trigger?
Könnte es an deiner Zeitabfrage liegen?
Funktioniert dein Blockly wenn du die Zeitabfrage weglässt?
Für die Abfrage eines Zeitfensters gibt es einen eigenen Block.
Ersetze mal diesen Block hier:
Durch diesen:
In den Objekten in der Spalte Name kannst du jedem Objekt einen eindeutigen Namen geben. Einfach reinklicken, dann lässt sich der Name editieren.
Ersetze deinen ursprünglichen Chronjob durch den FALLS-Block mit der Zeitprüfung.
Oder anders: Deine Blöcke mit der Temperaturprüfung und dein Trigger-Block für den AVR müssen in den FALLS-Block mit der Zeitprüfung.
So werden die Temperaturprüfung mit der jeweiligen Aktion und dein "Filmschalter" allerdings nur im angegebenen Zeitraum ausgeführt. Ich hoffe das ist so gewollt.
super danke, da aber beide Trigger das selbe auslösen, könnte ich die Sperre direkt einbauen, und nicht auf jedes Objekt extra, oder?
Ich bin mir nicht sicher ob ich deine Frage richtig verstehe.
Wenn du meinst, dass du beide Objekte in einen Trigger nehmen kannst, muss ich dazu sagen, dass ich das auch erst versucht hatte, dadurch aber die Schaltzustände der beiden Schalter nicht ganz sauber gewechselt wurden. Durch die Trennung der beiden Schalter auf jeweils einen eigenen Trigger tritt dieses Problem nicht mehr auf.
ist noch ungetestet, aber mit Variablen hab ich noch nicht rumgespielt, steht aber bei youtube schon seit 1 Woche auf meiner Agenda.
An einigen Stellen kannst du sicherlich auf eine Variable verzichten und stattdessen auf den Zustand deiner Schalter prüfen.
Kleiner Tipp: Gib deinen Schaltern in den Objekten eindeutige Namen z.B. (Switch -> Kellerlicht Switch). Dadurch wird das Blockly übersichtlicher und lässt sich besser nachvollziehen.
