VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
mit einem Doppeltaster und 2 Shelly's bedienen so dass bei einem Klick der entsprechende Rollladen ganz hoch fährt, nochmal klick Stopp, runter analog.
Ich habe dies als einen reinen Eintastenbetrieb verstanden. horkatz Deine Handhabungsbevorzugung nutze ich auch, allerdings mit 4 Tastern und einem Shelly i4 in einer Dose -> WLAN erforderlich. Damit kann ich komfortabel zwei Rollläden manuell steuern. Vielleicht wäre solches auch etwas für Ekkkke . 
Aha, dann muss man also die "Auf"- und die "Ab"-Stellung eines solchen Tasters festhalten, solange der Rollladen fahren soll?
Eine solche Handhabung empfinde ich als wenig ergonomisch.
Mit einem Skript auf einem skriptfähigen Shelly gelingt solches mit jedem beliebigen einfachen Taster, allerdings mit der folgender Einschränkung.
Nach einem Stopp kann per nicht unterschiedenen Drücken (nur push, ohne double push oder long push) nur in einen nächsten Fahrvorgang gewechselt werden. Ich wundere mich immer wieder über die Festlegung auf bestimmte Taster bzw. deren Hersteller. Ein schlichter Doppeltaster aus dem Baumarkt kann hierfür eingesetzt werden, wenn man dafür ein flexibel konfigurierbares Skript einsetzt.
Mein folgendes Skript könnte hierfür bereits geeignet sein. Dieses erstellte ich für ein anderes Forumsmitglied.
// created by eiche, 2024-04-13
// Application for a roller shutter controlled by a single button
// Succ beinhaltet zu einem Schlüssel (key) die Nachfolgemethode als Wert (value)
// Die Struktur jedes Eintrags ist Schlüssel:Wert.
// Weil die Methode nach "stopped" vom letzten Schlüssel abhängt, ist der Wert von "stopped" ein zusammengesetztes Objekt
// bestehend aus zwei Einträgen. Jeder Eintrag beinhaltet als Schlüssel einen möglichen vorherigen Schlüssel.
// Damit ist für diese Anwendung eine hierarchische Struktur aus Einträgen konfigurierbar,
// in welcher jeder Eintrag einen einfachen Wert (einstufig) oder eine Struktur (zweistufig) mit einfachen Werten enthält.
// Diese Konfiguration wird anwendungsgerecht von eventHandler() verarbeitet.
let Succ = {
"opening":"Cover.Stop",
"closing":"Cover.Stop",
"stopped":{"opening":"Cover.Close","closing":"Cover.Open"}, // Nach "stopped" gibt es zwei mögliche Nachfolgemethoden.
"closed":"Cover.Open",
"open":"Cover.Close"
};
let last = null, // für das letzte Ereignis (event)
next = null; // für die auf das letzte Ereignis folgende Methode
function eventHandler(e) {
//print(e.name);
switch(e.name) {
case "cover":
e = e.info.event;
if(e===undefined) return;
//print(e);
if(Succ[e]===undefined) return;
let s = Succ[e];
switch(typeof(s)) {
case "string": next = s; break;
case "object": next = s[last]; break;
default: return;
}
last = e;
print("last: "+last+", next: "+next);
break;
case "input": // Diesen Teil habe ich nicht getestet.
if(typeof(next)==="string")
Shelly.call(next, {id:0}, function(res, errc, errm) {
if(errc) print(errc, errm);
});
break;
}
}
Shelly.addEventHandler(eventHandler);Dafür steht die RPC Methode "Sys.GetStatus" zur Verfügung. Diese liefert ein Resultat im JSON Format, welches auch die Komponente "uptime" enthält.
Es bleiben folgende Fragen.
Ich nutze als zentrales System ausschließlich Node-RED, womit ich das Gewünschte leicht implementieren könnte, auch ohne den Shelly.
Mit anderen übergeordneten Systemen kenne ich mich nicht hinreichend aus.
Per Skript könnten die Einschaltdauern zielführend allenfalls mit Genauigkeiten in Minuten und einer zusätzlichen Toleranz von ca. 1 Minute gespeichert werden, da er nicht "weiß", wann er ausgeschaltet wird.
Wenn der Shelly kurz vor dem Ausschalten darüber informiert werden kann, können die Einschaltdauern durchaus per Skript ermittelt und persistent auf dem Shelly gespeichert werden, bspw. bestehend aus dem aktuellen Zeitstempel (unixtime) und dem uptime Wert. Selbstverständlich bleibt dabei ein systematischer Fehler von vermutlich ca. -1s. Es bleibt die Frage nach der Sinnhaftigkeit einer solchen Implementation.
Ggf. weitere Möglichkeiten und deren Zweckmäßigkeiten können erst genauer betrachtet werden, wenn du mehr von deinem Projekt preisgibst, auch eine Schaltskizze wäre evtl. nützlich.
Hast du einen Plus Plug S oder einen Plug S (ohne Plus). In #1 schreibst du "+PlugS", im Pfad steht aber "Shelly Plug S".
Ein Plus Plug S kann seinen Access Point trotz Einbindung in's WLAN zur Verfügung halten, ein Plug S nicht.
Im ersten Fall ist es möglich, ihn über seinen AP zu erreichen, nachdem du dein Endgerät mit seinem AP verbunden hast (192.168.33.1).
und es gibt keinen AP
Das müsste bedeuten, dass du im Falle eines Plus PLug S dessen AP selbst deaktiviert hast.
Edit:
Unabhängig davon muss sich der (Plus) Plug S durch sehr langes Drücken des kleinen Buttons auf die Werkseinstellungen zurücksetzen lassen. Es hat dabei aber auch schon Probleme gegeben, weil irgendwelche Konfigurationseinträge beibehalten wurden. Zumindest sein AP sollte dann wieder verfügbar sein.
Also z.B. 192.168.44.45:0 - und solch ein Port funktioniert nicht.
Wenn du dies ablesen kannst, bist du vermutlich über den AP mit dem Shelly verbunden. Dann solltest du bspw. ein "Factory reset" auslösen und ihn danach neu einrichten können. Vielleicht gelingt stattdessen auch eine Änderung in der Konfiguration.
Ich bin nicht sicher, ob dieses hinreichend helfen kann, weil ich es bisher nicht brauchte.
Unter "Cover settings" gibt es "Movement time limits" 1) und "Idle power thresholds" 2).
1) Damit wird die maximale Dauer zum öffnen und/oder schließen eingestellt.
2) Damit sollte der Shelly eigenständig feststellen können, wenn der Motor angehalten ist.
Eine kleine, wohlmeinende Thread Kritik - auch mitunter auf andere Threads übertragbar
Im folgenden verwende ich nicht die Zitierfunktion des Forums, markiere aber die Textstellen als Zital mit Quellenangabe. Grund: Ich bereitete dieses Statement in einem Editor vor und zögerte, es zu veröffentlichen.
Das Thema dieses Threads lautet: "Shelly Plus2PM Control Button Mode Script"
Hiermit wird zwar offenbar nach einem Skript bzw., wie im ersten Post zu lesen, nach der Möglichkeit gefragt, etwas per Skript zu lösen.
Dann wird es allerdings speziell:
"Ich würde den Modus gerne auch auf SW2 erweitern. Also, dass beim Tasterdruck auf SW1 oder SW2 zwischen den Modi Open -> Stop -> Close -> Stop gewechselt wird."
Im nachhinein betrachtet war die Intention des TE vermutlich, dies eher als Beispielanwendung anzuführen - s. #23:
"Ja das stimmt, wollte ich einfach nur brücken hätte ich nicht nach einer Script Lösung gefragt"
Auch kann es sein, dass der TE weitere, von ihm hier nicht eröffnete Anwendungsmöglichkeiten sucht.
Die folgende Äußerung aus #1 lässt nicht zwingend das Ziel erkennen, etwas über ein Skript zu erfahren.
"Hat das vielleicht schon jemand umgesetzt oder könnte das vielleicht mittels eines Skriptes umsetzen?"
Mir widerstrebt es nicht, auf die Möglichkeiten eines Skripts einzugehen. Aber andere hier im Forum versuchen, wann immer auch nur halbwegs möglich, eine Skriptlösung als überflüssig oder übertrieben anzusehen. Dann wird allzuoft das Ziel eines TE überaus kritisch hinterfragt. Auch wenn dieses Hinterfragen zielführend sein kann, so nehme ich mitunter wahr, dass es einem TE schwer gemacht wird, trotz alledem im gegebenen Kontext an seinem Ziel festzuhalten. Aus einem solchen Grund können "Belehrungen" bzgl. des TE-Anliegens kontraproduktiv sein.
Ich halte ein Nachfragen zu den Absichten des TE für zielführend, nicht aber eine wiederholende Belehrung über eine, vorsichtig ausgedrückt, Sinnarmut des TE Anliegens. Irgendwann sollte imho das Anliegen eines TE akzeptiert werden und ihm/ihr die Freiheit eines vielleicht fehlgeleiteten Weges selbst überlassen bleiben. Dabei kann es helfen, die eigene Fehlbarkeit in der Betrachtung eines Themas oder von Perspektiven einzuräumen. Ich nehme mich selbstverständlich aus solchen Fehlbarkeiten nicht aus.
Mir gefällt es mehr, wenn ein Post eine gewisse Eigenkreativität erkennen lässt - im Vergleich zu einem schlichten und ausschließlich auf Konsum ausgerichtetem "Wie geht das?".
Ich hoffe, hiermit niemandem zu nahe getreten zu sein und dass meine Absicht als konstruktiv erkennbar ist. Ich bitte darum, vor einer Reaktion diesen Text sorgfältig und wohlmeinend zu lesen.
Auf weiterhin gute (reibungsarme) Zusammenarbeit
Das höchste Ziel des TE ist doch, daß es KEINE Unterschiede geben soll. Oder habe ich da etwas falsch verstanden?
Das stimmt. Wenn dies so bleiben sollte, schließe ich mich deiner einfachen Lösung vorbehaltlos an. Mal sehen, wie der TE reagieren wird.
Aber wozu der Quatsch?
Solches kannst du dir in Zukunft sparen oder versuche einfach, meine Erklärungen zu verstehen! 
Da der TE sich bisher nicht weiter erklärte, bleiben alle Optionen zunächst offen.
Bei Verwendung eines Skripts können bei (a) beide unterschieden werden, was mit (b) nicht gelingen kann.
Ganz einfach: Wenn der TE die Handhabungen testen möchte, ohne später die Anschlüsse ändern zu müssen, bietet sich einfach ein Skript an. Insbesondere dann, wenn viele solcher Schaltungen eingesetzt werden. Ein Skript ist innerhalb einer Minute kopiert und gestartet, ohne Wekzeug. 
Ok, ok, ein Skript zu erstellen, kostet Zeit. ...
Das geht per Skript. Als Anwendung täte ich allerdings die Funktion der beiden Taster unterscheiden, bspw. so:
Taster 1 zum öffnen und anhalten.
Taster 2 zum schließen und anhalten.
Ein Skript muss per sog. EventHandler oder evtl. StatusHandler die letzte/aktuelle Aktion speichern, um mit dem nächsten Tastendruck die nächste vorgesehene Aktion auszulösen. Das gelingt sowohl mit beiden gleichgenutzten Tastern als auch mit unterschiedlichen Tasterfunktionen. Ich kann dies allerdings nicht testen, da ich meine Rollladensteuerungen per remote, also nicht angeschlossenen, Tastern implementierte.
Btw, ich glaube nicht an Neustarts wegen wechselnder WLAN Feldstärke. Sollte dies so sein, ließe es sich per persistenter Speicherung der letzten Aktion lösen, was auch gegen Stromausfall hülfe.
Krauskopp
Die meisten deiner Hinweise sind sicher passend, aber
Was passiert, wenn durch einen Fehler einer der Shellys versehentlich im laufenden Betrieb bei offenem Wasserhahn abschaltet?
"versehentlich" gibt es hier nicht.
Fehler lassen sich bei solch kleinen Projekten ausschließen, es sei denn, ein Hardwaredefekt liegt vor. Dagegen ist eh kein Kraut gewachsen.
Und schließlich lässt sich MaMoe696 offensichtlich nicht von seinen Wünschen abbringen.
JuergenAC Danke für die gute Dokumentation
thgoebel Die Shelly Schedule Jobs verarbeiten ausschließlich Zeitmuster mit Sekundenauflösung, nicht kleiner. Damit sind keine höherfrequenten Pulse möglich.
Für programmierbare, höherfrequente PWM dürften ladbare Hardware-Zähler mit eigenem Taktgenerator am besten geeignet sein.
Evtl. sind die ESP32 internen Counter , welche auch für Interrupts nutzbar sind, und hardwarenahe Programmierung in C(++) auch gut geeignet. Dann ist aber die Shelly Firmware außen vor.
Speziell für unsere Sprachassistenten verwenden wir zumeist eine Hierarchisierung, ähnlich wie bereits von anderen beschrieben wurde.
Beispiele:
Wohnen links, Wohnen rechts. Schlafen mitte, ... für Rollladenantriebe
Wohnen Decke, Küche Decke, aber einfach Spüle, ... für Lichtquellen
Bei mobilen Geräten wie Shelly Plug S, H&T ... den Einsatzzweck wie Pflanzen-1, Pflanzen-2 oder auch schlicht menschliche Vornamen
Entscheidend ist halt, dass sowohl die Sprachassistent-Software wie auch wir diese Namen gut unterscheiden und wir diese leicht zuordnen können.
Dies hat sich bewährt. Allerdings ist dein Titel wenig passend, da zumindest oft auch Aktoren zum Zuge kommen. "Wie benennt ihr eure Geräte?" wäre bspw. etwas passender.
Wäre doch eine Möglichkeit ohne viel "drumrum"
Ja klar, statt zweier Modi schlicht zwei parallel geschaltete Ausgänge verwenden. Das Abschalten bei Minimum < P < Maximum gelingt afaik per Action nicht, wohl aber per Skript - und vermutlich per Szene. Eine Sicherheitsabschaltung per Cloud zu implementieren, halte ich für gruselig.
Warum nicht 2 Shelly? Der eine Schaltet nach Verbrauch, der andere wird gesteuert und schaltet nach 30 Min ab.
Danke für diese Ergänzung.
Das ist eine Option, wenn die Wahl des Modus nicht hinreichend einfach gelingt. Sobald solches bspw. auf 4 verschiedne Modi erweitert werden soll, wird die Lösung mit einem Shelly je Modus aber etwas ... hust ... wenig intelligent.
Am Abschalten auf Grund des Pumpen-Leerlaufs ändert das nichts.
Edit:
Dafür wäre dann bspw. ein Shelly Plus 2PM geeignet.
Ich versuche mich mal deiner Anwendungsrealität zu nähern.
Soweit ich es verstand, willst du zwei unterschiedliche Modi nutzen.
Wenn diese beiden Modi, die unterschiedlich zu starten sind, dein Anliegen sind, dann sollte folgendes Prinzip zum Ziel führen.
Irgendwie wird dem Skript mitgeteilt, wenn Modus 2 zu verwenden ist, ansonsten ist es Modus 1. So etwas ist möglich.
Das Skript prüft ständig, ob die Pumpe leer läuft, d.h. ob bspw. 1W < P < 30W. Wenn ja, wird das WW ausgeschaltet.
Im Modus 1 wird das WW generell nach bspw. 30 Minuten ausgeschaltet.
Im Modus 2 läuft das WW einfach durch. Es wird eh abgeschaltet, wenn ein Leerlauf der Pumpe erkannt wird.
Täte das für deine Anwendung passen?
Ich hinterfrage den Sinn deiner Anwendung explizit NICHT.
Vielleicht gelingt so etwas auch per Szenen. Ich bevorzuge Skripte, weil diese lokal arbeiten und damit funktionssicherer sind.
täte es gelingen.