Beiträge von eiche

TomyH

1. Zum Hit URL: Wenn die Nachricht an deselben Shelly gelingen soll, musst du dafür localhost verwenden, also 127.0.0.1
   
2. Hier die Anfangsversion für den Eventhandler zur Erfassung des digitalen Eingangs (input:100)
   

Shelly.addEventHandler(
  function(e) {
    //print(JSON.stringify(e));
    let comp = e.info.component;
    if(comp===undefined) return;
    if (comp==="input:100") {
      print("Digital Input: ", e.info.state);
      //In e.info.state liegt der Eingangszustand false|true.
      // ...
    }
  }
);

Edit:

Nun gibt es prinzipiell zwei Implementationen.

1. Du verwendest den Eventhandler (s.o.) und speicherst immer den aktuellen Zustand von e.info.state in einer globalen Variablen.
   Wenn bedingt geschaltet werden soll, fragst du dafür den Wert dieser Variablen ab.
2. Du fragst an passender Stelle den Status von input:100 ab und lässt bedingt schalten.

Ich favorisiere eindeutig Variante 1. Code kann bei Bedarf folgen ...

Edit 1:

Variante 2 ist aufwändiger, weil hierfür ein RPC Aufruf erforderlich ist und diese Aufrufe asynchron ablaufen. D.h. dass dir der Status nicht unmittelbar zur Verfügung steht.

Ich habe mal das Shelly Relais mit GND und Digital Input verbunden und lasse schalten.

Damit liefert die Abfrage .../rpc/input.getstatus?id=100 die passenden Werte.

Nun werde ich mal den Eventhandler erstellen und prüfen.

Bis später ...

Ja klar, und der Input muss auch eingerichtet/angemeldet werden am Shelly ...

*vor den Kopf schlag*

TomyH

nachdenk ...

TomyH

Ich nutze einen Plus 1 mit AddOn, aber mit einem DHT22 Sensor und keinem digitalen Input.

Meine Abfrage liefert ebenfalls

{"id":0,"state":false}

was nicht verwunderlich ist. Somit vermute ich, dass dein Anschluss nicht korrekt ist oder dein Schalter nicht arbeitet.

Prüfe bitte mal mit einem Durchgangsprüfer (Ohmmeter), ob dein Schalter wirklich schaltet!

Ich hatte Hilfe zur Selbsthilfe versucht und zu wenig Zeit für mehr Aufwand.

Ansonsten ist es spannend, wie der TE mit einem Skript zurechtkommt.

Ganz ohne Kenntnisse dbzgl. ist er anscheinend nicht.

TomyH

Die Dokumentation von Allterco Robotics ist vergleichsweise umfang- und aufschlussreich.

Zum Input eines AddOn: https://shelly-api-docs.shelly.cloud/gen2/Component…tstatus-example

Btw, die schedule jobs sind per RPC sehr flexibel nutzbar, falls du über die in der WebUI angebotenen Möglichkeiten hinausgehen möchtest.

Dazu https://shelly-api-docs.shelly.cloud/gen2/Component…rvices/Schedule

Woll-E

zwecks Entwirrung folgender Kommentar meinerseits:

Deine Klemmenbezeichnungen 0 und 1 sind irreführend, sie sollten I (Input) und O (Output) lauten.

Der TE besitzt afaik keinen separaten Druckschalter.

DarkSoul

Ich als "Skript Junkie" lege Wert auf hohe Funktionssicherheit.

agent47

Ab Firmware 1.0 steht nach der Doku die Date Klasse zur Verfügung.

Ich habe bisher nicht damit experimentiert.

In der Doku findest du den Hinweis unter

https://shelly-api-docs.shelly.cloud/gen2/Scripts/S…anguageFeatures

Dort geht es per Linktext Espruino zu https://www.espruino.com/Reference#Date.

Vielleicht genügt die Performance für hinreichend genaue Daten.

Viel Erfolg

dewaldo

Mir gefällt prinzipiell dein Entwurf, trotzdem habe ich zwei kleine Einwände.

Vorteile deines Entwurfs:

1. Ein vorhandenes Gerät kann weiterhin für den gewünschten Zweck genutzt werden.
2. Es muss ausschließlich konfiguriert werden, Programmierung ist nicht erforderlich.

Nachteile deines Entwurfs:

1. Die beiden Mikrocontroller müssen für diese Funktionalität kommunizieren, das Kommunikationsmedium könnte aber ausfallen.
2. Es sind zwei Geräte erforderlich, wo ein geeignetes genügen würde - etwas höherer Energieverbrauch.

