Beiträge von eiche

Zunächst einmal ohne Skript, welches evtl. auch nicht erforderlich ist.

Du kannst eine Action hinzufügen, die bei "Cover closed" einen URL (HRRP Request) aktiviert.

Dann muss aber irgendein Gerät auf diesen HTTP Request reagieren, damit du erkennen kannst, dass dies prinzipiell funktioniert.

Vermutlich zügig zielführend, aber ohne eigene Erfahrung meinerseits:

Bei "Cover closed" lässt du einen HTTP Request (URL) an den selben Shelly senden (127.0.0.1 als IP Adresse).

Hier kannst du verschiedene RPC Methoden testen. Die Methode "Cover.GoToPosition" sollte hier nützlich sein.

Weitere Infos dazu: https://shelly-api-docs.shelly.cloud/gen2/Component…osition-example

Mit dem Parameter (Prozentangabe) wirst du experimentieren müssen.

Falls obiges nicht gelingen sollte. Welche Umgebung nutzt du?

Soll heißen, nutzt du ein übergeordnetes System?

Ich kann ausschließlich bei Node-RED weiterhelfen.

Du kannst aber auch einen weiteren Shelly einsetzen, der per HTTP Request bspw. einen Ausgang schaltet. Dazu kann auch ein Shelly der ersten Generation genutzt werden.

Per Skript geht sehr viel. Ich nehme an, dass du den Shelly im Roller Modus nutzt.

Ich habe nur Erfahrungen mit Rollläden, nicht mit Jalousien.

Eine ungetestete einfache Idee:

Im Skript per Eventhandler prüfen, welche Events beim fahren der Jalousie hereinkommen. Deren Infos analysieren.

Sollte ein Ereignis beim Ausschalten der Jalousie, wegen erreichen der geschlossenen Endlage hereinkommen, ist vermutlich folgende Lösung möglich.

Sobald das o.a. Event hereinkommt, Hochfahren einschalten und einen Timer starten, dessen callback Funktion die Jalousie anhält.

Die Zeit des Timers ist durch Experimente zu ermitteln.

Ich habe keinen Shelly smoke.

Meiner Erfahrung nach verarbeitet die Shelly Firmware die Timestamps in Millisekunden, wahrend der abfragbare Unix Timestamp in Sekunden vorliegt.

Schneide doch bei Bedarf einfach die Nachpunktstellen per Math.floor() oder Math.round() ab - oder lasse in Sekunden umrechnen.

Es sollte jedenfalls kein Problem sein, die ts Werte zu analysieren und ggf. von ms in s umzurechnen.

Zumindest hat das Übertragungsformat, hier MQTT, nichts damit zu tun.

Ein Anweisungsblock wird in geschweifte Klammern gesetzt - so wie ein Funktionsrumpf.

if(Bedingung) {
    Anweisung_1;
    Anweisung_2:
    ...
}

Das fällt aber mittlerweile aus dem Rahmen dieses Forums. Vielleicht kannst du ein Buch finden. Ich habe kein Javascript Buch, weil ich keines brauche.

Zumeist wird Javascript in Webseiten eingebettet beschrieben, was für diese Skripte nicht ganz passt. Aber kennenlernen kann man die Syntax darüber auch.

Ich verwende gelegentlich die Referenz auf w3schools.com, wo es auch ein engl. Tutorial gibt. https://www.w3schools.com/js/default.asp

Sobald es hier wieder um Shelly Skript, RPC Methoden, Zeitpläne ... geht, kann ich wieder Auskunft geben.

Javascript ist keine typenstrenge Sprache, weshalb manches auf einfache Weise gelingt, aber man unter Umständen euch verwundert wird und etwas Unbeabsichtigtes herauskommt.

Referenzen sind als solche nicht erkennbar, obwohl sie vom Javascript Interpreter häufig eingesetzt werden.

Wundere dich also nicht, wenn Resultate nicht so sind, wie du sie erwartest.

User defined parameter ist derjenige, welcher in der Timer callback Funktion bei Bedarf verwendet werden kann, aber nicht muss. Er ist optional.

Ausschnitt aus deinem Code von #10 mit meinen Kommentaren:

Timer.set(
CONFIG.BKW_time,
true,
function (ud) { // ud ist der user defined parameter, unbenannte Funktion
  timer_start(); // deine Funktion, die das tun soll, was du haben willst
              },
null // und hier wird für ud ein null (also eigentlich nichts) übergeben - total sinnfrei
);

Das gilt übrigens auch in anderen Programmiersprachen, die optionale Parameter kennen, wie C, C++, ...

Und eine unbenannte Funktion einzusetzen, die ausschließlich deine Funktion timer_start() aufruft, ist sehr umständlich. Dafür kannst du im Aufruf von Timer.set gleich als dritten Parameter den Namen deiner Funktion einsetzen.

Der hierfür zweckmäßige Code - zweckmäßig, weil er kürzer , übersichtlicher und frei von unnötigem Ballast ist.

Timer.set(CONFIG.BKW_time, true, timer_start);

Es gibt zwei auf Gleichheit prüfende Vergleichsoperatoren.

• == prüft auf Wertegleichheit, aber nicht auf Typgleichheit. Das geht gut mit Zahlen bzw. numerischen Ausdrücken.
• === prüft auf Werte- und Typgleichheit und sollte im Zweifelsfalle genutzt werden.

Wie du auch immer dein Skript zusammenstellst, ein Parameter null als user defined parameter einzusetzen ist zwar syntaktisch möglich, aber inhaltlich ein ziemlicher Quark.

Dann kann ich nur empfehlen, solches überflüssiges Zeug wegzulassen.

Noch eines:

Ich lese immer wieder, wie in einer Bedingung ein Ausdruck mit true verglichen wird. Auch das ist ein Füllen mit Überflüssigem.

Beispiel:

if(OffEable===true) ... // unbedachter Code
// imho besser:
if(OffEnable) ...

In meinem Skriptangebot liegt bereits Retriggerung vor.

Zu "mindestens 1 Minute eingeschaltet bleiben" fehlen noch Informationen zu Ausschaltbedingungen.

Edit:

Du kannst einen zweiten Timer verwenden zum Sperren des Ausschaltens.

Hilfe zur Selbsthilfe:

Zusammen mit dem Einschalten kannst du eine globale Variable "OffEnable" auf false setzen und einen Timer starten, der nur einmal abläuft.

In dessen callback Funktion setzt du OffEnable auf true.

Vor einem Ausschalten lässt du OffEnable prüfen ...

Jo.

Die RC Kombination (es gibt noch eine andere Variante) ist nur wegen der relativ trägen Analog-Digital-Umsetzung erforderlich.

RC sorgt dafür, dass bei loslassen des S2 die Spannung relativ langsam sinkt und die analoge Eingangsspannung eindeutig als "High erkannt" wird.

Es muss geprüft werden, ob die analoge Spannung über einem bestimmten Wert liegt, bspw. >5V => als High interpretieren.

Mike2024

Hier der verschlankte Code inkl. Schalten und übersichtlicheren Einrückungen - ungetestet:

let CONFIG = {
  BKW_time: 5 * 1000,
  BKW_URL:  "http://192.168.178.7/EVUM.txt",
  EinSchwelle: 200, // bzw. dein passender Wert
  AusSchwelle: 50 // bzw. dein passender Wert
};

function timer_start(){
    Shelly.call(
        "HTTP.GET", {url: CONFIG.BKW_URL},
        function(result) {
            print(result.body); // nur zum kennenlernen der Antwort
            let value = JSON.parse(result.body); // Text in Zahl umwandeln
            if(value > CONFIG.EinSchwelle) Shelly.call("Switch.Set", {id:0, on:true});
            if(value < CONFIG.AusSchwelle) Shelly.call("Switch.Set", {id:0, on:false});
        }
    );
}

Timer.set( CONFIG.BKW_time, true, timer_start);

Hiermit ist eine Schalthysterese zwischen Ein- und Ausschalten implementiert. Vermutlich willst du das so.

Viel Erfolg damit!

Die Namen der CONFIG Komponenten erscheinen mir zu speziell zum BKW gewählt. Ich wollte aber deinen Code nicht allzu sehr verändern.

Statt BKW_time wäre Request_Period gut geeignet, statt BKW_URL einfach nur URL.

