Beiträge von eiche

Ich habe mit allen vieren keine Erfahrung.

Zitat von Krauskopp

Und dafür gibt es auch für Deppen wie mich, fertige Beispiele. Logisch.

Ich nehme allenfalls solche Beispiele als Anregung. Bisher sah ich nichts, was bereits für meine Ziele "fertig" war.

Zitat von Krauskopp

Er wollte ja gerade bei Handbetrieb die Sperre ("wenn ich z. Bsp. den Taster betätige")

Das ist unerheblich. Entscheidend ist die Tatsache, dass es per Skript möglich ist, unterschiedliche Quellen zu unterscheiden und daraufhin selektiv arbeiten zu lassen.

Das derartige Ziel des Klienten kann so implementiert werden.

Für mehr Übersicht in einem per Skript gespeicherten Protokoll habe ich folgende Idee.

Das Protokollskript sollte separat arbeiten, also unabhängig vom Applikationsskript.

Zum Protokollskript:

Es erhält den gleichen Eventhandler wie das Applikationsskript, welcher aber etwas anderes tut.

Er speichert gewisse, in Verdacht gerate Dinge in einer Datenstruktur - oder in mehreren. Ich nenne diese mal Verdacht.

Das Protokollskript erhält eine weitere Funktion, ich nenne sie mal speichern().

speichern() sorgt irgendwie dafür, dass die Daten in Verdacht gespeichert werden, lokal oder per Nachricht remote.

Das Applikationsskript nutzt Ausnahmebehandlung (try, catch).

Im catch Block wird per ein Ereignis ausgelöst, welches vom Protokollskript zum speichern verarbeitet wird.

oder

Im catch Block wird per Methode "Script.Eval" die Funktion speichern() aufgerufen.

Auf diese Weise wird eine Protokolldatei nicht voll gemüllt sondern enthält evtl. interessante Informationen.

Welche Dinge zu speichern sind, hängt vom Verdachtsfall ab.

Edit:

Um einen Shelly.call() Aufruf zum speichern zu vermeiden, ist es vielleicht doch besser, die Teile vom Protokollskript in das Applikationsskipt zu integrieren.

Automatik-, Zeit- und bspw. Helligkeits-gesteuerter Betrieb lassen sich leicht in einem Skript unterscheiden und entsprechend kann der Handbetrieb ungesperrt arbeiten.

Zitat von Krauskopp

Und nun eine Lösung für "NichtSkriptFans"

Die sollen hinausgehen und das Eis abkratzen.

Im Ernst:

Ohne Skript lassen sich imho ausschließlich vorgesehene Dinge implementieren.

Alles, was darüber hinausgeht, ist etwas für Skripte - und bei Bedarf Schedule Jobs.

Zitat von Krauskopp

Dann schreibst Du ein dickes Skript, mit dem Du dann die Rollladenfunktionen in allen Plus2PM abschaltest.

Sooo dick muss das nicht sein. Ein Datenfeld mit Einträgen für alle betreffenden Shelly und eine passende Schleife ...

Zitat von Krauskopp

Da gibt es das Wetter umsonst.

Es gibt etwas umsonst? Wo wo wo ...

Das Wetter ist immer umsonst, nur manche Folgen nicht. Und das (erste) ist gut so.

Sorry, das waren halt Steilvorlagen - tue ich sonst eher nicht.

Zitat von alex0711

Kann ich dem Shelly vlt. explizit auftragen, nach einem Addon zu suchen?

Habe ich noch nicht versucht. Die Dokumentation beinhaltet Sys.SetConfig ... https://shelly-api-docs.shelly.cloud/gen2/0.14/Comp…s#configuration sorry, erst ab der zweiten Generation

Zwecks Fehlersuche erscheint es zielführend, vom Groben zum Feinen vorzugehen.

• Shelly gegen anderen des gleichen Typs austauschen -> Probelauf, auch über längere Dauer
• AddOn gegen anderes austauschen -> Probelauf, auch über längere Dauer

Falls eines von beiden den Fehler beseitigt, zwecks Kontrolle vorheriges Teil desselben Typs wieder einbauen und testen.

Tritt der Fehler wieder auf, dieses Teil reparieren (lassen) oder entsorgen.

Mögliche Fehlerursachen:

