Beiträge von eiche

Den Entfeuchter mal aufschrauben und

1. Einen Anschluss der Powertaste lösen und Messgerät zum messen der Stromstärke dazwischen schalten, Powertaste drücken.
   Es ist ein schwacher Strom zu vermuten, aber sicherheitshalber messen.
2. Wenn möglich, einen Shelly in den Entfeuchter einbauen, der mit seinen Anschlüssen I und O den Taster überbrückt.
   Dann kann dieser Shelly gesteuert den Entfeuchter aktivieren. Das kann bspw. der bereits verwendete 1 Plus mit AddOn sein.

Wenn mit der Powertaste auch ausgeschaltet werden kann, was ich vermute, dann ist ein Toggeln zielführend. Dann wird aber wohl noch eine Strommessung erforderlich sein, bspw. per vorgeschaltetem Plug S, um feststellen zu können, ob der Entfeuchter an/aus ist. Evtl. kann mit Elektronikkenntnissen auch geprüft werden, ob die Beschaltung der Signalleuchte zum Betriebszustand alternativ genutzt werden kann. Dann könnte der zweite Shelly (Plug S) entfallen. Das wäre ein Thema für thgoebel und DIYROLLY.

Ok, das ist eine Möglichkeit.

Das bedeutet aber auch eine Änderung von Einstellung(en) auf mehreren Geräten, was auch mal vergessen werden kann.

Und zumindest wäre eine Kommunikation zwischen Shellies und Cloud trotz Sperre mit einem Vertrauensverlust gegenüber Allterco Robotics verbunden.

Das Prüfen auf neuer Firmware schließe ich dabei aus.

ostfriese

Du willst damit sagen, dass trotz deaktivieren des Cloud-Zugriffs auf einem Shelly, trotzdem die Cloud mit dem Shelly kommuniziert?

Oder du hast zumindest diesen Verdacht?

Das wäre ein Grund, keinen Shelly mehr einzusetzen.

Dann fällt mir nur noch ein aufwändiges Workaround per Skript ein.

• Alle Konfigurationsdaten in das KVS schreiben.
• Bei Skriptstart die aktuelle Konfiguration einlesen und mit den KVS-Daten vergleichen.
• Bei Abweichung per RPC gemäß KVS-Eintrag entsprechend neu konfigurieren. Danach rebooten lassen - in der Hoffnung, dass dies nicht endlos wird.
• Falls keine Abweichung festgestellt wird, kein Reboot. (selbstverständlich)

Dies könnte in das Anwendungsskript integriert oder ein dafür zusätzliches Skript erstellt werden.

Tja, nicht wenig Arbeit, aber wenn von Entwicklerseite nichts fruchtbares kommt, vielleicht die einzige Möglichkeit.

Ok.

Ich hatte das Problem bereits verstanden.

Mehr kann ich nicht dazu beitragen.

Seit der 1.x beta habe ich keine Reboots mehr, kann also nicht mit zusätzlichen Erfahrungen dienen.

Dieses Verhalten sollte jedenfalls den Entwicklern der Firmware bekannt gemacht werden.

Ich habe keinen Pro3EM aber andere Shelly der zweiten Generation.

Bisher habe ich das von dir beschriebene Verhalten nicht feststellen können.

Ich halte so etwas aber für möglich.

In einem anderen Thread hat der TE nach vielen konstruktiven Postings schließlich ein Factory Reset durchgeführt ...

(neu konfiguriert) und das vorherige Fehlverhalten war weg - ohne sonstige Änderungen.

Thema

Dimmer 2 Aktion um anderen Shelly Dimmer zu steuern

Lösung:

Factory Reset des Dimmer1



Hallo,

ich habe im Laufe der letzten Woche Hand an das ganze Shelly Universum gelegt und stoße nun an die Grenzen, bei denen ich mit Googlen und API lesen leider nicht weiterkomme.

Zum Setup:

Verbaut habe ich zwei Shelly Dimmer 2 , die ich im Folgenden auseinanderhalte mit Dimmer1 und Dimmer2. Dimmer1 hat außerdem noch einen Doppeltaster angeschlossen an SW1 und SW2. Button-Type: Detatched. Beide Dimmer haben die Firmware-Version: 20230510-082920/v1.13.1-gda6f9f2.

…

boedefeld

8. August 2023 um 19:06

Hast du mal ein solches Factory Reset vorgenommen? Vielleicht kann dies helfen.

Ich setze mal voraus, dass auf deinem betroffenen Shelly ein Skript läuft.

Wenn dies so ist bleibt die Frage nach dem, was das Skript tut.

Hast du einen weiteren baugleichen Shelly mit diesem Skript getestet?

Ich schalte das Websocket Debug nicht aus.

Hast du aktuelle Beta Firmware 1.x beta installiert?

