Beiträge von eiche

Die Firmware 1.3.1 lässt im Web UI keine Änderung von KVS Variablen mehr zu. Damit ist für manche Anwender die KVS Nutzung kaum noch möglich. Hoffentlich wird dies noch geändert. Ob dies per RPC Methode gelingt, habe ich bisher nicht getestet.

Die Firmware 1.3.1 lässt im Web UI keine Änderung von KVS Variablen mehr zu. Damit ist für manche Anwender die KVS Nutzung kaum noch möglich. Hoffentlich wird dies noch geändert.

Mit FW 1.2.2 hatte ich es getestet. Nun habe ich FW 1.3.1 drauf.

Btw, ich habe in meiner Dokumentation die Möglichkeit aufgezeigt, Messdaten und Zeitstempel in zwei Dateien zu speichern, wobei i.d.R. die Zeitstempeldatei nur eine oder bei Stromausfall nur sehr wenige Zeilen umfasst. Erst bei der Übertragung wird der Zeitstempel zu jedem Messwert generiert. Ein Copy & Paste würde damit aufwändiger.

Vielleicht wäre mit deinen Datensätzen auch eine Komprimierung möglich.

just izi abel oder auf engl. just easy ability

Was sagt eine KI dazu?

Haftet diese für ihre Aussagen eigentlich? Oder wer oder was?

Ich lasse nun meinen Test-Shelly mit Skript durchlaufen und will testen, ob es abgebrochen wird - vor 20480 Byte Füllstand in "data".

Soweit ich erinnere, tat ich dies bereits, ohne dass das Skript vorher abgebrochen wurde. Damit konnte ich dieses Limit belassen. ...

Du kannst meinem Skript entnehmen, dass ich dort das Limit auf 20480 setze (=20k). Dieses Limit der Dateigröße hat sich bewährt, ist aber dem Einsatzzweck angepasst. Meine Experimente ergaben, dass bei wesentlich größerer Datei, soweit ich erinnere um die 30k, irgendwann ein Skriptabbruch die Folge war.

Die API Dokumentation schweigt sich darüber aus. Ein Forenmitglied hatte mir einmal mitgeteilt, dass die experimentell maximale Größe bei 48k läge und die verfügbaren Speicherressourcen seit Firmware Version 1.x (?) fest auf die 10 möglichen Skripte aufgeteilt seien. Nach meinen Erfahrungen teilt sich vermutlich diese Größe von ca. 48k auf Skriptlänge und Arbeitsspeicher auf. Um solches herauszufinden, bleiben offenbar nur eigene Experimente.

In einem anderen Projekt scheiterte mein Vorhaben jedenfalls an der ram_size von 260016, welche bei nicht laufendem Skript angezeigt wird. Dies ist aber nicht die maximale Größe einer Datei.

Das Speichern im Shelly hat insbesondere dort seinen Vorteil, wo irgendwelche Informationen zur Auswertung gespeichert werden sollen, wo keine Kommunikation mit anderen Geräten oder Internet verfügbar ist.

Da bis zu 10 Skripte möglich sind, sollte bis zu theoretisch 9*20k Byte Speicherkapazität ohne Probleme nutzbar sein. Solche Versuche habe ich bisher nicht durchgeführt, weil ich dazu keinen Anlass hatte.

Das hat nichts mit dem i4 zu tun, sondern mit dem empfangenden Rollladen-Shelly.

Der URL .../roller/0?go=stop u.ä. gehören zur ersten Generation der Shelly wie der 2.5 und sollte in den Shelly ab zweiter Generation noch abwärtskompatibel sein. In den neueren Shelly gibt es hierfür die wesentlich flexibler nutzbaren RPC-Methoden.

Ich empfehle eine allmähliche Umstellung auf RPC-Methoden bei Shelly ab zweiter Generation.

Du kannst versuchen, die Daten auf mehrere Dateien aufzuteilen.

Afaik wird jedem Skript eine maximale Speicherkapazität zugeordnet.

Wie eine solche Aufteilung zielführend zu strukturieren ist, hängt von den Daten ab, welche du speichern willst.

Zitat von Requiem

