Beiträge von eiche

    Offenbar schaltet die Hauptstelle die Lampe. Diese Klemme sollte an den SW-Eingang eines schaltenden Shelly (Shelly 1, Shelly Plus 1, Shelly Plus 1 PM, ...) geführt werden. Dann schaltet der Shelly die Lampe(n) und "kennt" somit auch den Schaltzustand, welcher damit automatisch in der App, in der Cloud und auch auf der Webseite des Shelly zu sehen ist.

    Dazu ist der graue Shelly PM Mini Gen 3 durch einen Shelly mit SW Eingang und Schaltausgang zu ersetzen.

    Könnte man es denn mit einem Shelly Plus 1PM realisieren? L und N anschliessen. Lichtstrom aus dem Zeptrion auf SW (schwarzer Draht auf meinem Foto) und O mit der Lampe verbinden (roter Draht).

    Ja, das sollte dein Ziel erreichen.

    Denn es gibt Zeptrion Schalter, die die Lampe ebenfalls ein- und ausschalten können.

    Wenn diese Zeptrion Schalter auf den SW Eingang des Shelly geführt werden können/sollen, dann täte dies ohne Messung genügen, weil dann der die Lampe schaltende Shelly den Schaltzustand "kennt".

    Ich kenne deine gesamte Schaltung nicht (mehr).

    Bitte skizziere diese mit allen beteiligten Teilen - Schalter/Taster, alle die Lampe(n) schaltenden Zeptrion Schalter, Verbindungen!

    Brendianer

    Ich muss mich ein wenig verbessern. Der die Lampe schaltende Shelly braucht nicht zu messen. Außerdem sollte so der Schaltzustand der Lampe direkt von diesem Shelly signalisiert werden. Hierfür genügt sogar ein Shelly (Plus) 1, also auch ein Shelly der ersten Generation käme in Frage.

    Was kommt dann an SW und was an O?

    An SW kommt der bisher schaltende Ausgang deiner Elektronik. Es bleibt zu prüfen, ob diese Beschaltung wie erwartet schaltet. Die Ausgangsspannungen deiner Elektronik sind hierbei entscheidend. Falls das Schalten nicht erfolgreich gelingt, käme vermutlich noch der hier sog. "Bukoski-Draht" zum Zuge.

    O ist der Schaltausgang des Shelly, mit welchem die Lampe letztlich geschaltet wird. An I sollte L gelegt werden.

    Falls diese Lösung gelingt, was ich stark vermute, ist die Lehre daraus "Es ist mitunter zielführend, Abstand von den eigenen Gedanken zu gewinnen. Das fördert Alternativen." ;)

    const json = response['body'];

    const obj = JSON.parse(json);

    Offenbar hast du Programmiererfahrung. Warum legst du die Variablen json und obj per const statt per let an?

    (Ich bevorzuge Zugriffe auf Komponenten per Punktnotation.)

    Zwei Schritte sind hier nicht erforderlich. Es genügt bspw.

    Code
    let obj = JSON.parse(response.body);

    Edit: Der Code von HighFive tat dies übrigens bereits so.

    GuenterP

    Ein Shelly Skript wird immer auf dem Shelly gespeichert, welcher das Skript abarbeitet. Damit kann ein Shelly weitgehend autark arbeiten, was ein erheblicher Vorteil sein kann.

    Die Firmware liefert Messwerte

    1. in gewissen Zeitabständen, bspw. ca. 60s,
    2. wenn sich ein solcher Messwert gendert hat.

    Wohin liefert die Firmware solche Messwerte?

    1. In die Cloud, wenn der Shelly in die Cloud eingebunden ist.
    2. An die Web UI des Shelly.
    3. An eine dafür im Skript erstellte Funktion, welche hierfür in der Firmware registriert wurde.
    4. An ein übergeordnetes lokales System, wenn die Kommunikation dafür konfiguriert ist.

    Die zügigste, sicherste und flexibelste Verarbeitung solcher Messwerte findet lokal im Shelly per Skript statt. Auch übergeordnete Systeme bieten reichlich Möglichkeiten hierfür, wofür aber zwingend die Kommunikation mit dem Shelly funktionieren muss. Die Funktion im Skript, welche die Messwerte entgegennimmt ist entweder ein sog. Eventhandler oder ein Statushandler. Wenn es ein Eventhandler tut, täte ich diesen bevorzugen. In deinem Fall ist dies so.

    Ein Skript erfordert programmieren. Mit Klicken, Selektieren und hier und da einen Eintrag erstellen ist es nicht getan.

    Ein erstes Skript, um sich einer Lösung zu nähern sieht bspw. so aus.

    Code
    function evh(ev) {
    	print(JSON.stringify(ev);
    }
    
    Shelly.addEventHandler(ev);

    Der Eventhandler, welcher über die Messwerte per Parameter "ev" von der Firmware informiert wird, ist hier die Funktion "evh", welche per letzter Anweisung der Firmware als Eventhandler zwecks Registrierung mitgeteilt wird.

    Dieser Eventhandler ist sehr schlicht und gibt nur die Datenstrukturen aller eintreffenden Events aus, auch der Events von Messwerten. An Hand solcher Ausgaben ist es möglich, die interessanten Teile per Analyse ausfindig zu machen und zu erkennen, wie man per Skript auf diese Teile zugreifen kann. Vermutlich lauten die für deine Zwecke zielführenden Teile des Parameters "ev"

    • "name": "temperature"
    • "id": 100 oder 101 oder 102
    • "info": eine Datenstruktur, in welcher der jeweilige Messwert steckt.

    Ungeprüft fokussiert vermutlich das folgende Skript die Ereignisse, welche gemessene Temperaturwerte liefern.

    Code
    function evh(ev) {
    	if(ev.name==="temperature") {
    		print(JSON.stringify(ev);
    	}
    }
    
    Shelly.addEventHandler(ev);

    Zur Regelung

    Für deine Anwendung halte ich es zielführender, wenn du

    • einen ad hoc änderbaren Wert für die Zieltemperatur "targetTemp",
    • einen Hysteresewert "dTargetTemp" und
    • eine feste Temperaturdifferenz "dTemp" festlegst.

    "targetTemp" ist die angestrebte Zieltemperatur des Poolwassers. Ist dessen gemessene Temperatur "tempPool" unterhalb targetTemp - dTargetTemp, wird die Erwärmung freigegeben. Ist tempPool > targetTemp + dTargetTemp, wird die Erwärmung gesperrt und ggf. abgestellt.

    Ist bei freigegebener Erwärmung die Differenz der Temperaturen von Heizmatte und Einspeisung mindestens gleich dTemp, so wird die Heizungzirkulation eingeschaltet.

    Zusätzlich ist noch eine manuelle Freigabe/Sperrung der Heizung vorzusehen.

    Hinweise für ein anwendungsgerechtes Skript

    1. Die im Eventhandler eintreffenden Messwerte sind in globalen Variablen zwischenzuspeichern.
    2. Wenn alle zwischengespeicherten Messwerte gültig sind, sollte der Eventhandler (hier evh) an Hand der Parameter (s. "Zur Regelung") prüfen, ob eine Erwärmung zu aktivieren ist und dies ggf. tun, d.h. die Heizungszirkulationspumpe einschalten.

    Zusatzhinweise

    Ein ausgereiftes Skript ist etwas komplexer und sollte wenigstens die Änderung der Zieltemperatur ermöglichen. Hierfür ist bspw. die Kommunikation per MQTT geeignet. Bei Verwendung eines übergeordneten Systems genügt vermutlich bereits HTTP. Wenn du ohne zusätzliche Installationen auskommen möchtest, gelingt die Einstellung von Parametern auch per Shelly ab dritter Generation und virtuellen Komponenten (virtual Components), die auf der Web UI des Shelly verfügbar gemacht werden können. So kann bspw. per Schiebeeinsteller auf der Web UI die Zieltemperatur geändert werden. Solche virtuellen Komponenten können per Skript verwendet werden - Werte lesen, Änderung erfassen, schreibend ändern.

    Vielleicht käme dir die Nutzung solcher virtueller Komponenten für deine Zwecke entgegen.

    Falls du alles auch remote ablesen und manipulieren können möchtest bleibt die Cloud (auch ohne Skript) oder VPN und Skript. Ich halte die zweite Variante für die erheblich bessere, allerdings ist sie aufwändiger zu implementieren.

    Ich hoffe, hiermit ein wenig zur Erhellung beigetragen und dich nicht allzusehr verwirrt zu haben.

    Ich "mache" daran nichts. Ich hatte per Konversation einige Lösungsmöglichkeiten aufgezeigt, die der TE aber so nicht nutzen will. Er sucht eine Möglichkeit per Cloud/App oder notfalls HomeAssistant den Schaltzustand eine Lampe per Fernzugriff abzulesen. Diese Lampe wird aber nicht direkt von einem Shelly geschaltet. Da er einen messenden Shelly an der Lampe nutzt, könnte dieser den Schaltzustand mitteilen.

    Der TE möchte eine sehr einfache und nicht erst zu interpretierende Darstellung des Schaltzustandes.

    Ich denke, er sollte mit deinen Hinweisen weiterkommen. Mehr will und kann ich nicht einbringen.

    apreick

    Ich bin im Vorfeld dieses Threads ein Stück weit involviert. Deshalb meine zusätzliche Frage.

    Dein Beispiel-Template ist mit dem Ausgangszustand eines Gerätes verknüpft, wenn ich es richtig verstehe.

    Dem TE stehen hierfür allerdings ausschließlich die Messungen am Verbraucher per nicht schaltendem Shelly zur Verfügung. Dieser Shelly kann eine Nachricht senden - an HomeAssistant (von welchem ich nur den Namen kenne). Deshalb ist er darauf angewiesen, dass das HA-Template auf eine solche Nachricht reagiert. Vermutlich gibt es hierfür einen (Software-)Adapter, welcher per MQTT, URL oder sonstwie erreichbar ist und der den Anzeigezustand des Template manipulieren kann.

    Damit sollte sich das Anliegen des TE erfüllen lassen.

    Kannst du bitte auf dieses Szenario eingehen?

    Ich fand soeben hierher - interessantes Projekt.

    Nur als Info und Anregung, da ich dies aktuell mangels Equipment nicht selbst testen kann.

    Die Lösung per Skript, ohne Cloud und ohne übergeordnetes System

    1. Die Messwerte zu erfassen und umzurechnen ist sehr einfach - Eventhandler oder zyklische Abfrage.
    2. Die Ansteuerung des Ventils ist bereits vorhanden.
    3. Die Wasserverbräuche können persistent in einer (Skript-)Datei auf dem Shelly gespeichert und bei Bedarf abgefragt werden. Dabei ist prinzipiell jede Zeitzuordnung möglich.

    Zum lesen, interpretieren und ggf. erstellen einer Grafik muss ein anderer Weg als die Cloud/App genutzt werden. Ein Raspberry Pi mit einem übergeordneten System kann dies bewerkstelligen. Ich bevorzuge für solches Node-RED, den MQTT Broker Mosquitto, das Zeitreihendatenbanksystem Influx und zwecks grafischen Darstellungen Grafana. Diese Kombination ist der Cloud deutlich überlegen.

    Wenn nur die auf dem Shelly persistent gespeicherten Werte manuell übertragen und bspw. per Tabellenkalkulation auswerten will, braucht die o.a. Raspberry Pi Ausstattung nicht. Hierfür können gelegentlich alle auf dem Shelly gespeicherten Daten unter Verwendung dessen Web UI und Copy & Paste auf einen PC übertragen werden. Danach können diese Daten bei Bedarf auf dem Shelly gelöscht werden.

    Eine solche persistente Messwertaufzeichnung per Skript habe ich implementiert. Sie könnte auf diesen Anwendungsfall angepasst werden.

    Zum Skript

    Da ich (noch) keinen Plus UNI besitze, kann ich leider keine Erfahrung zur geeigneten Erfassung der Messwerte sammeln. Deshalb hier zunächst nur das Prinzip.

    1. Beide Messwerte zyklisch abfragen oder per Eventhandler entgegennehmen und zwischenspeichern. Ich täte Eventhandler bevorzugen, weil dieser bei Änderung eines Messwertes benachrichtigt werden wird.
    2. Die zwischengespeicherten Werte (ebenfalls bspw. im Eventhandler) verarbeiten, was sehr einfach sein dürfte.
    3. Die Resultate per Skriptfunktion MQTT.publish() veröffentlichen.

    Bei Verwendung eines Eventhandlers kann alles erforderliche in dieser Funktion abgearbeitet werden.

    Bei Verwendung eines Timers kann alles erforderliche in dessen callback Funktion abgearbeitet werden.

    In beiden alternativen Verwendungen wird nur mit einem zwischengespeicherten Messwert und einem aktuell eingetroffenen Messwert gearbeitet werden können, da beide Werte nur asynchron eintreffen. Eine "Gleichzeitigkeit" beider Messwerte gibt es nicht.

    Romeda

    1. Hast du weitere Shelly in Gebrauch, welche dieses Problem nicht mit sich führen?
    2. Vermutlich nutzt die nicht wirklich die o.a. IP Adressbereiche. Es könnte hilfreich sein, deine tatsächlich nicht gerouteten IP Adressen und -Bereiche des Routers zu kennen.
      1. Subnetz (Maske oder /Bitanzahl)?
      2. DHCP Einstellung?

    Mit diesen Informationen ließe sich vermutlich mehr anfangen.

    Zusätzlich habe ich noch ein Plus AddOn mit zwei Mikrotastern vorgesehen, über welche die Zieltemperatur manuell schrittweise verändert werden kann. Hierfür bietet die Webseite drei Anzeige (Refresh) Modi.

    Screenshot dieser Webseite

    Heizkreisregelung.jpg

    Selbstverständlich kann MQTT zwecks Kommunikation mit einem übergeordneten System oder einer MQTT Client App verwendet werden.

    Ich nutze hierfür parallel ein Node-RED Dashboard.

    Das Skript läuft ausschließlich auf dem regelnden Shelly, was für die Autarkie auch erforderlich ist. Mit einer Cloud oder App hat dies nichts zu tun.

    Die vom Skript gelieferte Webseite wird von einem Web Browser dargestellt.

    Edit:
    Und sollte das WLAN ausfallen, erreicht man den Shelly und die Webseite über dessen AP Adresse 192.168.33.1, nachdem man das Endgerät (Smartphone, Tablet, ...) mit diesem AP verbunden hat.

    Edit 2:
    Neben dem C&P ist noch das einmalige Anlegen von bspw. 8 Schedule Jobs erforderlich, was mit einer meiner unterstützenden Webseiten relativ leicht möglich ist, allerdings nicht DAU sicher.

    oder gib ordentlich Geld aus und schreibe Scripte.

    Das ist nicht ganz stimmig. Ein Stellantrieb kostet ca. 15 €, eine Shelly Plus 1 liegt geschätzt bei 20 € (lange keinen mehr gekauft). Diese Kombination ist somit recht preisgünstig. Das Schreiben bzw. verstehen eines Skriptes ist wohl am aufwändigsten. Meines könntest du kostenfrei von mir erhalten. Ob dir die per Skript gelieferte Weboberfläche gefallen täte, ist eine offene Frage. Ich möchte sie tatsächlich noch verbessern, weiß aber nicht, wann ich genügend Antrieb dazu haben werde.

    Gruß Gerhard

    Afaik werden die TRV nicht mehr produziert.

    Ich bin auch nicht sehr zufrieden damit und habe einen Ersatz dafür mit einem Shelly Plus 1 und einem umfangreicheren Skript erstellt. Hierzu ist ein vom Shelly geschalteter Antrieb für das Stellventil (Stift) erforderlich. Diese Zusammenstellung arbeitet bei mir an einem Heizkörper sehr zuverlässig und insbesondere autark. Eine Spannungsversorgung ist dafür vor Ort notwendig. Ich habe bis zu 8 aktive Zeitpläne vorgesehen, deren Anzahl auf bis zu 16 erweitert werden könnte. Profile dazu habe ich nicht erstellt.

    Meine TRV werde ich sukzessive und nach Bedarf durch diese Kombination ersetzen. Mit den FRITZ! Thermostaten von avm habe ich keine Erfahrung.

    Flutschi und HighFive

    Ich kann nicht erkennen, wo der Beitrag #4 auch nur annähernd etwas konstruktives aufweist.

    Das ist wohl logisch.

    Das ist alles andere als "logisch" sondern ein Fakt, welcher aus zwar naheliegenden Gründen des Aufwandes aber nicht notwendigerweise so ist. Die Scheduler (Cron) Implementation wurde im Laufe von etlichen Jahren fortlaufend verbessert und wir können diese dankenswerterweise nutzen. Es ist aber durchaus möglich, auch nach einem Stromausfall eine zeitgesteuerte Aktion nachträglich noch ausführen zu lassen, bspw. per Skript oder einer sonstigen Implementation.

    Wo hast du jetzt etwas von Skripte geschrieben?

    Ich ging auf die Frage des TE ein und habe sie andeutungsweise beantwortet. Es liegt am TE, bei Bedarf genauer nachzufragen.