Beiträge von eiche

    deebeo

    Hier mein Skriptentwurf. Ich konnte es nicht komplett testen, vermute aber, dass es so funktioniert, wie du es haben willst.

    Das Problem besteht darin, dass der Status keine erforderliche Zeitinformation mitbringt.

    Deshalb habe ich in der StatusHandler Funktion per Methode "Sys.GetStatus" diese Zeit abgefragt.

    Weil aber eine solche Abfrage asynchron ist, muss die Verarbeitung von Zeit, Dauer und Leistung in der callback Funktion des Methodenaufrufs erfolgen.

    Wenn die aktuelle Leistung erstmals oberhalb Level2 liegt, wird die Zeit gespeichert, ebenso wenn die aktuelle Leistung erstmals unter Level1 liegt.

    Liegt die aktuelle Leistung zwischen Level1 und Level2 einschließlich, wird die gespeicherte Zeit ungültig gemacht.

    Solange die Leistung unter Level1 liegt, wird deren Dauer per Zeitdifferenz ermittelt und bei Überschreitung der konfigurierten Dauer der Schaltausgang ausgeschaltet.

    Entsprechendes gilt, solange die Leistung über Level2 liegt.

    Ich habe das Skript möglichst schlank gehalten, damit es leichter verständlich ist. Außerdem ist es bereits so imho sehr robust gestaltet.

    Als Zeitwert nutze ich die uptime, weil diese immer existiert, was mit unixtime nicht zwingend der Fall ist.

    Ich bin gespannt, wie es laufen wird und überarbeite das Skript gerne, wenn die gewünschte Funktionalität nicht erfüllt sein sollte.

    Dann brauche ich möglichst detaillierte Informationen über das Fehlverhalten.

    Edit:

    Es kann sein, dass der Status nicht hinreichend oft gesendet wird. In diesem Fall muss ich noch einen Timer einbauen, der gestartet wird, wenn erstmalig Level1 unterschritten oder Level2 überschritten wird. Das ist kein Problem. Aber teste erst einmal ...!

    Ich überarbeite das Skript, weil mit Sicherheit ein Timer erforderlich ist. Dann kann statt der uptime-Differenz vielleicht besser ein Periodenzähler genutzt werden. Ich denke über Vor- und Nachteile nach ...

    Ich hoffe, dass das die richtigen Antworten auf deine Fragen sind.

    Teilweise.

    Zunächst eine kleine Vereinfachung im Code:

    Code
    let value = JSON.parse(result.body)*-1;         // damit Wert positiv wird  
    // einfacher und ein wenig kürzer und vermutlich geringfügig schneller ;-)
    let value = -JSON.parse(result.body);         // damit Wert positiv wird  

    Zum Wesentlichen

    Du nutzt also http. Somit arbeitet auf deinem Windows (am Pfad erkennbar) ein HTTP Server.

    Die Dokumentation hierzu sagt, dass die Methode PUT per HTTP.Request gelingen soll.

    Ich teste es jetzt aus verschiedenen Gründen nicht, täte es aber per Skript wie folgt versuchen. Ob dies gelingt, ist vermutlich nicht dokumentiert, weshalb man sich selbst durchärgern muss

    Code
    Shelly.call("http.request", {method:"PUT", url:"http://<IP Adresse>/" + Config.BKW_URL, body:JSON.stringify(dein_Messwert)});

    Nach den Beschreibungen wäre diese Parameterstruktur logischerweise passend.

    Ich habe dies ausschließlich der Doku entnommen und keine Erfahrung damit.

    Auch bin ich gespannt darauf, ob es funktioniert.

    Wenn ja, kann weiter verfeinert werden, indem noch ein timeout und insbesondere eine callback Funktion ergänzt wird.

    1. Also wäre es möglich, dass der Shelly defekt ist?

    2. Somit wäre ein Austausch die Lösung?

    3. Also müsste ich dann auch den neuen Shelly integrieren und konfigurieren?

    zu 1. Ja, möglich, aber nicht sicher.

    zu 2. Das wäre zu prüfen. Wenn du noch einen geeigneten Shelly auf Lager hast, solltest du diesen probehalber einbauen.

    zu 3. Ja sicher. An einem bereits genutzten, bereitliegenden Shelly evtl. vorher Werksreset vornehmen und nach Einbindung Firmware aktualisieren!

    Es kann für solche Fälle nützlich sein, einen kleinen Lagervorrat zu haben. ;)

    Sie sollten ja in ihrer Datenbank irgendwo die gesendeten Signale persistieren.

    Nein! Aus welchem Grund sollten "sie" dies tun?

    Dass "sie" es tun könnten, ist klar.

    Es könnte am betroffenen Shelly 2.5 eine Störung wegen gealtertem Elektrolytkondensator vorliegen. In einem solchen Fall wäre der (oder die) Kondensator(en) auszutauschen.

    Dazu kann thgoebel mehr mitteilen. Du kannst im Forum nach "defekte Elkos" o.ä. suchen lassen.

    Edit:

    Nimm sicherheitshalber die Web UI des betroffenen Shelly statt der App und sieh damit unter Zeitplänen nach!

    Ich habe einen Shelly mit dem ich von einer IP-Adresse (192.162.172.8/Text1.txt, PC im gleichen Netz) ) den Inhalt einer Datei (beinhaltet nur eine Zahl mit Komma) per JS in den Shelly holen kann

    Eigentlich "tut man so etwas nicht".

    Grund: Wo sieht denn der PC im Verzeichnisbaum nach, um die Datei Text1.txt zu finden? Und wie lautet der komplette URI (Uniform Ressource Identifier), also die komplette Quellenangabe?

    Mit http als Protokoll braucht es auf dem PC einen HTTP-Server, auch Webserver genannt.

    Ein solcher Server hat seinen eigenen Teil-Verzeichnisbaum, welcher wie ein Ast mit Zweigen ein Teil eines natürlichen Baumes ist.

    Mit dem URI 'http://192.162.172.8/Text1,txt' sucht dann der Server in der Wurzel (=Astansatz) seines Teilbaumes nach.

    Nun wäre es interessant zu wissen, wie auf dem PC das Holen des Dateiinhaltes (=Zahlenwert) abgearbeitet wird. Dazu folgende Fragen/Bitten:

    1. Welches Betriebssystem arbeitet auf diesem PC?
    2. Wie lautet der komplette von dir genutzte URI beim holen des Wertes?
      Dazu gehört auch die Protokollangabe, bspw. http, ftp, file.
    3. Notiere bitte die Anweisung(sfolge), mit welcher du in JavaScript das Holen des Wertes implementiert hast!

    apreick

    Danke für deine Ergänzung.

    Stimmt. Ich habe vor lauter Neugier und leichter Begeisterung meinen Blick etwas zu eng fokussiert.

    Wenn bereits per Schalter/Taster eingeschaltet ist, darf der Motion nicht mehr einschalten lassen.

    Dies habe ich bei den Actions übersehen.

    Wenn dann noch eine bedingte Retriggerung per Motion gewünscht ist, dürfte dies nur per Skript gelingen.

    Auch eine Latenzdauer nach manuellem Ausschalten, während der Nachrichten vom Motion keine Wirkung haben sollen, gelingt vermutlich nur per Skript.

    Dann bleibe ich doch beim Skript. ;)

    Typischerweise, wenn auch vielleicht nicht immer, wird man per Bewegungserkennung das Licht für eine gewisse Dauer (toggle_after) einschalten lassen.

    Wenn nun der Nutzer den Schalter betätigt, wird das Licht trotzdem nach Ablauf der erwähnten Dauer ausgeschaltet.

    Genau das soll aber per Schalterbetätigung verhindert werden.

    Bin auf die Szene(n) gespannt, die das erreichen. Das meine ich durchaus offen und neugierig.

    (Nur am Rande bemerkt: Eine direkte Kommunikation vom Motion zum Schalt-Shelly ist ohnehin am ausfallsichersten.)

    Edit:

    Vielleicht gelingt es mit einer zweiten Szene, die auf das Einschalten per Schalter reagiert und das Licht entweder einschaltet oder kurzzeitig aus- und wieder einschaltet.

    Ich kann solches wegen Abwesenheit derzeit nicht testen. Vielleicht doch ... mal versuchen.

    Edit 2:

    Ich habe zwei RPC URL per Browser getestet - mit einem Shelly Plus Plug S. Vermutlich gelingt es doch mit Szenen.

    1. http://<IP Adresse>/rpc/switch.set?id=0&on=true&toggle_after=60 und anschließend
    2. http://<IP Adresse>/rpc/switch.set?id=0&on=true

    Nach 2. bleibt der Ausgang eingeschaltet.

    Dass per Skript noch andere Feinheiten möglich sind, brauche ich wohl nicht zu erwähnen. ;)

    Edit 3: Fast vergessen ...

    Dies kann dann selbstverständlich auch per Actions realisiert werden.

    Der Motion sendet die Nachricht 1 - http://<IP Adresse>/rpc/switch.set?id=0&on=true&toggle_after=60

    Action 1: Wenn Schalter auf Ein wechselt, 'http://127.0.0.1/rpc/switch.set?id=0&on=true'

    Action 2: Wenn Schalter auf Aus wechselt, 'http://127.0.0.1/rpc/switch.set?id=0&on=false'

    Hierfür ist der Eingang auf detached zu stellen.

    Wie dies per Blu Motion gelingen kann, weiß ich allerdings nicht.

    Edit 4: Sorry ;)

    Mit einem Taster am Eingang müsste der Nutzer für Dauerlicht den Taster zweimal drücken - das erste Mal für aus (toggle), das zweite Mal für ein (toggle). Hierfür genügt dann eine Action statt zwei.

    ... hmm ... oder zwischen "push" und "long push" unterscheiden:

    "push" toggelt wie üblich, "long push" schaltet ein -> dann kann der Nutzer bei per Motion eingeschaltetem Licht mit "long push" das Dauerlicht aktivieren.

    Einen hab ich noch. :S

    Es versteht sich von selbst, dass statt eines am Schalt-Shelly angeschlossenen Tasters auch bspw. ein Button 1 genutzt werden kann. Das ist dann interessant, wenn der Schalt-Shelly an der Lampe montiert wird und ein vorheriger Ausschalter wegen Brücken (Dauerphase zum Shelly an der Lampe) seine Funktion verliert. Dann kann neben dem Motion ein Taster an i3 oder i4 oder ein Shelly Button genutzt werden.

    Wie genau ist denn die Uhr im Shelly? Oder ist da gar keine?

    Die Shelly haben keine selbstlaufende Uhr, also eine, die auch ohne Stromversorgung weiterläuft, wie es sie batteriegepuffert in PCs gibt.

    Ich habe die Schaltung zwar nicht so untersucht, wie dies thgoebel tut oder täte, kann aber mit sehr hoher Wahrscheinlichkeit annehmen, dass der Shelly Uhrtakt vom Systemtakt abgeleitet wird. Vielleicht wird ein Hardwarezähler mit Interrupt hierfür verwendet - ich würde dies in einer hardwarenahen Programmierung so tun. Ok, entscheidend ist aber das Verhalten der Shelly. Mit einem Shelly Plus 2(PM) konnte ich an Hand einiger Versuche folgendes feststellen.

    Der Shelly versucht nach dem Booten, die aktuelle Uhrzeit von dem Zeitserver zu erhalten, welcher in der Konfiguration eingetragen ist. Solange dem Shelly dies nicht gelingt, hat er keine aktuelle Unixzeit (Sekunden seit dem 1970-01-01 00:00 Uhr). Dann ist sein Zeitstempel gleich seiner Uptime, also die Dauer seit dem letzten Booten. Zeitpläne die in Minutenperioden ausgeführt werden, wie dies in der Hauptuhranwendung der Fall ist, liegen dann maximal 30s neben dem Minutentakt eines Zeitservers. Sobald der Shelly seine Zeit per Zeitserver synchronisieren konnte, sind auch die Zeitpläne synchron, also mindestens sekundengenau. Verliert nun der Shelly die Verbindung zum Zeitserver (keine WLAN- oder Internetverbindung), taktet seine interne Uhr recht genau weiter, solange er nicht neu bootet. Ich testete dies an Hand eines Smartphone Hotspot, welcher dem Shelly weniger als eine Minute zur Verfügung stand. Diese kurze Dauer genügte dem Shelly, seine Uhrzeit per SNTP zu synchronisieren. Dies war insofern interessant, als ich so herausfinden konnte, dass eine Nebenuhr bspw. in einem Gartenhaus per Shelly ohne WLAN betrieben, erfolgreich genutzt werden kann.

    Das "Hauptuhrskript" stellt die Nebenuhr sowohl nach einem Stromausfall als auch bei der Zeitumstellung automatisch richtig, nachdem die Uhrzeit synchronisiert werden konnte - bspw. per Smartphone Hotspot. Man muss dafür nur einmal zu Beginn die richtige Zeit einstellen, wofür ich eine Website erstellt habe. Dieses Projekt habe ich dokumentiert. Du kannst diese Doku hier finden.

    Ich betreibe derzeit eine solche, von Thomes geschenkte Nebenuhr an meinem Schuppen. Sie ist die verlässlichste Uhr in meinem Haushalt. ;)

    Mit der aktuellen Firmware ist es inzwischen möglich, die Zeitmuster von angelegten Schedule Jobs relativ komfortabel zu ändern, wenn man sich nicht mit dem Ändern per RPC und Methode "Schedule.Update" beschäftigen möchte.

    Frage an thgoebel und an DIYROLLY:

    Besitzt ein Druckdifferenzsensor eine brauchbare Auflösung?

    Sorry, es kommt selbstverständlich auf die von Jan_Stfbg gewünschte Auflösung an.

    Ich täte, etwas unbedarft, eine Lösung mit einem Ultraschallaktor/-sensor in einem KG-Rohr mit Abdeckung anstreben. Das gelingt allerdings nicht mit einem Shelly-Skript, weil aus Sofia nichts dafür angeboten wird.

    So etwas gelingt aber mit einem ESP32 Board und Tasmota32.

    Ich habe so etwas für meine Zisternen-Füllstandsmessung realisiert. Dies sollte auf noch einfachere Weise für eine Pegelmessung, insbesondere für eine Pegeländerungsmessung eignen, vielleicht sogar ohne ein zusätzliches Programm in der Sprache Berry.

    Ich nutze als übergeordnetes System ausschließlich Node-RED und dessen Flows, also kein ioBroker, Home Assistant, ...

    Mal angenommen, davon schrieb der TE nichts, die Kommunikation findet per MQTT statt und der Shelly sendet eine MQTT Nachricht mit gesetztem Retain Flag. Und angenommen, im ioBroker wird an zumindest einer Stelle das Subscribing wiederholend aktiviert. Dann erhält der ioBroker in irgendwelchen Zeitabständen wiederholt denselben Wert. Falls darin auch ein Zeitstempel steckt, ließe sich so etwas herausfinden.

    Damit will ich keinen konkreten Verdacht äußern. Damit will ich nur darstellen, dass es viele mögliche Quellen für Irritationen gibt.

    Schon deshalb sollte man in solchen Fällen den ioBroker, die App und die Cloud außen vor lassen, um erste und grundlegendste Erkenntnisse gewinnen zu können.