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.
Schaltet dein Hauswasserwerk ab, wenn in der Zisterne Wasser zum ansaugen fehlt?
Das sollte es. Wenn nicht, ist eine Sicherheitsabschaltung erforderlich, wofür eine Cloud Szene zu unsicher ist.
MaMoe696 Eine verständliche Antwort auf diese meine Frage aus #11 könnte etwas Licht in das Dunkel bringen. Auf eine solche Antwort warte ich noch.
Ah, jetzt habe ich verstanden, warum das Skript gestartet werden soll und warum SebMai anmerkte, dass das Skript für deinen Anwendungsfall gestoppt sein müsse.
Ich glaube zunächst trotzdem nicht, dass ein Skriptstart zwingend erforderlich ist.
Voraussetzung - ob dies gelingt, weiß ich noch nicht:
Per Skript auf dem Wall Display kann die Änderung eines Display Widget erfasst werden.
Wenn diese Voraussetzung erfüllt ist, kann diese Änderung durch dieses Skript an alle gewünschten Lampen per http gesendet werden
oder, wie es dein Skript auf dem Plus 2PM teilweise tut,
die Widget Änderung an die "Master"-Lampe gesendet werden und im Plus 2PM Skript eine Funktion "sync()" per "Script.Eval" aufgerufen werden, welche die Einstellungen der "Master"-Lampe liest und an die anderen Lampen sendet. Hierfür ist das Skript nicht zu stoppen, im Gegenteil, es muss auf dem Plus 2PM ständig laufen.
Edit: Wenn ich ein Wall Display habe, werde ich dessen Skript-Möglichkeiten testen ...
Edit 2:
Ich verstehe dein Anliegen eines Automatismus, welcher von der "Master"-Lampe ausgehen sollte. Dann wäre es nämlich gleichgültig, von welcher Quelle ausgehend diese Lampe eingestellt würde. Frage dazu: Nutzt du MQTT oder denkst du darüber nach, MQTT zu nutzen?
Eine Änderung der Helligkeit schaltet die Lampe automatisch auch ein, eine Änderung der Lichtfarbe nicht. Als Workround könntest du folgendes versuchen.
Per Webhooks (=Actions) auf der "Master"-Lampe ruft diese Lampe eine Skript-Funktion auf, ich nenne sie noch einmal "sync()". sync() wird von der Lampe sowohl beim einschalten als auch beim ausschalten aufgerufen. sync() liest die Einstellungen der "Master"-Lampe ein und kopiert diese per http auf die "Slave"-Lampen.
Sobald die "Master"-Lampe eingeschaltet wird, werden auf diesem Wege auch die "Slave"-Lampen eingeschaltet. Es bleibt noch die folgende Lücke.
Wenn die Lichtfarbe der "Master"-Lampe geändert wird, ohne diese zu schalten, wird die Lichtfarbe nicht auf die "Slave"-Lampen übertragen. Diese Lücke wird sich aber nicht auswirken, weil die Lichtfarbe erst mit dem Einschalten zum Zuge kommt - und dabei wird bereits synchronisiert. Diese Lücke wirkt sich bei einer Änderung der Lichtfarbe aus, wenn währenddessen die Lampe eingeschaltet bleibt. Um diese Lücke zu umschiffen, könntest du die "Master"-Lampe kurz (vielleicht im ms Bereich) ausschalten und wieder einschalten lassen. Vermutlich wäre solches nicht zu sehen. Edit: Das gelingt leider doch nicht so einfach. Ich habe dazu leider noch keine zündende Idee außerhalb eines Wall Display Skriptes. Mit der Änderung der Helligkeit im eingeschalteten Zustand ergibt sich die gleiche Lücke. Habe dies mit meiner einzigen Shelly Duo getestet.
Wenn du diesen Automatismus auch auf das Schalten der "Slave"-Lampen übertragen willst, trägst du einfach die Actions der "Master"-Lampe auch auf den "Slave"-Lampen ein! Dann gäbe es weder Master- noch Slave-Rollen, es würde schlicht nur repliziert. Dafür wäre beim Aufruf von sync() noch die Quelle als Parameter zu übergeben - sync('<eigene IP Adresse>').
Voilà
Nachgereicht: Aufruf der Skript-Funktion sync() per Action.
http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=<Skript Id>&code="sync()"
bzw.
http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=<Skript Id>&code="sync('<eigene IP Adresse>')"Falls du hierfür Hilfe beim coden der Funktion sync() brauchen solltest, frage einfach nach! 
Edit 3:
Das von mir unter Edit 2 beschriebene Workaround wird mit folgender Einschränkung funktionieren.
Immer dann, wenn du die Lichtfarbe oder die Helligkeit im eingeschalteten Zustand änderst, wird diese Änderung nicht auf die anderen Lampen übertragen. Um die Übertragung zu erwirken, musst du die Lampe, an welcher geändert wurde, kurz aus- und wieder einschalten. Danach sind alle Lampen gleich eingestellt. Dabei spielt die Quelle des Schaltens keinerlei Rolle.
Bin ich der Einzige, der das Prinzip dieser Bewässerung nicht versteht?
Nein.
Ich verstehe nur nicht, warum da noch ein Shelly 2 im Spiel ist.
Das hat einen technischen Hintergrund. Vielleicht gelänge das Vorhaben auch direkt auf einem Shelly Wall Display - ich werde solches erst demnächst testen können.
In jedem Fall kann ein Shelly Plus 2PM Skripte abarbeiten, mit welchen eine Master-Slave-Funktion implementierbar ist. Das kann eine Shelly Duo Lampe afaik nicht.
in mir keimt Hoffnung auf, dass ich bald wieder Licht im Wohnzimmer habe.
Nimm solange Kerzen!
Ist das eigentlich schon ein Beruf?
Nein, solches zähle ich jedenfalls eher zu ambitionierter, privater Beschäftigung.
Was machen Leute wie ich, die es nicht können?
Teuer einkaufen!
Muss man es lernen
Nein, weil dies alles nicht lebensnotwendig ist. Es sei denn für Menschen mit Einschränkungen und kleinem Geldbeutel bzw. Leuten, die solche Menschen mit technischen Mitteln unterstützen wollen.
macht es heutzutage der Elektriker?
Nein, weil die Shelly dafür nicht hinreichend zertifiziert sind und insbesondere ein Eigentümer dem Elektriker dazwischen wirken könnte. Ein Elektriker übernimmt typischerweise eine Gewährleistung für seine Installation, was er meiner Meinung nach bei Verwendung von Shelly Geräten mit solchermaßen offengelegter API nicht kann.
Diese sehr gut dokumentierte API bietet ja gerade einem ambitioniertem Anwender viele Möglichkeiten, die er nicht teuer einkaufen muss und für die er nicht zwingend irgendeine Zentrale braucht.
Fazit:
Wenn du dich lieber nicht selbst mit ambitioniertem Engagement um die Funktion deines smart home kümmern willst, vergiss die Shelly Geräte und kaufe beim Fachmann teuer ein! Alles andere ist Illusion.
Wenn MaMoe696 seine bisherige Zusammenstellung und Shelly Konfiguration hinreichend und verständlich beschriebe, wüssten wir mehr. Nun können wir nur vermuten. Entscheidende Dinge wurden bereits angemerkt.
Insbesondere dies erscheint mir unverständlich:
Die Pumpe schaltet automatisch ab sobald der Wasserdrverbrauch endet.
Was bedeutet "Wasserverbrauch endet"? 30 min nach Einschalten? Kein Wasser mehr verfügbar? ...
Ich versuche mal zu strukturieren und hoffe auf verständliche Antworten. Offenbar schaltet ein Shelly Plus 1 das Hauswasserwerk.
MaMoe696: Bitte beantworte diese Fragen, damit wir, oder zumindest ich, zielführend auf dein Anliegen eingehen können!
Hmm, liest sich so wie "von hinten durch die Brust in's Auge".
Es geht mit ziemlich viel Aufwand sicher auch das, was dir vorschwebt. Ich täte solches nicht weiter verfolgen.
Hast du mal darüber nachgedacht, deine bisherige Funkanlage durch Shelly zu ersetzen, möglichst ab Generation 2? Vielleicht gelingt dies auch parallel zur bestehenden Funkanlage. Dazu kann ich leider nicht viel mitteilen, da meine neuen Rollladenantriebe mit einfachen Motoren und drei Anschlüssen ausgestattet sind und bestens an Shelly 2.5 sowie Shelly Plus 2PM arbeiten.
Du könntest aber für den Anfang mit einem Rollladen experimentieren, was auch bereits per altem Shelly 2.5 gelingt. Jedenfalls brauchst du dann zu jedem Rollladen einen einzelnen Shelly, was du ja bereits feststelltest.
Zielführend für ein solches Vorhaben wären genauere Angaben zu deinem Rollladenantrieb - Motoren, Motoranschlüsse, ...
An Hand solcher Informationen können Andere hier voraussichtlich fachgerechte Hinweise geben.
Was mir in deinem Skript unmittelbar auffällt ...
Zeile 12:
urlSource = "http://" & urlSourceIP & "/light/0?/getstatus"Der Operator & dient dem bitweisen UND verknüpfen von Operanden. Was du damit willst, ist eine String-Verkettung, wozu der Operator + geeignet ist.
Deine Zeilen 22 bis 27:
if (boolOnOff === true) {
strOnOff = "on"
}
if (boolOnOff === false) {
strOnOff = "off"
}Umständlicher geht es kaum. Dazu zwei Alternativen:
if(boolOnOff) strOnOff = "on"; else strOnOff = "off";oder noch kürzer: (gefällt nicht jedem)
strOnOff = boolOnOff ? "on" : "off";Auch ist es keine gute Idee, Konstanten, wie bspw. IP Adressen, irgendwo im Code zu platzieren. Dies gehört in einen Konfigurationsbereich, möglichst Nähe Skriptanfang. Dies ist dir aber vermutlich klar, sorry.
Die Funktion deines Skripts habe ich nicht analysiert. Mache bitte weiter!
Noch etwas mehr ...
Prüfe bitte gelegentlich die Verwendung der Methode "Script.Eval"! Diese ist sehr leicht verwendbar und besitzt gegenüber dem Starten und Anhalten eines Skripts folgende Vorteile.
Allerdings wird das Skript von der Firmware abgebrochen, falls im RPC ein Fehler vorliegt, bspw. der Skriptname falsch notiert ist.
Um einen solchen Abbruch zu vermeiden, allerdings bei Fehler ohne gewünschten Effekt, ist ein HTTPServer Endpont zielführend, was etwas mehr Code-Aufwand nach sich zieht.
Allgemeiner:
http://<IP Adresse des betreffenden Shelly>/rpc/script.start?id=<Id des zu startenden Skripts>Die Skript Id kannst du ermitteln per .../rpc/script.list
Muss aber vorher beendet werden
Vielleicht war das mal der Fall vor Firmware 1.x.x, welche unprofessionell war.
Jedenfalls ist dies nicht erforderlich.
Eine Lösung per Action fällt mir dazu nicht ein. Da sind andere erfahrener als ich. Ich bevorzuge halt Skripte, die immer erfolgversprechend sind.
Dein Anliegen habe ich verstanden und kann folgendes aufzeigen, per Skript.
Die Pumpe wird eingeschaltet, was das Skript registriert.
30 Minuten später kann das Skript den aktuellen Verbrauch ermitteln und auf Grund dessen die Pumpe weiterlaufen lassen oder ausschalten. abhängig von deinem Schwellenwert.
Wenn die Pumpe weiterläuft, muss das Skript in kurzen Abständen oder per sog. StatusHandler den aktuellen Verbrauch prüfen, um bei Unterschreitung deines vorgegebenen Schwellenwertes abzuschalten.
Edit:
Es geht aber auch einfacher. Das Skript erfasst jederzeit die aktuelle Pumpenleistung und schaltet sicherheitstechnisch ab, wenn die Leistung den vorgegebenen Schwellenwert unterschreitet. Das sollte auch per Action gelingen.
Edit 2:
Dazu wären für deinen Einsatz schlicht zwei unterschiedliche Nachrichten zu verwenden.
Diese Liste kannst du nach deinem Bedarf erweitern.
In jedem Fall brauchst du einen Shelly, der die vom Verbraucher gezogene Leistung messen kann. Dazu genügt ein Shelly Plus 1 (ohne PM) nicht.
Hätte gerne wenn 30 min zu Ende aber noch xx Watt verbrauch, nicht abschalten.
Das entspricht meiner Interpretation 1.
Hast du Leistungsdaten der Pumpe, wenn sie
Ich stelle diese Frage, weil ich solches trotz Nutzung einer Zisternenpumpe noch nie brauchte.
Ich habe noch ein wenig gesucht und füge folgenden Link hinzu.
Zur RPC Kommunikation über MQTT
Dies hatte ich afaik bereits erwähnt.
Aha, du meinst also die RPC Kommunikation. RPC = Remote Procedure Call
Solche findest du in der recht ausführlichen Dokumentation.
Wenn du Interpretationshilfe brauchst, kann ich vermutlich weiterhelfen.
Spezifisch zur Firmware internen MQTT Konfiguration
Danke für die Erklärung.
Welche Erklärung meinst du? Die von mir zur MQTT Kommunikation? Dies ist für mich u.U. bedeutsam.
Ich suche jetzt schon mehrere Tsge die Seite, wo Befehle aufgeführt waren.
Welche "Befehle"? Wenn es um MQTT geht, gibt es keine "Befehle", aber Nachrichten. Wie diese umgesetzt werden, liegt am Emfänger. Im Empfänger können "Befehle" wirken.
Zielführende Informationen sind nur möglich, wenn deine Aussagen hinreichend verständlich (differenziert) sind.
Edit:
Es ist für einen Anfragenden, ich sage mal Klienten, sicher immer klar, was er meint und wie seine Umgebung gestaltet ist. Für jemanden wie mich, der versucht, das alles zu verarbeiten, ist es zumeist sehr hilfreich, wenn der Klient für ihn redundante Infos an einen Helfenden wiederholt.
der macht die Beleuchtungen aus.
In aller Freundschaft:
Nicht der Button macht in diesem Fall das Licht aus, sondern Amazon Software über den Internetzugriff und die Shelly Cloud. Ohne diese gelänge es nicht.
Dies hat nicht annähernd die Funktionssicherheit einer lokalen Lösung, da kannst du oder könnt ihr soviel schreiben, wie ihr wollt. Ich bitte schlicht nur darum, diese Perspektive nicht zu ignorieren.
Thomas63 Sei bei elektrischen Installationen sehr vorsichtig!
Bleibe aber beim experimentieren nicht so extrem vorsichtig!
Zumindest ich, wie sicher auch viele andere, habe meine Erfahrungen durch Experimente, Lesen, Fehler machen und reflektierendes Verarbeiten (Verstehen) von Zusammenhängen gesammelt. Das ist oft nicht unmittelbar befriedigend. Nach erfolgreicher Bewältigung in Verbindung mit dem Verstehen der Zusammenhänge stellt sich aber eine tiefere Befriedigung geistiger Art ein.
Fazit: Sei nicht so "ängstlich" - no risk no fun.
Zu deiner Frage: Ja, so sollte der URL lauten!
Kann man das in den Einstellungen so hinterlegen das dieser Zwischenschritt nicht nötig ist?
Ein Shelly kann ausschließlich auf Taster oder Schalter und bei Schalter in verschiedene Betriebsarten (Modi) konfiguriert werden. Dies wird auch nie mit einem binären (zumeist digital genannt) Eingang anders möglich sein. Abhängig von den eingesetzten Schaltern oder Tastern, ggf. mit mechanischen Verriegelungen/Freigaben, können solche Handhabungs-Unannehmlichkeiten auftreten, was per Firmware nicht vermeidbar ist. Ob hier ein Skript helfen könnte, weiß ich derzeit nicht, weil ich solche "altdeutschen" Schalter bewusst nicht einsetze. Solche Schalter/Taster ... entsprechen halt den Kenntnissen deutscher Mechanik-Fachkräfte, die die Flexibilität von Software auf Mikrocontroller nicht erkennen wollen oder können. 
Es gibt hierfür nichts flexibleres als schlichte Taster in Verbindung mit einem Skript. Damit lassen sich (vermutlich) alle Bedienungswünsche erfüllen. Nur eine Gesichtserkennung für unterschiedliche, individuelle Bedienungswünsche wären damit nicht erreichbar. 
Nun bleiben dir folgende Möglichkeiten.
Deinen Königsweg musst du selbst finden, wenn es einen solchen überhaupt gibt. Ich habe meinen per Taster und Skript gefunden.
Ja klar, bei 5 Rollläden müsste der Button aber auch jeweils 5, also 10 oder 15 Actions verarbeiten. Das könnte mit Schwierigkeiten verbunden sein.
Und käme ein weiterer Rollladen dazu, wird diese Variante noch problematischer.
Ich dachte noch einmal über das Skript nach und favorisiere folgende relativ einfache Implementation. Dabei setze ich voraus, dass die Durchführung auf den Gruppenmitgliedern gerne auch um jeweils bspw. 1s versetzt erfolgen darf.
Das Skript kann mit wenig Aufwand noch vielseitiger verwendbar gestaltet werden. Hier ist die Anzahl an Gruppenmitgliedern bereits nur durch die interne Speicherkapazität begrenzt. Das Ganze ohne Warteschlange, aber robust, weil die Aktionen zeitversetzt genutzt werden. Ungetestet, aber wegen Einfachheit vermutlich so lauffähig.
Wenn in einer Button 1 Action ein Namensfehler, bspw. statt "to_all" als Funktionsname "toall" eingetragen ist, wird das Skript leider gestoppt. Das liegt nicht am Skript sondern an der Firmware bzw. der verwendeten Methode "Script.Eval". Es ginge auch robuster ohne Skriptstop, im Fehlerfall nur mit Nichtausführung des Gewünschten, das macht aber das Skript etwas komplexer.
// ---------------- Auf eigene Umgebung anpassen! -----------------
let Members = [ // Liste/Datenfeld aus den IP Adressen aller Gruppenmitglieder.
"127.0.0.1", // für sich selbst
"172.16.7.1", // oder so
"172.16.7.2",
// weitere Mitglieder IP Adressen
];
let Period = 1000; // zeitlicher Abstandswert von Aktion zu Aktion in Millisekunden, damit darf experimentiert werden.
// -------------- Ab hier keine Änderungen vornehmen! --------------
let Th, What, Index;
function act() {
if(Index >= Members.length) Timer.clear(Th);
else {
Shelly.call("http.get", {url:"http://" + Members[Index] + "/rpc/" + What + "?id=0"});
++Index;
}
}
function to_all(doThis) {
Index = 0;
What = doThis;
Th = Timer.set(Period, true, act);
}Wenn mit dem Period Wert experimentiert werden will, dann nur soweit verkleinern, bis das Skript mit Fehlermeldung abbricht. Danach vorsichtshalber den letzten Period Wert verdoppeln - fertig.
Die im Button 1 zu jedem spezifischen Tastendruck einzutragende Actions:
(Hier mit vorausgesetzter Skript ID von 1, was mit dem ersten Skript immer der Fall ist.)
zum öffnen
http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=1&code="to_all(cover.open)"zum schließen
http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=1&code="to_all(cover.close)"zum anhalten
http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=1&code="to_all(cover.stop)"Zum fahren auf eine Position müsste das Skript ein wenig umgestaltet werden.
Falls du es einsetzt, viel Erfolg damit und Freude daran!
Die Skript-Lösung kann leicht per Konfiguration vielseitig gestaltet werden. Diese Konfiguration kann im Skript selbst vorliegen oder im KVS - für solche, die lieber kein Skript öffnen.
Ungetestet: Der Parameter doThis ist schlicht die zu verteilende Methode. Hier habe ich die Component Id mit 0 fest verankert.
let Members = [ // Liste/Datenfeld aus den IP Adressen aller Gruppenmitglieder.
"127.0.0.1", // für sich selbst
"172.16.7.1", // oder so
"172.16.7.2",
// ...
];
function to_all(doThis) {
for (let i=0; i<Members.length; ++i)
Shelly.call("http.get", {url:"http://" + Members[i] + "/rpc/" + doThis + "?id=0"}); // hier mal ohne callback function
}Problem: Die Methodenaufrufe sind in ihrer Anzahl begrenzt nutzbar.
Abhilfe wäre die Nutzung einer FiFo-Struktur (Warteschlange, Queue), in die alle Aufträge eingeschrieben und in Abständen von ca 1 bis 3s abgearbeitet werden.
Eine entsprechende Action im Button 1: Das obige Skript möge die Id 1 besitzen.
http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=1&code="to_all(cover.open)"zum öffnen der Rollläden. Die anderen Actions zum schließen, anhalten, ... entsprechend.
Du kannst selbstverständlich das Skript auch auf die Component "Cover" bereits festlegen und nur noch als Parameter die Cover-Methode übergeben.
Oder in Members Objekte (JSON) unterbringen mit der jeweiligen IP Adresse und der Component Id, was das Skript noch ein wenig flexibler macht ...