1. Kontaktproblem (wo auch immer)
2. Temperaturproblem - die Chiptemperatur kann vielleicht gelesen werden (bei Gen 1 bin ich nicht sicher, bei Gen 2 geht dies)
3. Riss in der Platine -> mit Lupe absuchen, notfalls alles nachlöten, was geht
4. Bauteil aus der Toleranz -> Fachleute wie thgoebel, DIYROLLY ... fragen
5. Störung in unmittelbarer Umgebung -> nur wahrscheinlich, wenn mehrere ausgetauschte Shelly das gleiche Verhalten zeigen
6. etwas, was mir jetzt nicht einfällt

Viel Erfolg!

walterli

Ich zeige hier nur das Prinzip. Wie du auf die eintreffenden Messwerte zugreifen kannst, solltest du selbst herausfinden oder dir von jemandem weiterhelfen lassen, der einen solchen Shelly besitzt.

Das folgende Skript ist so nicht lauffähig. Drei Punkte hintereinander bedeuten soviel wie "Da muss etwas hin, was ich nicht genau weiß." (Ich habe keinen solchen Shelly.)

let Topic = "meine/Werkstatt/Messwerte"; // Auf das von dir gewünschte Topic abändern!

let Measurement = {
    voltage: null,
    current: null,
    apower: null,
    aenergy: {total: null}
};

function handleEvent(event) {
    print(JSON.stringify(event)); // zeigt die komplette Struktur des eintreffenden event - mit Schlüssel und Werten; kann später entfallen
    // Hier die events selektieren, die zu deinem Anliegen passen
    if(event. ... === ...) {
        // Messwerte speichern
        Measurement.voltage = ...;
        Measurement.current = ...;
        Measurement.apower = ...;
        Measurement.aenergy.total = ...;
    }
}

function send() {
    MQTT.publish(Topic, JSON.stringify(Measurement)); // Bei Bedarf kann QoS und retain als 3. und 4. Parameter hinzugefügt werden.
}

Shelly.addEventHandler(handleEvent);

Die Messwerte werden in nicht sehr regelmäßigen Abständen per Event eintreffen. Diese werden einfach in Measurement zwischengespeichert.

Dazu brauchst du noch einen Schedule Job, den du folgendermaßen per Web Browser in der Adresszeile anlegen kannst. Die Angaben in timespec lassen sich später per Web UI ändern.

http://<IP Adresse des Shelly>/rpc/schedule.create?timespec="0 */2 * * * *"&calls=[{"method":"script.eval","params":{"id":<Skript Id>,"code":"send()"}}]

Wenn die Skript Id 1 ist und die IP Adresse des Shelly 192.168.178.100:

http://192.168.178.100/rpc/schedule.create?timespec="0 */2 * * * *"&calls=[{"method":"script.eval","params":{"id":1,"code":"send()"}}]

Dieser Schedule Job ruft alle 2 Minuten die Funktion send() im Skript auf, unabhängig davon, wann die Messwerte eintreffen.

Sollte ein Messwert den Wert null haben, dann ist für diesen nach dem Skriptstart noch kein Wert eingetroffen.

Zur Unterstützung beim Anlegen eines solchen Schedule Job habe ich eine Webseite zusammengestellt: Unterstützung beim anlegen, ändern und entfernen von Schedule Jobs (Zeitplänen)

mrsample

Ich habe ein wenig experimentiert, mit folgendem Ergebnis.

Ich lasse in einem EventHandler (Shelly Plus 2 PM Skript zur Rollladensteuerung) die Quellen von Ereignisses ausgeben.

Diese Quelle liegt in event.info.source.

Bei Steuerung per Cloud ist die Quelle "SHC", bei Steuerung per Skript ist die Quelle "loopback".

Du könntest somit selektiv (event.info.source==="SHC") bspw. event.info.timestamp und event.info.event per print ausgeben lassen und/oder noch besser speichern, um nachträglich zu analysieren, wann welche Aktion per Cloud ausgelöst wurde.

Zum speichern gibt es verschiede Möglichkeiten:

1. lokal in einem Datenfeld
2. lokal in einer Datei (Script Slot)
3. Nachricht an speicherndes Gerät senden

Ich nutze für unser Smart Home einen Raspberry Pi mit u.a. Node-RED und MQTT. Damit lassen sich sehr leicht MQTT Nachrichten vom Shelly empfangen und auf dem RPi in einer Datei speichern.

