Beiträge von eiche

VPN/Proxy erkannt

Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.

    Danke Michael.

    Eine kleine Ergänzung, welche aber in Richtung Off Topic geht.

    Es stellt sich selbstverständlich die Frage, ob dafür nicht besser ein anderes ESP32 Board genutzt werden sollte, bspw. mit Tasmota32.

    Da der ESP32 über mehrere ADC (analog to digital converter) Eingänge verfügt, bräuchte man nur noch ein Netzteil und einen Opto Triac oder Optokoppler+Relais.

    Ein ESP32 Entwicklungsboard ist leicht zu flashen und führt i.d.R. die meisten oder alle GPIO (general purpose input output) Pins des Mikrocontrollers nach außen zum anschließen externer Hardware.

    Statt eines Shelly Skript wäre ein in Berry geschriebenes Programm und ggf. ein paar Rules zusammenzustellen.

    Je nach Sensoren wären noch einfache Spannungsteiler erforderlich, eine Verstärkung der analogen Signale dürfte nicht notwendig sein.

    Die Konfiguration könnte im nichtflüchtigen Speicher (Tasmota: 16 MEM Variable) abgelegt werden.

    You can try with an URL and RPC method. At least with Generation 2, remote access should be possible.

    In the callback function you can use the response in JSON format.

    An example - untested

    Code
    Shelly.call('http.get',{url:'http://<remote ip address>/rpc/switch.getstatus?id=0'},
        function(response) {
            let power = response.apower;
            //...
        }
    );

    To use a remote Gen. 1 Shelly, you should study its HTTP communication.

    Das geht sehr einfach.

    Du schaltest das Netzteil mit einem Shelly Ausgang.

    Das Schalten wird per Zeitpläne (siehe Web UI -> Schedules) vorgenommen. In deinem Fall sind es 4 Schedule Jobs.

    05:00 Uhr ein

    09:00 Uhr aus

    15:30 Uhr ein

    20:00 Uhr aus

    fertig

    Mit einem Analog-Multiplexer (elektronische Ergänzung außerhalb des Shelly Angebotes) ginge so etwas. Für 4 analoge Signale wären allerdings 2 Bit für die Selektion erforderlich.

    Und hier ist das Shelly Problem. Ein Plus 1 hat, auch mit AddOn nur einen digitalen (Relais) Ausgang.

    Man kann unter Verwendung eines Skripts so etwas implementieren (theoretisch, praktisch zu testen).

    Ein Zähler wird per Relais-Ausgang getaktet.

    Bit 0 und Bit 1 des Zählers werden zur Selektion am Multiplexer angeschlossen.

    Bit 2 des Zählers wird mit dem digitalen Eingang am AddOn verbunden.

    So ließen sich zyklisch die analogen Signale nacheinander durchschalten.

    Die Rückmeldung eines Zyklus gelänge mit Bit 2 an Digital In des AddOn, damit das Skript immer eindeutig "weiß", welcher Feuchtigkeitssensor seine Werte gerade einspeist.

    Ich weiß nicht, ob du mit dieser Materie vertraut bist und ob du eine solche Erweiterung überhaupt aufbauen wolltest, aber es müsste so gelingen. Vermutlich wäre noch ein RC-Glied für den Takt zum entprellen zielführend.

    Edit:

    Mit einem zusätzlichen Plus Uni und dem Analog Multiplexer dürfte dies noch besser gelingen, weil der Uni zwei Ausgänge schalten kann. Hier wären die Ausgänge zur Selektion der 4 analogen Eingangssignale geeignet.

    Das Skript kann auf dem Uni arbeiten und die kleine KI täte Befehle an den Plus 1 senden.

    Du könntest (ohne Skript, mit Skript gelingt so etwas immer) den Eingang zwischen Sonnenauf- und Sonnenuntergang deaktivieren oder als detached einstellen.

    Das gelingt mit einem passenden Zeitplan (Schedule Job).

    Eine solche lokale Lösung ist verlässlicher als eine per Cloud. Und warum soll eine Cloud überhaupt etwas davon erfahren? Rhetorische Frage

    Die Struktur eines solchen Jobs, der afaik so nicht per Web UI erstellt werden kann, dies jedoch per URL möglich ist:

    Dieser Job müsste die Wirkung des Eingangs mit id 0 zum Zeitpunkt des Sonnuntergangs freigeben.

    Das Gegenstück ist entsprechend - hier in einer Zeile dargestellt

    Code
    {"enable": true, "timespec": "@sunrise * * *",  "calls": [{"method":"Input.SetConfig","config":{"id": 0,"enable": false}}]}

    Hiermit müsste die Wirkung des Eingangs (Taster) bei Sonnenaufgang gesperrt werden.

    Bei Bedarf kann jeweils ein Offset zu Sonnenauf- sowie Sonnenuntergang hinzugefügt werden.

    Falls dies nicht funktionieren sollte, kann man mit input:0 detached ... experimentieren.

    Hier die nachgereichten URL.

    1. Bei Sonnenuntergang wird (hoffentlich) der Eingang 0 freigegeben.

    Code
    http://<IP Adresse Shelly>/rpc/Schedule.Create?timespec="@sunset * * *"&calls=[{"method":"Input.SetConfig","config":{"id":0,"enable":true}}]

    2. Bei Sonnenaufgang wird (hoffentlich) der Eingang 0 gesperrt.

    Code
    http://<IP Adresse Shelly>/rpc/Schedule.Create?timespec="@sunrise * * *"&calls=[{"method":"Input.SetConfig","config":{"id":0,"enable":false}}]

    Nach dem Anlegen beider Schedule Jobs können deren Zeiten per Web UI geändert werden und weiteres ...

    Ich bin gespannt, ob es in deinem Sinne so funktioniert. ;)

    Die Einschaltdauer kannst du leicht an anderer Stelle per Web UI einstellen.

    886W/230V = 3,85A

    Das passt etwa.

    Die Ursache für die Shelly Messung der Stromstärke erscheint paradox, weil afaik der Shelly die Leistung aus Spannung und Stromstärke berechnet.

    Einer besonders aktueller Firmware darf man immer misstrauen. ;)

    Ich kenne solche Heizungen nicht aus eigener Erfahrung und weiß demzufolge nicht, welche Verzerrungen und Phasenverschiebungen auftreten können.

    Ich vermute intuitiv dort eher keine spezifischen Probleme ...

    1. Kennwort = Passwort

    Was bedeutet das "und" dazwischen?

    Meinst du vielleicht die SSID deines WLAN? Diese solltest du selbst wissen oder herausfinden können - und das Passwort dazu.

    2. Welche IP Adresse meinst du?

    Die des ausgelieferten Shelly oder vielleicht die per DHCP erhaltene? Letztere vermutlich nicht, da du anscheinend den Shelly nicht in dein WLAN einbinden konntest.

    3. Hast du die übliche IP Adresse des Shelly eigenen Access Point genutzt? Diese lautet 192.168.33.1
    Dass du dafür einen Computer, ein Smartphone oder Tablet vorher per WLAN mit dem AP des Shelly verbinden musst, wirst du hoffentlich wissen.

    4. Hast du schon versucht, die Konfiguration des Shelly in den Auslieferungszustand zu versetzen? (Factory reset, Gebrauchsanweisung lesen!)

    5. Hast du den Shelly gebraucht gekauft? Dann hat der Verkäufer vielleicht den Shelly AP nicht in den offenen Modus gesetzt, also ohne Passwort.

    In diesem Fall, wenn möglich, den Verkäufer kontaktieren. Alternative: Es gibt im Forum jemanden, der ggf. das Passwort mit viel Aufwand auslesen kann.

    Wenn du obige Punkte nicht beantworten kannst, beschreibe möglichst genau, was du getan hast!

    Ein schönes Projekt, was kompetent begleitet wird. Ich habe gerne gelesen. :thumbup:

    Eine Verständnisfrage Wolle Merk: Ist ein Zwei Wege Ventil, wie du es einsetzen willst, eines, das eine Zuführung (Eingang) und zwei Wegführungen (Ausgänge) besitzt? Oder öffnet/schließt es nur einen Strang?

    Ich habe NC Ventile liegen, die ich noch für Gartenbewässerung einsetzen will - aus China, aber "nur" 1 Zoll. Vermutlich gibt es solche auch in 2 Zoll Ausführung, brauche ich halt nicht.

    Ein solches Ventil hat nur zwei Leitungen für die Stromversorgung. Es wird durch einschalten per Motor geöffnet und gleichzeitig ein Kondensator als Energiespeicher geladen. Ist das Ventil ganz offen, wird der Motor intern abgeschaltet und das Ventil bleibt in seiner Stellung.

    Wenn das Ventil von der Versorgung getrennt wird (=ausschalten), schließt der vom Kondensator betriebene Motor den Fluss (NC).

    Eine Sicherheitseinrichtung, die eine Nichtfunktion beim schließen oder öffnen meldet, habe ich in meinen Ventilen nicht.

    Wären solche Ventile für deine Zwecke geeignet? Dann bräuchtest du kein Umschaltrelais zur Ansteuerung.

    Zum Skript von ostfriese: Darin einfach die Kombination "11" nicht wirken lassen, damit auf diesem Wege nicht beide Relais eingeschaltet werden können.

    Sorry, falls dies bereits angemerkt wurde.

    Mast25

    Den Hinweisen von ostfriese möchte ich etwas hinzufügen.

    Es wird jedes mal, wenn wetter() aufgerufen wird, ein Statushandler mit derselben callback Funktion hinzugefügt.

    Das ist unbrauchbar und führt zudem zum Skriptabbruch wegen zu vieler Handler (Limit überschritten).

    Du solltest, wenn überhaupt, den Statushandler außerhalb der Funktion wetter() hinzufügen.

    Shelly.addStatusHandler(...) ist, wenn zuweilen auch komplex zusammengestellt, eine Anweisung. Die darin notierte callback Funktion wird mit jeder Statusänderung, evtl. auch zyklisch, aufgerufen und der Status als Parameter (in deinem Skript per Parameter b) übergeben.

    Zeilen 19 bis 25 fügen einen Eventhandler hinzu, der sofort wieder entfernt wird, was keinen Sinn ergibt.

    Wenn du einen Timer verwendest, ist es unzweckmäßig einen Status- oder Eventhandler zu nutzen, weil diese Handler Ereignis gesteuert aufgerufen werden.

    Entweder du verwendest einen Timer, der bspw. den Status abfragt - siehe Skript von ostfriese, oder du verwendest einen Handler, dann aber ohne einen Timer zwecks ermitteln des Status.

    Ich greife auf deinen Skriptauszug zurück - und optimiere ein wenig. Dies ist das Handler Pendant zur Statusabfrage von ostfriese.

    Die Variable StatusHandle wird nicht benötigt, wenn in deinem Skript der Statushandler nie entfernt wird.

    (Einen booleschen Ausdruck wie b.delta.state mit true zu vergleichen, ist überflüssig, weil state bereits true oder false enthält - nur als Nebenbemerkung.)

    Hier ist es sinnfrei, einen Timer zur Statusabfrage einzusetzen.

    Ein Timer, oder ein Schedule Job, ist dann zweckmäßig, wenn du in genau definierten Zeitabständen etwas tun lassen willst.

    Wenn aber eintreffende Informationen (Event, Status) das Tun triggern sollen, ist ein Handler zweckmäßig.

    Was von beiden zielführender ist, hängt von deiner angestrebten Anwendung ab.

    romkeller8 und vielleicht auch Neo1984

    Es gibt keine einfache Möglichkeit, dies zu realisieren, weil dein Anliegen keine vorgesehene Standard-Anwendung ist.

    Du solltest dir die Dokumentation ansehen und damit experimentieren.

    https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Cover

    Die Methode "Cover.GoToPosition" akzeptiert ausschließlich ganzzahlige Parameter.

    Beispiel: Fährt auf die Position 1%, d.h. fast geschlossen.

    Code
    http://<Shelly IP Adresse>/rpc/cover.gotoposition?id=0&pos=1

    Mit Nachkommastellen arbeitet die Methode nicht.

    Somit bleibt nur ein Skript, welches ich bereits in #2 und #5 prinzipiell beschrieb.

    Ob alternativ auch ein übergeordnetes System dazu geeignet ist, weiß ich nicht. Ich könnte dies allenfalls mit einem Node-RED Flow testen.

    Gegenüber einem Skript sind solche Lösungen imho aber suboptimal, weil dies ein Shelly sehr gut selbst bewerkstelligen kann.

    Zu Skript gibt es ein kleines Tutorial.

    Weitergehende und hierfür erforderliche Informationen sind recht gut dokumentiert: https://shelly-api-docs.shelly.cloud/gen2/Scripts/S…anguageFeatures

    Zum experimentieren und testen ist ein Eventhandler geeignet, der Events mit event.name==="cover" selektiert, d.h. nur dann das Folgende abarbeitet.

    Prüfen, ob event.info.event==="closed" ist. Nur wenn dies vorliegt

    1. per Methode "Cover.Open" das Hochfahren der Jalousie starten. Shelly.call("Cover.open", {id:0});
    2. per Timer.set(<die von dir gewünschte Dauer in ms>, false, function() {Shelly.call("Cover.stop" {id:0});}); das Fahren der Jalousie anhalten.

    Ob die von dir gewünschte Position bzw. Öffnung der Jalousie so hinreichend genau erreicht wird, musst du selbst testen. Ich habe keine derart komfortablen Jalousien.

    Hier nun doch ein vermutlich geeignetes Skript zum testen:

    Dieses Skript fährt aber immer, wenn es geschlossen wird, die Jalousie ein kurzes Stück hoch.

    Um dies nur bei Bedarf zu erreichen, muss ggf. weiterer Code zusammengestellt werden. Dazu sind aber weitere Informationen darüber notwendig, wie der Shelly gesteuert werden soll. Mit einem Sprachassistenten (Alexa, Hey Google, Iris?) wird das nicht unmittelbar gelingen.

    Jeden Morgen sollen meine heruntergeladenen Jalousien zu weniger als 1% geöffnet werden

    Dazu ist ein spezieller Zeitplan (schedule job) geeignet, der die Skriptfunktion open(dur) aufruft.

    Ein solcher Job lässt sich mit der aktuellen Web UI (Firmware 1.2.0 oder 1.2.1) nicht erstellen.

    Ich kann dir dazu meine Webseite empfehlen, die solches unterstützt: Unterstützung beim anlegen, ändern und entfernen von Schedule Jobs (Zeitplänen)

    Zusätzlich kannst du dir meine Doku für Einsteiger in Schedule Jobs durchlesen: Mächtige Schedule Jobs

    Der für deine Zwecke passende URL (Browser Adresszeile) lautet etwa so:

    http://<Shelly IP Adresse>/rpc/schedule.create?timespec="0 0 7 * * *"&calls=[{"method":"script.eval","params":{"id":<Id deines Skripts>,"code":"open(150"}}]

    Dieser ruft täglich um 07:00 Uhr die Skript-Funktion open mit dem Parameter 150 (ms) auf.

    Die Uhrzeit und auch bspw. die Wochentage lassen sich per aktueller Web UI ändern, nicht aber der Funktionsaufruf "open(150)".

    Letzteres gelingt mit meiner o.a. Webseite.

    Es sollte klar sein, dass du mit der Dauer des kurzzeitigen Öffnens experimentieren musst.

    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.