Beiträge von eiche

    Das Skript fand ich leider noch nicht. Hier ist nur die vom Skript gelieferte Webseite zu sehen:

    Shelly Virus für Gen2/3 -> Beitrag #28

    Ich suche weiter ...

    Edit 1:
    Bisher fand ich bei mir lokal eine Anleitung zur Nutzung des Ruuvi Sensors von 66er. (Auch dieses Forumsmitglied ist leider nicht mehr hier dabei). Darin ist ausgeführt, dass man per Shelly unter Scripts -> LIbrary ein Skript dazu finden und einfügen kann, Suchtext: BLE in scripting -Ruuvi example
    Da ich noch keinen Ruuvi habe, kann ich das Skript weder testen noch überarbeiten.

    Also nee! Der "Kühlschrank" darf keinesfalls per Cloud geregelt werden. Das ist viel zu unsicher.

    Es ist überhaupt kein Problem, die Regelung per Shelly Plus 1 (PM) und einem AddOn vorzunehmen. Dazu muss man noch nicht einmal ein Skript einsetzen. Es genügen zwei geeignete Actions.

    Der Nachteil dieser Lösung besteht im erforderlichen/zweckmäßigen durchbohren der Wandung. Die deshalb bessere Lösung ist die Kombination aus Ruuvi im Kühlschrankinneren, welcher die Temperatur per Bluetooth an ein externes Gerät sendet. Das kann ein Shelly Plus 1 sein, welches die Regelung dann per Skript durchführen muss. Bei fester Temperaturhysterese ist das Skript dafür sehr einfach. Man braucht halt zusätzlich noch ein bereits existierendes Skript, welches die Temperatur (und den Batteriestand?) aus der Bluetooth Kommunikation extrahiert.

    Ein Schedule Job könnte noch ca. einmal im Jahr daran erinnern, dass die Knopfzelle im Ruuvi gewechselt werden sollte.

    Diese Kombination ist ziemlich funktionssicher.

    Also bleibt eine Temperaturregelung per Schalten des Kompressors. Warum auch nicht? Wenn die Schalthysterese groß genug gewählt wird, wird der Kompressor weniger oft geschaltet. Die Ruuvi Sensoren haben einen sehr guten Ruf. Ein Shelly H&T ginge wohl auch, der sendet aber in sehr großen Abständen, wenn er von einer Batterie versorgt wird.

    lacala

    App und Cloud bieten nicht den unmittelbaren Zugriff auf die Geräte.

    Um deren Erreichbarkeit in deinem WLAN und deren Funktionalität zu prüfen solltest du per Browser die Websites der Shelly selbst nutzen. Also in der Browser Adresszeile die IP-Adresse der Geräte eingeben. Alternativ oder ergänzend kannst du auch das sehr gute Programm ShellyScanner nutzen, über welches du u.a. komfortabel auf die Geräte-Websites kommst.

    Wenn auf den Geräten alles wie gewünscht läuft, dürfte das Problem entweder bei deinem Internetzugang oder in der Cloud liegen.

    Was du beschreibst klingt gut, Öffnen-Zeitplan wird erst ab 6 Uhr aktiviert. Allerdings, wenn der Öffnen-Zeitplan ("Öffne 15 Min. vor Sonnenaufgang") bereits vor 6 Uhr erfüllt war und er aber erst ab 6 Uhr aktiviert wird, dann wird er doch nicht mehr ziehen, oder?

    Ok, dein Einwand ist berechtigt, ich muss präziser werden. ( Candid und Flutschi )

    Nehmen wir folgende Schedule Jobs.

    1. Job A enabled Job D bei Sonnenaufgang - immer enabled
    2. Job B lässt öffnen bei Sonnenaufgang - abends disabled
    3. Job C enabled Job B um 6 Uhr - immer enabled
    4. Job D lässt öffnen um 6 Uhr - abends disabled
    5. Job E sei der Job zum schließen. Dieser kann zusätzlich Job B und Job D disablen.
      Dies gelingt, weil ein Job eine Liste an Methoden aufruft, hier also drei Methoden. Diese Liste ist das Datenfeld (Array) "calls", welches mindestens eine Methode enthält. Die Fleißarbeit besteht darin dieses Datenfeld fehlerfrei zusammenzustellen. Die Methode zum enablen/disablen lautet "Schedule.Update" und ist hier dokumentiert: https://shelly-api-docs.shelly.cloud/gen2/Component…#scheduleupdate

    Zwei Fälle sind zu unterscheiden. Ich verweigere den Fall Sonnenaufgang genau um 6 Uhr. ;)

    1. Sonnenaufgang < 6 Uhr
      Job A enabled Job D.
      Um 6 Uhr lässt Job D öffnen.
      Um 6 Uhr enabled Job C den Job B, was nichts bewirkt, weil der Zeitpunkt von B bereits vergangen ist.
    2. Sonnenaufgang > 6 Uhr
      Job A enabled Job D, was nichts bewirkt, weil der Zeitpunkt von D bereits vergangen ist.
      Job C enabled Job B.
      Bei Sonnenaufgang lässt Job B öffnen.

    Auf diese Weise wird um 6 Uhr geöffnet, wenn der Sonnenaufgang vor 6 Uhr liegt.
    Liegt der Sonnenaufgang nach 6 Uhr, wird dann erst geöffnet.

    Konkret zum disablen der Jobs B und D mit dem Schließen des Rollladens: B mag die id 2, D die id 4 haben. (ungetestet)
    Hier nur der "calls" Teil. Die anderen Dinge ließen sich per WebUI einstellen und danach der calls Teil updaten.

    Die Konstellation dieser 5 Schedule Jobs ist immer gleich. Die Zeiten können jederzeit leicht per WebUI geändert werden.

    Zum Fall Sonnenaufgang genau um 6 Uhr:
    Hierfür müsste es genügen, einen der beiden 6 Uhr Jobs auf 5:59 Uhr vorzuverlegen. Welcher vorverlegt werden sollte, überlasse ich dem geneigten Leser.8)

    Nachgereicht

    Die obigen Schedule Jobs sollen die folgenden id haben: A:1, B:2, C:3, D:4, E:5

    Alle Jobs können zunächst per WebUI im Advanced Mode angelegt werden. Anschließend können diese per URL wie folgt abgeändert werden. Die IP-Adressen sind selbstverständlich anzupassen. Die Zeilennummern sind zu ignorieren.

    Code
    http://192.168.178.53/rpc/Schedule.Update?id=1&calls=[{"method":"Schedule.Update","params":{"id":4,"enable":true}}]
    
    http://192.168.178.53/rpc/Schedule.Update?id=3&calls=[{"method":"Schedule.Update","params":{"id":2,"enable":true}}]
    
    http://192.168.178.53/rpc/Schedule.Update?id=5&calls=[{"method":"Cover.Close","params":{"id":0}},{"method": "Schedule.Update","params":{"id":2,"enable":false}},{"method":"Schedule.Update","params":{"id":4,"enable":false}}]

    Diese URLs passen die zuvor in geeigneter Reihenfolge (A ... E) angelegten Schedule Jobs an. Danach können alle Jobs so bleiben. Bei Bedarf können diese in den Zeiten nachträglich per WebUI geändert werden. Dabei nicht die Actions ändern oder löschen!
    Das WebUI zeigt bei solchen Jobs, die nicht die vorgesehenen Actions enthalten an: "Call may not work as expected". Dies zeigt nur, dass das WebUI die eingetragenen Calls (=Actions) nicht kennt. Sie funktionieren trotzdem.

    Nachgereicht 2

    Um solche Methodeneinträge für Schedule Jobs in URLs zu unterstützen, habe ich soeben eine neue Webseite zusammengestellt. Diese ist zu finden unter https://tools.eichelsdoerfer.net/schedjob_methods.html. Nach vorzunehmenden Einträgen ist ein Link anzuklicken, welcher (hoffentlich) die gewünschte Aktion ausführen lässt.

    Damit lässt sich bspw. der oben letzte URL zusammenstellen, indem man die IP-Adresse, die id des Schedule Jobs (hier: 5), die drei Methoden (hier: "Cover.Close", zweimal "Schedule.Update") und die Parameter (hier: {"id":0}, {"id":2,"enable":false}, {"id":4,"enable":false}) einträgt. Daraufhin kann man den Text des Links komplett lesen und zwecks Ausführung anklicken.

    Wenn Job A zu einer bestimmten Zeit den Job B aktiviert, welcher zu einer bestimmten Zeit eine Methode C aufruft, dann wird C aufgerufen, wenn A UND B gewirkt haben.

    Wenn Job A eine Methode C aufruft und Job B dieselbe Methode C, dann wird C aufgerufen, wenn A ODER C gewirkt haben.

    Außerdem wird in einem Schedule Job eine Liste an Methoden aufgerufen, in den meisten Fällen enthält diese Liste halt nur eine Methode. Jeder Schedule Job kann also mehrere Methoden aufrufen. Solche Methoden können bspw. mehrere Ausgänge zur gleichen Zeit auf Grund eines einzigen Schedule Jobs schalten.

    Zusätzlich können diese Methoden Aufrufe von (parametrierten) Skriptfunktionen sein. Dies ermöglicht noch viele weitere Dinge, deren Kombinationen praktisch endlos sind. Ich habe solche Grundlagen auf einer meiner Websites beschrieben:
    https://iotig.eichelsdoerfer.net/index.php/anwe…e-schedule-jobs

    Diese Möglichkeiten gehen weit über die Konfigurationen von Zeitplänen per WebUI oder App/Cloud hinaus.

    Die Meckerei von Candid hat mich etwas geärgert, weil ich seine Kompetenz in dieser Angelegenheit anzweifle und er großspurig von "keine große Kunst ..." Verknüpfungen zu integrieren schrieb. Ich kenne keinen Scheduler, der dies kann, wohl aber den Aufruf von Programmen, Shell-Kommandos ...

    Vielleicht kennt sich Candid mit solchen Dingen besser aus als ich. In diesem Fall mag er dies genauer und besser erklären, was er sich unter "Verknüpfungen von Regeln" in einem Schedule Job vorstellt.

    Ergänzung zu tvbshelly :

    Der Status enthält auch die Chiptemperatur. Um aber daraus eine Messreihe zu machen, muss irgendetwas programmiert werden. Das kann ein Shelly Skript oder ein Node-RED Flow oder ein Shellskript oder ... sein. Bei einem Shellskript können die Daten sukzessive in einer Textdatei gespeichert werden, was auch leicht mit einem Node-RED Flow gelingt.

    Die beste Übersicht erhält man allerdings per Grafik, wozu eine Textdatei wenig taugt.

    Edit: Workaround für Liebhaber von Tabellenkalkulation
    Eine Textdatei kann als CSV Datei genutzt werden und die Tabellenkalkulation kann daraus eine Grafik basteln. :)

    Leider kann man bei den Zeitplänen keine UND/ODER-Verknüpfungen von Regeln "programmieren" sondern nur jew. eine Regel. Das ist eigentlich schon ziemlich Schwach vom Shelly. Es wäre keine große Kunst zu integrieren, dass man Regeln miteinander UND/ODER verknüpfen kann.

    Wenn man weiß wie, kann man durchaus ein funktionales UND bzw. ODER unter Verwendung der Schedule Jobs erreichen. Dies gelingt durch aktivieren und deaktivieren von Schedule Jobs per Schedule Jobs. Ich habe dies oben angedeutet. Man kann selbstverständlich die Schedules durch ein Skript erweitern, welches von ebensolchen Jobs genutzt wird, muss dies aber nicht in jedem Fall tun.

    Die Idee von Schubbie mit dem zusätzlichen Festwiderstand zum resistiven Sensor (falls vorhanden) erscheint mir am besten. Um den passenden Wiederstandwert zu ermitteln, müsste der Sensor bekannt sein oder eine Messreihe R = f(T) aufgenommen werden. Damit sollte der passende Widerstandswert gefunden werden. Hierfür täte ich einen passenden Akku/Batterie zur Versorgung in den Schrank packen. Daran ein Shelly Plus 1 mit Add-On, DS 18B20 und Spannungsteiler aus Sensor und etwa gleich großem Festwiderstand am analogen Eingang. Der Shelly kann entweder die Messdaten in seinem nichtflüchtigen Speicher ablegen oder an einen Empfänger übertragen.

    Zu ersterem habe ich mal ein Skript geschrieben. Dazu braucht man kein zusätzliches Equipment, weil man die Messdaten einfach per WebUI des Shelly holen kann.

    Da eine Messreihe die beste Grundlage bildet, wäre es nützlich, für die Messungen einen baugleichen Sensor zu haben. Ansonsten könnte der Sensor temporär durch einen Festwiderstand ersetzt werden, welcher dem Schrank eine zu hohe Temperatur vorgaukelt und dieser ständig (unter gewisser Beobachtung) kühlt. Parallel kann die Messreihe aufgenommen werden.

    Ich weiß, dass eine Messreihe relativ aufwändig ist. Ich möchte aber aufzeigen, was man tun kann - nicht muss. ;)

    Eine Shelly Szene per Sprachassistenten zu aktivieren wäre afaik ein total neues Feature. Ich täte mich sehr wundern, wenn dies herkömmlich, also ohne für den Sprachassistenten etwas zu programmieren, gelänge.

    Da dieser Assistent mit einem Shelly Plus 1 keine Rollladen- bzw. Torsteuerung assoziiert, habe ich einen Shelly Plus 2 PM in's Spiel gebracht. Dieser wird vom Assistenten klar mit einer Rollladensteuerung und den Anweisungen "öffnen" sowie "schließen" assoziiert.

    Der Rest wird von einem Skript erheblich verlässlicher und auch erheblich flexibler als jegliche Szene verarbeitet.

    In dieser Angelegenheit kostet ausschließlich die Hardware Geld. Aber ja, der Aufwand wäre für dich so groß, dass dies nur dann sinnvoll zu verfolgen ist, wenn du jemanden kennst, der dies für dich tun kann. Einen solchen Aufwand zu treiben ist für einen einzigen Anwendungsfall dieser Art nicht angemessen. Ich habe einfach nur so geantwortet, weil dies eine zielführende Vorgehensweise wäre. Außerdem kannte ich weder deine Ausstattung noch deine einschlägigen Kenntnisse. :)

    Solche Aufzeichnungen gelingen nicht mit den einfachen, vorgesehenen Mitteln. Was davon in der Cloud möglich ist, weiß ich nicht, da ich die Cloud nur sehr eingeschränkt zum Zuge kommen lasse.

    Nur zur Information:

    Es gibt viele legal kostenfreie Mittel dafür. Sie zu nutzen kostet halt zu Beginn Zeitinvestition. Bei mir haben sich ein Raspberry Pi, MQTT-Broker (Mosquitto), Node-RED Flows, InfluxDB (Zeitreihendatenbanksystem) und Grafana zur grafischen Darstellung erheblich bewährt. Diese Kombination ist kaum zu toppen.

    Vermutlich ist dafür kein Skript erforderlich. Notfalls nur ein sehr kurzes. Ich kenne es aber derzeit nicht.

    Ein Schedule Job (Zeitplan) schaltet um 6:00 den Öffnen-Zeitplan aktiv.

    Ein zweiter Zeitplan oder der Schließen-Zeitplan schaltet den Öffnen-Zeitplan wieder inaktiv.

    Letztlich ist das eine Frage von Schedule-Job Kenntnissen und deren zielgerichteter Nutzung. Mit den üblichen Klickmitteln ist das nicht zu machen.

    Weiteres dazu gibt es hier: https://iotig.eichelsdoerfer.net/index.php/anwe…e-schedule-jobs

    und insbesondere in der Shelly Doku https://shelly-api-docs.shelly.cloud/gen2/Component…rvices/Schedule

    Wenn der Plug S zu warm wird, dann liegt das bestimmt nicht am Verbraucher, weil im Plug S ein herkömmliches Relais schaltet. Dann täte ich mal die Umgebung des Plug S unter die Lupe nehmen und ggf. versuchen, vorsichtig das Gehäuse des Plug S zu öffnen. Hilfreich wäre es auch, den Temperaturverlauf des Chip aufzuzeichnen, um diesen analysieren zu können.

    Jo, bspw. mit einem Ruuvi Sensor und einem Skript. Ein geeignetes Skript hat ein früheres, hier leider nicht mehr mitwirkendes, Forum-Mitglied geschrieben. Ich habe derzeit keinen Ruuvi, weshalb ich das nicht implementieren kann. Die Feinheiten einer solchen Regelung müssten evtl. angepasst werden.