Aus technischer Sicht würde ich den Einsatz eines Gerätes (bspw. Shelly Plus 1PM) bevorzugen und diesem ein kleines Skript einverleiben.

Ein solches Skript ist nicht aufwändig, muss allerdings erstellt werden. Vielleicht gibt es dafür auch eine Vorlage.

Skriptidee:

Das Signal am Switch-Eingang des Shelly ändert sich -> Ereignis -> der Eventhandler registriert dies und arbeitet wie folgt:

Bei ON wird der Zustand einer Error-Variablen geprüft.

Beinhaltet diese true, geschieht nichts weiter, weil die Pumpe vorher zu lange lief.

Andernfalls wird der Ausgang auf ON geschaltet und ein Timer (für 20 Minuten) gestartet,

Bei OFF wird der gestartete Timer beendet, der Ausgang auf OFF geschaltet und Error nicht verändert..

Mit Ablauf des Timers wird die Variable Error auf true gesetzt und der Ausgang auf OFF geschaltet.

Um das Ganze ausfallsicher zu gestalten, wird mit jeder Änderung von Error dessen Wert in den nichtflüchtigen Speicher (NVS) kopiert - hier per KVS.

Dieser Wert wird mit jedem Skriptstart, regulär nach einem Stromausfall, vom NVS in die Variable Error kopiert.

Ich wäre evtl. bereit, ein solches Skript zu erstellen, genügend Muße meinerseits dafür vorausgesetzt.

Mein Motiv dafür könnte ein Einsatz für meine Zisternenpumpe sein.

Edit:

Eine Kommunikationsschnittstelle zum rücksetzen von Error auf false ist vorteilhaft und implementierbar.

Auch die Dauer für den Timer ist per KVS konfigurierbar.

Edit2:

Statt des Switch-Eingangsereignisses sollte hier ein Ereignis der Leistungsänderung genutzt werden, ich vergaß dies vorübergehend.

Steigt diese Leistung über einen festgelegten Schwellwert, wird der Timer gestartet.

Fällt diese Leistung unter einen festgelegten Schwellwert, wird der laufende Timer beendet.

Ansonsten wie oben.

Die Schwellwerte können bei Bedarf ebenfalls per KVS konfigurierbar gemacht werden.

DarkSoul

An einer Tauchpumpe würde ich kein Elektrikgehäuse ohne Not öffnen ...

Zusätzlich wäre es erforderlich, die Werte vom Drucksensor zu analysieren, um eine zielführende Schadensbegrenzung erreichen zu können.

Genau genommen sind für einen solchen Fall zwei Druckmessstellen jeweils an den Schlauchenden zielführend.

Diesen Aufwand will der TE vermutlich nicht treiben.

Die vom TE genutzte Transformation Schaltzustand -> Leistungsentnahme erscheint mir für eine Implementation mit geringem Aufwand durchaus geeignet.

Garten

Da du eine Schadensminderung durch bspw. geplatzten Schlauch anstrebst, erscheint es mir unangemessen, hierfür die Cloud einzusetzen (Szene).

Eine solche Schadensminderungsfunktion sollte möglichst direkt auf dem überwachenden Gerät implementiert werden.

Hierzu empfehle ich eine Shelly der zweiten Generation (Zusatz "Plus", bspw. Shelly Plus 1 PM) und ein Skript.

Deren aktuelle Firmware arbeitet derzeit sehr stabil, auch mit Skripten.

Was du letztlich bevorzugst, ist selbstverständlich alleine deine Angelegenheit.

...

Folgende Fragen/Anmerkungen/Unklarheiten:

Vorweg - ich kann kein Python, bin Anhänger von C und C++.

Ich nutze erstmalig PyCharm (community edition).

1. Ich bevorzuge, wenn möglich, die Speicherung auf meinem NAS.
   Das scheint hier Probleme zu verursachen. Somit speichere ich nun auf meinem Notebook (Windows 10).
2. Ich lege ein Projekt an.
   Ob dies erforderlich ist, habe ich bisher nicht ergründen können.
3. Ich erstelle eine Hallo Welt JavaScript Datei (scratch file).
4. Ich binde in das angelegte Projekt ein dein Python Programm "RunOnShelly.py".

Nun erwarte ich irgendeine Konfiguration bzw. Quellcode-Anpassung zum Ziel-Shelly, finde dazu aber nichts.

Ein mutiger Klick auf den Run-Button (grüner Pfeil/Dreieck) ergibt eine Fehlermeldung

Zitat

import requests

ModuleNotFoundError: No module named 'requests'

Nun weiß ich nicht weiter.

Was kann ich?

