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.
Automatik-, Zeit- und bspw. Helligkeits-gesteuerter Betrieb lassen sich leicht in einem Skript unterscheiden und entsprechend kann der Handbetrieb ungesperrt arbeiten.
Und nun eine Lösung für "NichtSkriptFans"
Die sollen hinausgehen und das Eis abkratzen. 
Im Ernst:
Ohne Skript lassen sich imho ausschließlich vorgesehene Dinge implementieren.
Alles, was darüber hinausgeht, ist etwas für Skripte - und bei Bedarf Schedule Jobs.
Dann schreibst Du ein dickes Skript, mit dem Du dann die Rollladenfunktionen in allen Plus2PM abschaltest.
Sooo dick muss das nicht sein. Ein Datenfeld mit Einträgen für alle betreffenden Shelly und eine passende Schleife ... 
Da gibt es das Wetter umsonst.
Es gibt etwas umsonst? Wo wo wo ... 
Das Wetter ist immer umsonst, nur manche Folgen nicht. Und das (erste) ist gut so.
Sorry, das waren halt Steilvorlagen - tue ich sonst eher nicht.
Kann ich dem Shelly vlt. explizit auftragen, nach einem Addon zu suchen?
Habe ich noch nicht versucht. Die Dokumentation beinhaltet Sys.SetConfig ... https://shelly-api-docs.shelly.cloud/gen2/0.14/Comp…s#configuration sorry, erst ab der zweiten Generation
Zwecks Fehlersuche erscheint es zielführend, vom Groben zum Feinen vorzugehen.
Falls eines von beiden den Fehler beseitigt, zwecks Kontrolle vorheriges Teil desselben Typs wieder einbauen und testen.
Tritt der Fehler wieder auf, dieses Teil reparieren (lassen) oder entsorgen.
Mögliche Fehlerursachen:
Viel Erfolg!
Ich zeige hier nur das Prinzip. Wie du auf die eintreffenden Messwerte zugreifen kannst, solltest du selbst herausfinden oder dir von jemandem weiterhelfen lassen, der einen solchen Shelly besitzt.
Das folgende Skript ist so nicht lauffähig. Drei Punkte hintereinander bedeuten soviel wie "Da muss etwas hin, was ich nicht genau weiß." (Ich habe keinen solchen Shelly.)
let Topic = "meine/Werkstatt/Messwerte"; // Auf das von dir gewünschte Topic abändern!
let Measurement = {
voltage: null,
current: null,
apower: null,
aenergy: {total: null}
};
function handleEvent(event) {
print(JSON.stringify(event)); // zeigt die komplette Struktur des eintreffenden event - mit Schlüssel und Werten; kann später entfallen
// Hier die events selektieren, die zu deinem Anliegen passen
if(event. ... === ...) {
// Messwerte speichern
Measurement.voltage = ...;
Measurement.current = ...;
Measurement.apower = ...;
Measurement.aenergy.total = ...;
}
}
function send() {
MQTT.publish(Topic, JSON.stringify(Measurement)); // Bei Bedarf kann QoS und retain als 3. und 4. Parameter hinzugefügt werden.
}
Shelly.addEventHandler(handleEvent);Die Messwerte werden in nicht sehr regelmäßigen Abständen per Event eintreffen. Diese werden einfach in Measurement zwischengespeichert.
Dazu brauchst du noch einen Schedule Job, den du folgendermaßen per Web Browser in der Adresszeile anlegen kannst. Die Angaben in timespec lassen sich später per Web UI ändern.
http://<IP Adresse des Shelly>/rpc/schedule.create?timespec="0 */2 * * * *"&calls=[{"method":"script.eval","params":{"id":<Skript Id>,"code":"send()"}}]Wenn die Skript Id 1 ist und die IP Adresse des Shelly 192.168.178.100:
http://192.168.178.100/rpc/schedule.create?timespec="0 */2 * * * *"&calls=[{"method":"script.eval","params":{"id":1,"code":"send()"}}]Dieser Schedule Job ruft alle 2 Minuten die Funktion send() im Skript auf, unabhängig davon, wann die Messwerte eintreffen.
Sollte ein Messwert den Wert null haben, dann ist für diesen nach dem Skriptstart noch kein Wert eingetroffen.
Zur Unterstützung beim Anlegen eines solchen Schedule Job habe ich eine Webseite zusammengestellt: Unterstützung beim anlegen, ändern und entfernen von Schedule Jobs (Zeitplänen)
Ich habe ein wenig experimentiert, mit folgendem Ergebnis.
Ich lasse in einem EventHandler (Shelly Plus 2 PM Skript zur Rollladensteuerung) die Quellen von Ereignisses ausgeben.
Diese Quelle liegt in event.info.source.
Bei Steuerung per Cloud ist die Quelle "SHC", bei Steuerung per Skript ist die Quelle "loopback".
Du könntest somit selektiv (event.info.source==="SHC") bspw. event.info.timestamp und event.info.event per print ausgeben lassen und/oder noch besser speichern, um nachträglich zu analysieren, wann welche Aktion per Cloud ausgelöst wurde.
Zum speichern gibt es verschiede Möglichkeiten:
Ich nutze für unser Smart Home einen Raspberry Pi mit u.a. Node-RED und MQTT. Damit lassen sich sehr leicht MQTT Nachrichten vom Shelly empfangen und auf dem RPi in einer Datei speichern.
Ich kenne die Cloud-Anwendung deines betroffenen Shelly nicht. Vielleicht erfolgt eine Kommunikation zwischen Shelly und Cloud in kurzen Abständen, was sich an den timestamps ablesen ließe.
Jedenfalls wäre dies eine Möglichkeit, die per Cloud getriggerten Ereignisse zu erfassen und zu analysieren.
Dies ist nicht mehr als eine Idee, anderen Fehlerursachen als dein Skript - worin wir keinen Fehler finden konnten - auf die Spur zu kommen.
Btw, dieses Erfassen und irgendwo Speichern sollte per separatem Skript, außerhalb des Applikations-Skript implementiert werden.
Ein Schedule Job triggert die eingetragene Methode Zeit gesteuert.
Eine Action triggert die eingetragene Methode Ereignis gesteuert.
Man kann Methoden in Schedule Jobs weit über die Möglichkeiten der Web UI hinaus eintragen.
Ob und wie dies in ähnlicher Weise bei Actions gelingt, weiß ich derzeit nicht.
der Shelly kommuniziert mit der Cloud(das will ich auch nicht deaktivieren),
Auch nicht temporär zum suchen der Fehlerursache?
Edit:
Selbstverständlich können Actions sehr flexibel und kreativ per Skript implementiert werden.
From Web UI:
Cycle switch - At the push of a button, the sequence is: Ch1-ON Ch2-OFF, Ch1-OFF Ch2-ON, Ch1 & Ch2 ON, Ch1 & Ch2 OFF.
This mode can only be selected if input mode = Button.
If you provide a schematic of your current system, someone may be able to give you a qualified answer.
Noch'n Tipp
Man kann eine Methode vor der Verwendung in einem Skript auf Funktion und Syntax testen. Nach erfolgreichem Test ist es relativ einfach, den Methodenaufruf in ein Skript einzubetten.
Zunächst vorbereitend ein Funktionstest per Web Browser. Der Uniform Resource Locator (URL) besitzt die folgende Form:
http://<IP Adresse des Shelly>/rpc/<zusammengesetzter Methodenname>?Schlüssel1=Wert1&Schlüssel2=Wert2&...
(Es gibt Methoden ohne Schlüssel-Wert Paare oder mit nur einem Schlüssel-Wert Paar.)
Der zusammengesetzte Methodenname ist case insensitiv, d.h. es wird nicht zwischen Groß- und Kleinschreibung unterschieden. Switch.Set ist also gleichbedeutend mit switch.set oder Switch.set oder switch.Set.
Werte können Zahlen, Wahrheitswerte (beide ohne Anführungszeichen) oder Zeichenketten (Strings, in Anführungszeichen) sein.
Bei Erfolg des Funktionstests kann dies in ein Skript überführt werden:
Eine callback Funktion ist nicht mit jeder Methode zwingend erforderlich, sie ist aber optional immer möglich und kann für Fehlerfälle bzw. Antworten des (remote) Systems genutzt werden.
Angenommen, man will einen Verbraucher an Ausgang 0 einschalten, hier mal ohne callback Funktion.
Falls MQTT zur Kommunikation eingesetzt wird, gelingt dies völlig anders.
Hierfür gibt es die Skript Funktionen MQTT.publish() und MQTT.subscribe().
Dies beschreibe ich aber hier nicht, damit es nicht zu lang wird.
Edit:
Diese Beschreibung kann als Versuch gewertet werden, gegen die Skriptphobie zu wirken.
Du kannst auch für die callback Funktion eine benannte (mit Namen versehene) Funktion verwenden. Das kann die Übersichtlichkeit eines Skripts verbessern.
function handleEvent(event) {
if(event.name==="input"){
let id = event.info.id;
// Anweisungen, die für alle Tasten vor deren Unterscheidung gelten sollen.
switch(id) { // Fallunterscheidung nach der Tasten Id, 0 bis 3
case 0:
// Anweisungen zu Taste 0
break;
case 1:
// Anweisungen zu Taste 1
break;
case 2:
// Anweisungen zu Taste 2
break;
case 3:
// Anweisungen zu Taste 3
break; // hier nicht erforderlich, stört aber auch nicht
}
// Anweisungen, die für alle Tasten nach deren spezifischen Behandlungen (s. case Id) gelten sollen
}
}
Shelly.addEventHandler(handleEvent);Shelly Script bzw. mJS ist eine Untermenge von JavaScript mit zusätzlichem API (Application Programming Interface).
Die API beinhaltet die in der Shelly Dokumentation beschriebenen RPC Methoden (Remote Procedure Call), welche u.a. per HTTP und in einem Skript per Shelly.call(Methode, Parameter, callback) aufgerufen werden können.
Zum erstellen oder anpassen eines Skript solltest du dich deshalb auch mit JavaScript beschäftigen.
Eine brauchbare Quelle (Tutorial und Referenz zum Nachschlage) hierfür ist w3schools: https://www.w3schools.com/
… aber wie selektiere ich nun den Inputs. wo, an welcher Stelle ergänze ich input:2 bzw. id:2
Wenn du im Skript bspw. alle 4 Tasten unterschiedlich nutzen willst, kannst du eine Fallunterscheidung verwenden.
Weil die Event Informationen redundant sind, brauchst du hier den Komponentennamen nicht, es genügt deren Id, wenn zuvor der Name auf "input" geprüft wird.
Shelly.addEventHandler(
function (event) {
if(event.name==="input"){
let id = event.info.id;
// Anweisungen, die für alle Tasten vor deren Unterscheidung gelten sollen.
switch(id) { // Fallunterscheidung nach der Tasten Id, 0 bis 3
case 0:
// Anweisungen zu Taste 0
break;
case 1:
// Anweisungen zu Taste 1
break;
case 2:
// Anweisungen zu Taste 2
break;
case 3:
// Anweisungen zu Taste 3
break; // hier nicht erforderlich, stört aber auch nicht
}
// Anweisungen, die für alle Tasten nach deren spezifischen Behandlungen (s. case Id) gelten sollen
}
}
);Kleiner Hinweis:
Ich nutze nicht selten bei englischsprachigen Begriffen und Abkürzungen mal dieses mal jenes Geschlecht.
API mit I = Interface kann als das Interface oder als die Schnittstelle gedacht werden, entsprechend das API oder die API.
Edit:
Zur Sprache Shelly Script kenne ich kein Tutorial. Dasjenige in der Shelly Dokumentation ist ausschließlich zur Handhabung von Skripten geeignet, nicht zum kennenlernen der Sprache.
Auch kenne ich keine JavaScript Einführung, die außerhalb von Webseiten angesiedelt ist.
Da muss man halt durch, wobei die Kenntnis einer C ähnlichen Sprache nützlich ist.
Abhängig von der Umgebung (Weglänge, Position des Blu Motion, übliche Laufwege), könnte vielleicht ein zusätzlicher (Blu) Motion in Verbindung mit einem Skript helfen.
Der erste Motion sendet eine Nachricht an den Plus 1 bzw. Skript.
Das Skript verzögert das Einschalten (Wartedauer).
Wenn der zweite Motion innerhalb der Wartedauer eine Nachricht sendet, unterbleibt das Einschalten.
Andernfalls schaltet das Skript nach Ablauf der Wartezeit ein, weil die Person sich vermutlich noch im Bereich des ersten Motion aufhält.
Hierfür ist eine gute Abstimmung und Platzierung der Motion zielführend, was selbstverständlich nicht in jeder Umgebung möglich ist.
Oder 89new experimentiert mit einem Motion ohne Blu.
Die Id steckt in event.info.
Shelly.addEventHandler(
function (event) {
if(event.name==="input"){
let id = event.info.id;
// Nun kannst du die gewünschte id selektieren.
// ...
}
}
} So etwas kannst du selbst herausfinden, indem du event per print() ausgeben lässt - weniger Zeilen umfassend per print(JSON.stringify(event)).
Wenn du den Überblick hast und dich bspw. nur für das interessierst, was in event.info steckt, dann print(JSON.stringify(event.info)).
...
Ich verstehe nicht, warum ich immer wieder diesen user_data als Parameter finde, obwohl nichts dafür oder null übergeben wird. Das ist absoluter Unsinn.
Wenn du den Code leicht verbessern willst, nimm dieses stereotype, überflüssige Zeug heraus!
Am Beispiel der Funktion toggleRGBW(ip) gezeigt:
function toggleRGBW(ip) {
Shelly.call(
"http.get", {
url: 'http://' + ip + '/light/0?turn=toggle'
},
function (response, error_code, error_message, ud) { // ud wird nicht gebraucht.
}, // Komma weg!
null // null bedeutet soviel wie "nichts" oder "ungültig", auch weg!
);
}Dann bliebe nur noch ein Skript auf dem Plus 1, welches abhängig von den Nachrichten des Blu Motion erst später schaltet.
Ich kann wegen fehlendem Blu Motion nichts dazu beitragen, weil hierfür die Analyse der Nachrichten erforderlich ist.
Außerdem hat offensichtlich die Blind Time eine andere Wirkung als die von mir angeführte Sleep Time eines Motion.
Im Motion gibt es auch die Blind Time, welche der TE ostfriese mit seinem Beitrag ja in ihrer Wirkung beseitigte.
Das weiß ich mangels Gerät nicht. Suche selbst!
Es ist aber zu erwarten, dass es auch im Blu Motion diese Einstellung gibt.
Im Motion: Sensor Control -> Sleep Time
Alles auf der Web UI. Ich nutze die App fast nie.
Mal unabhängig von deiner sonstigen Ausstattung.
Du kannst eine Kombination aus Schedule Job und Skript einsetzen. Ich meine damit nicht, dass es keine andere Möglichkeit gibt.
Die System integrierte MQTT Kommunikation ist aber etwas komplex, weil sie, jedenfalls in Shelly der zweiten Generation, eine Peer to Peer Kommunikation nachbildet.
Das Skript braucht folgendes.
Der Schedule Job ruft in festgelegten Abständen die Funktion send() auf.
Somit werden auch dann Werte, die zwischengespeicherten, gesendet, wenn keine neuen hereinkommen.
Habe ich den Anliegen richtig verstanden?
Wenn du weitere Hilfe dazu möchtest, melde dich!
Hast du mal die Sleep Time genutzt?
Aus einem Motion, nicht Motion 2:
Ein Schedule Job ist erst einmal kein Shelly call.
Da der Job aber etwas bewirken soll, ergibt er imho ohne eine Methode (im Skript als Shelly.call() nutzbar) keinen Sinn.
Du kannst jede Methode verwenden, die dein Shelly bietet.
Mit http://<IP Adresse>/rpc/Shelly.ListMethods kannst du alle Methoden auflisten lassen, die der Shelly bietet.
Ein Schedule Job arbeitet unabhängig von Skripten, er kann per Methode "Script.Eval" aber eine Anweisung in einem laufenden Skript ausführen lassen.
Zumeist dürfte es zielführend sein, per "Script.Eval" eine Funktion eines laufenden Skripts, ggf. mit Parameter, aufrufen zu lassen.
Das Limit (derzeit 5) für Calls bezieht sich jeweils auf ein Skript und nicht etwa auf den Shelly. Seihe auch Ressource Limits
Ein Call bzw. Methodenaufruf per Schedule Job fällt somit nicht darunter.
Hast du mal die Periode zum Aufruf von checkWifiIP() deutlich verlängert?
Wenn deine Vermutung der "Geister-Calls" auf Grund deren Anhäufung in einer Warteschlange zutreffen sollte, dann müssten diese ab einer genügend langen Periode wegbleiben - nur zwecks Fehleranalyse.
Da der default Timeout-Wert 15s beträgt und du alle 2 Minuten eine Nachricht senden lassen willst, ist trotzdem nicht zu erwarten, dass diese Maßnahme weiterhilft.
Ein Schedule Job, wie ich ihn oben angab, arbeitet eigenständig, weshalb du diesen einmal verwenden solltest, wenigstens zum testen.
Weitere mögliche Schritte zur Fehlersuche
Weil es bisher keine Spur zur Fehlerursache gibt, will ich den Timer nicht ausschließen, auch wenn dies sehr unwahrscheinlich ist.
Vielleicht verändert sich die Timerperiode, aus welchen Gründen auch immer. Angenommen, sie verkürzt sich. Dann könnten die periodisch aufgerufenen Calls irgendwann zu dicht aufeinander folgen.
Hier kann ein Schedule Job Abhilfe schaffen.
Edit:
Man kann auch Ereignisse auslösen lassen. Damit lassen sich bspw. die Aktionen eines Skripts auf mehrere Skripte verteilen.
Eine andere harte Alternative zum Reboot, besteht bspw. darin, das Skript die Funktion checkWifiIP() aufrufen zu lassen und sich nach 30s oder 60s selbst zu beenden. Oder das Skript beendet sich in der innersten callback Funktion, wenn also alles abgearbeitet wurde, was abzuarbeiten ist. Der Ort des Skript Stoppens wäre in deinem Skript die Funktion handleResponse(), selbstverständlich am Ende.
Ein Schedule Job kann in regelmäßigen Abständen dein Skript per Methode "Script.Start" starten, bspw. alle 2 Minuten.
Dabei stellt sich die Frage, ob es eh nicht besser wäre, im WoMo Shelly Plus Uni einzusetzen, ggf. mit SSR (Solid State Relais).
Diese Kombination sollte weniger Energie verbrauchen und bietet mehr Möglichkeiten.
Noch eine Idee:
Du könntest den Shelly Plus 1 durch einen Plus 2 ersetzen.
Dieser ist so (ohne Skript) per Action oder Leitung konfigurierbar, dass das zweite Relais den umgekehrten Zustand zum ersten einnimmt. Eine daran angeschlossene LED mit Vorwiderstand täte auch ohne Web UI den aktuellen Zustand anzeigen.
12V Versorgung für den Plus 2 ? Hm ... mal nachsehen
Edit: Schade, Plus 2PM geht nicht mit 12V.
Da dein Anliegen mit der Web UI nicht realisierbar ist, sehe ich derzeit eine einzige Möglichkeit, deinem Wunsch näher zu kommen.
Ein Skript, welches eine interaktive Webseite zur Verfügung stellt, auf welches ziemlich alles, was an Symbolen gewünscht ist, implementierbar ist - auch die Darstellung "aktiv" bei ausgeschaltetem Relais.
Falls du dich dafür interessierst und bereit bist, dich mit einem Skript (und etwas HTML) zu beschäftigen, liefere ich dir gerne den Anfang - bei Gelegenheit.
Edit: Im WoMo einen zusätzlichen Shelly nur wegen eines Gimmicks zu installieren, halte ich für Energieverschwendung.
Selbstverständlich ist es deine Entscheidung.
Edit 2: Ich vergaß, darauf hinzuweisen, dass dafür ein Shelly der zweiten Generation oder höher erforderlich ist. Den hast du aber offensichtlich.