Ich kenne die Cloud-Anwendung deines betroffenen Shelly nicht. Vielleicht erfolgt eine Kommunikation zwischen Shelly und Cloud in kurzen Abständen, was sich an den timestamps ablesen ließe.

Jedenfalls wäre dies eine Möglichkeit, die per Cloud getriggerten Ereignisse zu erfassen und zu analysieren.

Dies ist nicht mehr als eine Idee, anderen Fehlerursachen als dein Skript - worin wir keinen Fehler finden konnten - auf die Spur zu kommen.

Btw, dieses Erfassen und irgendwo Speichern sollte per separatem Skript, außerhalb des Applikations-Skript implementiert werden.

Ein Schedule Job triggert die eingetragene Methode Zeit gesteuert.

Eine Action triggert die eingetragene Methode Ereignis gesteuert.

Man kann Methoden in Schedule Jobs weit über die Möglichkeiten der Web UI hinaus eintragen.

Ob und wie dies in ähnlicher Weise bei Actions gelingt, weiß ich derzeit nicht.

Zitat von mrsample

der Shelly kommuniziert mit der Cloud(das will ich auch nicht deaktivieren),

Auch nicht temporär zum suchen der Fehlerursache?

Edit:

Selbstverständlich können Actions sehr flexibel und kreativ per Skript implementiert werden.

From Web UI:

Cycle switch - At the push of a button, the sequence is: Ch1-ON Ch2-OFF, Ch1-OFF Ch2-ON, Ch1 & Ch2 ON, Ch1 & Ch2 OFF.

This mode can only be selected if input mode = Button.

If you provide a schematic of your current system, someone may be able to give you a qualified answer.

Noch'n Tipp

Man kann eine Methode vor der Verwendung in einem Skript auf Funktion und Syntax testen. Nach erfolgreichem Test ist es relativ einfach, den Methodenaufruf in ein Skript einzubetten.
Zunächst vorbereitend ein Funktionstest per Web Browser. Der Uniform Resource Locator (URL) besitzt die folgende Form:

http://<IP Adresse des Shelly>/rpc/<zusammengesetzter Methodenname>?Schlüssel1=Wert1&Schlüssel2=Wert2&...

(Es gibt Methoden ohne Schlüssel-Wert Paare oder mit nur einem Schlüssel-Wert Paar.)

Der zusammengesetzte Methodenname ist case insensitiv, d.h. es wird nicht zwischen Groß- und Kleinschreibung unterschieden. Switch.Set ist also gleichbedeutend mit switch.set oder Switch.set oder switch.Set.

Werte können Zahlen, Wahrheitswerte (beide ohne Anführungszeichen) oder Zeichenketten (Strings, in Anführungszeichen) sein.

Bei Erfolg des Funktionstests kann dies in ein Skript überführt werden:

1. Aktor, Sensor ist lokal, also auf dem Gerät, auf welchem das Skript arbeitet.
   Für RPC Aufrufe steht die Funktion Shelly.call(...) zur Verfügung, welche die Methode auf demselben Shelly aufruft.
   Shelly.call(<zusammengesetzter Methodenname>, {Schlüssel1:Wert1, Schlüssel2:Wert2, ...}, callback Funktion);
   Am einfachsten ist es, die callback Funktion vorher zu schreiben (zu definieren) und den Namen im Shelly.call() Aufruf einzutragen.
   Der zweite Parameter {Schlüssel1:Wert1, ...} ist ein Objekt im sog. JSON Format (JSON = JacaScript Object Notation).
   JSON Kenntnisse sind hier sehr wichtig, sie werden auch außerhalb von JavaScript in verschiedensten Applikationen eingesetzt.
2. Aktor, Sensor ist remote, also auf einem anderen Gerät als das Skript.
   Bei Erfolg kann der getestete URL in das Skript kopiert werden.
   Auch hier ist Shelly.call(...) zu nutzen, aber mit der Methode HTTP.Get und dem Schlüssel "url".
   Shelly.call("HTTP.Get", {url: 'http://<IP Adresse des Shelly>/rpc/<zusammengesetzter Methodenname>?Schlüssel1=Wert1&Schlüssel2=Wert2&...'}, callback Funktion);
   Ich setze den url Wert in Hochkomma (single quote), Zeichenketten (Strings) im url Wert dann in Anführungszeichen (double quote).

