Beiträge von eiche

Gunter Nerd

Schade, du kannst oder willst offensichtlich nicht sorgfältig lesen.

Wenn du das nämlich tätest, würdest du spätestens nach meinen Reaktionen erkennen müssen, dass ich kein Skript angeboten habe.

Ich habe vermutlich mehr Zeit deinem Thema geopfert als du selbst.

Darüber mal nachzudenken, wäre angemessen.

Und deinen Sarkasmus kannst du dir schenken. Er ist nicht angebracht und destruktiv.

Ein derart impertinentes und ignorantes Verhalten ist mir hier noch nicht begegnet.

Edit:

Falls du bereit bist, trotz unserer Differenzen, konstruktiv an deinem Thema und mit möglichen, auch alternativen Implementationen zu experimentieren, können wir hoffentlich diese Differenzen hinter uns lassen. Eine fertige Lösung auf die Schnelle wirst du vermutlich mit der derzeitig aktuellen Firmware und Cloud nicht erhalten. Falls doch, darfst du gerne mein Statement ignorieren.

Von meinen 5 im Einsatz befindlichen TRV fallen immer mal wieder welche aus, d.h. ich erreiche sie im Netz nicht mehr und sie sind auch nach Akku aufladen und Resets nicht erreichbar.
Ich muss immer wieder mal experimentieren, was mich inzwischen sehr stört.

Deshalb steige ich auf Shelly Plus 1 mit AddOn + Ventilantrieb und insbesondere selbst erstelltem Skript um.
Diese Kombination arbeitet erheblich zuverlässiger und ähnlich autark wie die TRV.

Zitat von Harald Ott

Das System Shelly läuft eigentlich ganz gut. Bis auf die Fühler.

Für die Fühler kann "das System Shelly" nichts - bis auf die Empfehlung, DS18B20 einzusetzen. Für die Fühler ist letztlich der Anwender zuständig.
Dein Einsatz erscheint auch leicht grenzwertig bei solch hohen Temperaturen - mit allen Einschränkungen der von DIYROLLY angemerkten fakes.

Du verwendest offensichtlich die Cloud (Stichwort Szenen), ich weiß allerdings nicht, zu welchem Zweck.

Wenn du damit etwas regeln lässt, kann ich nur davon abraten, die Cloud zu verwenden, wenn diese Regelung wichtig ist.

Wie ich bereits an anderen Stellen anmerkte, ist die Cloud nicht hinreichend funktionssicher.

Für wichtige Regelungen sollte etwas Lokales eingesetzt werden, damit solche Regelungen auch bei Ausfall der Cloud oder des Internetzugangs noch funktionieren.

Das ist irgendwie logisch.

Es bleibt die Frage, warum diese Sensoren in solch kurzen Abständen ausfallen.

Auszug aus dem Datenblatt: Measures Temperatures from -55°C to +125°C

Liegen deine zu messenden Temperaturen oberhalb 125°C?

Nach deiner Eröffnunng eher nicht.

Hm ...

Harald Ott

Ich nutze zwar keine Szenen (aus guten Gründen), eine Notwendigkeit der Umkonfiguration bei einem Sensortausch kann ich aber nicht erkennen.

Die Komponente ist jeweils unabhängig vom Sensorexemplar "temperature:100" bzw. "temperature:<Sensor Id>", die Id Werte der am AddOn angeschlossenen Sensoren beginnen mit 100, dann101, ...

In der grafischen Oberfläche heißen diese Temperature (100) ...

Eine Sensor interne Id, mit welcher die Firmware den jeweiligen Sensor erkennt, sollte in den Anwendungen keine Rolle spielen, da die Firmware die o.a. Id (100, ...) bereitstellt.

Edit:

Ich musste bisher keinen solchen Sensor tauschen. Ich weiß somit nicht, ob mit einem Tausch die Firmware eine neue Id vergibt. Evtl. kann hier ein solches Problem vorliegen, wenn mehrere Sensoren an einem AddOn angeschlossen sind.

Ich habe diesen Thread als Anlass genommen, eine Einführung in Shelly Scripting zu erstellen.

Diese Einführung ist hier zu finden: Skripteinführung - Teil 1

Warum habe ich dies in Angriff genommen?

Ich sehe immer wieder, dass hier die Cloud zusammen mit Szenen und sogar für Temperaturregelungen bevorzugt eingesetzt wird.

Ich kann davor nur warnen.

Wenn, durch welche Ereignisse auch immer, die Cloud oder gar der Internetzugang ausfällt, funktionieren solche Szenen und Regelungen nicht mehr.

Deshalb halte ich es für zweckmäßig, die Cloud als zusätzliche Option zu verwenden, wann man dies mag - aber keinesfalls als obligatorischen Bestandteil.

Alles, was ein Shelly eigenständig abarbeiten kann, ist deutlich funktionssicherer als eine Cloud-Lösung und sogar funktionssicherer als eine Implementation in einem übergeordneten lokalen System.

Dies halte ich für triftige Grunde, im Zweifelsfall und bei hinreichendem Engagement auf Skript-Implementationen zu setzen.

Auch bei Einsatz eines übergeordneten Systems ist eine zumindest teilweise Autarkie eines Shelly für dieses System entlastend. Skripte können auch adaptierend eingesetzt werden, um Nachrichten an das übergeordnete System "mundgerecht" bereitzustellen.

Der bekannte Nachteil besteht in der Zweckdienlichkeit, zumindest grundlegende Kenntnisse im Shelly Scripting zu besitzen.

Falls sich jemand meine bisher erstellte Einführung "antun" sollte und dabei Verständnisfragen auftreten, bin ich gerne bereit, mich auf solche Fragen einzulassen.

Es kann aber auch sein, dass ich dann auf andere Dokumentationen verweisen muss.

Aah, das fällt unter meinen möglichen Fehlerpunkt 6.

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);