Statt "timer_start" wäre bspw. "process" (für verarbeiten) oder "request" (für anfragen, anfordern) passender gewählt.

Das Ein- und Ausschalte gelingt mit der Methode "Switch.Set" und dem Parameter im JSON Format {id:0, on:true} bzw. {id:0, on:false}.

Ich entnehme deinem Skript Code, dass es sich um ein Balkon PV Kraftwerk handelt.

Der Skript Code lässt sich verschlanken, das Schallten in der (unbenannten) callback Funktion des Shelly.call() Aufrufs passend unterbringen.

Diese Zahl steckt offenbar in einer Textdatei.

Was erzeugt denn eine solche Zahl?

Welches Gerät (wegen IP Adresse) liefert diese Textdatei?

Prinzipiell könnte ein Node-RED Flow eine solche Zahl per HTTP Request an einen Shelly liefern, der per Skript (Stichwort HTTP Endpoint) eine solche Zahl verarbeiten könnte.

Das ist insgesamt für deine Anfänge viel zu kompliziert.

Beschreibe bitte mal den gesamten Zusammenhang!

Welche Geräte sind beteiligt?

Welches Gerät soll den Shelly dazu bringen, ein- oder auszuschalten?

Welcher Anlass liegt für das Schalten vor?

Es gibt vermutlich einen relativ einfachen Weg, dein Vorhaben zu realisieren.

Eine Diskussion darüber hier ist tatsächlich wenig angmessen.

Zitat

beim Erstellen des ersten Accounts hat das System gemeckert, weil zu kurz.

Daraufhin habe ich sie zwei Buchstaben noch angehängt.

Du schließt bei den Wörtern "ersten Account" darauf, dass es der zuerst angelegte sein müsse. Das ist aber ein schwacher Schluss, weil ebendies nicht gemeint sein muss.

Nur mal so als Anregung ...

Ich war auch zunächst etwas irritiert. Ich vertraue ihm aber schon deshalb, weil ich nicht erkennen kann, wo er sich bisher irgendetwas hat zu Schulden kommen lassen.

Von Tasmota habe ich in diesem Thread nichts gesehen (evtl. übersehen). Die Web UI galt einem evtl. möglichen Power Offset.

Was ist euer Antrieb, den Verdacht auf zwei "Anfänger" Accounts derart zu verfolgen?

Zur flexiblen Nutzung von Schedule Jobs habe ich für Anfänger einen kurzen Artikel geschrieben: Mächtige Schedule Jobs

@opoel Einen Aspekt möchte ich noch hinzufügen.

Du kannst ja auch einen längeren zeitlichen Sendeabstand wählen. Dazu kannst du die von dir gewünschten Werte im Skript berechnen und zwischenspeichern, auch mehrere bis viele Werte.

Der Kreativität sind keine Grenzen gesetzt.

@opoel

Zitat

gibt es eine Möglichkeit, den Shelly per Script dazu zu bringen, minütlich so etwas wie einen Mittelwert zu liefern?

Ja, die gibt es. Per Timer oder besser per Schedule Job. Aber ... die Messwerte treffen vermutlich sowohl in kürzeren als auch in längeren Abständen als 1 Minute ein. Das stellt zwar kein Problem dar, ist aber, die Werte betreffend, leicht fragwürdig. Die Werte können ja leicht zwischengespeichert und der letzte Wert (oder ein gemittelter Wert) zur nächsten vollen Minute übertragen werden. Zum Zeitpunkt der Übertragung kann sich aber der tatsächliche (noch nicht gemessene) Wert verändert haben.

Wenn das für dich Ok ist, kann ich dir empfehlen, ein Skript zu erstellen mit einem Eventhandler zwecks Entgegennahme des Messwertes und dessen Speicherung (ggf. + Verarbeitung) und einer Funktion "send()".

Dazu ist ein Schedule Job zu erstellen, der per timespec="0 * * * * *" zu jeder vollen Minute per Methode "Script.Eval" die Skriptfunktion send() aufruft ...

Der timespec Wert (Zeichenkette) kann später relativ leicht per Web UI geändert werden, jedenfalls in der Firmware Version 1.2.0.

Edit:

Das Senden eines Mittelwertes ist selbstverständlich dann zielführend, wenn zwischen zwei Sendungen mehrere Messwerte (per Firmware und Event) eintreffen. Ansonsten kannst du deine Mittelwerte selbstverständlich so (ggf. nachführend) berechnen lassen, wie es dir gefällt.

Zitat

Wie bitte stellt man an dem 1PM den Offset ein?

Ich kann das derzeit nur mit AddOn testen/nutzen. Dort kann man bspw. zur gemessenen Temperatur ein Offset eintragen

Home -> Temperature (100) -> Stift -> Offset ...

Ansonsten geht so etwas per (kurzem) Skript oder beim Empfänger - per Node-RED ist das ein Kinderspiel.

Ich fragte aus gutem Grund nach seinem Plug S. Ich weiß nicht, welchen er hat.

Nach seinem Text hat er vermutlich keine Ahnung vom Skripten.

...

Das lässt sich ja leicht vermeiden.

Ich könnte ein Beispiel zusammenstellen, wenn ich genügend Muße dazu habe.

Auf die Schnelle mal hier die Grundlagen.

Variante 1: (offenbar bereits von dir implementiert)

Zu den nicht sehr regelmäßig eintreffenden Werten die Zeitstempel holen und damit die zwischenzeitlich gelieferte/verbrauchte Energie berechnen. Ergebnis senden.

Variante 2:

Immer, wenn ein neuer Wert eintrifft, diesen zusammen mit dem Zeitstempel in einem Datenfeld (Array) ablegen. Prüfen, ob Werte mit "abgelaufenen" Zeitstempeln (älter als bspw. 5 Minuten) im Datenfeld liegen, ggf. diese entfernen.

Im Schedule Job wird per Methode "Script.Eval" eine Funktion deines Skript aufgerufen, ich nenne sie mal "send()". Diese Funktion sendet den per Skript berechneten Mittelwert bzw. den diskret integrierten Wert.

Ob du diesen mit jedem Eintreffen eines neuen Wertes berechnen lassen willst oder erst mit dem Aufruf von send(), bleibt dir überlassen.

Mit Variante 2 werden in regelmäßigen, von dir festlegbaren Abständen Werte gesendet. Zum Anlegen eines geeigneten Schedule Jobs mit Methode "Script.Eval" ist derzeit die Web UI nicht geeignet. Hierfür habe ich eine Webseite erstellt, welche dies unterstützt:

Zum anlegen von Schedule Jobs mit Methode Script.Eval sowie ändern, löschen von Jobs

Die Zeiten bzw. Abstände solcher bereits angelegter Jobs kann man mit der Firmware Version 1.2.0 inzwischen sehr gut und relativ leicht ändern.

Der timespec Wert für minütliches Senden rund um die Uhr und täglich lautet "0 * * * * *".

Eine Quelle für so etwas liegt in meinem Kopf. (selbst kreiert und genutzt)

Edit:

Falls es in den Messwerten Ausreißer gibt, könnte eine "Mediane Mittelwertbildung" genutzt werden. Hierfür sind die wenigen Messwerte (mit Zeitstempel) in ein Datenfeld einzusortieren - insertion sort genügt. Der Wert in der Mitte bzw. die zwei in der Mitte des Datenfeldes liegenden Werte (noch einmal mit (val1+val2)/2 mitteln) ist dann der Mediane Mittelwert. Evtl. ist dieses Verfahren für deine Zwecke geeignet. Es kann bei einseitigen Ausreißern noch optimiert werden. Mit diesem Verfahren ist das Datenfeld nach dem Senden bzw. ermittelten Mittelwert zu leeren, um darin nur die nachfolgend eintreffenden Werte zu speichern.

Edit 2:

Eine Korrektur von ggf. auftretenden Messfehlern kann nur optimiert werden, wenn solche Fehler genauer und sorgfältig analysiert werden, wozu eine möglichst dichte Aufzeichnung der Daten erforderlich ist. Hierzu könntest du eines meiner Projekte für deine Zwecke anpassen, welches ich hier beschrieben habe, noch ohne Skript-Offenlegung: Autarke Temperaturmessung 2.x per Shelly Script

Damit lassen sich viele Messwerte auf dem Shelly persistent zur späteren Übertragung speichern und somit später analysieren.