Beiträge von eiche

May I write in german?

If you need the measurements on the fly, you may use the internal Access Point of a Shelly 1 PM generation 2+.

But if you want to store the measurents values, I may have a solution for you, based on a script. This script stores many values into its non volatile storage and you may take it to your home for reading this values. Alternatively you may use a MQTT transfer over your smartphones hotspot without replacing the Shelly, if you use a MQTT subscriber at home.

Btw, my solution via script may be used with a smartphone directly reading the stored values. I've created this script for using MQTT, but it may be used without MQTT.

If you are interested in my solution: https://iotig.eichelsdoerfer.net/index.php/loes…r-shelly-script

Ich werde da mangels eigener entsprechender Ausstattung vermutlich nicht weiterhelfen können. Du solltest aber wissen, dass zum eingehen auf dein Anliegen mehr Informationen erforderlich sind. Zumindest wird ein Shelly 3 EM (Name kann sich ändern) der möglichst neuesten Generation zielführend sein. Was den Rest angeht, hängt dies von deiner Ausstattung ab.

1. Welche Leistungen werden von der PV geliefert?
2. Welchen Wechselrichter nutzt du? Wie speist du in dein Hausnetz - einphasig, dreiphasig?
3. Bietet der Wechselrichter eine (standardisierte) Kommunikationsschnittstelle (auch API genannt)?
4. Welchen Speicher hast du oder willst du dir zulegen?
5. Bietet der Speicher eine (standardisierte) Kommunikationsschnittstelle (auch API genannt)?
6. Welche Stromkreise wirst du optional zuschalten wollen/können?
7. Evtl. ist ein Verkabelungsplan erforderlich, um besser verstehen zu können.

Das stimmt, da hatte ich nicht sorgfältig gelesen. Es kann aber sehr ähnlich (invertierend) gelingen, auch wenn ich das so nicht implementieren täte.

1. Plug 1 wird vom W2839 mit Strom versorgt und schaltet seinen Ausgang ein (so konfiguriert). Plug 1 nutzt den Ausschalttimer mit 1800s.
2. Wenn Ausgang von Plug 1 ausgeschaltet wird, sendet dieser eine RPC Nachricht an Plug 2 zum einschalten dessen Ausgangs.
3. Plug 2 schaltet die Verbraucher, bei Bedarf mit Ausschalttimer.

Ich kann derzeit folgendes nicht testen, vermute aber, dass es nicht funktioniert.
Wenn mit Einschalten der Versorgung und dem damit verbundenen Ausschalten des Ausgangs der Timer zum automatischen einschalten getriggert wird, kann damit das Ganze sehr einfach gelöst werden. Für das aktive Zeitfenster bräuchte es dann zwei Schedule Jobs, die in die Konfiguration eingreifen müssten. Job 1 aktiviert den Timer, Job 2 deaktiviert diesen.

Ergänzung zu Flutschi : Das sollte so gelingen.

Mit dem Ausschalten die Aktion zu "Bewegung erkannt" entsprechend aktivieren.

Das schreibt allerdings (wieder einmal) jeweils in den nichtflüchtigen Speicher, erspart aber ein Skript, welches kein Schreiben in den nichtflüchtigen Speicher braucht. Und nach Stromausfall bleibt diese ereignisgesteuerte Konfiguration, was vermutlich eher stören wird.

Noch ein potentieller Nachteil der Aktionenlösung:
Hiermit ist es afaik nicht möglich, eine Zeitverzögerung einzubauen, damit unmittelbar nach dem Ausschalten eine Bewegungserkennung nicht sofort wirkt. Dies gelingt letztlich aber per Skript.

bp4willi

Das ist zweifelsfrei eine passende Antwort auf #17 von Thunder2020 .

Allerdings ist dies eine umständliche Lösung für Leute, die skriptphobisch sind oder die ausschließlich Shelly Plug S nutzen bzw. keine Installation vornehmen wollen.

Zitat von bp4willi

Wie wäre es, wenn ihr die Lichtschaltung nicht über einen Helligkeitssensor aktiviert, sondern über Zeitschwellen zu Sonnenaufgang bzw Sonnenuntergang?

Und dann mit Bewegungsmelder kombiniert.

Das ist auch eine Möglichkeit und vielleicht etwas verlässlicher, nur nicht lokal so genau theoretisch möglich, wie die Helligkeit zu nutzen. Solches ist ja durch anwenden von Schedule Jobs und Skript implementierbar.

Whity

Man darf mich gerne in bspw. 4 Wochen an dieses Projekt erinnern - ggf. via PN. Dann kann ich einen Shelly BLU Motion haben und bin dann auch wieder zu Hause - aus dem Krankenhaus.

Versuch einer Zusammenfassung

1. Das Dosiergerät w2839 besitzt einen Ausgang, der externe Steckdosen aktivieren kann.
   Schaltet dieser Ausgang belastbare 230V, wodurch auch Pumpen geschaltet werden können?
   Oder ist es ein reiner Steuerausgang, wofür intelligente ansteuerbare Steckdosen erforderlich sind?
2. Sobald das Dosiergerät w2839 Steckdosen aktivieren täte, soll ein Shelly Plug S Gen 3 erst nach 30 min diese Steckdosen aktivieren/versorgen.
3. Es liegt bei Bedarf eine Internetverbindung vor - wegen des erforderlichen Zeitservers, der ggf. nicht zwingend dauerhaft mit dem Internet verbunden sein müsste.
   Wie ist der Internetzugriff realisiert? Kann der Router als Zeitserver dienen?

Lösungsansätze

1. Angenommen, das Dosiergerät w2839 kann die volle Versorgung schalten. Dann wird der Plug S damit eingeschaltet und ein Skript gestartet, welches dafür sorgt, dass 30 min später der Plug S Ausgang eingeschaltet wird, falls die Uhrzeit innerhalb der gewünschten Zeitspanne liegt. Dazu braucht der Plug S kurzzeitig innerhalb dieser 30 min einen Zeitserverzugriff.
2. Das Dosiergerät w2839 liefert nur ein Steuersignal zum einschalten von Steckdosen. Dann gelingt die Lösung wie unter 1, aber nicht mit einem Plug S, sondern bspw. mit einem Shelly 1 Gen 3+. Dieser wird dauerhaft versorgt und reagiert via Skript auf die Änderung an seinem Eingang wie oben beschrieben.

Diese Lösungen arbeiten autark. Wenn statt eines Shelly 1 Gen 3+ ein Shelly mit zwei Ausgängen genutzt wird, kann auch der Internetzugang zeitlich passend temporär aktiviert werden.

Oliver Schade

Ein Shelly 1 Gen3+ mit Addon passt leicht in eine ansonsten leere Dose, erst recht dann, wenn diese tief ist.

Ich nutze so etwas zur Regelung meiner Heizkörper. Kleiner keilförmiger Schlitz in den Leerdosendeckel und die Leitung des DS18B20 dort durchführen!

Das Addon sollte automatisch erkannt werden. Der Sensor muss per Konfiguration hinzugefügt werden. Danach kann die Sicherheitsabschaltung leicht per lokaler Aktion erfolgen.

steffda Auch wenn es weh tun sollte ... ... und der Vollständigkeit wegen.

Seitens Shelly ist solches nicht als Standardanwendung vorgesehen und somit bisher nicht konfigurierbar.

Ich habe ähnliches vor längerer Zeit per Skript gelöst und dies hier dokumentiert: Per Bewegungsmelder ausschließlich in ausgeschaltetem Zustand einschalten mit Einschaltdauer, deaktivierbar
Dieses Skript wird hier nicht zum gewünschten Erfolg führen, weil es nicht für die Anwendung eines BLU Motion ausgelegt ist. Es bildet aber eine geeignete Basis und beinhaltet die grundlegende Lösungsidee.

Grund: Per Skript kann die auslösende Quelle weitgehend unterschieden werden. Meine Lösung beinhaltet allerdings einen Shelly Motion der Generation 1 und einen Shelly Plus 1. Wie die Helligkeit hier einfließen kann, weiß ich nicht sicher, das sollte aber auf einem BLU Motion konfigurierbar sein.

Die von mir zunächst theoretisch angebotene Lösung
(Ich habe derzeit noch keinen BLU Motion, aber andere BLU Geräte.)

1. Das Skript "ble-shelly-blu.js" (kurz: Skript 1) - via Suchmaschine auffindbar - stellt die Kommunikation zwischen BLU Geräten und dem Shelly Plus 1 her. Es decodiert die bthome Nachrichten und emittiert Ereignisse, die vom anwendungsbezogenen Skript (kurz: Skript 2) empfangen werden.
2. Skript 2 (ähnlich meinem Skript, s. Link oben) empfängt u.a. die von Skript 1 emittierten Ereignisse und entscheidet abhängig von der auslösenden Quelle (Schalter/Eingang vs. Skript oder ggf. Cloud) und dem aktuellen Schaltzustand, ob eingeschaltet wird.
   Skript 2 nutzt die Unterscheidung folgender Quellen und reagiert, wie gewünscht.
   1. Nachricht vom BLU Motion -> Skript 1 -> Skript 2
   2. Ereignis "Eingang eingeschaltet" -> Skript 2
   3. Cloud -> Skript 2 (optional)

Somit ist eine Lösung in deinem Sinne möglich, aber nicht ohne Skript(e). Bei Nutzung eines Shelly 1 Gen 3+ kann Skript 1 entfallen. Dazu wäre Skript 2 geringfügig abzuändern. Nur bei Interesse bin ich bereit, diese Lösung weiter zu verfolgen - und kann solche erst dann komplett fertigstellen, wenn ich bald einen Shelly BLU Motion habe + hinreichend Muße.

Vielleicht findet sich ein anderes Forum Mitglied mit Skript Affinität, einem Shelly Plus 1 und Shelly BLU Motion, der die Skriptlösung bereitstellen kann und will.

Zitat von horkatz

Ich habe in allen Shellys die exakten Geo-Daten hinterlegt, die 2.5er Rollladen öffnen morgens ein paar Minuten früher als die 2PM.

Interessant. Bei mir ist es umgekehrt. Vielleicht fragen die alten Shelly in größeren Zeitabständen die Daten ab. Auch weiß ich nicht, wie die Zeiten von Sonnenauf- und Sonnenuntergang in den Scheduler einfließen und ob es dabei Unterschiede zwischen Shelly Gen 1 und Gen 2 gibt.

Mich stört das nicht. Es wäre vielleicht von "akademischem Interesse", auf welcher Grundlage die Daten in den Scheduler hineinwirken.

Oliver Schade

Vielleicht ist es eh zweckmäßig, das Schalten der Elektroheizung einem anderen Shelly, wie einem Shelly 1 Generation 3 (oder 4) mit Addon und bspw. zwei DS18B20 Sensoren, zu überlassen. Das WD kann weniger starke Ströme schalten als ein solcher Shelly 1.

In diesem Zusammenhang stellt sich die Frage, wieviel Leistung die Heizung "zieht". Vermutlich wird mit 230V betrieben.

Die Thermostatfunktion kann leicht per Aktionen implementiert werden.

Oder besser noch:

1. Das Walldisplay wird als Thermostat genutzt, bei Bedarf mit einem zusätzlichen externen Relais.
2. Ein Shelly 1 Gen 3/4 mit Addon und 1/2 DS18B20 zur Sicherheitsabschaltung bei zu hoher Temperatur an/in dichter Nähe der Heizung.

Dann sind die Relaiskontakte des Shelly 1 in Reihe zu den Schaltkontakten des Heizungs-Schaltrelais zu nutzen.

Ein BLU H&T besitzt den Nachteil, dass er wegen schwacher Batterie ausfallen kann. Das kann allerdings durch ein Skript abgefangen werden, indem dies eine Nachricht absetzt, wenn der Sensor ausgefallen ist und die Heizung ausschaltet. Da aber auf dem mir bekannten Wall Display kein Skript möglich ist, kommt dafür zunächst wieder ein Shelly 1 Gen 3/4 in Frage.

Hinweis: Ein Shelly Plus 1 (=Gen 2) tut es bereits, ist aber inzwischen alt.

Zwecks Spurensuche nenne ich mal eines meiner Themen, welches ich nicht als erledigt markieren kann:

Thema

Änderung mindestens einer KVS Methode von Firmware 1.4.4 auf 1.5.1

Ich stellte soeben mit Verwunderung fest, dass eine afaik undokumentierte Änderung im Resultat der KVS Methode "KVS.GetMany" vorliegt. Imho stellt dies eine gewisse Inkonsistenz dar. Die Dokumentation dazu ist allerdings korrekt - seit wann? Im Changelog fand ich dazu nichts.

Warum sehe ich dort eine gewisse Inkonsistenz - in der Resultatsstruktur?

In Firmware 1.4.4 lieferte KVS.GetMany ... eine verschachtelte Objektstruktur. Auf deren Elemente konnte man per Keys zugreifen. Die gleiche Struktur…

eiche

27. April 2025 um 21:09

Zitat von MIHO

Laut Forenbetechtigungen, können registrierte Benutzer Themen als erledigt markieren in diesen beiden Foren.

-können +dürfen , statt dürfen auch gerne "erhalten die Möglichkeit". Soweit die Berechtigungen.

Nur: Können kann ich dies in dreien von mir angemerkten insgesamt 15 eigenen Themen nicht. Eigenes Thema = von mir erstelltes Thema

Somit erscheint die Ursache dieses Widerspruchs auch den Administratoren noch unbekannt?

Btw, man findet eigene Themen ja leicht via Menüeintrag. Uuund ich erkenne meine Themen dort auch wieder.

Angelos

Du hast dich ja bereits auf den Hinweis von Flutschi in #2 eingelassen.

Dein Screenshot zeigt "Missing or bad key". Solches darf nicht sein. Hier wird guter Rat teuer bzw. unmöglich sein, soll heißen, dass vermutlich der BLU Motion einen Fehler mitbringt.

Trotzdem solltest du einen echten Power On Reset am Mini1Gen3 und am BLU Motion vornehmen.

BLU Motion, wie an anderen Stellen beschrieben, Batterie für min. 10s entfernen und dann mit gedrückt gehaltener Taste wieder einsetzen - nicht sehr einfach.

Mini1Gen3 erfordert ein Abklemmen der Spannungsversorgung, bspw. via temporärem Abschalten des zugeordneten Leitungsschutzschalters (Sicherung).

Hinweis:
Ein Power On Reset wirkt im Zweifelsfall umfassender als ein einfaches Reset per Klick oder per Button drücken, was in jedem Gerätetyp unterschiedlich sein kann.

Wenn dies keinen Erfolg bringt, dann tippe ich auf einen Fehler im BLU Motion.

Nachtrag:
Da das Power On Reset am BLU Motion schwieriger zu bewerkstelligen ist, können mehrfache Versuche nützlich sein. Dieses Reset am Mini1Gen3 braucht nur einmal vorgenommen zu werden.

An (zu) alten Datenbankeinträgen kann es jedenfalls nicht liegen, weil dies zumindest auch ein sehr neues Thema meinerseits betrifft.

Zitat von tvbshelly

bei Einsteigerfragen gibt es diese Funktion wohl nicht

Hmm, ich habe, angeregt durch diesen Thread, alle eigene Themen/Threads als erledigt markiert. Wirklich alle?

Nein, da gibt es noch gallische Dörfer ... äh eigene Themen, in deren Kontext ich diese Möglichkeit des als erledigt Markierens nicht vorfand.

In meinem Fall betreffen dies die Kategorien:

1. SHELL > Shelly-Inside
2. SHELLY > SHELLY SCRIPTE > Shelly Scripting

Sind diese Kategorien sinnhaft Einsteigerfragen zuzuordnen? Oder woran wird ein nicht als erledigt markieren Können festgemacht?

Vielleicht ergibt dies durchaus Sinn. Sowohl Themen in Shelly-Inside als auch in Shelly Scripting werden vielleicht mit geringster Wahrscheinlichkeit jemals als erledigt betrachtet werden können.

Für das Lichten dieses Nebels wäre ich (eingeschränkt ) dankbar.

Es ist inzwischen mehr als 3 Jahre her ...

Ich räume gerade meine Themen auf, mit dem Ziel des Abschließens - genauer: als erledigt markieren.

Deshalb will ich der Vollständigkeit wegen noch auf die Frage von Sektflasche eingehen.

Zitat von Sektflasche

id 0 und 1 ist kein Problem aber wie bekomme ich die inputs 2 und 3?

Die entscheidende Stelle ist die Definition von cfg im Skript von #1.

let cfg = [ // d=duration bound, msg=mqtt message, url=http request url, t=mqtt topic, p=payload/parameter
  [{d:1, msg:{t:Cmd03,p:'open'}, f:dependState, i:Idx.right}], // id 0
  [{d:1, url:Url12, p:'open', f:dependState, i:Idx.left}], // id 1
  [{d:1, url:Url12, p:'close', f:dependState, i:Idx.left}], // id 2
  [{d:1, msg:{t:Cmd03,p:'close'},f:dependState, i:Idx.right}] // id 3
];

cfg ist ein Datenfeld aus Datenfeldern. Das erste der inneren Datenfelder ist Eingang 0 (s. Kommentar // id 0) zugeordnet, das zweite Datenfeld darunter ist Eingang 1 zugeordnet, ... Somit liegen die Datenfelder zu Eingang 2, 3 an den Stellen 2, 3 oder wie im Code oben in den cfg Zeilen 3, 4.

Jedes einem Eingang zugeordnete Datenfeld kann mehrere Struktureinträge ({...}) enthalten, die sich zunächst in ihren maximalen Tastendrückdauern (d Werte) unterscheiden. Diese Dauern sind quasi hierarchisierte Schlüssel zu den auszuführenden Aktionen. Die Hierarchie ergibt sich aus den Positionen innerhalb eines solchen Datenfeldes, erster Eintrag hat höchste Priorität.

towiat

Sorry, im obigen Verlauf hatte ich nicht hinreichend sorgfältig gearbeitet, was ich nun aus Anlass des Schließens dieses Thread nachträglich tat.

Die von dir in #18 dargelegte Stelle der API Dokumentation zum RPC Protocol weist eindeutig die id Komponente im Request Frame als required auf. An anderer Stelle fand ich aber auch folgendes.

Quelle: https://www.jsonrpc.org/specification

Dort unter 4 Request Object
id
An identifier established by the Client that MUST contain a String, Number, or NULL value if included. If it is not included it is assumed to be a notification.

Offenbar sieht hier Shelly keinen Weg ohne Response vor, weshalb in diesem Kontext die id zwingend wird.

Ich bitte um Nachsicht, weil ich zuvor nicht sorgfältig recherchierte - mein Fokus klebte eng am konkreten Vorhaben des Zähler Rücksetzens.

Ich finde, dass es unterschiedliche Themenkategorien gibt (geben sollte?).

1. Ein Problem führt zu einer Frage oder mehrere Fragen.
2. Die Mitteilung eines Sachverhaltes, einer Erkenntnis, eines (vermeintlichen) Fehlers.
3. Vorstellung eines Projektes.
4. Anstoßen einer Diskussion.

Zumeist sollte 1. abgeschlossen werden, die anderen nicht aber zwingend.