Ich wusste nicht, dass ein Skripten über die Cloud möglich ist. Wozu soll das gut sein? Als Ersatz für VPN, wenn man einen remote Zugriff auf ein Skript braucht?
Das ist ja so, als wenn ich von Frankfurt nach Kassel über Kairo fahren wollte.
Beiträge von eiche
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.
-
-
Siehst du unter dem Editierfenster den blauen Schriftzug "Console" und in der selben Höhe rechts ein ">" Zeichen?
Dann klicke auf eines von beiden!
Wenn das nicht hilft:
Welcher Shelly?
Welche Firmware-Version?
Sind die Browser halbwegs aktuell?
Browser Cache geleert?
printf() gibt es in C, nicht hier. Hier gibt es print() oder console.log().
-
Interessante Kombination.
Detached bedeutet, dass der Eingang nicht (unmittelbar) auf den Ausgang wirkt.
Das erscheint mir zweckmäßig, wenn du eine Veränderung am Eingang bzw. Tastendrücke per Action (URL) verarbeiten lassen willst.
Ein Momentary mit solchen Actions habe ich noch nie versucht.
Diese Kombination erscheint mir aber als gegenseitig störend.
Somit solltest du Detached ausprobieren.
-
Du willst offenbar nicht verstehen, dass eine Nichtbewegung nicht erkennbar ist, dafür aber die Dauer von ausbleibenden Bewegungserkennungen.
Für Letzteres gäbe es bei entsprechender Ausstattung eine Möglichkeit.
Dazu müsstest du dir aber mehr Mühe für grundlegendes Verstehen geben, als du bisher gezeigt hat.
Ich schließe somit mein Bemühen hiermit ab.
-
Genau! Immer, wenn etwas per App oder Cloud nicht gelingt, sollte man den nächsten Weg versuchen - und das ist Browser mit Shelly IP-Adresse als URL ...
-
Du hattest dich bereit erklärt, das zu testen, denn du hast den Motion 2.
Ich habe einen Motion ohne 2. Ich kann ausschließlich prüfen, ob man an einem solchen Motion die Bewegungserkennung bzw. -Action deaktivieren kann. Da ich derzeit weit weg von meinen Shelly bin, kann ich nicht den Erfolg prüfen. Eine Deaktivierungsmöglichkeit fand ich bisher nicht.
Ein Motion bietet das Auslösen einer Action (URL) bei "END OF MOTION DETECTED".
Darauf bist du nicht eingegangen. Vielleicht täte dich so etwas deinem Ziel näher bringen, falls es am Blu Motion existiert.
Entweder er erkennt eine Bewegung oder nicht. Das will ich wissen. Wie du es sprachlich formulierst, ist mir egal.
Die Nichterkennung einer Bewegung ist etwas anderes als die Erkennung von einer Nichtbewegung. Es ist durchaus nicht egal, wie es tatsächlich gemeint ist.
Zitat (ließ sich nicht einfügen): Prüfen, ob nun tatsächlich keine Bewegung erkannt wird.
Wie willst du etwas prüfen, was nicht erkannt werden kann?
Du kannst allenfalls (per Skript) prüfen, wie lange keine Bewegung erkannt wurde.
-
Bäh, das sieht nach Cloud bzw. App aus - wenig für Experimente geeignet.
Noch einmal gefragt: Welcher Shelly ist der betreffende? Genaue Bezeichnung bitte!
-
Retriggerung bedeutet, dass ein getriggerter Zustand, der nur eine gewisse Dauer, bspw. 2 Minuten, andauern soll, durch einen erneuten Trigger wieder gestartet wird.
zum Bsp: Nun wird getrriggert -> Zustand für 2 Minuten ein, nach 1 Minute wird erneut getriggert -> Zustand für weitere 2 Minuten ein, also insgesamt 3 Minuten ...
vor dem Gerät einen Jive tanzen
Hast du Aufnahmen davon?
Ein Bewegungsmelder kann nicht keine Bewegung erkennen, aber etwas ähnliches vielleicht.
Ein Motion bietet das Auslösen einer Action (URL) bei "END OF MOTION DETECTED".
Auch wenn ich die Nachrichten ignoriere, meldet das Blu Motion dennoch nicht, ob sich jetzt etwas bewegt, sondern auch ob sich innerhalb der letzten 30 Sekunden
Schwer verständlich. Ein (Blu) Motion sollte nach Ablauf einer Blind Time immer eine Bewegung erkennen und die Action auslösen.
Eigentlich programmiere ich gern, aber wenn ich die riesigen Beispielcodes sehe, scheint mir das bei Shelly eher aufwändig. Aber ich komme wohl um die Skripts nicht herum.
Vielleicht hilft dir für den Anfang meine Skripteinführung, der Rest besteht im Studium der relativ ausführlichen Dokumentation - insbesondere der "Methoden".
-
Nun, es sollte zwar mit "localhost" gelingen, probiere trotzdem mal 127.0.0.1!
-
Kann das irgendwas mit dem Punkt "Anmeldung einschränken" zu tun haben?
Das kann sein. Dann wären Anmeldedaten in den URL einzufügen.
Das kannst du aber doch ganz leicht selbst herausfinden, indem du im Ziel-Shelly die geforderte Authentifizierung temporär entfernst und damit die Funktionstüchtigkeit prüfst.
Welche Gründe kann es haben, dass genau die Einstellung, wie beim TE beschrieben bei mir dennoch nicht funktionieren?
19784.5 Grunde
Dazu solltest du uns erst mitteilen, welche Shelly beteiligt sind.
-
Und noch etwas fällt mir bei genauerem Hinsehen auf.
Das Skript gibt jeweils bzgl. des Schaltens etwas aus, was "es nur vermuten kann", aber nicht vom beauftragten Gerät bzw. der Methode als Antwort kommt.
Das ist nicht geeignet und führt zu nicht sicheren Beobachtungen.
Hierfür sind Responses oder callback Funktionen einzusetzen.
Bei Einsatz von HTTP.Get ist die Antwort auszuwerten, die bei Shelly.call("HTTP.Get", ...) in der callback Funktion per Parameter (oft result benannt) eintreffen sollte.
-
Sorry. Bin zwar gelernter Ingenieur aber das kommt hier wohl nicht so klar hervor
Willkommen im Club.
Psst, ich nehme auch Phasenprüfer, Handwerker haben aber dbzgl. und ihren Erfahrungen dafür professionelle Geräte, die Spannungen anstatt mitunter schwebende Potentiale erfassen.
-
Noch etwas zum Skript.
Ich kenne den Ersteller des, nach deinem Hinweis, ursprünglichen Skriptes und halte sehr viel von seiner Kompetenz. Trotzdem ist es wenigstens guter Stil, eine Variable mit deren erstem Einsatz per Schlüsselwort "let" anzulegen,
also bspw. in Zeile 19 statt temp_kamin =
let temp_kamin =
zu notieren.
Die grundsätzliche Funktionsfähigkeit sollte aber mit diesem Skript gelingen.
Noch ein kleiner Hinweis:
Wenn du den Wert von Config.relay als String einsetzt (hier '0'), kannst du dir an anderer Stelle den Aufruf JSON.stringify(Config.relay) sparen und stattdessen nur Config.relay einsetzen.
Empfehlung:
Wenn du dich gelegentlich mit event handler beschäftigen solltest, wirst du vielleicht erkennen, dass es durchaus zielführend wäre, einen solchen event handler statt der regelmäßigen Abfragen einzusetzen. Dies ist aber nur eine zweckmäßige Alternative und keine Notwendigkeit. Bei Einsatz eines event handlers sind allerdings eintreffende Werte immer auch zu speichern, damit diese für spätere Vergleiche zur Verfügung stehen.
-
Wenn die Temperatur im Kamin 65 Grad erreicht dann schalte die Pumpe an.
So etwas geht nicht wirklich. Was soll "65 Grad erreicht" bedeuten?
Nur wenn die Temperatur genau 65 Grad ist (für Regelungen unbrauchbar) oder wenn sie mindestens 65 Grad ist?
Letzteres passt nicht zum folgenden Zitat.
Wenn die Temperatur über 65 Grad ist, dann prüfe den Temperaturunterschied zum Pufferspeicher, ist dieser größer, gleich 4 Grad, dann schalte Pumpe an
Dies sollte den Inhalt des ersten Zitats überflüssig machen.
Zum brauchbaren Regeln (oder Steuern) fehlt hier eine Hysterese der Temperaturdifferenz. Ohne eine solche Hysterese wird im nahen Bereich der Differenz von 4 Grad (mal 4.1, mal 3.9) wiederholt in kurzen Abständen geschaltet. Solche Temperaturschwankungen bzw. Messschwankungen sind zu erwarten.
-
L1‘ rauf und L1‘‘ runter (in meinem Fall schwarz und grau) abklemmen, Wago drauf und in den Shelly, vom Shelly weiter in die Schalter
Alle anderen Punkte sollten passen, auch wenn es da von Elektrikerseite Einwände gäbe (Phasenprüfer).
Der zitierte am Ende nicht.
L1' und L1'' sind ja offenbar die Leitungen, welche zum Antrieb führen.
Wenn das stimmt, dann gehören diese beiden an die Ausgänge des Shelly.
Jedenfalls sind den Schaltern L zuzuführen und deren beide Ausgänge an die beiden Eingänge des Shelly zu legen.
-
Das Skript arbeitet offensichtlich zumindest gelegentlich, was an Hand der Skriptausgeben zu sehen ist.
Wenn etwas nicht funktioniert, ist als erstes zu prüfen, ob das Skript weiterhin läuft.
Du schreibst von einem Shelly Plus 1PM und später von einem Shelly Plug - ist das einer der ersten Generation (vermutlich).
Es ist nicht hinreichend deutlich, welcher der beiden wofür zuständig ist.
Im Skript werden HTTP Requests ausschließlich an die IP Adresse 127.0.0.1 (=localhost) gerichtet, was ja ausschließlich am selben Shelly wirksam werden kann, auf dem das Skript arbeitet.
Hierzu dürfte in der Config Struktur ein Eintrag Remote (o.ä.) fehlen, der die IP Adresse des Plug beinhalten muss.
In den oder zumindest einem der HTTP Requests ist dann statt 127.0.0.1 Config.Remote zu verwenden, damit der Plug die Requests erhält.
Falls du lokal schalten lassen willst, täte ich dafür kein HTTP Request einsetzen sondern einen schlichten Shelly.call("Switch.Set", ...) Aufruf, es sei denn du willst das Skript so offen halten, dass du jederzeit statt lokal zu schalten ein anderes remote Gerät schalten lassen kannst. Dann sind aber die IP Adressen in deinen Requests unterschiedlich zu wählen, also ggf. ein weiterer Config Eintrag einzusetzen.
Ich empfehle sogar, in Config komplette URL(s) zu notieren, die an dieser einen Stelle gepflegt werden können und an den Stellen ihres Einsatzes einen schlichteren Aufruf gestatten.
Bsp:
let Config = {UrlPumpe: 'http://<IP Adresse>/relay/0?turn=off'; // Hier wird der zielführende URL komplett festgelegt.
// ...
}// An der Stelle der URL-Nutzung:
Shelly.call("http.get", {url: UrlPumpe});
Ich bin derzeit überfragt, ob ein Shelly der zweiten Generation auch URLs verarbeitet, die für Geräte der ersten Generation gelten. Wenn, dann ausschließlich aus Gründen einer Rückwärts-Kompatibilität. Andernfalls laufen solche URLs in's leere.
Zwecks Fehleranalyse sind erheblich genauere Informationen erforderlich.
Aber irgendwie funktioniert das nicht immer. Gestern lief es erst, aber heute morgen nicht.
Solche Aussagen haben einen Informationsgehalt von fast Null.
- Was lief gestern?
- Was lief heute Morgen nicht?
- Welche Schaltvorgänge gelingen?
- Welche Schaltvorgänge gelingen nicht
Das sollte erst einmal genauer geklärt werden.
Trotzdem können dich meine obigen Aussagen zum Skript bereits weiterbringen.
-
Dahinter die LAN Kabel von denen ich nicht weiß, was die da machen.
Ich sehe da keine LAN Kabel, aber Wago Klemmen. Vermutlich verwechselst du eine Klemme mit einem LAN Stecker.
Dann war mir auch nicht klar, was passiert wenn ich z. B. auf App RAUF mache, aber zeitgleich am Schalter RUNTER? Liegt dann Strom an beiden Seiten des Motors/Kondensators für die Steuerung an? Geht dann was kaputt?
Das kann passieren, hängt aber davon ab, wie die Elektrik des Motors arbeitet.
Zumindest sollte ein Plus2 PM zur Ansteuerung geeignet sein, wenn er im Roller Modus betrieben wird.
Du solltest die beiden Schalter/Taster mit den Eingängen des Shelly verbinden. Vermutlich können so die beiden Eingänge des Shelly genutzt werden.
In jedem Fall sollte ausschließlich der Shelly den Antrieb schalten und möglichst die beiden Schalter/Taster den Shelly steuern.
-
Du brauchst ja nicht dort zu kaufen. Es gibt aber offensichtlich ein reichhaltiges Angebot an Antrieben.
Fensterantriebe für Kippfenster
Ich kenne aus eigener Erfahrung einen Kettenantrieb an einem ca. 60x60cm² (geschätzt) großen Kippfenster in einem Badezimmer.
Dieser ist nicht leise, funktioniert aber afaik nach 18 Jahren noch immer.
Da ich dort nur hin und wieder zu Besuch auftauche, kann ich dazu nicht mehr sagen.
Wenn du genauer planen willst, musst du halt die erforderlichen Kräfte zum öffnen und schließen messen und die Kraftangaben mit denen solcher Produkte vergleichen.
Alternative: Du suchst einen Handwerker auf, der damit Erfahrung hat.
Einen Batterie betriebenen Antrieb kann ich mir hierbei schlecht vorstellen.
Edit:
In meinem derzeitigen Haus öffnen und schließen wir die Fenster manuell, wofür ich per zentralem Raspberry Pi und Node-RED ein Dashboard zur Verfügung stelle.
Auf diesem Dashboard (Smartphone) tippen wir ein Symbol "lüften" an, woraufhin die Zentrale Nachrichten an die entsprechenden Heizkörper-Shelly sendet, die die Zieltemperatur auf bspw. 10°C senken. Im Winter spüren wir, wenn es kühl wird und schließen bei Bedarf nachdem wir auf dem Dashboard lüften deaktivierten.
Das schreibe ich, weil wir dafür keinen Automatismus brauchen, aber ein Handhabungswerkzeug (das Dashboard) uns dabei bestens unterstützt. Dies gelingt auf diese Weise selbstverständlich nicht mit herkömmlichen, mechanischen Thermostaten.
-
Kleine Ergänzung:
Per kurzem Druck auf den Button wird der Alarm Aus Timer neu gestartet, was auch Retriggerung genannt wird.
Wenn bspw. die gute Frau den Button kurz drückt und dies später erneut tut, wird der Alarm länger als ursprünglich gewollt verhindert.
Der Alarm Aus Zustand kann durch immer mal wieder kurzes Drücken ständig ausgedehnt werden.
Wenn dies nicht gewollt ist, ist das Skript ein wenig abzuändern.
Wie immer ein für Nutzer leicht anzuwendendes Skript.
-
Weil mit dem Plus per Skript und flexibler Schedule Jobs und überhaupt
viel mehr möglich ist.Ohne solche Dinge kann es Einschränkungen geben, die entweder ein übergeordnetes System verlangen oder einen Tausch zu Gunsten eines Plus.
Edit:
Mit einem Plus kannst du (prinzipiell) Messdaten speichern und, wann immer es gebraucht wird, diese Daten übertragen.
Auch die Kommunikation gelingt per Skript erheblich flexibler als ohne.
Du weißt hoffentlich bereits, das auf einem Uni (ohne Plus) kein Skripting und keine flexiblen Schedule Jobs möglich sind.
