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.

  • Gartenpumpe abschalten nach Zeit UND unter xxx Watt Verbrauch

    Noch kein Skript, nur das Prinzip:

    Irgendwie wird das Wasserwerk (WW) eingeschaltet.
    Dieses wird von der Firmware registriert und an eine Skriptfunktion weitergereicht.
    Diese Skriptfunktion startet einen Timer, der nach 30 Minuten abläuft.
    Mit dem Ablauf des Timers wird eine andere Funktion "check()" aufgerufen, die die zuletzt und sehr aktuell gemessene Leistung P von der Firmware abruft.
    Diese Leistung wird mit zwei konfigurierten Werten verglichen, bspw. 1W und 30W.
    Wenn P>1W UND P<30W dann wird as WW abgeschaltet.

    Verbesserung:

    Statt des direkten Aufrufs von check() wird ein weiterer Timer gestartet, der periodisch, bspw. jede Minute, diese Funktion check() aufruft. Sobald check() das WW ausschaltet, wird der periodisch arbeitende Timer beendet.
    Fertig.

    Edit 2: Zu kompliziert ... s.u.

  • Gartenpumpe abschalten nach Zeit UND unter xxx Watt Verbrauch

    Na ja, per Skript ginge das durchaus. Deine Zeiten sind nicht eindeutig.

    Wenn nach 30 Minuten geprüft wird, ob ab dann 10 Minuten lang P<30W ist, dann kann erst nach 40 Minuten abgeschaltet werden. Also sollte vielleicht 20 Minuten nach dem Einschalten 10 Minuten lang geprüft werden, ob P<30W dauernd vorliegt. Und warum die Prüfdauer auf P<30W von 10 Minuten sein soll, erschließt sich mir auch nicht.

    Edit: Ich ahne es.
    Du hast ja einen Pufferbehälter und die Pumpe schaltet sich zwischenzeitlich aus. Dann sollte aber als Ausschaltkriterium bspw. 1W < P < 30W genügen.

  • RGBW Wert an mehrere Duos synchronisieren

    Zitat von Hojo7871

    Die andere von Dir vorgeschlagene Lösung (dauerndes Wiederholen des Skripts) bereitet mir etwas Sorgen. Tut es dem Shelly gut, wenn das Skript permanent läuft (bzw dann, wenn die Bulbs eingeschaltet sind). Ist nur so ein Bauchgefühl.

    lol, das macht dem Shelly absolut nichts aus. Das Skript wird nicht dauernd wiederholt. Ein Timer ruft periodisch eine Funktion auf, welche die Status-Daten vom Master liest und an die Slaves überträgt. Das ist noch etwas einfacher als dein bisheriges Skript. Das Skript wird nie gestoppt.

    Edit:
    Ein Shelly Skript ist immer Ereignis gesteuert. Da wird, solange man es geeignet erstellt, nichts von sich aus wiederholt. Das Skript stellt also gewisse Teile/Funktionen zur Verfügung, welche auf Grund von Ereignissen abgearbeitet/aufgerufen werden. In meinem letzten Lösunmgsvorschlag sorgt ein Timer periodisch dafür, dass eine Funktion "sync()" aufgerufen wird, die sich um das Synchronisieren kümmert. Die Ereignisse sind also periodische Timerabläufe.

  • Shelly Virus für Gen2/3

    Zitat von jay_bee

    Das ist ja in 5 Minuten getestet. Hätte ich aus Interesse gleich nach dem Paketerhalt gemacht.

    Wie willst du dies denn anders interpretieren, als so, wie es thgoebel tat. Mir ging es genauso wie ihm, ich bin nur nicht involviert. Schließlich ist er der Empfänger des Pakets. Somit ignorierst du Thomas' eigenständige Zeiteinteilung. Damit ist nicht Thomas eine Mimose sondern du gebärdest dich total unsensibel.

    Ich täte diesen Kommentar nicht schreiben, wenn es bei Thomas' Aussage geblieben wäre. Stattdessen führst du dich wie der Angegriffene auf. Das ist schlicht unverschämt.

    Noch etwas sehr WICHTIGES!

    Thomas hat im Forum sehr viel dokumentiert, Reparaturen angeboten und durchgeführt, Bauteile bereitgestellt und insbesondere Fragen beantwortet. Und alles das "ehrenamtlich", soll heißen, ohne etwas daran zu verdienen. Und ich habe ihn immer sachlich sowie sehr geduldig erlebt.

    Das musste ich loswerden. Meinetwegen kann es in ruhigem Fahrwasser weitergehen.

    Edit:

    Zitat von jay_bee

    Vor der Firmware wird aber der Bootloader gestartet. Und wenn Gpio9 während dem Boot auf Masse liegt, sollte die Firmware garnicht starten, sondern das Ding auf neue Firmware warten...

    Das sollte so sein und ich wunderte mich, wenn es anders wäre. Als Einwand ist dies angemessen, nur halt nicht als Vorgabe, was Andere noch tun sollten. Vor allem dann nicht, wenn man nicht weiß, wie diese Anderen ausgelastet sind und welche Ausstattung sie (nicht) besitzen. ;)

  • RGBW Wert an mehrere Duos synchronisieren

    Ich habe noch eine Idee für einen relativ komfortablen Automatismus, welcher allerdings auch ein wenig einschränkt.

    Die Einschränkung liegt darin, dass für diese Idee wieder eine Master-Lampe eingeführt werden muss.

    Man kann einen Zeitgeber verwenden, der in definierbaren Zeitabständen die Master-Lampe abfragt und deren Einstellungen auf die Slave-Lampen überträgt. Der Zeitgeber kann ein Skript interner Timer oder ein Schedule Job sein. Ich nehme als Zeitabstandswert mal 1s, was relativ kurz ist. Diese 1s ist zugleich, mit einer gewissen Toleranz im ms Bereich, die maximale Zeitverzögerung, mit welcher die Slave-Lampen auf die Master-Lampe passiv reagieren. Passiv deshalb, weil das Skript dafür aktiv ist.

    Das Skript fragt nach jeder Sekunde den Zustand der Master-Lampe ab, ohne selbst dafür getriggert zu werden. Somit entfallen hierfür auch die Actions auf den Lampen, auch auf der Master-Lampe. Das Skript überträgt die von der Master-Lampe geholten Einstellungen selbstständig auf die Slave-Lampen. Auf diese Weise kann der Anwender nicht mehr die Slave-Lampen als eigenständige Lampen separat einstellen, weil eine solche Einstellung kurz danach vom Skript überschrieben würde. Eine separate Einstellung der Slave-Lampen wollen afaik JayR82 und Hojo7871 auch nicht. Die einzige Unschönheit ist eine Verzögerung der Einstellungen zwischen der Master-Lampe und den Slave-Lampen, die zudem quasi zufällig lang ist, aber maximal eine Sekunde beträgt. Die Traffic-Dichte ist dabei relativ hoch, die Datenpakete aber klein.

    Der Vorteil dieser Idee liegt darin, dass sich der Anwender nicht um die Übertragung auf die Slave-Lampen kümmern muss und letztlich ausschließlich die Master-Lampe einstellt. Er darf sich halt nicht an der verzögerten Reaktion der Slave-Lampen stören.

    Das Ganze funktioniert völlig unabhängig von der einstellenden Quelle sowohl lokal als auch über die Cloud. Btw, wer dafür auch die Cloud nutzen will, braucht dafür nur die Master-Lampe der Cloud hinzuzufügen, die Slave-Lampen nicht, weil das Skript lokal arbeitet. Insgesamt betrachtet besteht diese Lampenanordnung steuerungstechnisch aus nur einer Lichtquelle.

    Man kann selbstverständlich auch das von mir in #13 unter Edit 2 beschriebene Workaround mit dieser Zeittriggerlösung zu kombinieren versuchen. Dabei sollten sich die beiden Trigger per Zeit und per Action allerdings gegenseitig sperren, damit nicht zu viele RPC Aufrufe fast zeitgleich erfolgen können. (Interessant wäre auch der Versuch, dafür kaskadierte RPC Aufrufe zu coden. Die Kaskadestufen wären per RPC Aufrufe innerhalb der callback Funktionen zu implementieren. Vermutlich könnte dies eine Überschreitung des RPC Limits verhindern. Bei vielen Slave-Lampen käme solches besonders zum tragen. Eine einfachere Alternative wäre die Verwendung einer Timers mit einem Indexzähler, welcher auf die Einträge einer Liste (Datenfeld, Array) verweist.)

    Wer mit jeder neuen Einstellung der Master-Lampe ein künstlerisch gestaltetes Lichtspiel haben möchte, kann eine zufällige Verzögerung in der Reaktion der Slave-Lampen implementieren. Je mehr Lampen beteiligt sind, desto unterhaltsamer wäre das Lichtspiel. Ich sollte mir das patentieren lassen ... ;)

  • RGBW Wert an mehrere Duos synchronisieren

    Hojo7871

    Vielleicht schilderst du dieses Webhook Problem der Shelly Duo dem Support mit der Bitte, Webhooks auch beim Ändern der Lichtfarbe einzubauen. Ob von deren Seite solches interessant genug wäre, die Firmware zu ändern, kann ich nicht einschätzen.

    Inzwischen erkannte ich auch eine nicht überzeugende Logik im Verhalten der Shelly Duo.

    Im ausgeschalteten Zustand wird die Lampe bei Änderung der Helligkeit automatisch eingeschaltet, bei Änderung der Lichtfarbe hingegen nicht.

    Ich finde, dass sich beide Änderungen auf den Schaltzustand gleich auswirken sollten - unabhängig von deinem Anliegen.

    Diese Firmware hat noch Verbesserungsbedarf. Ich brauche allerdings dergleichen bisher nicht.;)

  • RGBW Wert an mehrere Duos synchronisieren

    Hojo7871

    Ah, jetzt habe ich verstanden, warum das Skript gestartet werden soll und warum SebMai anmerkte, dass das Skript für deinen Anwendungsfall gestoppt sein müsse.

    Ich glaube zunächst trotzdem nicht, dass ein Skriptstart zwingend erforderlich ist.

    Voraussetzung - ob dies gelingt, weiß ich noch nicht:
    Per Skript auf dem Wall Display kann die Änderung eines Display Widget erfasst werden.

    Wenn diese Voraussetzung erfüllt ist, kann diese Änderung durch dieses Skript an alle gewünschten Lampen per http gesendet werden

    oder, wie es dein Skript auf dem Plus 2PM teilweise tut,

    die Widget Änderung an die "Master"-Lampe gesendet werden und im Plus 2PM Skript eine Funktion "sync()" per "Script.Eval" aufgerufen werden, welche die Einstellungen der "Master"-Lampe liest und an die anderen Lampen sendet. Hierfür ist das Skript nicht zu stoppen, im Gegenteil, es muss auf dem Plus 2PM ständig laufen.

    Edit: Wenn ich ein Wall Display habe, werde ich dessen Skript-Möglichkeiten testen ...

    Edit 2:
    Ich verstehe dein Anliegen eines Automatismus, welcher von der "Master"-Lampe ausgehen sollte. Dann wäre es nämlich gleichgültig, von welcher Quelle ausgehend diese Lampe eingestellt würde. Frage dazu: Nutzt du MQTT oder denkst du darüber nach, MQTT zu nutzen?

    Eine Änderung der Helligkeit schaltet die Lampe automatisch auch ein, eine Änderung der Lichtfarbe nicht. Als Workround könntest du folgendes versuchen.

    Per Webhooks (=Actions) auf der "Master"-Lampe ruft diese Lampe eine Skript-Funktion auf, ich nenne sie noch einmal "sync()". sync() wird von der Lampe sowohl beim einschalten als auch beim ausschalten aufgerufen. sync() liest die Einstellungen der "Master"-Lampe ein und kopiert diese per http auf die "Slave"-Lampen.

    Sobald die "Master"-Lampe eingeschaltet wird, werden auf diesem Wege auch die "Slave"-Lampen eingeschaltet. Es bleibt noch die folgende Lücke.
    Wenn die Lichtfarbe der "Master"-Lampe geändert wird, ohne diese zu schalten, wird die Lichtfarbe nicht auf die "Slave"-Lampen übertragen. Diese Lücke wird sich aber nicht auswirken, weil die Lichtfarbe erst mit dem Einschalten zum Zuge kommt - und dabei wird bereits synchronisiert. Diese Lücke wirkt sich bei einer Änderung der Lichtfarbe aus, wenn währenddessen die Lampe eingeschaltet bleibt. Um diese Lücke zu umschiffen, könntest du die "Master"-Lampe kurz (vielleicht im ms Bereich) ausschalten und wieder einschalten lassen. Vermutlich wäre solches nicht zu sehen. Edit: Das gelingt leider doch nicht so einfach. Ich habe dazu leider noch keine zündende Idee außerhalb eines Wall Display Skriptes. Mit der Änderung der Helligkeit im eingeschalteten Zustand ergibt sich die gleiche Lücke. Habe dies mit meiner einzigen Shelly Duo getestet.

    Wenn du diesen Automatismus auch auf das Schalten der "Slave"-Lampen übertragen willst, trägst du einfach die Actions der "Master"-Lampe auch auf den "Slave"-Lampen ein! Dann gäbe es weder Master- noch Slave-Rollen, es würde schlicht nur repliziert. Dafür wäre beim Aufruf von sync() noch die Quelle als Parameter zu übergeben - sync('<eigene IP Adresse>').

    Voilà

    Nachgereicht: Aufruf der Skript-Funktion sync() per Action.

    Code
    http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=<Skript Id>&code="sync()"
