Beiträge von eiche

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:

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

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

{"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.

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.

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 ...

Konirad

Wenn du "es wissen willst", im Sinne von "jetzt aber mal sehen, was geht", dann kann ich dir Thomas' Angebot empfehlen - auslöten, Passwort finden, einlöten, ...

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!

Zitat von ostfriese

Der sinnlose Abschnitt Zeilen 19 bis 25 stammt aus meiner Antwort auf die Ursprungsfrage des TE. Sollte nur die Frage beantworten.

Ja klar, das habe ich bemerkt. Mast25 hat halt diese irgendwie eingebaut, was zeigt, dass er (oder sie?) noch Lernbedarf hat.

Deshalb wollte ich noch etwas mehr Licht in die Sache bringen.

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

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.

let StatusHandle = Shelly.addStatusHandler(function(b) {
    print(b);
    if (b.component === "input:0") {
        if (b.delta.state) {
            print("Input is on");
        }
        else {
            print("Input is off");
        }
    }
    // oder kurz ;-)
    // print("Input is " + (b.delta.state ? "on" : "off"));
});

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.

Thomas war schneller.

Dazu gibt es hier einiges, insbesondere von thgoebel.

Konstruktive Lösungen für einen Widerstand an Klemme- SW in

Berry steht ausschließlich auf ESP32 zur Verfügung, ein ESP8266 hat dafür nicht die erforderlichen Ressourcen und vielleicht auch nicht die Performance.

Dies ist der umfangreichen Tasmota Dokumentation zu entnehmen.

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.

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:

let Duration = 150; // Millisekunden

function open(dur) {
 Shelly.call("Cover.Open", {id:0});
 Timer.set(dur, false,
  function(){
   Shelly.call("Cover.Stop", {id:0});
  }
 );
}

Shelly.addEventHandler(
 function (event) {
  if(event.name==="cover") {
   if(event.info.event==="closed") open(Duration);
  }
 }
);

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.

Zitat von romkeller8

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.

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.