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 ...
Beiträge von eiche
-
-
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.
-
Lol Micha, eher nein. Das überlasse ich gerne dir.
Evtl. kann ich den Part zum temporären Schedule Job dazu beitragen.
Edit:
Es sollte einfacher gehen - aber mit diesem speziellen, temporären Schedule Job.
Wenn sich das Skript mit beiden Endpoints selbst beendet, kann es nicht schalten.
Dann muss vor dem Beenden der Schedule Job angelegt bzw. erneuert (update) werden.
Dieser Job startet dann einfach das Skript drei Stunden später.
Für ein vorzeitiges Beenden des Sperrens kann ein zweites Skript nach Eintreffen einer bestimmten Nachricht das erste starten.
Was meinst du dazu?
Hm, noch eine Idee - ohne Schedule Job und noch einfacher:
Im zweiten Skript wird vom ersten Skript eine Funktion aufgerufen, die das erste Skript stoppt und einen Timer für 3h startet, an dessen Ende das erste Skript gestartet wird.
-
Zu #3
Sorry Michael, aber den Input zu deaktivieren bringt nur etwas, wenn an diesem Eingang etwas elektrisch angeschlossen ist.
Soweit ich es verstand, werden aber Nachrichten gesendet.
Selbstverständlich können solche Nachrichten per Skript ignoriert werden und eine Nachricht ein solches Ignorieren für 3 Stunden starten.
Dazu können im Skript, wie du mindestens so gut weißt wie ich, HTTP Endpoints eingesetzt werden.
Ich sehe derzeit nur eine Möglichkeit zur Implementation deines Anliegens - Cloud und Szenen ausgenommen, weil diese hier extrem suboptimal sind.
Auf deinem Mini arbeitet ein Skript mit zwei HTTP Endpoints, d.h. es gibt zwei Empfänger (im Skript) für zwei unterschiedliche URL.
Der eine URL (Nachricht 1) kommt von deinem mir unbekannten Bewegungsmelder, der andere URL (Nachricht 2) vom Blu Button.
Trifft Nachricht 2 ein, wird eine Enable Variable auf false gesetzt und ein Timer für 3 Stunden gestartet, an dessen Ende Enable auf true gesetzt wird.
Wenn innerhalb dieser 3 Stunden eine Nachricht 1 eintrifft, wird sie nicht verarbeitet, weil Enable auf false steht.
Ich kann dir hierfür leider nichts anbieten, was ohne Skript auskommt. Auch den Einsatz eines übergeordneten Systems kann ich für diesen Einsatz nicht empfehlen.
Den Blu Button an die Reinemachekraft alias "Putzfrau" auszuhändigen, erfordert viel Vertrauen.
Btw, es ist möglich, dieses Skript vorsichtshalber und zur Bewahrung einer gewissen Funktionssicherheit bspw. alle 2 Minuten zu starten - per Schedule Job.
Ob all dies deinen Sicherheitsbedürfnissen gerecht wird, wirst du selbst entscheiden müssen.
Edit:
Deinen Hinweis auf ein Skript von @De kat habe ich jetzt erst gesehen. Dann kann evtl. meine Darlegung zur Funktion eines Skript ignoriert werden.
Ich muss mich korrigieren, was den Schedule Job betrifft. Habe nicht sorgfältig genug nachgedacht. Das ist selbstverständlich Bullshit, weil dann die Timerfunktion weg ist ...
Aber, was ich bisher noch nicht versuchte, es ist möglich, einen temporären Schedule Job so anzulegen, dass er 3h später eine Funktion auffruft, die Enable auf true setzt und diesen Schedule Job entfernt.
-
Ja, mir ich bewusst, das bei Li-Akkus die Spannungskurve sehr flach ist, und das dadurch schlecht Rückschlüsse auf den SoC gemacht werden können, aber man sieht, wann der Akku voll oder leer ist.
Gegenfrage in die Runde. Wären Z-Dioden in Reihe zum Spannungsteiler nicht dazu geeignet, den Teilungsfaktor zu verringern? Vermutlich ergibt das mehr Genauigkeit als mit einem simplen Spannungsteiler.
Ich täte dies jedenfalls versuchen und glaube an den Vorteil.
An vielleicht weniger Elektronikbehaftete: Z-Dioden subtrahieren praktisch eine gewisse Spannung (deren Z-Spannung) von einer Gesamtspannung. Manche sagen auch noch immer Zenerdiode dazu, obwohl nicht ausschließlich der Zenereffekt darin wirkt, je nach Z-Spannung mehr oder weniger.
Und täglich grüßt die Cloud - in ihrem Schlepptau die Szene. Ihr gebt zu viel an Funktionalität an Andere, weniger Verlässliche ab!
Warum UNBEDINGT nen UNI nehmen? Nen UNI hätte ich hier liegen, einen UNI Plus nicht.
Je mehr das Gerät kann, desto weniger muss kommuniziert und desto unabhängiger von der Cloud können Lösungen gefunden werden. Ich weiß, ich weiß ... die Szenen sind ja so verlockend, wie die Loreley.
-
ich brauche die Bewegungserkennung zu genau einem bestimmten Zeitpunkt. Falls in den 30 sek zuvor schon eine Bewegung stattgefunden hat, würde ich ja einen falsch positiven Wert bekommen.
Meinst du damit eine Retriggerung, welche du vermeiden möchtest? Genau dafür ist afaik die Blind time gedacht.
Eine Bewegungserkennung zu einem bestimmten Zeitpunkt ergibt imho keinen Sinn, aber in einer festgelegten Zeitspanne durchaus. Vermutlich meinst du dieses.
Frage: Könnte ich das auch lösen, indem ich die Bewegungserkennung grundsätzlich abschalte und nur zum gewünschten Zeitraum einschalte?
Dazu könnte ich nur in einem meiner Motion (ohne Blu) nachsehen, ob dieses möglich ist. Ich werde es versuchen.
Man kann aber auf einem Schalt-Shelly der zweiten Generation per Skript die Nachrichten vom Blu Motion ignorieren und nur für die gewünschte Zeitspanne wirken lassen.
Edit:
Mit jeder Szene steigt die Abhängigkeit eines Smart Home von der Cloud und einem ständigen Internetzugriff. Ich verstehe die Beliebtheit solcher Szenen nur sehr eingeschränkt.