bzw.
http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=<Skript Id>&code="sync('<eigene IP Adresse>')"

    Falls du hierfür Hilfe beim coden der Funktion sync() brauchen solltest, frage einfach nach! ;)

    Edit 3:
    Das von mir unter Edit 2 beschriebene Workaround wird mit folgender Einschränkung funktionieren.
    Immer dann, wenn du die Lichtfarbe oder die Helligkeit im eingeschalteten Zustand änderst, wird diese Änderung nicht auf die anderen Lampen übertragen. Um die Übertragung zu erwirken, musst du die Lampe, an welcher geändert wurde, kurz aus- und wieder einschalten. Danach sind alle Lampen gleich eingestellt. Dabei spielt die Quelle des Schaltens keinerlei Rolle.

  • RGBW Wert an mehrere Duos synchronisieren

    Zitat von Smarter

    in mir keimt Hoffnung auf, dass ich bald wieder Licht im Wohnzimmer habe.

    Nimm solange Kerzen! ;)

    Zitat von Smarter

    Ist das eigentlich schon ein Beruf?

    Nein, solches zähle ich jedenfalls eher zu ambitionierter, privater Beschäftigung.

    Zitat von Smarter

    Was machen Leute wie ich, die es nicht können?

    Teuer einkaufen!

    Zitat von Smarter

    Muss man es lernen

    Nein, weil dies alles nicht lebensnotwendig ist. Es sei denn für Menschen mit Einschränkungen und kleinem Geldbeutel bzw. Leuten, die solche Menschen mit technischen Mitteln unterstützen wollen.

    Zitat von Smarter

    macht es heutzutage der Elektriker?

    Nein, weil die Shelly dafür nicht hinreichend zertifiziert sind und insbesondere ein Eigentümer dem Elektriker dazwischen wirken könnte. Ein Elektriker übernimmt typischerweise eine Gewährleistung für seine Installation, was er meiner Meinung nach bei Verwendung von Shelly Geräten mit solchermaßen offengelegter API nicht kann.

    Diese sehr gut dokumentierte API bietet ja gerade einem ambitioniertem Anwender viele Möglichkeiten, die er nicht teuer einkaufen muss und für die er nicht zwingend irgendeine Zentrale braucht.

    Fazit:
    Wenn du dich lieber nicht selbst mit ambitioniertem Engagement um die Funktion deines smart home kümmern willst, vergiss die Shelly Geräte und kaufe beim Fachmann teuer ein! Alles andere ist Illusion.

  • Gartenpumpe abschalten nach Zeit UND unter xxx Watt Verbrauch

    Wenn MaMoe696 seine bisherige Zusammenstellung und Shelly Konfiguration hinreichend und verständlich beschriebe, wüssten wir mehr. Nun können wir nur vermuten. Entscheidende Dinge wurden bereits angemerkt.

    Insbesondere dies erscheint mir unverständlich:

    Zitat von MaMoe696

    Die Pumpe schaltet automatisch ab sobald der Wasserdrverbrauch endet.

    Was bedeutet "Wasserverbrauch endet"? 30 min nach Einschalten? Kein Wasser mehr verfügbar? ...

    Ich versuche mal zu strukturieren und hoffe auf verständliche Antworten. Offenbar schaltet ein Shelly Plus 1 das Hauswasserwerk.

    1. Schaltet dein Hauswasserwerk ab, wenn in der Zisterne Wasser zum ansaugen fehlt?
      Das sollte es. Wenn nicht, ist eine Sicherheitsabschaltung erforderlich, wofür eine Cloud Szene zu unsicher ist.
    2. Nutzt du zum abstellen des Wasserflusses ein Magnetventil?
      Vermutlich nicht, weil bisher nicht angegeben.
    3. Hast du den Shelly so eingestellt, dass er nach 30 min automatisch ausschaltet (Timer in der Konfiguration)?
    4. Womit beauftragst du den Shelly, das Wasserwerk einzuschalten?
      App, Schalter oder Taster am Shelly Eingang, Shelly Button 1, ...?
    5. Willst du zwischen Gartenbewässerung mit abschalten nach 30 min und Dauereinschalten mit manuellem Ausschalten unterscheiden?
      Wenn ja, sind das zwei Betriebsarten, die leicht per unterschiedlicher Actions oder URL gestartet werden können.

    MaMoe696: Bitte beantworte diese Fragen, damit wir, oder zumindest ich, zielführend auf dein Anliegen eingehen können!

  • Funk-Rolladensteuerung über Shelly

    Hmm, liest sich so wie "von hinten durch die Brust in's Auge". ;)

    Es geht mit ziemlich viel Aufwand sicher auch das, was dir vorschwebt. Ich täte solches nicht weiter verfolgen.

    Hast du mal darüber nachgedacht, deine bisherige Funkanlage durch Shelly zu ersetzen, möglichst ab Generation 2? Vielleicht gelingt dies auch parallel zur bestehenden Funkanlage. Dazu kann ich leider nicht viel mitteilen, da meine neuen Rollladenantriebe mit einfachen Motoren und drei Anschlüssen ausgestattet sind und bestens an Shelly 2.5 sowie Shelly Plus 2PM arbeiten.

    Du könntest aber für den Anfang mit einem Rollladen experimentieren, was auch bereits per altem Shelly 2.5 gelingt. Jedenfalls brauchst du dann zu jedem Rollladen einen einzelnen Shelly, was du ja bereits feststelltest.

    Zielführend für ein solches Vorhaben wären genauere Angaben zu deinem Rollladenantrieb - Motoren, Motoranschlüsse, ...
    An Hand solcher Informationen können Andere hier voraussichtlich fachgerechte Hinweise geben.

  • RGBW Wert an mehrere Duos synchronisieren

    Hojo7871

    Was mir in deinem Skript unmittelbar auffällt ...

    Zeile 12:

    Code
    urlSource = "http://" & urlSourceIP & "/light/0?/getstatus"

    Der Operator & dient dem bitweisen UND verknüpfen von Operanden. Was du damit willst, ist eine String-Verkettung, wozu der Operator + geeignet ist.

    Deine Zeilen 22 bis 27:

    Code
       if (boolOnOff === true) {
     strOnOff = "on"
   }
   if (boolOnOff === false) {
     strOnOff = "off"
   }

    Umständlicher geht es kaum. Dazu zwei Alternativen:

    Code
    if(boolOnOff) strOnOff = "on"; else strOnOff = "off";

    oder noch kürzer: (gefällt nicht jedem)

    Code
    strOnOff = boolOnOff ? "on" : "off";

    Auch ist es keine gute Idee, Konstanten, wie bspw. IP Adressen, irgendwo im Code zu platzieren. Dies gehört in einen Konfigurationsbereich, möglichst Nähe Skriptanfang. Dies ist dir aber vermutlich klar, sorry.

    Die Funktion deines Skripts habe ich nicht analysiert. Mache bitte weiter! ;)

    Noch etwas mehr ...

    Prüfe bitte gelegentlich die Verwendung der Methode "Script.Eval"! Diese ist sehr leicht verwendbar und besitzt gegenüber dem Starten und Anhalten eines Skripts folgende Vorteile.

    1. Das Skript kann durchlaufen, wenn per "Script.Eval" einfach eine spezifizierte Funktion im Skript aufgerufen wird.
    2. Die aufgerufene Skriptfunktion kann Parameter importieren.
    3. Per RPC ist eine Skriptfunktion leicht aufrufbar.
      http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=<Skript Id>?code="<Anweisung>"
      Als Anweisung ist fast immer ein Funktionsaufruf, bei Bedarf mit Parameter, zielführend - mit derselben Syntax wie im Skript auch.

    Allerdings wird das Skript von der Firmware abgebrochen, falls im RPC ein Fehler vorliegt, bspw. der Skriptname falsch notiert ist.

    Um einen solchen Abbruch zu vermeiden, allerdings bei Fehler ohne gewünschten Effekt, ist ein HTTPServer Endpont zielführend, was etwas mehr Code-Aufwand nach sich zieht.

  • Gartenpumpe abschalten nach Zeit UND unter xxx Watt Verbrauch

    Eine Lösung per Action fällt mir dazu nicht ein. Da sind andere erfahrener als ich. Ich bevorzuge halt Skripte, die immer erfolgversprechend sind.

    Dein Anliegen habe ich verstanden und kann folgendes aufzeigen, per Skript.

    Die Pumpe wird eingeschaltet, was das Skript registriert.

    30 Minuten später kann das Skript den aktuellen Verbrauch ermitteln und auf Grund dessen die Pumpe weiterlaufen lassen oder ausschalten. abhängig von deinem Schwellenwert.

    Wenn die Pumpe weiterläuft, muss das Skript in kurzen Abständen oder per sog. StatusHandler den aktuellen Verbrauch prüfen, um bei Unterschreitung deines vorgegebenen Schwellenwertes abzuschalten.


    Edit:
    Es geht aber auch einfacher. Das Skript erfasst jederzeit die aktuelle Pumpenleistung und schaltet sicherheitstechnisch ab, wenn die Leistung den vorgegebenen Schwellenwert unterschreitet. Das sollte auch per Action gelingen.


    Edit 2:
    Dazu wären für deinen Einsatz schlicht zwei unterschiedliche Nachrichten zu verwenden.

    1. Einschalten und nach 30 min aus.
    2. Einschalten ohne Zeitbegrenzung.

    Diese Liste kannst du nach deinem Bedarf erweitern.

    In jedem Fall brauchst du einen Shelly, der die vom Verbraucher gezogene Leistung messen kann. Dazu genügt ein Shelly Plus 1 (ohne PM) nicht.