Eine callback Funktion ist nicht mit jeder Methode zwingend erforderlich, sie ist aber optional immer möglich und kann für Fehlerfälle bzw. Antworten des (remote) Systems genutzt werden.

Angenommen, man will einen Verbraucher an Ausgang 0 einschalten, hier mal ohne callback Funktion.

1. lokal
   Shelly.call("Switch.Set", {id:0, on:true});
2. remote
   Shelly.call("HTTP.Get", {url: 'http://<IP Adresse des remote Shelly>/rpc/Switch.Set?id=0&on=true'});

Falls MQTT zur Kommunikation eingesetzt wird, gelingt dies völlig anders.

Hierfür gibt es die Skript Funktionen MQTT.publish() und MQTT.subscribe().
Dies beschreibe ich aber hier nicht, damit es nicht zu lang wird.

Edit:

Diese Beschreibung kann als Versuch gewertet werden, gegen die Skriptphobie zu wirken.

Du kannst auch für die callback Funktion eine benannte (mit Namen versehene) Funktion verwenden. Das kann die Übersichtlichkeit eines Skripts verbessern.

function handleEvent(event) {
  if(event.name==="input"){
    let id = event.info.id;
    // Anweisungen, die für alle Tasten vor deren Unterscheidung gelten sollen.
    switch(id) { // Fallunterscheidung nach der Tasten Id, 0 bis 3
      case 0:
        // Anweisungen zu Taste 0
        break;
      case 1:
        // Anweisungen zu Taste 1
        break;
      case 2:
        // Anweisungen zu Taste 2
        break;
      case 3:
        // Anweisungen zu Taste 3
        break; // hier nicht erforderlich, stört aber auch nicht
    }
    // Anweisungen, die für alle Tasten nach deren spezifischen Behandlungen (s. case Id) gelten sollen
  }
}

Shelly.addEventHandler(handleEvent);

Shelly Script bzw. mJS ist eine Untermenge von JavaScript mit zusätzlichem API (Application Programming Interface).

Die API beinhaltet die in der Shelly Dokumentation beschriebenen RPC Methoden (Remote Procedure Call), welche u.a. per HTTP und in einem Skript per Shelly.call(Methode, Parameter, callback) aufgerufen werden können.

Zum erstellen oder anpassen eines Skript solltest du dich deshalb auch mit JavaScript beschäftigen.

Eine brauchbare Quelle (Tutorial und Referenz zum Nachschlage) hierfür ist w3schools: https://www.w3schools.com/

Zitat von searge

… aber wie selektiere ich nun den Inputs. wo, an welcher Stelle ergänze ich input:2 bzw. id:2

Wenn du im Skript bspw. alle 4 Tasten unterschiedlich nutzen willst, kannst du eine Fallunterscheidung verwenden.

Weil die Event Informationen redundant sind, brauchst du hier den Komponentennamen nicht, es genügt deren Id, wenn zuvor der Name auf "input" geprüft wird.

Shelly.addEventHandler(
  function (event) {
    if(event.name==="input"){
      let id = event.info.id;
      // Anweisungen, die für alle Tasten vor deren Unterscheidung gelten sollen.
      switch(id) { // Fallunterscheidung nach der Tasten Id, 0 bis 3
        case 0:
            // Anweisungen zu Taste 0
            break;
        case 1:
            // Anweisungen zu Taste 1
            break;
        case 2:
            // Anweisungen zu Taste 2
            break;
        case 3:
            // Anweisungen zu Taste 3
            break; // hier nicht erforderlich, stört aber auch nicht
      }
      // Anweisungen, die für alle Tasten nach deren spezifischen Behandlungen (s. case Id) gelten sollen
    }
  }
);

Kleiner Hinweis:

Ich nutze nicht selten bei englischsprachigen Begriffen und Abkürzungen mal dieses mal jenes Geschlecht.

API mit I = Interface kann als das Interface oder als die Schnittstelle gedacht werden, entsprechend das API oder die API.

Edit:

Zur Sprache Shelly Script kenne ich kein Tutorial. Dasjenige in der Shelly Dokumentation ist ausschließlich zur Handhabung von Skripten geeignet, nicht zum kennenlernen der Sprache.

Auch kenne ich keine JavaScript Einführung, die außerhalb von Webseiten angesiedelt ist.

Da muss man halt durch, wobei die Kenntnis einer C ähnlichen Sprache nützlich ist.

