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.
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.
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.
Solches herauszusuchen täte ich allenfalls gegen Gebühr.
Ich habe nie eine CCU genutzt, weiß aber dass Homematic auch eine Node-RED (ich glaube dort heißt es Node-Matic(?)) Installation bereithält.
Damit kann man einen sog. Flow erstellen, der die Daten per MQTT oder HTTP Request erhält. Ob und wie diese auf dem Raspberry Pi in einer Datei abgelegt werden können, entzieht sich meiner Detailkenntnis.
Ich nutze dafür einen RPi, Mosquitto, Node-RED, InfluxDB und Grafana - also kein fertiges System. Damit geht so ziemlich alles.
Für einen Freund habe ich eine persistente Speicherung auf einem Shelly Plus ... per Skript implementiert, welche nach Bedarf (spätestens nach 8 Tagen, aber abhängig von der Abtastrate) per MQTT abgerufen werden kann.
Das habe ich auch dokumentiert.
Es wäre bspw. so möglich, an die Daten zu kommen - zunächst ohne die CCU:
per Web UI -> Scripts -> Script "data" (ist kein Skript, sondern eine Datei) öffnen -> per Copy & Paste die Daten in deine Verarbeitungsanwendung kopieren und schließlich per Homematic eine MQTT Nachricht senden, die die Aufzeichnung neu starten lässt.
Eine Anpassung an das von dir benötigte Datenformat sollte leicht möglich sein.
Was per Homematic dbzgl. ginge, weiß ich naheliegenderweise nicht.
Edit:
Obiger Datentransfer gelingt auch ganz ohne die CCU.
Dazu kann man in der Web UI das Skript stoppen, das Nichtscript "data" löschen, das Skript starten - fertig, denn nun beginnt die Aufzeichnung von vorne.
Dies ist bereits jetzt implementiert.
Für eine Vermarktung ließe ich mir noch bessere Usability einfallen, deren Grundlage ich bereits kenne.
Nö, aber implementieren könnte ich so etwas.
Ok ok - etwas mehr Informationen.
Per Shelly, möglichst Plus 1 oder Plus Uni, den Schließer schalten, was ggf. ein Eingriff in dessen Elektrik erfordert.
Mit dem Starten des Lüftens auch eine Nachricht an den Shelly senden.
Wie diese Nachricht zu gestalten ist, hängt von deinem genaueren Vorhaben und deinem Equipment ab.
Der Shelly kann nach einer gewissen, parametrierbaren Dauer das Schließen einschalten.
Eine einfache Nachricht zwecks einschalten (bzw. auch ausschalten) sieht so aus.
http://<IP Adresse Shelly>/rpc/switch.set?id=0&on=true&toggle_after=1800Diese sorgt dafür, dass der Shelly den Ausgang einschaltet und nach 30 Minuten umschaltet, hier also aus.
Falls du ausschalten und nach 30 Minuten einschalten lassen willst, ersetze einfach on=true durch on=false!
Solltest Du eine Idee haben wie ich diese Info über WLAN abfragen kann, würde das bereits reichen.
Ich habe dazu einige "Ideen".
Welche dir dazu am besten helfen könnte, hängt stark von der Anwendung ab, mit welcher du die Daten empfangen und verarbeiten lassen willst.
Ein simples Beispiel ist den Status eines Ausgangs per Web Browser und passendem RPC (Remote Procedure Call) anzufordern.
http://<IP Adresse Shelly>/rpc/switch.getstatus?id=0Falls du mehr über den gesamten Shelly-Status wissen willst, gelingt dies bspw. mit
http://<IP Adresse Shelly>/rpc/shelly.getstatusAm besten im Edge- oder Firefox-Browser, weil diese die Antwort übersichtlich darstellen. Wie dies Safari tut, weiß ich nicht.
Mein Vorschlag:
Sieh dir mal die beiden Antworten genauer an und gewinne einen Eindruck, was du damit anstellen möchtest.
Danach können wir vielleicht weitersehen.
Es gibt dafür verschiedene Implementationsmöglichkeiten. Am flexibelsten ist hier immer, auch ein Skript zu verwenden.
Ich skizziere mal zwei Varianten, die jeweils ein geeignetes Skript im zusammenwirken mit zwei Schedule Jobs nutzen.
Das Skript stellt zwei Funktionen zur Verfügung, ich nenne sie sunset() und sunrise().
Diese werden per zweier Schedule Jobs mit der Methode Script.Eval aufgerufen, der eine Job ruft sunset() auf, der andere sunrise().
Einen EventHandler brauchst du zunächst nicht dazu.
sunset() und sunrise() schalten jeweils "ihre primären" Ausgänge, starten jeweils einen Timer, welcher nach 2000ms eine Funktion abarbeitet, die den anderen Ausgang passend schaltet.
Mit dieser Implementation brauchst du die von dir verdrahtete Rückkopplungen nicht.
Ein geeigneter Schedule Job kann wie folgt angelegt werden:
http://<IP Adresse Shelly>/rpc/schedule.create?timespec="@sunset * * *"&calls=[{"method":"script.eval","params":{"id":<Script Id>,"code":"sunset()"}}]
Du kannst selbstverständlich auch die Rückkopplungen zusammen mit einem EventHandler einsetzen.
Der EventHandler reagiert selektiv auf die Änderungen an den Eingängen wie folgt.
Er startet einen Timer, der nach 2000ms den gewünschten Ausgang ausschaltet. Die Wartezeit ist aber nur erforderlich, wenn nicht sofort nach eintreffen des Eingangsänderungs-Ereignisses geschaltet werden soll.
Die beiden Schedule Jobs brauchen dann nicht wie in Variante 1 die Methode Script.Eval sondern die Methode Switch.Set mit der Ausgangs ID und on=true.
Ein solcher Schedule Job kann wie folgt angelegt werden:
http://<IP Adresse Shelly>/rpc/schedule.create?timespec="@sunset * * *"&calls=[{"method":"switch.set","params":{"id":<Ausgangs Id>,"on":true}}]
Bei Variante 1 kannst du per RPC Methode die Daten anfordern und in der callback Funktion senden lassen.
Bei Variante 2 kann der EventHandler die eintreffenden Informationen senden.
In beiden Fällen sollten die Daten mit JSON.stringify(Daten) vorher in einen String umgewandelt werden.
Oder ähnlich, falls dies nicht ganz zu deinem Anliegen passen sollte.
Auch kannst du Daten regelmäßig senden lassen, wozu ein weiterer Schedule Job empfehlenswert ist ,,,
Falls du konkreteres wünschst, empfehle ich zunächst meine Skripteinführung.
Es sollte zumindest deutlich geworden sein, dass dein Anliegen implementierbar ist.
Edit:
Notfalls gelingt dein Vorhaben vermutlich auch ohne Skript und ausschließlich mit vier Schedule Jobs - zwei zum sunrise und zwei zum sunset.
zum sunrise:
Ein Job lässt bei @sunrise Ausgang 0, der andere Job (versuchsweise) bei @sunrise+2s Ausgang 1 schalten.
Damit ist aber noch kein senden von Daten verbunden. Ob dies ohne Skript brauchbar gelingen kann, vermute ich, weiß ich aber derzeit nicht.
Für die beiden @sunset(+2s) Jobs gilt entsprechendes.
Da irrst du dich nicht. Ich habe bisher keine Bootzeit gemessen. Aber das Booten geht sehr flott, schätzungsweise in maximal ca. 10s.
Wechsle den "Fachmann"!
13A bei derart kleinen Kontakten als Dauerstromstärke ist völlig inakzeptabel.
Allenfalls eine kurze Spitzenstromstärke dürfte in solche Regionen aufsteigen.
Und ja, ein solches Bewerben ist mit Vorsicht zu genießen. Das tun andere aber auch ...
Wenn der SHELLY diese Last, die deutlich unter der maximal beworbenen Last liegt, nicht für 10 Minuten sicherstellen kann, ist das schwer verständlich.
"deutlich" ist hier Ansichtssache.
Wenn das für dich und vielleicht deinen Fachmann schwer verständlich ist, dann kannst du bzw. könnt ihr hier bei Offenheit und einer gewissen Ausdauer besseres erfahren.
In aller Freundschaft 