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.
Noch kein Skript, nur das Prinzip:
Irgendwie wird das Wasserwerk (WW) eingeschaltet.
Dieses wird von der Firmware registriert und an eine Skriptfunktion weitergereicht.
Diese Skriptfunktion startet einen Timer, der nach 30 Minuten abläuft.
Mit dem Ablauf des Timers wird eine andere Funktion "check()" aufgerufen, die die zuletzt und sehr aktuell gemessene Leistung P von der Firmware abruft.
Diese Leistung wird mit zwei konfigurierten Werten verglichen, bspw. 1W und 30W.
Wenn P>1W UND P<30W dann wird as WW abgeschaltet.
Verbesserung:
Statt des direkten Aufrufs von check() wird ein weiterer Timer gestartet, der periodisch, bspw. jede Minute, diese Funktion check() aufruft. Sobald check() das WW ausschaltet, wird der periodisch arbeitende Timer beendet.
Fertig.
Edit 2: Zu kompliziert ... s.u.
Na ja, per Skript ginge das durchaus. Deine Zeiten sind nicht eindeutig.
Wenn nach 30 Minuten geprüft wird, ob ab dann 10 Minuten lang P<30W ist, dann kann erst nach 40 Minuten abgeschaltet werden. Also sollte vielleicht 20 Minuten nach dem Einschalten 10 Minuten lang geprüft werden, ob P<30W dauernd vorliegt. Und warum die Prüfdauer auf P<30W von 10 Minuten sein soll, erschließt sich mir auch nicht.
Edit: Ich ahne es.
Du hast ja einen Pufferbehälter und die Pumpe schaltet sich zwischenzeitlich aus. Dann sollte aber als Ausschaltkriterium bspw. 1W < P < 30W genügen.
Die andere von Dir vorgeschlagene Lösung (dauerndes Wiederholen des Skripts) bereitet mir etwas Sorgen. Tut es dem Shelly gut, wenn das Skript permanent läuft (bzw dann, wenn die Bulbs eingeschaltet sind). Ist nur so ein Bauchgefühl.
lol, das macht dem Shelly absolut nichts aus. Das Skript wird nicht dauernd wiederholt. Ein Timer ruft periodisch eine Funktion auf, welche die Status-Daten vom Master liest und an die Slaves überträgt. Das ist noch etwas einfacher als dein bisheriges Skript. Das Skript wird nie gestoppt.
Edit:
Ein Shelly Skript ist immer Ereignis gesteuert. Da wird, solange man es geeignet erstellt, nichts von sich aus wiederholt. Das Skript stellt also gewisse Teile/Funktionen zur Verfügung, welche auf Grund von Ereignissen abgearbeitet/aufgerufen werden. In meinem letzten Lösunmgsvorschlag sorgt ein Timer periodisch dafür, dass eine Funktion "sync()" aufgerufen wird, die sich um das Synchronisieren kümmert. Die Ereignisse sind also periodische Timerabläufe.
Das ist ja in 5 Minuten getestet. Hätte ich aus Interesse gleich nach dem Paketerhalt gemacht.
Wie willst du dies denn anders interpretieren, als so, wie es thgoebel tat. Mir ging es genauso wie ihm, ich bin nur nicht involviert. Schließlich ist er der Empfänger des Pakets. Somit ignorierst du Thomas' eigenständige Zeiteinteilung. Damit ist nicht Thomas eine Mimose sondern du gebärdest dich total unsensibel.
Ich täte diesen Kommentar nicht schreiben, wenn es bei Thomas' Aussage geblieben wäre. Stattdessen führst du dich wie der Angegriffene auf. Das ist schlicht unverschämt.
Noch etwas sehr WICHTIGES!
Thomas hat im Forum sehr viel dokumentiert, Reparaturen angeboten und durchgeführt, Bauteile bereitgestellt und insbesondere Fragen beantwortet. Und alles das "ehrenamtlich", soll heißen, ohne etwas daran zu verdienen. Und ich habe ihn immer sachlich sowie sehr geduldig erlebt.
Das musste ich loswerden. Meinetwegen kann es in ruhigem Fahrwasser weitergehen.
Edit:
Vor der Firmware wird aber der Bootloader gestartet. Und wenn Gpio9 während dem Boot auf Masse liegt, sollte die Firmware garnicht starten, sondern das Ding auf neue Firmware warten...
Das sollte so sein und ich wunderte mich, wenn es anders wäre. Als Einwand ist dies angemessen, nur halt nicht als Vorgabe, was Andere noch tun sollten. Vor allem dann nicht, wenn man nicht weiß, wie diese Anderen ausgelastet sind und welche Ausstattung sie (nicht) besitzen.
Ich habe noch eine Idee für einen relativ komfortablen Automatismus, welcher allerdings auch ein wenig einschränkt.
Die Einschränkung liegt darin, dass für diese Idee wieder eine Master-Lampe eingeführt werden muss.
Man kann einen Zeitgeber verwenden, der in definierbaren Zeitabständen die Master-Lampe abfragt und deren Einstellungen auf die Slave-Lampen überträgt. Der Zeitgeber kann ein Skript interner Timer oder ein Schedule Job sein. Ich nehme als Zeitabstandswert mal 1s, was relativ kurz ist. Diese 1s ist zugleich, mit einer gewissen Toleranz im ms Bereich, die maximale Zeitverzögerung, mit welcher die Slave-Lampen auf die Master-Lampe passiv reagieren. Passiv deshalb, weil das Skript dafür aktiv ist.
Das Skript fragt nach jeder Sekunde den Zustand der Master-Lampe ab, ohne selbst dafür getriggert zu werden. Somit entfallen hierfür auch die Actions auf den Lampen, auch auf der Master-Lampe. Das Skript überträgt die von der Master-Lampe geholten Einstellungen selbstständig auf die Slave-Lampen. Auf diese Weise kann der Anwender nicht mehr die Slave-Lampen als eigenständige Lampen separat einstellen, weil eine solche Einstellung kurz danach vom Skript überschrieben würde. Eine separate Einstellung der Slave-Lampen wollen afaik JayR82 und Hojo7871 auch nicht. Die einzige Unschönheit ist eine Verzögerung der Einstellungen zwischen der Master-Lampe und den Slave-Lampen, die zudem quasi zufällig lang ist, aber maximal eine Sekunde beträgt. Die Traffic-Dichte ist dabei relativ hoch, die Datenpakete aber klein.
Der Vorteil dieser Idee liegt darin, dass sich der Anwender nicht um die Übertragung auf die Slave-Lampen kümmern muss und letztlich ausschließlich die Master-Lampe einstellt. Er darf sich halt nicht an der verzögerten Reaktion der Slave-Lampen stören.
Das Ganze funktioniert völlig unabhängig von der einstellenden Quelle sowohl lokal als auch über die Cloud. Btw, wer dafür auch die Cloud nutzen will, braucht dafür nur die Master-Lampe der Cloud hinzuzufügen, die Slave-Lampen nicht, weil das Skript lokal arbeitet. Insgesamt betrachtet besteht diese Lampenanordnung steuerungstechnisch aus nur einer Lichtquelle.
Man kann selbstverständlich auch das von mir in #13 unter Edit 2 beschriebene Workaround mit dieser Zeittriggerlösung zu kombinieren versuchen. Dabei sollten sich die beiden Trigger per Zeit und per Action allerdings gegenseitig sperren, damit nicht zu viele RPC Aufrufe fast zeitgleich erfolgen können. (Interessant wäre auch der Versuch, dafür kaskadierte RPC Aufrufe zu coden. Die Kaskadestufen wären per RPC Aufrufe innerhalb der callback Funktionen zu implementieren. Vermutlich könnte dies eine Überschreitung des RPC Limits verhindern. Bei vielen Slave-Lampen käme solches besonders zum tragen. Eine einfachere Alternative wäre die Verwendung einer Timers mit einem Indexzähler, welcher auf die Einträge einer Liste (Datenfeld, Array) verweist.)
Wer mit jeder neuen Einstellung der Master-Lampe ein künstlerisch gestaltetes Lichtspiel haben möchte, kann eine zufällige Verzögerung in der Reaktion der Slave-Lampen implementieren. Je mehr Lampen beteiligt sind, desto unterhaltsamer wäre das Lichtspiel. Ich sollte mir das patentieren lassen ...
Hast du vor, das in #13 unter Edit 2 beschriebene Workaround zu versuchen?
Ich bin sicher, dass es so wie beschrieben funktioniert.
Aha, das überrascht mich. Im Shop steht unter "Firmware Fähigkeiten" Scripting: Ja.
Das ist offensichtlich ein Fehler, weil im Manual unter "Firmware capabilities" Scripting: No steht.
Vielleicht schilderst du dieses Webhook Problem der Shelly Duo dem Support mit der Bitte, Webhooks auch beim Ändern der Lichtfarbe einzubauen. Ob von deren Seite solches interessant genug wäre, die Firmware zu ändern, kann ich nicht einschätzen.
Inzwischen erkannte ich auch eine nicht überzeugende Logik im Verhalten der Shelly Duo.
Im ausgeschalteten Zustand wird die Lampe bei Änderung der Helligkeit automatisch eingeschaltet, bei Änderung der Lichtfarbe hingegen nicht.
Ich finde, dass sich beide Änderungen auf den Schaltzustand gleich auswirken sollten - unabhängig von deinem Anliegen.
Diese Firmware hat noch Verbesserungsbedarf. Ich brauche allerdings dergleichen bisher nicht.
täte es gelingen.