1. Ich kann zumeist nach einigem Durchärgern mit einer IDE umgehen.
2. Ich kann eine JavaScript Datei erstellen, die auf einem ESP 32 Shelly ausführbar/interpretierbar ist.
3. Ich kann Fehlersuchen in mir vertrauten Umgebungen/Programmcodes durchführen.

Was kann ich nicht?

1. Ich kann nicht erraten, welche Schritte in einer mir nicht vertrauten Umgebung zum Erfolg führen.
2. Ich kann bisher - und will dies auch nicht - Code auf Verteilungsplattformen wie GitHub veröffentlichen. Dies tue ich lieber ohne irgendeine Verpflichtung auf meinen Websites.

Welche Schritte sind durchzuführen, damit

1. ein Skript auf einen Ziel-Shelly transferiert wird,
2. das Skript dort ausgeführt wird und
3. die Ausgaben in der IDE erscheinen?

Diese Fragen sind inzwischen geringfügig veraltet. Ich lasse sie trotzdem stehen, weil sie mir im Vorfeld noch nicht als hinreichend behandelt erscheinen.

Ich habe inzwischen die Parametereinstellungen zu deinem Python-Programm gefunden.

Was bedeuten bzw. bewirken die letzten drei Parameter "1 0 1"?

Die o.a. Fehlermeldung bleibt trotz passender Parametereinträge. Vermutlich fehlt mir eine passende Bibliotheksumgebung.

Gruß

eiche

Edit:

Ich verwende sehr ungerne vorgefertigte Projekt-Pfade und tat dies in diesem Projekt auch nicht.

Also ...

zunächst einmal vielen Dank für deine Informationen.

Ich bin dran, dieses Verfahren zu testen, muss aber noch learning by doing praktizieren.

Falls präzisierbare Fragen meinerseits auftauchen, werde ich diese hier posten.

Bisher kam ich mit dem Editor im Browser gut zurecht, erkenne aber an, dass eine IDE beim coden unterstützt.

Dass ich ein Anhänger von Skripten der ESP 32 bin, dürfte bekannt sein.

Rainer Meyer

Vorweg: Ich habe derzeit keinerlei PV-Anlage.

Es bleibt die Frage, wie du feststellen lassen kannst, wenn die kleine PV-Anlage einspeist.

Ist daran ständig ein Verbraucher angeschlossen, über den du die Stromstärke bzw. Leistung (richtungsabhängig) messen kannst?

Dann bliebe die Frage nach der Messempfindlichkeit eines EM.

Ansonsten erscheint mir der Einwand von Schubbie sehr begründet.

Ich kann dir nur eine Zusammenfassung von bereits Angeführtem empfehlen + kleine Ergänzung.

Nimm eine Raspberry Pi - mindestens Gen. 2 - und installiere dort einen MQTT Broker.

Dann hast du dieses eh doofe Cloud Gedöns nicht.

Wo der Raspberry Pi laufen soll, überlegst du dir selbst.

Mit einer VPN gelingt die Verbindung.

Die Installation eines Brokers wie Mosquitto ist sehr einfach.

Wenn du dir das nicht zutraust, kennst du vielleicht jemanden, der das mal schnell für dich erledigt.

Nebenbei könnte der Raspberry Pi noch andere Dinge tun.

Von nichts kommt nichts.

hheck

Zitat von hheck

Der link von Loetauge zeigt, daß man den Shellys auch jedem eine eigene IP verpassen kann, allerdings als Server.

Das bringt insofern nichts, als dann immer noch beide Shellies ihr eigenes WLAN aufspannen.

Zitat von hheck

(never change a winning team )

Nun, so richtig gewinnt dieses dein Team ja eigentlich nicht.

Es wird höchste Zeit, dass du dir einen neuen Router zulegst.

Vermutlich nutzt du DHCP. Da ist der Aufwand, deine Geräte mit einem neuen Router zu verbinden vergleichsweise gering.

Aber auch, wenn du statische IP-Adressen verwendest, ist der Router relativ leicht dafür einzustellen.

Trau dich!

Edit:

Und dein Vorhaben gelingt mit einem ESP32 Shelly per Skript noch leichter und besser.

Ich täte versuchen, dir dabei zu helfen.

hheck

Ich nutze derzeit keine Arduino-Programmierung und komme nicht dazu, deinen Programmcode zu prüfen.

In Zeile 41 steht

Zitat von hheck

if (httpCode > 0) // httpCode will be negative on error

Wenn der Kommentar stimmt, sollte die Bedingung so lauten:

if (httpCode >= 0)

Vielleicht ist dies nicht relevant, ich kenne die möglichen Resultate nicht.

Der Code weist so oder so einige "Unschönheiten" auf, welche das Programm sehr schlecht pflegbar macht.

