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.
Noch eine Kleinigkeit - aber nicht erheblich.
Am Ende deines Skripts zu finden:
var tH1 = 0; //Global Timer Handler
checkWifiIP();
if(!tH1) tH1 = Timer.set(interval, true, checkWifiIP);Da in deinem Skript nirgendwo der Timer mit dem Handle th1 beendet wird, läuft die Nutzung von th1 in's Leere. Auch die Anweisungsbedingung ist überflüssig. Es genügt - am Ende deines jetzigen Skripts:
checkWifiIP();
Timer.set(interval, true, checkWifiIP);Ich finde auch keine Ursache für das Skriptversagen in deinem Code.
Ich vermute, ohne davon überzeugt zu sein, dass der Timer abgebrochen wurde.
Grund: Wenn das Skript läuft, muss der Timer deine Funktion checkWiFiIP() aufrufen. Dann müsste zumindest hin und wieder etwas übertragen werden.
Deshalb mein Vorschlag.
Nimm den Timer heraus (auskommentieren) und verwende stattdessen einen Schedule Job, der bspw. alle 2 Minuten checkWiFiIP() aufruft.
Das gelingt per URL wie folgt.
http://<IP Adresse des Shelly>/rpc/schedule.create?timespec="0 */2 * * * *"&calls=[{"method":"script.eval","params":{"id":<Id deines Skripts>,"code":"checkWiFiIP()"}}]Zur Unterstützung beim Anlegen ... eines Schedule Jobs stelle ich eine Webseite zur Verfügung: Unterstützung beim anlegen, ändern und entfernen von Schedule Jobs (Zeitplänen)
Damit kann wenigstens ermittelt werden, ob es am Timer liegt.
Die Schedule Periode kannst du nach dem Anlegen des Jobs leicht per Web UI ändern, den Job kann man derzeit aber nicht per Web UI anlegen.
Edit:
Einen weiteren Schedule Job kannst du übrigens auch zum regelmäßigen starten deines Skripts verwenden.
Und als Notfall Idee: Einen Job zum regelmäßigen Reboot des Shelly. Das muss gelingen, weil hierfür kein Skript verwendet werden muss.
Edit 2:
Zur Notfall Idee den passenden URL nachgereicht - ungetestet: Rebootet alle 2 Stunden
http://<IP Adresse des Shelly>/rpc/schedule.create?timespec="0 0 */2 * * *"&calls=[{"method":"shelly.reboot"}]Für seinen Handhabungszweck ist das kein Fehler.
Aha, verständlich.
Auch wenn deine bisherigen Taster-Handhabungen vermutlich so intuitiv geworden sind, dass du dich davon nicht lösen möchtest, kann ich dir folgendes als Option anbieten.
Vorbemerkung:
Unsere Rollladenantriebe steuern wir per je zwei Taster eines Shelly Wall Switch 4 an einem Shelly i4 und MQTT. Mit einem Switch 4 steuern wir somit zwei Rollläden oder einen Rollladen und bis zu zwei andere Schalt-Shelly.
Die Switch 4 werden dafür nicht erforderlich sein, das müsste mit deinen Tastern genauso gehen. Auch MQTT ist unerheblich dafür.
Mit dem oberen Taster für einen Rollladen starten wir dessen Fahrt nach oben, mit dem unteren nach unten - jeweils mit kurzem Drücken.
Angehalten wird der Rollladen durch erneutes drücken auf denselben Taster. Fahrtrichtung geändert per Drücken auf den jeweils anderen Taster.
Dies erscheint mir hinreichend intuitiv. Diese Funktionalität erreiche ich per Skript.
Nun zu deinen Antrieben und Taster:
Wenn du mein Skript, auf deinen Tasterbetrieb angepasst, verwenden tätest, wäre die beschriebene Handhabung aller Wahrscheinlichkeit nach bei dir die gleiche wie bei mir.
Dazu wäre der "long push" als Ereignis im Skript hinzuzufügen.
Vorteil:
Per Skript gibt es fast beliebige Möglichkeiten, etwas gewünschtes zu triggern.
Nachteil:
Um ein Verhalten zu ändern, müsste eine Änderung im Skript vorgenommen werden, wozu das Skript wenigstens verstanden sein muss.
Dieser Nachteil könnte per KVS Eintrag zum großen Teil ausgeglichen werden, wozu das Skript den entsprechenden KVS Eintrag verarbeiten müsste.
Auch wenn ich viel im Konjunktiv schrieb, bin ich davon überzeugt, dass dies gelänge.
Interessantes Anliegen.
Da sind die Cloud- und Szenen-Nutzer gefragt.
Ich bin auf die Antworten gespannt.
Das erscheint mir jedenfalls mal eine sinnvolle Anwendung per Cloud.
Prinzip ist klar.
Du wirst folgendes dazu brauchen.
Vielleicht hilft dir diese Aufzählung zur Orientierung.
Nein, nicht zwingend.
Mit einem Stromausfall können aber auch Spannungsspitzen verbunden sein.
Spannungsspitzen können in jedem Computer das Umkippen eines Bit (oder mehrerer) erzeugen.
Wenn dies zufälligerweise im nichtflüchtigen Speicher dort geschieht, wo Konfiguration abgelegt ist ...
Das ist wenig wahrscheinlich, aber möglich, abhängig von der Speichertechnologie.
Wenn sich dies wiederholen sollte, halte ich eine solche Ursache allerdings für wenig wahrscheinlich.
Um mehr darüber zu erfahren, müsstest du dich zu einem Nanowesen oder kleiner 
transformieren, in den Chip eindringen und die Halbleiterpfade nach breiter "ausgetretenen" Pfaden, eigentlich per stärkerer Strömchen erwirkten Kristallumbildungen (Stromkanälen), absuchen.
Sonderzeichen in Passwörtern, welche der Shelly nutzt, ist ein altes Thema.
Man sollte solche Zeichen im WLAN/AP für Shelly vermeiden.
Ich mag die App für solche Zwecke nicht, weil ich damit nicht erkennen kann, was während des Einrichtens geschieht.
Deshalb empfehle ich, die ursprüngliche Vorgehensweise ohne App zu verwenden.
Deaktiviere doch einfach mal Bluetooth auf deinem Smartphone/Tablet!
Hast du das mal versucht? Das kann nämlich zeigen, ob du mit der App per Bluetooth verbunden bist.
Falls du dann den Shelly immer noch erreichst, ist die App per WLAN mit dem Shelly verbunden.
Ich kenne jedenfalls keine dritte Verbindungsmöglichkeit.
Ich habe keinen Shelly Plus Uni, nur einen Uni, der nicht im Einsatz ist.
Ich bin aber ziemlich sicher, dass darauf Zeitpläne erstellt werden können, wobei der Plus Uni interessanter ist.
Vermutlich gelingt dies für deinen Zweck sogar per Klicks und so.
Auf dem Plus Uni kann man noch flexibler als auf dem Uni der ersten Gen. Zeitpläne (Schedule Jobs) erstellen, was jedoch je nach Anwendung etwas Einarbeitung erfordern kann.
Es ist zielführend, erst einmal herauszufinden, wie du per App den Shelly erreichst.
Deaktiviere doch einfach mal Bluetooth auf deinem Smartphone/Tablet!
Falls du dann immer noch den Shelly erreichen solltest (per App), dann stimmt deine Annahme nicht, dass der Shelly nicht in dein WLAN kommt.
Andernfalls werden hier verschiedene Leute weiterhelfen können, wenn du mehr über deine gesamte WLAN-Struktur mitteilst und womit sich der Shelly verbinden sollte.
Nutzt du ausschließlich einen Access Point (im Router), dann empfehle ich, den Shelly in die Nähe des AP zu bewegen, falls er sich weiter davon weg befindet.
Hier findest du mehr dazu:
https://shelly-api-docs.shelly.cloud/gen2/General/RPCChannels#mqtt
MQTT ist nicht für peer to peer Kommunikation vorgesehen, was aber mit http gelingt.
Meine Erfahrung in Node-RED ist folgende.
Als workaround nutzt die Shelly Firmware in der MQTT Nutzlast (message, payload) einen Eintrag mit einer Absenderkennung, welche in der Antwort zu einer "Anfrage" im Topic genutzt wird.
Wenn du diese etwas komplexe Nachricht-Struktur nicht nutzen möchtest, kannst du, zweite Shelly Generation vorausgesetzt, ein Skript hierfür verwenden. In einem solchen Skript kannst du deine bevorzugten Topics verwenden.
Siehe auch die Dokumentation unter Scripts.
In Skripten stehen MQTT Methoden wie MQTT.publish() und MQTT.subscribe() zur Verfügung.
Vermutlich nutzt du DHCP und die Abb. zeigt die Cloud Oberfläche (?).
Dann sieh einfach im Router nach. Dort solltest du die vergebene IP Adresse zu deinem "2) Klingel-NEU" finden, allerdings als "shelly-...".
Ohne eine IP Adresse wird sich der Shelly nicht mit der Cloud verbinden können.
Das erscheint mir als widersprüchlich.
Wenn du die Web UI siehst, wie gelingt das im Browser ohne IP Adresse?
Oder siehst du diese in der App?
Falls Letzteres zutrifft, müsste eine Bluetooth Verbindung vorliegen.
Da ich keine Automatisierungen zum einbinden in mein WLAN nutze, kann ich hier nicht weiterhelfen.
Sorry, ich nutze die App sehr selten.
Hast du die Cloud-Verbindung auf der Shelly Web UI (oder App Direktverbindung) aktiviert?
Wenn ja, wie lange wartest du bereits auf den Abschluss?
Etwas Geduld täte ich mitbringen.
Mein Gedächtnis reicht nicht bis hin zu, mitunter wechselnden, Bezeichnungen in Satusanzeigen der ... Web UI oder App (?).
Wenn du den Kontext genauer beschriebst, könnte ich zumindest eine Spur aufnehmen.
In's WLAN einbinden schlicht und einfach wie nach Erhalt des Shelly auch, also von vorne beginnen.
Grund: Es handelt sich (vermutlich) um ein Factory Reset.
Afaik kann man dies in der Konfiguration deaktivieren, was ich nur dann empfehlen kann, wenn das Gerät eine, mitunter aufwändigere Alternative für das Factory Reset bietet - möglicherweise immer vorhanden.
um das Licht im EG Flur zu steuern hätte ich gerne 4 Taster an verschiedenen Positionen:
Haustür, KG Treppenaufgang, EG Treppenaufgang, 1.OG Treppenabgang
Die einfachste Lösung ist, alle Taster parallel mit dem SW Eingang eines Shelly (Plus) 1 zu verbinden, vorausgesetzt dass alle Schalter vom selben Stromkreis versorgt werden wie der Shelly.
Dies ist zugleich auch die ausfallsicherste Lösung - WLAN Ausfall berücksichtigend.
Und eine Lösung, die jeder Elektriker rückbauen kann (Shelly entfernen ...).
Nur damit du eine Reaktion erfährst.
Ich wünsche dir Verkaufserfolg in Verbindung mit einem problemlosen Einsatz der TRV des Käufers.
Ich werde keine TRV mehr kaufen, und schon gar nicht gebraucht.
