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.

    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.

    Frage an einen Moderator: Sollen hemnes84 und ich hier weiter kommunizieren oder per PN?

    hemnes84

    Ich habe ein wenig experimentiert.
    Gerät: Shelly Plus 2PM, zunächst noch ohne Add-on, im Cover Modus

    Die Konfiguration sieht u.a. vor, einen oder zwei Taster zur Steuerung zu verwenden. Soweit ich verstand, wird der Torantrieb ursprünglich mit einem Taster bedient. Da du bisher den Ausgang des Plus 1 PM parallel zum vorhandenen Taster geschaltet hast (richtig?) und auch der Plus 2 PM einen solchen Taster emulieren soll, sind vermutlich die Eingänge auf Schalter zu konfigurieren. Dann könnte der Schaltsensor vermutlich mit einem Shelly-Eingang verbunden werden. Sicher ist das noch nicht. Das hängt letztlich auch von der finalen Schaltung ab. Der Taster kann auch mit einem Shelly-Eingang verbunden werden, dann aber als Taster statt Schalter. Der Schaltsensor ist vermutlich als Schalter zu behandeln. Der Plus 2 PM lässt aber keine unterschiedliche Eingangskonfigurationen zu.

    Gibt es einen oder zwei Schaltsensoren an deiner Anlage? Die Skizze dazu sollte vollständig sein!
    Diese Steuerung lässt keine Kalibrierung des Shelly zu, weil der Shelly nicht den Motor schaltet und somit dessen Leistungsaufnahme nicht messen kann. Falls der Shelly den Motor direkt steuern könnte/sollte, könnte eine Kalibrierung möglich sein. Ich weiß aber bisher nicht, ob dies auch bei 24V Versorgung gelingen kann. Mit einer Kalibrierung kann das Tor auch teilweise geöffnet werden.

    Im Skript werden Ereignisse mit Informationen verarbeitet. Diese können u.a. sein

    1. Tor wird bewegt ("opening" oder "closing").
    2. Eingang 0 (S1) hat sich verändert ("toggle"), Zustand geöffnet (false) oder geschlossen (true).
    3. Eingang 1 (S2) siehe Eingang 0.
    4. Quelle der Aktion: u.a. Eingang vs. Shelly Cloud - der Sprachassistent steuert über die Shelly Cloud.

    An Hand dieser Ereignisse kann das Skript wie gewünscht arbeiten.

    Hinweis: Es ist auch möglich, statt des bisherigen Tasters am Shelly zwei Schalter zu verwenden, einen zum öffnen, den anderen zum schließen des Tors.

    Du wirst von mir nicht auf Anhieb ein Skript erhalten, welches bereits die gesamte Funktionalität implementiert.
    Grund: Ich kann derzeit deine Umgebung nicht hinreichend nachbilden.

    Bewährt hat sich aber ein schrittweises Annähern an das gewünschte Verhalten. Ich habe somit vor, dir ein anfängliches kleines Skript zur Verfügung zu stellen, dessen Ausgaben im Skriptfenster unter Console du mir dann mitteilen solltest. Auf Grund solches Ausgaben kann ich dann das Skript weiterentwickeln. Abhängig von deiner zeitlichen Investition und meiner Freiheit/Muße kann das Skript innerhalb weniger Tage bis hin zu einigen Wochen in einen funktional befriedigenden Zustand wachsen.

    Der Vorteil einer solchen Lösung liegt in einer Cloud unabhängigen Arbeitsweise, mit der Option, einen Sprachassistenten (Amazon Echo, Google, Apple Iris) über die Cloud nutzen zu können. Du wirst also dann deine Torsteuerung bei fehlendem Cloud-Zugriff - aus welchen Gründen auch immer - manuell nutzen und zugleich bei Cloud Verfügbarkeit den Komfort einer Bedienung per Sprachassistent genießen können. So jedenfalls der Plan.

    Zunächst warte ich noch auf deine Schaltskizze, da das weitere Vorgehen eine geeignete Schaltung voraussetzt.