Beiträge von eiche

Dein Budget für solche Zwecke ist offenbar wesentlich größer als meines. Glückwunsch

Btw, derzeit arbeiten bei mir an drei Heizkreisen noch Shelly 1 (erste Gen.) mit AddOn. Diese werden von einem Node-RED Flow gesteuert, sind also nicht autark. Ich bin bisher zwar zufrieden damit, sehe aber die Zweckmäßigkeit der autarken Betriebsweise und werde sukzessive die alten gegen meine neue Entwicklung auf Basis der Shelly Plus 1 ... austauschen.

Edit:

Meine autarke Regelung per Skript befindet sich nach wie vor im Probelauf. Bisher hat sie sich bestens bewährt. Bei Ausfall könnte der Shelly zügig gewechselt werden - und es wäre davon nur ein Heizkreis betroffen. Das sehe ich als anzustrebende Sicherheit.

apreick Danke dafür.

Ein Shelly Plus 1 PM "weiß" allerdings eh, wie der aktuelle Schaltzustand seines Ausgangs ist. Das hatte ich oben vergessen.

Schließlich bleibt so oder so die Notwendigkeit einer Kommunikation mit dem Pumpen Shelly.

Diese letzte Aussage trifft nicht zwingend zu, wenn der Shelly an der Pumpe die Leistungssumme aller Stellglieder messen kann. Nach ersten Überlegungen sehe ich hierfür keine Realisierung.

Alle Regelungs-Shelly vom Pumpen-Shelly versorgt? => geringe, evtl. nicht signifikante Leistungsdifferenz bei schalten eines Stellgliedes

Wegen der nicht potentialfreien Ausgänge bei PM sehe ich keine andere Lösung.

Wenn es dafür einen Shelly mit potentialfreier Messung gibt, kann dieser vermutlich eingesetzt werden - ich kenne derzeit keinen solchen.

funkenwerner

Ich halte 10min Abstände für eine Heizungsregelung für zu lange, insbesondere wenn ein Shelly Plus 1 mit AddOn dies in ca. 1min Abständen tut.

Ich wies auch zusätzlich auf die fehlende Autarkie hin, da bei Verwendung eines H&T zwingend WLAN funktionieren muss. So ist eine funktionierende Regelung bei WLAN Ausfall nicht gewährleistet.

Elmar Heinen

Vermutlich ist ein PM zur Messung solcher kleiner Leistungen nicht hinreichend verlässlich. Dies können aber andere besser beurteilen.

Hier täte ich mit zwei WiFi Eintragungen experimentieren und testen, ob sich bei Ausfall des WLAN die Regelungs-Shelly mit dem Access Point des Pumpen-Shelly verbinden, um die Kommunikation sicherzustellen.

Ich halte die anzustrebende Funktionssicherheit für sehr wichtig, weshalb ich auch eine Cloud basierte Heizungsregelung als technisch unsinnig ansehe. Hier ist die von mir angestrebte Fähigkeit zur Autarkie wesentlich.

Shelly (Plus) H&T würde ich nicht für eine Regelung verwenden. Sie melden sich relativ selten. Außerdem muss dafür das WLAN funktionieren, also fehlt hier die Funktionssicherheit.

Eine Cloud Lösung (Szenen) halte ich für suboptimal. Was ist, wenn der Internetzugang oder die Cloud ausfällt?

Zur Heizungsregelung sollte der eingesetzte Shelly autark arbeiten können.

Somit kann ich einen Shelly Plus 1 mit AddOn und Temperatursensor empfehlen.

Für die autarke Regelung habe ich ein Skript erstellt. Allerdings setze ich diese Anordnung an relativ schnell reagierenden Heizkörpern ein. Ob dieses Skript auch für Fußbodenheizungen gut geeignet ist, kann ich nicht testen.

Wenn du mehr darüber wissen willst, hier meine Dokumentation dazu: Autarke Heizkreisregelung per Shelly Skript

Wie du mit den Shelly deine Stellglieder schalten kannst, kann ich dir nicht sagen - vermutlich parallel zur vorhandenen Beschaltung der Raumthermostate.

Die Ansteuerung der Pumpe sollte ebenfalls per Shelly Plus 1 und einem geeigneten Skript gelingen. Hierfür müssen die Heizkreis Shelly mit dem an der Pumpe kommunizieren, was per HTTP gelingt.

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.