Ein Rolladen ("Rolladen Haustür") reagiert seit ein paar Wochen nicht mehr auf "Rolladen Haustür schließen". Alexa antwortet dann mit "ich bin mir leider nicht sicher".

Hast du auch mal eine andere Benennung versucht wie bspw. "Rolltür" statt "Rollladen Haustür"?

Hast du ein anderes Gerät mit ähnlich klingendem Namen eingesetzt? "Haustür schließen" ist ein wenig verdächtig.

Das Skript biete ich nicht zum herunterladen an, da es in meiner Fassung recht spezifisch ist und für andere Anwendungen anzupassen wäre. Ich stelle es aber bei Interesse gerne zur Verfügung.

Versuch einer einfachen Beschreibung der Skript-Arbeitsweise

Einige Dinge sind optional, was ich dann jeweils erwähne. Sie können somit bei Nichtbedarf entfernt/weggelassen werden.

1. Es nimmt Messdaten als Ereignisse entgegen, die von der Firmware geliefert werden. Statt Messdaten können beliebige andere anwendungsspezifische Daten erfasst werden.
2. Zur Speicherung wird eine feste Abtastfrequenz per Schedule Job (Zeitplan) verwendet, was optional ist.
3. Aus den zwischen zwei Speicherungen eintreffenden Messwerten wird sukzessive der arithmetische Mittelwert gebildet, ebenfalls optional.
4. Die Daten werden in einer Skriptdatei namens "data" gespeichert, weil die Firmware hierfür Methoden bereit hält. Diese Datei ist allerdings kein Skript, sie ist aber unter Skripte einsehbar und somit können die Aufzeichnungsdaten per Copy & Paste kopiert und an gewünschter Stelle eingefügt werden.
5. Zusätzlich habe ich auf Grund der Wünsche des befreundeten Anwenders eine Datenübertragung per MQTT implementiert, was optional ist. Der Anwender suchte eine einfache Möglichkeit, die gespeicherten Daten nach ca. einer Woche vom Messort ohne Internetzugang nach Hause zu übertragen. Dies gelingt mit einem öffentlichen MQTT Broker und der Android App MQTT Dash. Dabei wird der Hotspot des Smartphone/Tablet genutzt.
6. Es liest Konfigurationswerte ein, die per Web UI unter KVS (Key Value Storage) leicht angelegt und geändert werden können. Eine solche Konfiguration sowie deren Verarbeitung ist auf die jeweilige Anwendung anzupassen.

Hier der aktuelle Inhalt der von mir für Testzwecke gespeicherten Daten. Vorne steht der Unix Timestamp, nach dem Komma der gemittelte Temperaturmesswert.

1714725000,14.7
1714725900,14.7
1714726800,14.7
1714727700,14.7
1714728600,14.7
1714729500,14.7
1714730400,14.8
1714731300,14.8
1714732200,14.8
1714733100,14.8
1714734000,14.8
1714734900,14.8
1714735800,14.8
1714736700,14.8
1714737600,14.8
1714738500,14.8
1714739400,14.8
1714740300,14.8
1714741200,14.8
1714742100,14.8
1714743000,14.8
1714743900,14.8
1714744800,14.8
1714745700,14.8
1714746600,14.8
1714747500,14.8
1714748400,14.8
1714749300,14.8
1714750200,14.8
1714751100,14.8
1714752000,14.8

Das Skript im Anhang dürfte für deine Zwecke nicht 1:1 nutzbar sein.

Zitat von Karl-Heinz

Ist beim Reset auch die eingespielte Software weg ?

Nein, da die Software im nichtflüchtigen Speicher liegt. Mehr kann ich dazu nicht sagen, weil du deine eingesetzte Software nicht genauer benennst/beschreibst.

RDAS1

Zitat von RDAS1

gibt es bei Ihnen Module für die Steuerung von elektrischen Rollläden

"Wir" sind Anwender von smart home und IoT, keine Anbieter.

Ergänzend zu obigen "Feststellungen":

