Beiträge von eiche

He, da ist ja der Code. Besten Dank tvbshell ! Danach suchte ich und sah diese Weiterführung nicht.

Wird umgehend kopiert.

hemnes84

Ich habe experimentiert und bin noch dran. Die Nutzung eines Sprachassistenten hat höchste Priorität. Dies gelingt nicht mit einem Shelly Plus 1.

Eingesetztes Gerät: Shelly Plus 2 PM

Die Ausgänge werden parallel geschaltet, weil der Torantrieb ausschließlich auf einen Impuls reagiert. Somit erhält die Torsteuerung sowohl mit der Sprachanweisung "Garage öffnen" als auch mit "Garage schließen" den Beginn des Einschaltimpulses.

1. Das Gerät muss im Modus Cover betrieben werden, weil andernfalls die Sprachanweisungen "öffnen" und "schließen" nicht wirken.
2. Deshalb greifen die Timer-Einstellungen in der Ausgangskonfiguration nicht.
3. Um einen Impuls auszugeben, muss das Skript nach dem Einschalten die Anweisung "stop" beauftragen.
4. Sollte das Tor nicht bewegt werden, weil es bereits den beauftragten Zustand besitzt (öffnen eines geöffneten Tors führt wegen Impuls zum schließen und umgekehrt), muss ein zweiter Impuls vom Skript ausgegeben werden, um das Tor wieder zurückzustellen.
5. Das Skript muss somit die Component "Cover" nutzen, um zu stoppen und um einen zusätzlichen Impuls auszugeben.

Das ist zwar etwas tricky, wird aber per Skript implementierbar sein. Ich arbeite daran ...

Zitat von tvbshell

Aber ich nehme an, das Skript von ostfriese ist sicher eine verbesserter Version davon.

Er hat dazu eine sehr übersichtliche Webseite per Skript erstellt. Leider fand ich das Skript noch nicht.

Prinzipiell tue ich so etwas auch, habe aber derzeit dazu keinen Antrieb.

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.

Ich werde mal danach suchen. Vielleicht ist es zu finden.

Zitat von HKaufmann

Wenn das Wlan bzw. die Cloud ausfällt, was macht man dann?

Genau darum geht es. WLAN Ausfall ist recht selten und ohne Strom arbeitet auch das Kühlaggregat nicht. Die Cloud ist bei diesem Vorschlag zweckmäßigerweise nicht beteiligt.

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.

horkatz

Ich kenne mich in den Cloud-Szenen nur sehr wenig aus, weil ich diese für ... äh, eingeschränkt nützlich halte.

Aber, unabhängig davon, ist mir keine Möglichkeit bekannt, per Cloud einen Eingangszustand verändern zu können.

Zitat von Candid

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.

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.

"calls": [
    {
      "method":"Cover.Close",
      "params": {
        "id":0
      }
    },
    {
      "method": "Schedule.Update",
      "params": {
        "id": 2,
        "enable": false
      }
    },
    {
      "method": "Schedule.Update",
      "params": {
        "id": 4,
        "enable": false
      }
    }
  ]

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.

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 tvbshell :

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.

Zitat von Candid

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.

Letztlich ist ein Teil der Verdrahtung eine Frage nach dem "wie du es haben willst".

Wenn der Shelly selbst nicht per Schalter/Taster bedient werden soll, wirst du das Add-On dafür nicht brauchen und den Magnetschalter an einen der beiden Eingänge nutzen können.

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

Am besten gelingt das Cloud unabhängig. Ich nutze für solche Dinge Node-RED, InfluxDB (zeitbasiertes Datenbanksystem) und Grafana zur grafischen Darstellung. Diese Kombination ist der Cloud-Aufzeichnung um Klassen überlegen.

s.a. meine Signatur