Beiträge von eiche

    Ich habe für meinen neuen Schuppen folgende Lichtschaltsteuerung implementiert.

    Danke für die Hinweise von ostfriese. Auf Grund seiner Hinweise liegt das Skript nun komplett vor.

    Anforderungen

    Eine Lampe soll per Bewegungsmelder eingeschaltet werden, wenn die Lampe aus ist.

    Der Bewegungsmelder soll per HTTP mit einem Shelly Plus 1 kommunizieren und dabei die Einschaltdauer per GET liefern.

    Sobald per Schalter/Taster am Plus 1 Eingang die Lampe eingeschaltet wird, soll die Einschaltdauer deaktiviert werden, damit die Lampe eingeschaltet bleibt.

    Dies löste ich mit Hilfe eines Shelly Motion (Gen. 1), einem Shelly Plus 1 und einem kleinen Skript auf dem Plus 1.

    Das Skript:

    Auf dem Bewegungsmelder wird folgende Action konfiguriert:

    Code
    http://<IP-Adresse des Plus 1>/script/<Skript Id>/on?<Dauer in s>

    Als Skript Id kommt typischerweise die 1 zum Zuge, falls auf dem Shelly kein anderes Skript abgelegt wurde.

    Dies ist im Zweifelsfalle zu prüfen.

    Es sind als Einschaltdauer auch Werte mit Nachkommastellen möglich.

    Wenn in der Action des Motion die Einschaltdauer fehlt, bleibt die Lampe eingeschaltet.

    Anwendungsfälle

    1. Jemand geht in den Schuppen, bspw. um ein Fahrrad zu holen.
      Die Lampe wird per Bewegungsmelder eingeschaltet und nach einer festgelegten Dauer automatisch ausgeschaltet.
    2. Jemand geht in den Schuppen, um sich dort länger aufzuhalten.
      Er schaltet die Lampe per Schalter ein (auch falls sie vom Bewegungsmelder eingeschaltet wurde).
      Die Lampe bleibt eingeschaltet, bis sie per Schalter ausgeschaltet wird.

    Vielleicht kann dies für andere nützlich sein.

    Die Heizungsregelung lässt sich leicht per Skript implementieren, aber ...

    Der Bewegungsmelder dürfte kein dauerhaftes Aktivsignal liefern, solange er eine Bewegung erkennt.

    Außerdem müsste sich dann jemand wiederholt bewegen, wenn geheizt werden soll.

    Etwa zielführend wäre folgende Lösung:

    Eingesetzt wird ein Skript, darin die Heizungsregelung, ein Eventhandler und ein Timer.

    Sobald eine Bewegung erkannt wird - Eingang ist aktiv - wird dies im Skript wie folgt verarbeitet.

    1. Die Heizungsregelung wird aktiviert - globale Zustandsvariable Ctrl = true.
    2. Der evtl. laufender Timer wird gelöscht (Handle erforderlich).
    3. Der Timer wird gestartet (repeat = false).

    2. und 3. bewirkt eine Retriggerung des Timers mit jeder Bewegungserkennung.

    Wenn der Timer abgelaufen ist, wird die Heizung ausgeschaltet und die Regelung deaktiviert.

    Ein Eventhandler zur Regelung prüft die globale Variable Ctrl. Nur wenn diese true beinhaltet, wird der vom Sensor gelieferte Temperaturwert zur Regelung verarbeitet.

    Ctrl muss demzufolge mit false initialisiert werden.

    Falls du selbst mit dem scripting nicht zurechtkommen solltest, wirst du dafür geeigneten Code brauchen.

    Die obige Idee sollte aber nutzbar sein.

    Die Dauer des Timers ist nach deinen Bedürfnissen zu wählen.

    Sowohl Temperaturschwellen (Hysterese) als auch Timerdauer könnten auch konfigurierbar gestaltet werden.

    Ich habe einen Motion (1. Gen.) im Außenbereich montiert. Andere Motions arbeiten unter Dach.

    Ich fand nirgendwo einen Hinweis, demzufolge ein solcher Motion ausschließlich unter Dach einzusetzen sei.

    Nach einem Regen leuchtet er durchgängig blau und ist nicht mehr erreichbar. Ich arbeite daran.

    Meine Frage:

    Sollte ein solcher Motion besser nicht Regen ausgesetzt sein?

    Nun sah ich, dass diese neue App auch Shelly Geräte der ersten Generation findet und zum Hinzufügen zur Cloud anbietet, auf welchen ich MQTT zur Kommunikation verwende. Ein Test ergab, dass nach wie vor bei solchen (älteren) Shelly nicht beides, MQTT und Cloud, nutzbar ist. Das "mal schnell" Hinzufügen eines MQTT Gerätes per App missfällt mir. Ok, ich muss wissen, das dies kontraproduktiv ist. Dies unterstützt jedoch nicht nur nicht den Anwender, es verleitet ihn dazu, es mal, vielleicht für Testzwecke, schnell zu tun. Das stufe ich als schwache Usability ein. Es ist durchaus möglich, die Konfiguration eines Shelly zu lesen ...

    Fauwee Danke

    Ich nutze ein Android Smartphone.

    Inzwischen fand ich in der neuen App die Stelle, an welcher ein Gerät der Cloud hinzugefügt werden kann. Dazu muss man wissen, dass zuerst das Home Icon in der Fußleiste zu wählen ist. Danach in der Kopfleiste nach rechts zu "Entdeckt" scrollen. Ich sah schlicht die Aufteilung zwischen Kopf- und Fußleiste in der App nicht. Auf der Website selbst ist nach meinen Versuchen das Hinzufügen eines Gerätes nicht mehr möglich. Somit ist man hierfür auf eine Smartphone App angewiesen. Dies halte ich, die Cloud Website betreffend, für einen Rückschritt.

    Ich freue mich aber, dass die neue App hierfür doch geeignet ist. :)

    Bisher hatte ich keine Probleme damit, ein neues Gerät (aktuell Shelly Plus 1) der Cloud hinzuzufügen. Nun finde ich den Pfad weder in der neuen App noch auf der Website control.shelly.cloud.

    Ich kann zwar anscheinend ein Gerät hinzufügen, lande dann erzwungen in der Auswahl eines Raumes und ... komme nicht weiter, weil ich kein neues Gerät hinzufügen kann.

    Der Shelly ist selbstverständlich mit der aktuellen Firmware ausgestattet und darauf die Cloud enabled.

    Edit: Mir erscheint die Konstellation aus neuer Cloud, deren Website und der neuen App unausgegoren. Ich finde darin keine Möglichkeit, der Cloud ein neues Gerät hinzuzufügen. Selbst wenn ich per https://control.shelly.cloud ein Gerät hinzufügen will, bin ich genötigt, die Shelly App auf einem Smartphone (o.ä.) zu installieren. Dann wird jedoch die alte App installiert. Dort wird mir mitgeteilt, ich solle die neue App installieren.

    Inzwischen konnte ich per alter App das Gerät per Angabe dessen IP-Adresse installieren. Dies war der einzige Weg, welcher mir nach meinen vielen Versuchen offenstand.

    Das riecht nach Überforderung der/des Softwareentwicklers bzgl. Cloud und neuer App.

    Mein Fazit: Die alte Shelly App bietet derzeit die einzige Möglichkeit, ein Gerät "zu Fuß" - und damit überhaupt - der Cloud hinzuzufügen.

    Never change a running firmware - soll heißen:

    Wenn man die Funktionalität einer Anlage nicht gefährden will, sollte man zum testen einen gleichen Shelly nutzen und die neue Firmware erst einmal damit ausgiebig testen.

    Das ist zwar aufwändiger, verringert aber die Gefahr von Fehlfunktionen der Anlage bei einem Firmware Update/Upgrade.

    Mit neuer Firmware steigt auch die Spannung bzgl. des neuen Verhaltens.

    Nur mal so und in aller Freundschaft. ;)

    Zudem: Warum ohne Cloud?

    Ich nutze einfach ne Alexa, die nebenbei Sonnenauf-/-untergang regelt.

    Wir nutzen für die Rollläden auch zusätzlich die Cloud und Amazon Echo. Ich mag es, einfach zu sagen: "Alexa, Wohnen links auf 50%." Dann fährt der entsprechende Rollladen so weit herunter, dass ich an meinem Notebook Display wieder genug erkennen kann. Das zeitgesteuerte Öffnen/Schließen per Sonnenaufgang/-untergang können die Shellies eh alleine, dazu braucht man keine Alexa.

    Und "ohne Cloud" sollte aufzeigen, dass hierfür keine Cloud erforderlich ist, das Ganze also bei nicht verfügbarem Internet noch funktioniert - mehr nicht.

    Btw., der i4 + 4fach Taster belegt eine Leerdose. Man muss ja nicht alle Taster nutzen, wenn dies nicht erforderlich ist. Außerdem kann man auch an zwei Taster einen Plus 2 (PM) anschließen, wenn man das will. Oder man kann einen i4 mit 4 sonstigen Tastern betreiben.

    All das sind Optionen und keinesfalls Notwendigkeiten. Da ich erst seit kurzem elektrische Rollläden betreibe, konnte ich in diesem Zuge die neuere, leistungsfähigere und flexiblere Hardware nutzen. Dies hätte ich auch dem TE empfohlen. Selbstverständlich hätte ich bereits bestehende und funktionierende alte Hardware beibehalten.

    Ich lagere die Steuerung meiner Rollläden in Shelly i4 aus. 4 Taster, je zwei für einen Rollladen. Die gewünschte Funktionalität implementiere ich per Skript.

    Mit einem i4 kann ich somit zwei Rollläden steuern, was sowohl mit Shelly 2.5 als auch mit Shelly 2 (PM) gelingt, da das jeweilige Kommando/Nachricht vom i4 gesendet wird.

    Der TE wird vermutlich seine Taster nicht gegen die 4fach Taster + i4 austauschen. Ich will aber eine alternative Möglichkeit aufzeigen, welche per Skript sehr flexibel implementierbar ist.

    Die Kommunikation zwischen i4 und Rollladen-Shelly geht über WLAN. Die Taster können beliebig platziert werden, da sie nicht mit den Rollladen-Shellies verbunden werden.

    Die von mir implementierten Funktionen sind

    • kurzer Druck auf obere Taste während Rollladen ruht -> der Rollladen wird hochgefahren
    • kurzer Druck auf obere Taste während Rollladen hoch fährt -> Rollladen wird angehalten
    • kurzer Druck auf untere Taste während Rollladen hoch fährt -> Rollladen wird runtergefahren
    • kurzer Druck auf untere Taste während Rollladen runterfährt -> Rollladen wird angehalten
    • für die umgekehrte Fahrtrichtung Rollentausch zwischen oberem und unterem Taster

    Längeren Tastendrücken ließen sich andere Funktionen zuordnen. Ich lasse damit bspw. meine Deckenlampe umschalten, weil ich die Leerdose des alten Lampenschalters mit dem i4 + 4fach Taster belege.

    Irgendwo hier im Forum habe ich mein i4 Skript mal veröffentlicht. Es enthält eine Datenstruktur zwecks Konfiguration, damit ein Nutzer sich nicht in den Programmcode vertiefen muss, wenn er umkonfigurieren will. Allerdings ist dann eine Einarbeitung in diese Datenstruktur erforderlich.

    Das Ganze gelingt ohne und mit Cloud, ganz wie man möchte.

    1. Es gibt viele Elektriker, die keine Ahnung von Shelly haben.
    2. Der TE ist offensichtlich nicht ganz ohne Kenntnisse.
    3. Was der Elektriker nach dem Post des TE mitteilte, hatte nichts von Konstruktivität - vielleicht ist er trotzdem bereit mitzuwirken.
    4. Nach meiner Erfahrung bauen Elektriker i.d.R. teuer und für den Anwender eher unflexibel.

    Von den ungeschalteten Steckdosen solltest du die Versorgung für den Shelly holen können. Evtl. brauchst du dafür noch zwei 3fach Klemmen.

    Die letzte dieser drei Steckdosen sollte aber noch je eine freie Klemme haben, von welchen die Versorgung geholt werden kann, falls noch genügend Raum für zwei Leitungsdrähte vorhanden ist.

    Dann bliebe noch die Frage, wie du die beiden Schalter mit dem Shelly verbinden kannst. Hierfür sei der Hinweis von horkatz aufzugreifen, die beiden Schalter durch Taster zu ersetzen und beide mit dem SW-Eingang des Shelly zu verbinden. Das sollte zumindest der Elektriker hinbekommen.

    Mit diesen Tastern ist es egal, durch welchen Taster geschaltet wird, es ist mit jedem Tastendruck zu wechseln (toggel).

    Anschließen eins Schalters an einen Shelly hat absolut nichts mit dem Einbinden des Shelly in ein Netzwerk zu tun.

    Ratschlag: Versuche zuerst, den Shelly in dein WLAN zu bringen!

    Danach kannst du dich mit der Nutzung eines Schalters bzw. zwei in Wechselschaltung am Shelly beschäftigen.

    Zumindest die Shellies der zweiten Generation (... Plus) gestatten es, den AP-Modus Passwort geschützt zu betreiben. Dann kann nicht jeder auf das WLAN des Shelly zugreifen.

    Wie Hiegeix7 breits schrieb, ist die Nutzbarkeit allerdings eingeschränkt.

    Um trotzdem auch zeitgesteuerte Aufgaben erfüllen zu können, kann ein Shelly X Plus beide Modi nutzen und bspw. sich über ein Smartphone Hotspot temporär, einmalig die aktuelle Zeit holen, welche dann intern weiter taktet - auch nach der Trennung vom Internet. Diese interne Zeit geht aber mit einem Reboot verloren.