1. Das, was du möchtest, geht auch sehr wohl ohne ein übergeordnetes System.
2. Eine Kombination aus Schedule Jobs und Skript macht dies möglich. Dazu bleibt die Frage, ob die Verwendung von sunrise und sunset hinreichend zielführend wäre.
3. Damit der gesteuerte Rollladen nicht relativ hochfrequent fährt, ist im Skript eine Schalt-Hysterese unterzubringen.
4. Alles was ein Shelly Plus 2PM eigenständig tut, ist am ausfallsichersten.

Damit will ich eine andere Perspektive aufzeigen und nicht etwa die Skript- + Schedule-Lösung in den Vordergrund stellen, da es viele gibt, die sich nicht mit Shelly Scripting beschäftigen wollen/können.

WWSolar

Ok, ca. 3k Byte können nach meiner Erfahrung locker auf einem Skript fähigen Shelly gespeichert werden.

Du könntest dir mal meine Beschreibung zur lokal auf dem Shelly zu speichernde Messwerte ansehen. Ich habe dazu ein für Messwerte geeignetes Skript erstellt. Für deine Zwecke wäre das Skript anzupassen.

Der wesentliche Unterschied zur Messwertspeicherung liegt vermutlich darin, dass deine Datensätze unterschiedlich lang sind. Ob alle lokal gespeicherten Daten mit einer einzigen MQTT Nachricht übertragen werden können, weiß ich nicht. Deshalb lasse ich die gespeicherten Daten in mehreren Paketen übertragen, wozu ich aber eine feste Zeilenlänge verwende. So können ganze Zeilen als Elemente der Nachrichten übertragen werden.

Falls dir ein Copy & Paste per Web UI genügt, könntest du die Datendatei öffnen und deren Inhalt per Zwischenablage kopieren.

Wenn du Interesse an meinem Skript hast, lasse es mich wissen, am besten per PM (Konversationen)!

Versuche es mal mit dem Aufladen des gewünschten TRV!

Notfalls ein Reset per Büroklammer, aber nicht an der Sensor Öffnung!

Zitat von bbernhard

ggfl ist das ja auch Absicht um Akku zu sparen ?

Ganz sicher, ja.

Ich kenne hierfür ausschließlich das Web UI von Shelly Geräten ab Generation 2. Diese zeichnet aber nur solange auf, wie "Diagnostics" im Web UI genutzt wird. Auf meinem Android Smartphone verwende ich MQTT Dash, in welchem empfangene Daten per JavaScript verarbeitet werden können. Ob dies es erlaubt, empfangene Daten zwischenzuspeichern und bei Bedarf zu übertragen, weiß ich nicht.

Ich täte solches per Node-RED Flow auf einem Raspberry Pi umsetzen, was ich auch bereits tat. Alternativ ist es möglich, Daten auf einem Skript fähigen Shelly (ab Gen. 2) auf dem Shelly selbst per Skript zu speichern. Diese Daten können bei Bedarf via Web UI und Copy & Paste leicht übertragen und auf dem Shelly gelöscht werden. Ich habe eine solche Anwendung zur Messwerte Aufzeichnung für einen Freund implementiert, incl. optionaler Übertragung per MQTT -> Node-RED Flow.

Solches gelingt auch mit allen Daten, die der Shelly bereit ist zu liefern. Dazu ist aber ein Skript erforderlich.

Dazu habe ich folgende Fragen.

1. Welche Daten willst du speichern?
2. Wie umfangreich (geschätzt) sind diese Daten (Datensatz) in Bytes etwa?
3. Wie soll das Speichern der Daten getriggert werden?
4. Über etwa welche Zeitspanne willst du diese Daten speichern?

Eine App, welche solches ermöglicht, kenne ich nicht.

FigUhr Kannst du das Skript manuell starten?

Nach meiner Erfahrung gelingt solches nur dann nicht, wenn der Interpreter einen Syntaxfehler findet. Dann muss es eine Fehlerausgabe im Protokollfenster geben. Wenn dies nicht so sein sollte, könnte das an einer noch fehlenden Freigabe des Web UI Protokolls liegen.

Johnny Kasuppke

Mein derzeit genutztes Skript ist für dein Ziel zu komplex. Ich will für dein Ziel ein Versuchs-Skript zusammenstellen und dies dann in diesem Beitrag ergänzen. Bis dahin ...

Johnny Kasuppke

Hier nun ein Skript, welches du nur geringfügig in der Konfiguration anzupassen brauchst. Das Skript ist in dieser Version nicht für die alten Shelly 2.5 geeignet. Wenn diese Kompatibilität gewünscht sein sollte, müsste ich das Skript dafür etwas umgestalten.

Entscheidend für das gewünschte Verhalten ist der Inhalt der Variablen (Struktur) "Config". Ich habe hier die Montage des i4 mit den Anschlussklemmen nach unten vorausgesetzt. Dann besitzen die Tastenanschlüsse folgende Id-Werte.
oben rechts: 0, oben links: 1, unten links: 2, unten rechts: 3
Jeder Taste ist ein Eintrag (Zeile) in Config zugeordnet, mit Id=0 beginnend (erste Zeile) und Id=3 endend (letzte Zeile). Nur wenn zwischen den eckigen Klammern hinter methods: etwas steht, wird der korrespondierende Tastendruck verarbeitet. Lasse dich nicht von den vielen id verwirren. Sie haben etwas unterschiedliche Aufgaben. Ich nutze aber lieber die Terminologie der Shelly API Dokumentation als mir neue Bezeichnungen aufzuzwingen.

Normalerweise wirst du die beiden IP Adressen hinter ip_addr: abändern müssen. Hier habe ich bewusst in jeder Zeile eine eigene IP Adresse vorgesehen, damit das Skript auch für andere Dinge relativ leicht anpassbar ist. Diese IP Adresse bezieht sich immer auf den Aktor, hier ein Shelly Plus 2PM im Cover Modus.

Falls du die Zeilen vertauschen musst, damit sie zu deiner Tastenanordnung passen, sind auch die "corr" Werte (hier 2 und 1) anzupassen - corr von correlation. Diese Werte beziehen sich auf die Tasten Id Werte und sorgen für eine besonders intuitive Bedienung, alles mit kurzen Tastendrücken.

Das Bedienverhalten

Taste links oben fährt nach Skriptstart den Rollladen hoch. Ein erneuter Druck auf diese Taste lässt den Rollladen stoppen. Der nächste Druck auf diese Taste lässt ihn weiter hochfahren.

Taste links unten fährt den Rollladen herunter. Ein erneuter Druck darauf lässt den Rollladen stoppen. ...

Wenn jemand die "falsche" Taste drückte und die Gegenrichtung wollte, genügt es, die andere Taste zu drücken. Dies wird mit den "corr" Werten ermöglicht. Ohne diese Werte kann es geschehen, dass mit dem anderen Tastendruck zunächst angehalten wird. Dieses Verhalten hängt dann davon ab, was mit dem letzten anderen Tastendruck bewirkt wurde und ist deshalb nicht immer gleich. Dies kannst du testen, indem du temporär die beiden corr:2 und corr:1 Teile entfernst.

Wichtig! Kopiere das Skript ausschließlich per Kopier-Icon im Rahmen oben rechts!

// created by Gerhard Eichelsdörfer alias eiche, 2024-04-27, V 1.1
// Application for a Shelly Plus 2PM as roller shutter, e.g. controlled by two buttons

//---- begin of configuration ----
let Config = [
  {i:0, methods:[], id:0}, // top right, id=0
  {i:0, ip_addr:"172.16.3.66", methods:["cover.open","cover.stop"], id:0, corr:2}, // top left, id=1
  {i:0, ip_addr:"172.16.3.66", methods:["cover.close","cover.stop"], id:0, corr:1}, // bottom left, id=2
  {i:0, methods:[], id:0} // bottom right, id=3
];
//---- end of configuration ----

function next(res, errc, errm, id)  {
  if(errc) {print(errc, errm); return;}
  Config[id].i = (Config[id].i + 1) % Config[id].methods.length;
  let corr = Config[id].corr;
  if(corr!==undefined) Config[corr].i = 0;
}