Abhängig von der Umgebung (Weglänge, Position des Blu Motion, übliche Laufwege), könnte vielleicht ein zusätzlicher (Blu) Motion in Verbindung mit einem Skript helfen.

Der erste Motion sendet eine Nachricht an den Plus 1 bzw. Skript.

Das Skript verzögert das Einschalten (Wartedauer).

Wenn der zweite Motion innerhalb der Wartedauer eine Nachricht sendet, unterbleibt das Einschalten.

Andernfalls schaltet das Skript nach Ablauf der Wartezeit ein, weil die Person sich vermutlich noch im Bereich des ersten Motion aufhält.

Hierfür ist eine gute Abstimmung und Platzierung der Motion zielführend, was selbstverständlich nicht in jeder Umgebung möglich ist.

Oder 89new experimentiert mit einem Motion ohne Blu.

Die Id steckt in event.info.

Shelly.addEventHandler(
  function (event) {
    if(event.name==="input"){
      let id = event.info.id;
      // Nun kannst du die gewünschte id selektieren.
      // ...
    }
  }
} 

So etwas kannst du selbst herausfinden, indem du event per print() ausgeben lässt - weniger Zeilen umfassend per print(JSON.stringify(event)).

Wenn du den Überblick hast und dich bspw. nur für das interessierst, was in event.info steckt, dann print(JSON.stringify(event.info)).

...

Ich verstehe nicht, warum ich immer wieder diesen user_data als Parameter finde, obwohl nichts dafür oder null übergeben wird. Das ist absoluter Unsinn.

Wenn du den Code leicht verbessern willst, nimm dieses stereotype, überflüssige Zeug heraus!

Am Beispiel der Funktion toggleRGBW(ip) gezeigt:

function toggleRGBW(ip) {
   Shelly.call(
       "http.get", {
           url: 'http://' + ip + '/light/0?turn=toggle'
       },
       function (response, error_code, error_message, ud) { // ud wird nicht gebraucht.
       }, // Komma weg!
       null // null bedeutet soviel wie "nichts" oder "ungültig", auch weg!
   );
}

Dann bliebe nur noch ein Skript auf dem Plus 1, welches abhängig von den Nachrichten des Blu Motion erst später schaltet.

Ich kann wegen fehlendem Blu Motion nichts dazu beitragen, weil hierfür die Analyse der Nachrichten erforderlich ist.

Außerdem hat offensichtlich die Blind Time eine andere Wirkung als die von mir angeführte Sleep Time eines Motion.

Im Motion gibt es auch die Blind Time, welche der TE ostfriese mit seinem Beitrag ja in ihrer Wirkung beseitigte.

Das weiß ich mangels Gerät nicht. Suche selbst!

Es ist aber zu erwarten, dass es auch im Blu Motion diese Einstellung gibt.

Im Motion: Sensor Control -> Sleep Time

Alles auf der Web UI. Ich nutze die App fast nie.

walterli

Mal unabhängig von deiner sonstigen Ausstattung.

Du kannst eine Kombination aus Schedule Job und Skript einsetzen. Ich meine damit nicht, dass es keine andere Möglichkeit gibt.

Die System integrierte MQTT Kommunikation ist aber etwas komplex, weil sie, jedenfalls in Shelly der zweiten Generation, eine Peer to Peer Kommunikation nachbildet.

Das Skript braucht folgendes.

1. Einen Eventhandler (callback Funktion) zum entgegennehmen der Messwerte. Diese sind in einer Variablen/Struktur zwischenzuspeichern.
   (Die callback Funktion kann stattdessen per Methode den Status des Shelly oder, was du brauchst, abfragen => noch eine callback Funktion in der ersten callback Funktion.)
2. Eine Funktion, ich nenne sie mal send(), welche die zwischengespeicherten Werte per Aufruf von MQTT.publish(...) sendet. Das Topic kannst du im Rahmen der Syntax beliebig wählen.

Der Schedule Job ruft in festgelegten Abständen die Funktion send() auf.

Somit werden auch dann Werte, die zwischengespeicherten, gesendet, wenn keine neuen hereinkommen.

Habe ich den Anliegen richtig verstanden?

Wenn du weitere Hilfe dazu möchtest, melde dich!

Hast du mal die Sleep Time genutzt?

Aus einem Motion, nicht Motion 2: