Beiträge von eiche

Solches herauszusuchen täte ich allenfalls gegen Gebühr.

Ich habe nie eine CCU genutzt, weiß aber dass Homematic auch eine Node-RED (ich glaube dort heißt es Node-Matic(?)) Installation bereithält.

Damit kann man einen sog. Flow erstellen, der die Daten per MQTT oder HTTP Request erhält. Ob und wie diese auf dem Raspberry Pi in einer Datei abgelegt werden können, entzieht sich meiner Detailkenntnis.

Ich nutze dafür einen RPi, Mosquitto, Node-RED, InfluxDB und Grafana - also kein fertiges System. Damit geht so ziemlich alles.

Für einen Freund habe ich eine persistente Speicherung auf einem Shelly Plus ... per Skript implementiert, welche nach Bedarf (spätestens nach 8 Tagen, aber abhängig von der Abtastrate) per MQTT abgerufen werden kann.

Das habe ich auch dokumentiert.

Es wäre bspw. so möglich, an die Daten zu kommen - zunächst ohne die CCU:

per Web UI -> Scripts -> Script "data" (ist kein Skript, sondern eine Datei) öffnen -> per Copy & Paste die Daten in deine Verarbeitungsanwendung kopieren und schließlich per Homematic eine MQTT Nachricht senden, die die Aufzeichnung neu starten lässt.

Eine Anpassung an das von dir benötigte Datenformat sollte leicht möglich sein.

Was per Homematic dbzgl. ginge, weiß ich naheliegenderweise nicht.

Edit:

Obiger Datentransfer gelingt auch ganz ohne die CCU.

Dazu kann man in der Web UI das Skript stoppen, das Nichtscript "data" löschen, das Skript starten - fertig, denn nun beginnt die Aufzeichnung von vorne.

Dies ist bereits jetzt implementiert.

Für eine Vermarktung ließe ich mir noch bessere Usability einfallen, deren Grundlage ich bereits kenne.

Nö, aber implementieren könnte ich so etwas.

Ok ok - etwas mehr Informationen.

Per Shelly, möglichst Plus 1 oder Plus Uni, den Schließer schalten, was ggf. ein Eingriff in dessen Elektrik erfordert.

Mit dem Starten des Lüftens auch eine Nachricht an den Shelly senden.

Wie diese Nachricht zu gestalten ist, hängt von deinem genaueren Vorhaben und deinem Equipment ab.

Der Shelly kann nach einer gewissen, parametrierbaren Dauer das Schließen einschalten.

Eine einfache Nachricht zwecks einschalten (bzw. auch ausschalten) sieht so aus.

http://<IP Adresse Shelly>/rpc/switch.set?id=0&on=true&toggle_after=1800

Diese sorgt dafür, dass der Shelly den Ausgang einschaltet und nach 30 Minuten umschaltet, hier also aus.

Falls du ausschalten und nach 30 Minuten einschalten lassen willst, ersetze einfach on=true durch on=false!

Zitat von Ralf_H

Solltest Du eine Idee haben wie ich diese Info über WLAN abfragen kann, würde das bereits reichen.

Ich habe dazu einige "Ideen".

Welche dir dazu am besten helfen könnte, hängt stark von der Anwendung ab, mit welcher du die Daten empfangen und verarbeiten lassen willst.

Ein simples Beispiel ist den Status eines Ausgangs per Web Browser und passendem RPC (Remote Procedure Call) anzufordern.

http://<IP Adresse Shelly>/rpc/switch.getstatus?id=0

Falls du mehr über den gesamten Shelly-Status wissen willst, gelingt dies bspw. mit

http://<IP Adresse Shelly>/rpc/shelly.getstatus

Am besten im Edge- oder Firefox-Browser, weil diese die Antwort übersichtlich darstellen. Wie dies Safari tut, weiß ich nicht.

Mein Vorschlag:

Sieh dir mal die beiden Antworten genauer an und gewinne einen Eindruck, was du damit anstellen möchtest.

Danach können wir vielleicht weitersehen.

Es gibt dafür verschiedene Implementationsmöglichkeiten. Am flexibelsten ist hier immer, auch ein Skript zu verwenden.

Ich skizziere mal zwei Varianten, die jeweils ein geeignetes Skript im zusammenwirken mit zwei Schedule Jobs nutzen.

Vatriante 1

Das Skript stellt zwei Funktionen zur Verfügung, ich nenne sie sunset() und sunrise().

Diese werden per zweier Schedule Jobs mit der Methode Script.Eval aufgerufen, der eine Job ruft sunset() auf, der andere sunrise().

Einen EventHandler brauchst du zunächst nicht dazu.

sunset() und sunrise() schalten jeweils "ihre primären" Ausgänge, starten jeweils einen Timer, welcher nach 2000ms eine Funktion abarbeitet, die den anderen Ausgang passend schaltet.

Mit dieser Implementation brauchst du die von dir verdrahtete Rückkopplungen nicht.

Ein geeigneter Schedule Job kann wie folgt angelegt werden:

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

Variante 2

Du kannst selbstverständlich auch die Rückkopplungen zusammen mit einem EventHandler einsetzen.

Der EventHandler reagiert selektiv auf die Änderungen an den Eingängen wie folgt.

Er startet einen Timer, der nach 2000ms den gewünschten Ausgang ausschaltet. Die Wartezeit ist aber nur erforderlich, wenn nicht sofort nach eintreffen des Eingangsänderungs-Ereignisses geschaltet werden soll.

Die beiden Schedule Jobs brauchen dann nicht wie in Variante 1 die Methode Script.Eval sondern die Methode Switch.Set mit der Ausgangs ID und on=true.
Ein solcher Schedule Job kann wie folgt angelegt werden:

http://<IP Adresse Shelly>/rpc/schedule.create?timespec="@sunset * * *"&calls=[{"method":"switch.set","params":{"id":<Ausgangs Id>,"on":true}}]

Das Senden

Bei Variante 1 kannst du per RPC Methode die Daten anfordern und in der callback Funktion senden lassen.

Bei Variante 2 kann der EventHandler die eintreffenden Informationen senden.

In beiden Fällen sollten die Daten mit JSON.stringify(Daten) vorher in einen String umgewandelt werden.

Oder ähnlich, falls dies nicht ganz zu deinem Anliegen passen sollte.

Auch kannst du Daten regelmäßig senden lassen, wozu ein weiterer Schedule Job empfehlenswert ist ,,,

Falls du konkreteres wünschst, empfehle ich zunächst meine Skripteinführung.

Es sollte zumindest deutlich geworden sein, dass dein Anliegen implementierbar ist.

Edit:

Notfalls gelingt dein Vorhaben vermutlich auch ohne Skript und ausschließlich mit vier Schedule Jobs - zwei zum sunrise und zwei zum sunset.

zum sunrise:

Ein Job lässt bei @sunrise Ausgang 0, der andere Job (versuchsweise) bei @sunrise+2s Ausgang 1 schalten.

Damit ist aber noch kein senden von Daten verbunden. Ob dies ohne Skript brauchbar gelingen kann, vermute ich, weiß ich aber derzeit nicht.

Für die beiden @sunset(+2s) Jobs gilt entsprechendes.

Da irrst du dich nicht. Ich habe bisher keine Bootzeit gemessen. Aber das Booten geht sehr flott, schätzungsweise in maximal ca. 10s.

Wechsle den "Fachmann"!

13A bei derart kleinen Kontakten als Dauerstromstärke ist völlig inakzeptabel.

Allenfalls eine kurze Spitzenstromstärke dürfte in solche Regionen aufsteigen.

Und ja, ein solches Bewerben ist mit Vorsicht zu genießen. Das tun andere aber auch ...

Zitat

Wenn der SHELLY diese Last, die deutlich unter der maximal beworbenen Last liegt, nicht für 10 Minuten sicherstellen kann, ist das schwer verständlich.

"deutlich" ist hier Ansichtssache.

Wenn das für dich und vielleicht deinen Fachmann schwer verständlich ist, dann kannst du bzw. könnt ihr hier bei Offenheit und einer gewissen Ausdauer besseres erfahren.

In aller Freundschaft

Du solltest jemanden hinzuziehen, der sich mit elektrischen Dingen auskennt.

Dieser wird sehr schnell erkennen, dass

1. ein Klicken auf ein Relais hinweist, das so klein ist, dass es eine solche Leistung nicht schalten sollte.
2. eine Temperatur von über 90°C auf der Halbleiteroberfläche kritisch ist und den Chip zerstören kann.
3. maximale Werte keine Betriebswerte sein dürfen.

Zitat von Ralf_H

Schreibt die 3EM so was in ein Log, dass über WLAN auslesbar ist?

Wenn das geht, seit bitte so nett und postet den Code, mit dem man des Strom und auch den Betriebszustand auslesen kann.

Ich besitze keinen 3EM um dies zu prüfen.

Du kannst dich aber durch die Dokumentation arbeiten und experimentieren: Doku zum 3EM

Jedenfalls wird es möglich sein, die Daten zu holen - vermutlich werden die Daten im Shelly nicht protokolliert.

Es bleiben folgende Fragen.

1. Was soll mit dem Shelly kommunizieren?
   Cloud (weniger empfehlenswert, aber möglich), übergeordnetes System (ioBroker, Home Assistant, OpenHAB, Node-RED, ...) , MQTT Broker ?
2. Was willst du mit diesen Daten anstellen?
   Nur aktuelle Werte anzeigen? In eine Datei schreiben? In eine Datenbank schreiben? Per Grafik als Zeitfunktion anzeigen?

Zitat von Ralf_H

Es muss sicher gestellt sein, dass die WP die Pumpe sofort einschalten kann.

Da gibt es afaik keine absolute Sicherheit, weil der Shelly per Kommunikation (Browser, Cloud, App -> Shelly) auch ausgeschaltet werden kann und afaik die Firmware keine Möglichkeit bietet, dies zu verhindern. Deshalb auch die Geräte-Empfehlungen von apreick.

Zitat von Ralf_H

Wie lange dauert es, wenn die Shelly Plus Plug S an 230V gelegt wird (Pumpe wurde von WP eingeschaltet) bis die Shelly über das WLAN Daten liefern kann?

Der Shelly sollte ca. 1 bis 2 Minuten nach dem Reboot Daten liefern (können). In einem Skript ist dies der Fall, per WLAN Übertragung ist das Gleiche zu erwarten.

Hannes.st

Vergiss an dieser Stelle am besten die App. Nimm stattdessen einen Web Browser!

Vorher versuche, dein Endgerät (Notebook, Smartphone, Tablet) per WLAN mit dem Shelly zu verbinden, dessen SSID beginnt mit shelly ...

Dann gib in der Adresszeile des Browsers die Standard Shelly Access Point IP Adresse ein: 192.168.33.1

Dies teilte dir apreick bereits mit, ich versuche nur noch etwas eindeutiger zu beschreiben.

Wenn du ganz sicher bist, dass dein Endgerät mit dem Access Point des Shelly mini verbunden ist UND du im Browser mit der Adresse 192.168.33.1 keine Website vom Shelly erhältst, solltest du einen Factory Reset vornehmen.

Danach das Gleiche noch einmal versuchen - noch immer OHNE diese App!

Falls auch das keinerlei Erfolg bringt, d.h. du im Browser keine Website erhältst, dann kannst du dem Verdacht nachgehen, dass die Shelly mini defekt sind.

Ja, so begann ich im ersten Versuch zu diesem Thread, weil ich bereits mit solchen Schedule Jobs arbeitete.

Da aber "params" nicht wie erwartet funktionierte, und ich nach meiner Erinnerung irgend etwas stattdessen per "config" las oder herausbekam (?), ersetzte ich "params" durch "config".

Es bleibt nach wie vor leicht widersprüchlich, weil bspw. id und enable nach dem RPC von Input.GetConfig in der Response auf der gleichen und einzigen Stufe notiert sind.

{"id":0,"name":null,"type":"switch","enable":true,"invert":false,"factory_reset":true}

Deshalb war das Naheliegende, den "calls" Eintrag so zu gestalten. --- !funktioniert nicht! ---

http://<IP Adresse Shelly>/rpc/Schedule.Create?timespec="@sunrise * * *"&calls=[{"method":"Input.SetConfig","params":{"id":0,"enable":false}}]

Die eigentliche Schwierigkeit besteht darin, die funktionierende Objekt-Struktur bzw. dessen erforderlichen Einträge herauszufinden, da afaik solches nicht in der API-Dokumentation zu finden ist. Dazu hilft nur zielgerichtetes "Trial and Error" - am leichtesten per Skript. Sobald die Transformation der Shelly.call() Parameter in ein HTTP GET gekonnt ist, stellt diese Übertragung kein Problem mehr dar.

Wäre die Antwort von RPC Input.Config bspw. wie folgt, läge die richtige Syntax von Schedule.Create nahe und wäre leichter verständlich.

{"id":0,"config":{"name":null,"type":"switch","enable":true,"invert":false,"factory_reset":true}}

! Obige Response ist nur zwecks Darlegung einer zielführenden Darstellung gedacht, sie kommt so nicht. !

Ich habe wieder etwas dazugelernt bzw. bin in zielführenden Versuchen etwas sicherer geworden.

Deshalb gilt mein Dank dir peru_19, weil du drangeblieben bist.

Nach diesem Beispiel in der Doku kann man es ahnen und in zwei Schritten hin zum Schedule.Create übertragen, allerdings gehört dazu viel Sicherheit im interpretieren der API Dokumentation.

peru_19

Heureka, ich fand die richtige Syntax.

Zuerst habe ich festgestellt, dass ich per Web UI in der Input (0) Konfiguration nachsehen kann.

Hier die funktionierende Syntax:

http://<IP Adresse Shelly>/rpc/Schedule.Create?timespec="@sunrise * * *"&calls=[{"method":"Input.SetConfig","params":{"id":0,"config":{"enable":false}}}]

Auf die Spur dieser Syntax kam ich per Experimente in einem simplen Skript.

Shelly.call("Input.SetConfig", {id:0, config:{enable:false}});

Da es damit funktionierte, brauchte ich diese Parameterstruktur nur auf den Schedule Job zu übertragen - in JSON, die keys in Anführungszeichen.

Im nachhinein betrachtet ist es auch folgerichtig.

Zitat von peru_19

'http://192.168.1.125/rpc/Input.SetConfig?id=0&config={"enable":false}'

id=0&config={"enable":false} sind die Parameter der Methode Input.SetConfig.

Die Parameter werden im Schedule Job per "params"-Objekt (bzw. Struktur) festgelegt.

Somit lautet der einzige call: {"method":"Input.SetConfig","params":{"id":0,"config":{"enable":false}}}

Zur Freigabe des Input (0) lautet dann der call entsprechend: {"method":"Input.SetConfig","params":{"id":0,"config":{"enable":true}}}

Mit der aktuellen Firmware 1.2.2 lässt sich per Web UI, ohne Fehlerhinweis, der timespec Eintrag mit Klicks ... festlegen.

Damit ist es leicht, sunrise und sunset statt alle 15 Minuten einzustellen.

Vielleicht interessiert dich in diesem Zusammenhang mein Artikel Mächtige Schedule Jobs, den ich vorhin überarbeitete.

peru_19

Ich bin gespannt auf deine Erkenntnisse.

Ich bin derzeit für voraussichtlich Wochen unterwegs und kann nicht mal eben einen Shelly zum testen greifen. Nur meine laufenden Shelly kann ich per VPN erreichen und damit ein wenig experimentieren. Da ich nun keinen Schalter betätigen kann (habe es versäumt, hierfür einen fernbedienbaren Shelly als Taster an einen anderen Shelly zu klemmen ), kann ich letztlich derzeit die Funktionalität des Schedule Jobs nicht testen.

Somit wünsche ich dir viel Ausdauer und Kreativität. Ich werde interessiert deine Berichte lesen.

Edit:

Zitat von peru_19

"data": "shos_rpc_inst.c:230 Input.SetConfig via loopback "

Ich nutze die Diagnostics Protokolle sehr selten und bin in deren Interpretation nicht standfest.

"loopback" begegnete mir bisher im Zusammenhang von Skripten, die einen RPC auslösten.

Wenn diese Quelle auch für Schedule Jobs gilt, ist das bedauerlich, weil nicht hinreichend differenzierend.

Du wirst vermutlich bessere Möglichkeiten haben, dies genauer zu prüfen ...

In diesem Sinne - viel Erfolg!

Zitat von DIYROLLY

Evtl. möchte der TE ja nur ein Tor für ne Katze öffnen/schließen

Jo, Präzision in der Status Quo Beschreibung ist offenbar recht selten.

Zitat von DIYROLLY

was passiert wenn der sich mal "aufhängt" oder nen Reset gemacht hat?

Unabhängig davon, dass Hardware zwecks sicherheitsrelevanter Abschaltungen immer redundant zweckmäßig bis erforderlich sind, gibt es Möglichkeiten solche Situationen zu berücksichtigen.

Beispiel: Nur zur Verdeutlichung, ggf. zweckmäßige Erweiterungen habe ich nur erwähnt.

Es gibt einen Schedule Job, der im Sekundentakt den Antrieb ausschaltet und zeitgleich eine Skriptfunktion f() aufruft.

Steht das Skript (abgebrochen ...), dann läuft der Aufruf von f() in's Leere.

Arbeitet das Skript, kann f() den Antrieb einschalten, um dem Ausschalten entgegenzuwirken. Evtl. kann per Elektronik mit Integrierglied das Ausschalten analog geringfügig verzögert werden.

Das endgültige Ausschalten geschieht somit automatisch, wenn f() nicht mehr einschaltet, weil bspw. das Erreichen einer Endposition erkannt wurde.

Auf eine solche Weise ist auch mehr Sicherheit eingebaut, die rein softwaretechnisch realisiert ist.

Falls der Shelly hängt, d.h. nicht regulär (ohne Skriptlauf) arbeitet, kann ein Hardware basierter Watchdog ergänzt werden, der von einem zweiten Ausgang (Shelly Plus 2) regelmäßig "gefüttert" wird.

Für Letzteres ist ein weiterer Schedule Job geeignet.

Es gibt also durchaus einige Möglichkeiten für Sicherheitsaspekte, die zumindest teilweise per Software abgedeckt werden können.

Noch zum Reset: Das kann superleicht konfiguriert werden, indem der Shelly den Ausgang zum Antrieb nach Reset auf OFF stellt.

Nachtrag:

Zitat von DIYROLLY

Ich habe den UNI gar nicht erwähnt weil das Risiko weiter durch Nutzung von Wlan steigt.

Das tut es nicht, wenn man den Shelly Plus Uni autark macht, wozu Schedule Jobs, Skript und Zusatzhardware geeignet sind.

Edit:

Btw, ein alter Analog-Timer wie der 555 sollte vermutlich als retriggerbarer Hardware-Watchdog geeignet sein. Dessen Einsatz liegt bei mir Jahrzehnte zurück, weshalb ich nicht ad hoc mit einer Schaltung dienen kann - und sicher auch nicht muss.

Edit 2:

Vielleicht tut es bereits eine digitale Schaltung mit CMOS-IC und Schmitt-Trigger Eingängen + Integrierglied - nur mal so.

Was DIYROLLY schreibt, kann ich nur bestätigen, insbesondere zu einer Torsteuerung - mit einem Rollladen wäre es vermutlich ein wenig weniger kritisch.

Mir ging/geht es ausschließlich um eine Machbarkeit.

peru_19

Die Angabe unter Schedules "... Every 15 Minutes. Every Hours ..." zeigt, dass du im timespec nicht @sunrise verwendet hast, sondern etwas wie "0 */15 * * * *".

Jetzt gelesen, dass du das obige bereits erwähnt hast.

Ansonsten sollte der Schedule Job wie beabsichtigt arbeiten, wenn er enabled ist.

Zitat von peru_19

'http://192.168.1.125/rpc/Input.SetConfig?id=0&config={"enable":false}'

Das ist genau der gleiche RPC wie er auch im Schedule Job eingebaut ist, nur ohne Zeitsteuerung.

Ich habe momentan keine Erklärung für dieses von dir beschriebene Verhalten.

Allerdings ist ein solcher Schedule Job mit deinem timespec wenig sinnreich, es sei denn, du enablest irgendwie zwischenzeitlich die Component "input:0".

Gibt es bei deinem Shelly noch etwas, das Input (0) (="input:0") enablen könnte?

Um ziemlich sicher zu sein, sollte jegliche sonstige Kommunikation gesperrt sein. Dazu gehören

• die Cloud
• ein übergeordnetes System (ioBroker, HomeAssistant, OpenHAB, Node-RED, ...
• MQTT

mhrnm

Klar kann man das per Skript lösen, aber vermutlich nicht einstellen.

Prinzip:

Ein Ereignis mit "component":"input:<id>" bei soeben gedrücktem Taster (event.info.state ist true) wird vom EventHandler erfasst, d.h. der Zeitstempel in event.now oder in event.info.ts wird gespeichert - sowohl die id als auch der Zeitstempel, ts1 genannt.

Ein zweites Ereignis mit "component":"input:<id>" bei soeben losgelassenem Taster (event.info.state ist false) wird erfasst und dessen id mit der gespeicherten id verglichen. Bei Übereinstimmung der Id wird der neue Zeitstempel verwendet, ts2 genannt.

Nur wenn ts2 - ts1 > deine definierte Dauer ist, wird die gewünschte Aktion per RPC, im Skript per Shelly.call(<Methodenname>, {id:<id Wert>, ...}) ausgelöst.

Wenn du Konkreteres brauchst, kannst du zumindest meine Skripteinführung verarbeitend lesen ... dann können wir weitersehen.

Edit:

Wenn es per Skript einstellbar sein sollte, braucht man dafür kein Skript.

Dann wäre es auch per RPC einstellbar, etwa so:

http://<IP Adresse Shelly>/rpc/input.setconfig?id=<Button Id>&config=...

Ich sah per Methode Input.GetConfig nach. Da ist nichts zur Dauer für Longpush zu sehen.

Daraus folgere ich (vorsichtig), dass diese Einstellung seitens der aktuellen Firmware (Version 1.2.2) nicht vorgesehen ist.

DerSchroeder

Ich habe keinen Shelly Plus Uni, aber Erfahrungen mit anderen Shelly der zweiten Generation - und insbesondere mit Skripten.

Zitat von DerSchroeder

Der Antrieb gibt via Poti die aktuelle Position aus, welche nicht überfahren werden darf.

1. Korrektur: Der Antrieb liefert via Spannung an einem (herkömmlichen) Potentiometerabgriff die aktuelle Position. Richtig?
2. Zu "welche nicht überfahren werden darf": Was darf diese Position nicht überfahren - ein Auto?
   Vermutlich meinst du Endpositionen, die mangels Endschalter analog festzulegen sind.
   Habe ich richtig interpretiert?

Wenn ja, lässt sich das Schalten des Antriebes per Skript implementieren.

Aber Vorsicht: Im Programmieren ist Präzision gefordert.

Für Sicherheitseinrichtungen musst du dich, insbesondere wegen Eigenbau, selbst verantwortlich fühlen.