function process(e) {
  if(e.info!==undefined && e.info.event==="single_push") {
    //print(JSON.stringify(e));
    let id = e.info.id;
    if(id<0 || id>=Config.length) return;
    let i = Config[id].i;
    if(i<0 || i>=Config[id].methods.length) return;
    let method = Config[id].methods[i];
    if(typeof(method)==="string") {
      print(id, method);
      Shelly.call("http.get", {url:"http://" + Config[id].ip_addr + "/rpc/" + method + "?id=" + Config[id].id}, next, id);
    }
  }
}

Shelly.addEventHandler(process);

Bei Fragen stehe ich selbstverständlich zur Verfügung. Die Konsolenausgaben dienen ausschließlich der Überprüfbarkeit, welche Id der gedrückten Taste zugeordnet und welche Methode aktuell mit diesem Tastendruck verbunden sind.

Edit: Ich habe das Skript noch ein wenig robuster gestaltet - V 1.1.

Ich kann nur raten, daraus zu lernen und neue Firmware auf nur einem Gerät gleichen Typs zu installieren und länger zu testen, um die möglichen Problemfälle klein zu halten.

Als Workaround täte ich einen kleinen Node-RED Adapter erstellen, welcher die neue MQTT-Nachrichtenstruktur in eine Home Assistant kompatible konvertiert. Ich kenne mich allerdings nicht mit Home Assistant aus. Ich will versuchen, die bisherige MQTT Nachrichtenstruktur zu protokollieren und zur Verfügung zu stellen.

Max.Solar Die MQTT Nachrichten per Firmware 20240223-141926/1.2.2-g7c39781 lauten (Werte selbstverständlich beispielhaft)

relative Luftfeuchtigkeit topic:PlusHT01/status/humidity:0, payload:{"id":0,"rh":51.4}

Temperatur topic:PlusHT01/status/temperature:0, payload:{"id":0,"tC":22.6,"tF":72.8}

Wie ersichtlich lautet mein Pre-Topic PlusHT01, dein Pre-Topic wirst du selbst wissen.

Es kamen noch andere Nachrichten herein, welche ich zunächst für an dieser Stelle unbedeutsam halte. Die MQTT Nachrichtenstruktur der neuen Firmware habe ich bisher nicht protokolliert. Diese kannst du selbst im MQTT Explorer sehen und zum vergleichen ggf. hier posten.

Johnny Kasuppke

Die RPC Methoden für Shelly Plus 2PM sind in der Dokumentation zu finden.

Sie lauten Cover.Open, Cover.Close, Cover.Stop und Cover.GoToPosition, wobei Groß-/Kleinschreibung keine Rolle spielt.

Als URL http://<IP Adresse des PLus 2PM>/rpc/cover.open?id=0 und für die anderen Methoden entsprechend. Die Id muss zur Steuerung des Rollladenantriebs immer angegeben werden, also auch dann, wenn es keine alternative Id gibt.

Zum Anfahren einer Position http://<IP Adresse des PLus 2PM>/rpc/cover.open?id=0&pos=<Prozentangabe des Öffnungsgrades relativ zum Gesamtfahrweg>.

Westerwald2000 hat in seiner Tabelle hierzu die alten, rückwärtskompatiblen und nicht RPC tauglichen URL genutzt. Die gehen zwar, solange diese Rückwärtskompatibilität in der Firmware bleibt, bieten aber keinen Vorteil. Ich kann nur empfehlen, sich an die erheblich vielseitigeren RPC Methoden zu gewöhnen.

Edit:
Mir gefällt ein long Push zum stoppen nicht, weil ein solcher weniger punktgenau gelingt. Ich nutze hierfür ein Skript, welches die letzte Aktion speichert. Wenn bspw. vorher Taste 2 zum herunterfahren gedrückt wurde, dann wird mit dem folgenden kurzen Tasterdruck auf denselben Taster die Stop Methode genutzt und umgekehrt. Solches gelingt afaik weder per Action noch per Cloud-Szene. Szenen sind eh wegen geringerer Zuverlässigkeit suboptimal.

thgoebel ist nun ein freier Shelly Mitarbeiter, was Reparaturen betrifft.

Ich bitte darum, seine Kapazität nicht übermäßig zu beanspruchen!