Beiträge von eiche

Wer dem Zauber einer Cloud hinterher hechelt, wird sich von deinem oder meinem Zeug nicht beeindrucken lassen.

Flutschi interessante Einwände

Im Rahmen dieses Thread und physikalischer Gegebenheiten ist tatsächlich nur die Zeitspanne zwischen Sonnenauf- und Sonnenuntergang relevant - in welcher die Bedingung false werden muss, sonst true.

Zitat von Flutschi

Zuerst

Ist die aktuelle Uhrzeit vor Sonnenaufgang

Danach

Ist die aktuelle Uhrzeit nach Sonnenuntergang.

Es gibt keine Uhrzeit die beide Bedingungen erfüllt.

Das muss sie, die Uhrzeit, auch nicht. Es genügt, wenn sie eine dieser Bedingungen erfüllt, also ist eine ODER Verknüpfung zu verwenden - die selbstverständlich in eine UND Verknüpfung transformiert werden kann.

Zitat von eiche

(b) wenn t <= e ODER t > b dann enable, sonst disable

Das = in <= ist hier irrelevant.

Angenommen b = Sonnenuntergang = 21:00, e = Sonnenaufgang = 06:00

Die ursprüngliche (gedankliche) Formulierung "t liegt zwischen Sonnenaufgang und Sonnenuntergang" ist zu transformieren/umzuinterpretieren zu "t >Sonnenaufgang UND t<Sonnenuntergang", was äquivalent ist zu "nicht (t<=Sonnenaufgang ODER t>=Sonnenuntergang)"

Die Uhrzeit t = 10:00 erfüllt die Bedingung "t >Sonnenaufgang UND t<Sonnenuntergang" => enable = false

Die Uhrzeit t = 23:00 erfüllt die Bedingung "t >Sonnenaufgang UND t<Sonnenuntergang" nicht => enable = true

Bei Verwendung der ODER Verknüpfung:

Die Uhrzeit t = 10:00 erfüllt die Bedingung nicht("t <=Sonnenaufgang ODER t>=Sonnenuntergang") => enable = false

Die Uhrzeit t = 23:00 erfüllt die Bedingung "t <=Sonnenaufgang ODER t>=Sonnenuntergang" => enable = true

Zitat von Flutschi

Alles falsch, es geht nicht über Szenen. Bei Szenen wird nur zum Zeitpunkt des Sonnenuntergang/Sonnenaufgang geprüft.

Ich kenne mich mit Szenen nur sehr wenig aus und verlasse mich auf deine Aussage. Dies entspricht dann den Schedule Jobs, die ausschließlich zu dem timespec Muster passenden Zeitpunkten Aktionen auslösen können.
Dann verbleibt aber als einziges, und schwaches, Argument für die Cloud-Verwendung, dass deren Implementationen leichter per Klicks und so zu erstellen sind.

Alle anderen Argumente - verlässlichere Funktionalität, meine Steuerung verbleibt in meinem lokalen Bereich, Funktion auch bei Ausfall des Internetzugangs ... - sprechen gegen die Cloud-Verwendung.

Wenn man sich dann noch mit Skripten beschäftigt, kann man erkennen, dass diese zusätzliche Verbesserungen zulassen. Dies ist aber für die ursprüngliche Absicht des TE nicht zwingend erforderlich.

Flutschi und Krauskopp

Zitat von Flutschi

Aber vor Sonnenaufgang und nach Sonnenuntergang ist immer false

Prinzipiell ist "vor Sonnenaufgang UND nach Sonnenuntergang" nicht immer false, sondern während der zeitlich festgelegten Dunkelphase true.

Die Bedingung ist vermutlich so formuliert verständlicher: "nach Sonnenuntergang UND vor Sonnenaufgang"

Ob dies in der Cloud auch so implementiert ist, ist eine andere Frage - die ich nicht beantworten kann.

Dahinter liegende Vergleiche werden sich auf Tageszeiten beziehen müssen.

Beispiel allg. formuliert:

t = aktuelle Zeit, b = Begin der Aktivität (Freigabe, enable), e = Ende der Aktivität (Sperren, disable) - alle drei Werte als Tages-Uhrzeit

Bedingung: e < b, was bei e = Sonnenaufgang und b = Sonnenuntergang erfüllt ist

t <= e (inkludiert t < b) => enable

t > e UND t < b => disable

t > b => enable

Zusammengefasst: (a), (b) und (c) sind alternative Darstellungen derselben Funktion

(a) wenn t > e UND t < b dann disable, sonst enable

(b) wenn t <= e ODER t > b dann enable, sonst disable

(c) enable = t <= e ODER t > b (boolescher Ausdruck, dessen Wahrheitswert enable zugeordnet wird)

Statt <= kann selbstverständlich auch < genutzt werden. Das erscheint vor dem Hintergrund der Anwendung unerheblich.

Mir erscheint eine solche Cloud Lösung suboptimal, weil das Auslösen geeigneter Aktionen per Schedule Job (zu Zeitpunkten) eindeutig ist und insbesondere lokal funktioniert.

Einziger Nachteil eines Schedule Jobs:

Wenn zum Zeitpunkt seines Triggers die Stromversorgung weg ist, kann er afaik die gewünschte Aktion nicht auslösen.

Dies könnte per Skript, einem minütlich auslösendem Schedule Job, zweier Konfigurationseinträge im KVS auch nachträglich (nach Stromausfall) zielführend verarbeitet werden.

Ich täte mich jedenfalls dabei mehr auf ein Skript verlassen, dessen Funktion analysiert, getestet und überarbeitet werden kann, als auf die Implementation in einer, nicht immer verlässlich erreichbaren Cloud, deren Implementationen mir verborgen sind.

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.

The second, inner function is never processed.

Warum sollte jemand eine Hand in eine Kreissäge stecken?

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

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:

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