Beiträge von eiche

Versuche es mal mit

http://<Shelly IP Adresse>/rpc/Shelly.GetStatus

und schaue, was als Antwort kommt.

Siehe auch die Dokumentation: https://shelly-api-docs.shelly.cloud/gen2/Component…tstatus-example

Sie annörgeln.

Ich kann hier nur empfehlen, MQTT Nachrichten Ereignis spezifisch zu senden, weil damit nicht ständig solche Nachrichten gesendet werden.

Nach meinen, allerdings älteren, Erfahrungen sendet Tasmota (32) eh schon allzu oft MQTT Nachrichten.

Für Ereignis spezifische Nachrichten sind die Rules gut geeignet. Dies kann bei Bedarf durch Berry Funktionen ergänzt werden.

Die von dir gewünschten Ereignisse solltest du in den Tasmota Dokumentationen suchen.

Ich habe weiter nachgesehen. Vielleicht gelingt es sogar ohne URL, also mit einer "local action".

Wähle hierfür

Create Action -> Execute when "Cover closed" -> Then do -> Add local action -> "Move Cover to specific position" -> Set Target position property -> per Schieber auf 2% stellen - bzw. damit experimentieren.

Edit:

Mein Test mit einem Rollladen hat tatsächlich funktioniert.

Ob die Prozent-Auflösung für deine Zwecke ausreicht, musst du selbst testen.

Edit 2:

Willst du die Jalousie mit dem Herunterfahren immer auf offene, also horizontal angeordnete Lamellen stellen?

Wenn nicht, stellt sich die Frage, wie du dies bisher selektierst oder zukünftig selektieren willst.

Es gibt per Skript flexible Möglichkeiten hierfür. Eine solche Selektion ohne Skript zu erreichen, gelingt nach meiner bisherigen Erfahrung nicht.

Inzwischen konnte ich feststellen, dass tatsächlich die Events für eine Implementierung deines Ziels in einem Skript hereinkommen und, wie oben von mir prinzipiell beschrieben wurde, nutzbar sind.

Der Vorteil der Skript-Lösung liegt in einer höheren Auflösung als in der RPC Prozentangabe.

In Millisekunden sollte die von dir gewünschte Lamellenöffnung sehr genau erreichbar sein.

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.