Beiträge von eiche

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.

...

Dagegen spricht ja auch nichts.

Mein Einwand bezieht sich auf die Lokation der Implementation einer grundlegenden Funktionalität.

Je weiter weg von den betroffenen Geräten so etwas implementiert wird, desto größer ist eine Ausfallwahrscheinlichkeit.

Ich täte eine solche Grundfunktionalität nicht per Cloud oder Alexa-Routine erstellen.

Wenn bspw. Internetzugriff oder Cloud oder AWS ausfällt, gelingt dies nicht.

Es ist immer am besten, solche Funktionalitäten möglichst nahe an den Geräten oder auf diesen zu implementieren.

Dann kann man immer noch zusätzlich Cloud und/oder Alexa-Routine nutzen.

Dann teile uns mal deine Adresse mit, per PN am besten!

Das Problem des gleichzeitigen Hoch- und Runterfahrens existiert vielleicht nicht.

Erstelle einfach ein Protokoll, experimentiere mit allen möglichen zweischrittigen Schaltfolgen und notiere sorgfältig das Verhalten des Lifts!

Daraus sollten sich Erkenntnisse ergeben und weiteres planen lassen.

Im ungünstigsten Verhaltensfalle könnten Skripte Abhilfe schaffen, aber vermutlich wird dies nicht erforderlich sein.

Zum testen kannst du ja mal I und O des "Runterfahr-Shelly" kurz überbrücken.

Notfalls täte ich die gesamte Anlage auch mal ausschalten und nach ca. 30s wieder einschalten, um einen Power On Reset zu erzeugen.

Dann stellt sich erneut die Frage nach der geeigneten Kommunikation - im weitesten Sinne.

Soweit ich mich erinnere, hattest du mit einfachen Brücken das gleiche Problem, hoch ging, runter ging nicht.

Wenn dies so war, kann ein Shelly bei gleicher Relaisverbindung auch nichts anderes bewirken.

Mir stellt sich auch die Frage nach dem Zweck der beiden Anschlüsse "tranceive data" und "receive data".

Edit:

Vermutlich sollte es statt "tranceive data" "transmit data" heißen - und wurde nie überarbeitet ... schwach

Edit 2:

Da war doch auch etwas mit gespiegelter Anordnung, was die Klemmennummern betrifft.