Ich hatte bei Plus 2 PM und Plus 1 mit laufenden Skripten vor der 1.x Firmware immer wieder Reboots, ca. alle 10 Stunden, aber nicht konstant periodisch.

Seit Firmware 1.x gibt es solche Probleme bei mir nicht mehr, ohne sonstige Änderungen an Skripten.

Die betroffenen Shelly laufen schlicht ohne jegliches Rebooten durch.

Ich vertraue der Firmware für die zweite Generation vor 1.x nicht.

Dann bleibt das Warten auf eine neue Dimmer Generation, die per Skript flexibler nutzbar ist.

Interessant.

Dann kann es vermutlich beim konfigurieren zu Problemen kommen ...

boedefeld

Neugierige Frage:

Hast du einen Factory Reset oder ein Hard Reset gemacht?

Ich interpretiere Hard Reset als Power On Reset.

Beim Factory Reset werden ja die Einstellungen rückgesetzt, beim "Hard Reset" hingegen nicht.

Nur der Vollständigkeit wegen und weil ich es so noch nicht von dir las:

http://127.0.0.1/light/0?turn=toggle

Hast du es genau so in einer Action versucht?

boedefeld

Ich habe solche Shelly Dimmer nicht.

Die Dokumentation sagt aber etwas anderes als

Zitat von boedefeld

http://shelly-ip/relay/0/on

In der Doku finde ich dazu zwar kein Beispiel, es liegt aber nahe, dass der passende URL folgendermaßen lautet:

http://<shelly_IP-address>/light/0?turn=on oder ...=off oder ...=toggle

Bei URL zum selben Shelly localhost bzw. 127.0.0.1 verwenden, wie Devil bereits anmerkte.

Mit dem Wert toggle hattest du, soweit ich dich verstand, bereits Erfolg.

Quelle: https://shelly-api-docs.shelly.cloud/gen1/#shelly-dimmer-1-2-light-0

Benjidoggi

Die von Devil vorgeschlagene Lösung hat ihren Vorteil darin, dass die gesamte, von dir gewünschte Funktionalität in einem Shelly vereint ist und keine zusätzliche Kommunikation zwischen zwei Shellies (über WLAN) erforderlich ist. Allerdings brauchst du dann zwei zusätzliche Relais oder zwei zusätzliche Shellies.

Deine bisherige Schaltung mit zwei Shelly Plus 1 ist aber durchaus geeignet.

Nach der letzten Verhaltensbeschreibung des TE beinhaltet die Lift-Elektronik offenbar eine interne Sperre, wenn beide Eingänge ein High erhalten.

Bspw. beide Eingänge auf ein XOR, dessen Ausgang auf Move Enable oder ähnlich.

Deshalb kann er auch seine beiden Plus 1 weiterverwenden und jeweils per Action den anderen Shelly ausschalten, wenn der eigene Ausgang eingeschaltet wird.

Aber klar, es gibt auch andere Lösungen für seinen Zweck.

In diesem Fall ist kein zusätzlicher Plus 2 PM erforderlich, wenn der Lift ausschließlich jeweils in Endstellung gefahren wird.

Website (auch WebUI genannt) des Shelly per Browser und dessen IP-Adresse

Voraugesetzt: aktuelle Firmware 1.x-beta...

-> Menü links

-> Actions

Dort nachsehen, was möglich ist. bspw. Webhook (http://... zu anderem Shelly) zwecks ausschalten eines anderen Shelly, wenn auf dem gegenwärtigen Shelly eingeschaltet wird.

Dann ist die Reihenfolge des Aus- und gegenläufigen Einschaltens offenbar nicht zwingend.

Dann solltest du gelegentlich hierfür die Actions einsetzen - nach hinreichend vielem Experimentieren und Dazulernen!

Klar, dann wäre zumindest ein Skript zielführend.

Aber vielleicht ist diese Reihenfolge nicht zwingend oder eine Priorität nutzbar.

Ergänzung zu Devil

Empfehlung: Sieh dir gelegentlich die Möglichkeiten von Actions an, welche per Konfiguration des entsprechenden Ausgangs genutzt werden können.

Damit sollten die gewünschten Verhalten bereits implementierbar sein.

Am besten wäre es, wenn du etwas mit einem bzw. zwei gerade nicht eingesetzten Shellies experimentierst, um darin Sicherheit zu bekommen.

Es lohnt sich jedenfalls, wenn du mehrere bis viele Shellies nutzt oder nutzen willst.

Zitat von Flutschi

kann er sowieso nur die vorhandene Fernbedienung benutzen.

Falsch!

Er kann dann immer noch sein WLAN und die Shellies nutzen.

Letztlich hängt dies von einem Vorrat an Frontends ab.

Wenn er bspw. ein zentrales System im WLAN nutzt, gibt es typischerweise ein solches Frontend zwecks Bedienung.

Alternativ funktionieren dann immer noch die WebUI der Shellies.

...