Es stecken einige "mystische Werte" darin.

Das sind die WLAN SSID der beiden Shellies "shellyem3-3494547B8D61" und "shelly1-349454798D61".

Stattdessen sind besser Konstanten zu setzen.

String ShellyEM3 = "shellyem3-3494547B8D61";
String Shelly1 = "shelly1-349454798D61";

Auch das Finden der gewünschten Daten (suchen nach "power") erscheint sehr umständlich. Stattdessen sollte die String Methode indexOf() verwendet werden.

Ab Zeile 50 in deinem Code etwa so:

const int SearchStart = 400;
int pos = payload.indexOf("power", SearchStart); 
if (pos>=0) {
    String x1 = payload.substring(pos, ...); // Ich kenne die genaue Textstruktur der Antwort nicht. Du magst mal eine solche Antwort posten.
    // verarbeiten
}

Auch ist es hilfreich, zunächst ausschließlich die Kommunikation mit dem EM3 zu testen.

Wenn dies fehlerfrei gelingt, wäre das Gleiche mit dem Shelly1 zu testen, allerdings mit anderem Code.

Im dritten Schritt kann versucht werden, beides zu vereinen.

Mein Problem: Ich kenne die Klasse WifiMulti nicht. Deshalb weiß ich derzeit nicht, wie damit von einem Access Point (AP) auf einen anderen umgeschaltet werden kann.

Vielleicht werde ich dbzgl. mal recherchieren.

Es erscheint auch verwunderlich, dass die Shellies sich nicht mit deinem WLAN verbinden lassen.

Es mag AP geben, mit denen Probleme auftreten können. Ich hatte bisher mit so etwas keine Probleme.

Welchen AP bzw. Router nutzt du?

Ich kann nur empfehlen, die Shellies in das WLAN zu bringen.

Halte die Ohren steif!

hheck

Du zeigst Code und fragst, ob das funktioniert.

Du solltest deinen Code testen, um zu erkennen, ob es so arbeitet, wie du das haben willst.

Deine dann daraus gewonnenen Erkenntnisse hier zu posten, wäre dann konstruktiv.

Wenn du auf diese Weise vorgehst, kann ich dir vielleicht weiterhelfen.

Allerdings erkenne ich bisher nicht die Gründe der von dir festgelegten Voraussetzungen - keine Einbindung der Shellies in ein WLAN.

Es wäre zielführend, wenn du aufzeigst, warum die Shellies nicht in ein WLAN eingebunden werden sollen.

Ich bin nach wie vor zur Mitarbeit bereit.

Kurzer Zwischenbericht

Mein Uhr-Projekt Shelly mit den aktiven, anwendungsbezogenen Schedule Jobs arbeitet nach wie vor seit 2023-06-11 23:00 Uhr ohne ein Reboot durch - Firmware 1.0.0-beta3.

Sollte ich zwischenzeitlich irgendein Problem feststellen, werde ich dies hier berichten.

Solange ich hier nichts schreibe, bin ich entweder verhindert oder (etwas wahrscheinlicher) der Shelly arbeitet stabil und problemfrei durch.

Edit: 2023-06-22, 09:00 Uhr

Der Uhr-Shelly arbeitet nach wie vor seit dem Firmware Update ohne ein Reboot. Darauf arbeiten drei Skripte und fünf Schedule Jobs verlässlich.

Edit: 2023-07-01, 18:50 Uhr

Der betreffende Shelly arbeitet immer noch ohne ein zwischenzeitliches Reboot - Firmware 1.0.0-beta3

Ich schließe nun meine Berichte ab, da nicht mehr damit zu rechnen ist, dass sich das alte Reboot-Problem ereignen wird.

Ich kann dir eine solche Vorgehensweise nicht empfehlen.

1. Die Shellies sollen vermutlich in deinem WLAN erreichbar sein. Das sind sie nicht über diese IP-Adresse.
2. Das Wechseln der AP-Shellies ist aufwändiger und kostet zusätzlich Wartezeit, beides muss zusätzlich implementiert werden.
3. Vermutlich sollen die beteiligten Shellies durchgehend zugreifbar sein. Das ist mit dieser IP-Adresse nicht möglich.

Wenn du das trotz aller Bedenken implementieren willst, solltest du dich mit den dafür vorgesehenen Bibliotheken genauer beschäftigen.

Auch genügt es dann nicht, eine Verbindung in der setup() Funktion herzustellen, da diese ausschließlich beim booten des Mikrocontrollers einmal abgearbeitet wird.

Du musst dann ja regelmäßig zwischen den Shelly-AP wechseln lassen.