Beiträge von eiche

    Ich versuche herauszufinden, wie die Angabe von Speichergrenze(n) zu verstehen ist.

    Ich fand dazu u.a. folgende Seite auf github zur Speicheroptimierung: https://github.com/LeivoSepp/Shelly-Memory-Optimization (Die Tipps sind mitunter gut zu gebrauchen, allerdings ist Stringsuche statt parsen nicht wirklich ernst zu nehmen.)

    Dort steht u.a. "Shelly devices have only 25KB of memory for scripts, shared between runtime and peak usage."

    Diese Aussage ist nicht hinreichend eindeutig.

    Stehen 25KB für alle aktiven Skripte auf einem Shelly zur Verfügung oder für jedes Skript 25KB? Dies ist wesentlich für eine evtl. Aufsplittung auf mehrere Skripte.

    Der RPC "Shelly.GetStatus" liefert u.a. mem_used, mem_peak und mem_free. Dabei fällt auf, dass der mem_free ert bei allen Skripten auf einem Shelly gleich sind, auch bei nicht aktiven Skripten.

    Vermutlich gelten die 25KB für die Vereinigung aller Skripte auf einem Shelly. Dies hätte zur Folge, dass eine Aufteilung auf mehrere Skripte keinen Memory Vorteil brächte.

    als wenn der Verbraucher, der als Schalter an L und SW angeschlossen ist

    Wie willst du das denn beschalten?

    Einen Verbraucher originär als Schalter zu nutzen ist zumindest sehr nutzungsfremd, imho tatsächlich unmöglich.

    Dafür greift der Vorschlag von Rickals mit einem ständig messenden (und nicht schaltenden) Shelly - der PM Mini. Dieser stellt dann fest, wenn ein Verbraucher als Master eingeschaltet wird und informiert schaltende Shelly.

    Meine Versuche zur Einbindung von Shelly BLU Geräten wie BLU H&T, BLU Door/Window via WebUI unter Components -> Bluetooth (BTHome) devices shlägt wiederholt fehl. Bereits der Scan Button unter "Add BTHome (Bluetooth) devices" ist grau unterlegt.

    Auch der Weg über "Add a device by MAC address" schlägt fehl.

    Installierte Firmware: 1.8.99-pillprod0 oder die Beta Version vom 2025-12-22

    An der Hardware dürfte es nicht liegen, weil Tests mit meinen Skripten zu Gen 2 Shelly erfolgreich verlaufen.

    Gibt es dazu Erkenntnisse/Informationen?

    Ich kenne HomeAssistant nicht. Jedenfalls unterstützt ein Shelly der Generation 2, wie die Plus Geräte, keine Einbindung von BLU Shelly via Firmware, was auch bereits festgestellt wurde. So etwas gelingt mit einem bzw. zwei Skripten, indem man bspw. MQTT Nachrichten nutzt. as HA mit MQTT kann oder nicht kann, weiß ich nicht. Ich kriege so etwas jedenfalls mit Skripten und Node-RED hin.

    Mit einem Gen 3+ Shelly wirst du weitere Optionen haben.

    Habe den BLU D/W in den Bluetooth Einstellungen des Shelly Plus 1 eingefügt

    Afaik ist so etwas bisher nicht möglich.

    Mein Fortschritt in der Nutzung von BLU Daten mit einem Shelly Plus (Gen 2)

    Dies ließe sich entsprechend auf ein Gen 3+ Gerät portieren, was ich noch nicht tat, weil mein einziges Gen 3 Gerät ausfiel.

    Es werden drei Skripte zu Grunde gelegt.

    1. "ble-shelly-blu.js" als bereits vorliegendes Skript zur Erkennung von Shelly BLU Geräten
      Dieses emittiert Events, welche von meinem folgenden Skript verarbeitet werden.
    2. Mein Skript "ble.js" verarbeitet Nachrichten, die von im Skript eingetragenen BLU Geräten gesendet werden:
      Derzeit habe ich folgende Geräte erfolgreich eingesetzt/getestet.
      BLU H&T, BLU Motion, BLU Door/Window und BLU Button
      Dieses Skript emittiert selbst bei Bedarf Events, welche bspw. von einem dritten Skript verarbeitet werden.
      Bei Bedarf sendet es eine Webseite, auf welcher die BLU Daten in Tabellenform dargestellt werden.
    3. Ein zusätzliches Skript "process.js" dient ausschließlich dazu, bei Bedarf auf Grund von BLU Nachrichten gewünschte Prozesse zu starten.
      Bisher gibt es ausschließlich von "ble.js" emittierte Ereignisse aus. Es stellt nur ein Grundgerüst bereit und ist nach Bedarf auszubauen.

    Diese Aufteilung bietet relativ übersichtlich alle Optionen, welche ein Anwender ggf. wünscht.

    Zwecks anwendungsorientierter Anpassung ist in "ble.js" die Konfiguration anzupassen und zwecks Verarbeitung "process.js" zu ergänzen.

    Mit den von mir bisher getesteten BLU Geräten lässt sich sehr viel implementieren, solange die Hardware dazu geeignet ist.

    Ein Beispiel zu einer Heizungsregelung - evtl. in einem Wohnmobil

    1. In "ble.js" oder in "process.js" oder einem weiteren Skript wird die eigentliche Regelung implementiert.
    2. Die Daten werden von "ble.js" via Webseite visualisiert.
    3. Mit einem BLU Button kann die Zieltemperatur verändert werden, bspw. einmal drücken -> verringern, zweimal drücken -> erhöhen, lange drücken -> Voreinstellung. Dies wird von "process.js" verarbeitet und kann bei Bedarf via Smartphone und Browser beobachtet werden.
    4. BLU Door/Window meldet offene(s) Fenster, woraufhin die Zieltemperatur temporär gesenkt wird.
    5. Wenn längere Dauer keine Bewegung via BLU Motion(s) gesendet wird, wird die Zieltemperatur gesenkt bzw. umgekehrt nach mehreren Bewegungserkennungen wird die Zieltemperatur auf einen vorgesehenen Wert gestellt.

    Der Vorteil einer solchen Realisierung liegt im geringen Leistungsbedarf, was für Wohnmobil/Wohnwagen besonders nützlich erscheint. Ein Smartphone ist i.d.R. ohnehin an Bord und via Hotspot bestens zu Zeitsynchronisation per NTP des Skript Shelly geeignet. Solange dieser Shelly keinen Neustart ausführt, bleibt die einmal synchronisierte Zeit weitestgehend aktuell. Das Smartphone ist aber auch danach als Hotspot geeignet, um die Webseite des Shelly via IP Adresse abzurufen. Dafür muss nicht der Shelly AP genutzt werden, auch wenn dies ebenso möglich ist.

    Die Skripte

    ble.js mit fünf konfigurierten BLU Geräten
    Die Daten eines noch nicht konfigurierten BLU Gerätes wird, alternativ zur App "Shelly BLE Debug", in der Console ausgegeben, wo u.a. die Adresse zu sehen ist. Dies erfolgt, wenn GetNew auf true gesetzt ist.

    ble-shelly-blu.js auch leicht im WWW zu finden. Hier eine etwas komprimierte Fassung.

    process.js ist nur eine minimale Bearbeitungsgrundlage, noch ohne echte Funktionalität. Hier werden nur Daten ausgegeben.

    JavaScript
    function process(ev) {
      if(ev.info.event!=="ble") return;
      //print(JSON.stringify(ev));
      let d = ev.info.data;
      print(d.name, d.val);
    }
    
    Shelly.addEventHandler(process);

    Der Übersichtlichkeit wegen sollte die Prozessfunktionalität in diesem Skript untergebracht werden. Es ist durchaus auch möglich, diese Funktionalität im Skript "ble.js" zu platzieren und die Webseitengenerierung in ein anderes Skript auszulagern. Bei Ausweitung eines solchen Projektes wird man sehen, was günstiger erscheint.

    Screenshot der Webseite

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Dazu eine autarke Lösung mit einem Shelly Plus Uni oder einem Shelly 2PM Gen x und einem Skript:

    • Zwei Taster an beiden Eingängen
    • Ein Ausgang schaltet (indirekt) den Verbraucher.
    • Der andere Ausgang lässt eine LED kurz blinken
      1 x blink -> Zieltemperatur runter
      2 x blink -> Zieltemperatur rauf

    Dazu liefert das Skript eine Webseite mit den gewünschten Informationen.

    Etwas ähnliches habe ich mit einem Shelly Plus 1 und Addon realisiert. Es funktioniert für mich bestens und verlässlich.

    Thybald

    Ein Shelly 1(PM) hat immer nur einen Schaltausgang (potentialfrei). Dafür steht die 1. Wenn immer eines der Ventile geöffnet sein soll, kannst du für das andere Ventil zusätzlich ein externes Relais verwenden. Oder du nimmst einen Shelly 2PM - zwei Ausgänge, aber nicht potentialfrei. Mit Letzterem kannst du auch beide Ventile schließen lassen.

    wotan2005

    Die meiner Ansicht nach beste Lösung ist ein Shelly Skript auf deinem 1PM Gen 4, welches neben der Regelung auch eine Webseite liefert. Darauf Symbole zum erhöhen/absenken der Zieltemperatur. Auch Zeitpläne sind bei Bedarf möglich. Das Einbinden eines BLU H&T statt eines kabelgebundenen Sensors ist auch kein Problem.

    So wird keine zusätzliche Ausstattung gebraucht, weil der schaltende Shelly völlig autark arbeitet. Was nicht gebraucht wird, kann auch nicht ausfallen bzww. dessen Ausfall wirkt sich nicht auf die Funktion der Heizungsregelung aus. Mit ioBroker kenne ich mich nicht aus.

    Die Verbindung mit dem 1PM kann auch über dessen Accesspoint laufen.

    stressfrei

    Wo und wie stellst du dir die Anzeige des BLU Door/Window Zustandes vor - in der App, Cloud oder WebUI (gelingt mit Gen 2 nicht) oder via eigener Webseite vom Plus 1?

    Eine Webseite kann per Skript geliefert werden, darin auch Daten/Zustände von BLU Geräten/Sensoren. Ein solches Skript könnte ich beisteuern. Wie so etwas prinzipiell aussehen kann, kannst du hier sehen. Statt Text sollte sich auch etwas per Symbolen oder Bildern machen lassen, was ich bisher noch nicht brauchte.

    --Adler--

    Ergänzung zur Machbarkeit - auch auf Basis der Schaltung von thgoebel in #25

    Zur Rollladensteuerung mit teilweiser Öffnung (%) muss der 2PM kalibriert werden. Letzteres wird vermutlich nicht gelingen. Wenn nach dem Motto "Nichts ist unmöglich" nach einer Lösung gesucht werden soll, bietet sich allenfalls Aufwändiges an.

    1. Tasmota auf einem ESP32 Board (Bsp.) mit manueller Kalibrierung
    2. Shelly Skript mit experimenteller Zeiterfassung und Konfiguration im Skript oder im Key Value Storage (KVS). Dazu müsste in gewissen Abständen eine Referenzstellung (Tor geschlossen oder komplett offen) angefahren werden.

    Dies sei nur der Vollständigkeit halber erwähnt.

    Für energiesparenden Einsatz: Shelly Gen 3+ liefert BLU Daten auf einer Webseite - keine Action erforderlich

    Konfiguration ausschließlich via Sensor (Messwerte) Nameneinträge, kein Eingriff in das Skript erforderlich

    Ich arbeite gelegentlich an einer Bluetooth Sensorabfrage ohne übergeordnetes System und ohne Cloud.

    Grund: Dies soll energiesparend unterwegs einsetzbar sein - bspw. in einem Wohnmobil oder einem Wohnwagen.

    Das folgende Skript ist weiterhin in Bearbeitung aber bereits nutzbar. Es generiert eine Webseite mit Daten von Shelly Bluetooth Sensoren. Somit können diese Daten per Smartphone dargestellt und beobachtet werden. Fernes Ziel ist, darin eine digitale Heizungsregelung zu implementieren.

    Ostfriese (Nickname) hatte eine sehr gute Lösung für Ruuvi Sensoren bereits implementiert. Ich verfolge hier eine reine Shelly Lösung. Dafür setze ich gegenwärtig ein ModX1 Entwicklungsboard ein, welches derzeit und bereits länger nicht mehr angeboten wird. Auch ein Shelly Plus Uni kann verwendet werden, erfordert dann aber ein zusätzliches Skript sowie Änderungen im untenstehenden Skript.

    Die Webseite wird durch die Namen der darzustellenden Sensordaten konfiguriert.

    Die zugrunde liegende Struktur jedes Namens: name:unit:index:category
    Als Separator der Namesteile dient der Doppelpunkt und kann bei Bedarf anders gewählt werden.

    Die Webseite zeigt in Tabellenform jeden aufzulistenden Eintrag.
    Eine Tabellenzeile besteht aus name, Messwert mit unit, Zeitpunkt der letzten Messwerterfassung.
    index gibt die Zeilenposition innerhalb der Tabelle an und sollte mit 0 beginnen.
    Derzeit wird category zur Darstellung der Messwerte verwendet (Farbe und Schriftgröße).
    Bisher verwendet das Skript die Kategorienwerte tmp (Temperatur), hum (Luftfeuchtigkeit) und bat (Batteriezustand).

    Im Tabellenkopf wird u.a. Zeitpunkt der letzten Webseitenaktualisierung angezeigt. Über diese Zeitangaben kann leicht die Aktualität der Daten beobachtet werden.

    Die Webseite wird standardmäßig alle 60s neu geladen. Dieser Refreshwert kann bei Bedarf per ?r=<Sekunden> gewählt werden.
    Nach dem Start des Skripts wird in der Console der vorgesehene URL angezeigt.

    Ein Screenshot zeigt den Aufbau der Webseite. Diese ist auch per Shelly Access Point erreichbar (192.168.33.1), also ohne Zusatzhardware.
    Der Webseite URL lautet http://<IP-Adresse>/script/1/data, wenn das Skript die Id 1 besitzt.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Die Temperaturunterschiede ergeben sich aus den unterschiedlichen Platzierungen der Shelly BLU H&T in unserem Wohnmobil - wir sind derzeit unterwegs.

    Beispiel der Konfiguration eines Sensors auf dem Shelly WebUI unter Components/Bluetooth (BTHome) devices/Supported sensors:

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
    Der Batteriezustand wird auf der Webseite in der dritten Tabellenzeile in % angezeigt (hier wäre wohl statt % der HTML Code besser).
    Diese Art der Konfiguration via Name ist ohne Skripteingriff nutzbar, aber nicht DAU sicher. So wird ein mehrfach vergebener gleicher index Wert dazu führen, dass immer der letzte assoziierte Datensatz an der indizierten Stelle platziert wird. Welche Folge ein (überflüssigerweise) sehr hoch gewählter index Wert hat, vermag ich nicht zu sagen. Ein vorgesehener Abstand von 5 (oder gar 10) zwischen zwei Shelly BLU Geräten mag nützlich sein, um später leichter Sensordaten eines weiteren Gerätes einfügen zu können. Dies habe ich bisher allerdings nicht getestet.

    Das Skript empfängt ohne Action die Sensordaten, speichert diese und die aufgerufene Webseite stellt die gespeicherten Daten asynchron dar.
    Wenn die Zeitpunkte mangels Zeitserver Verfügbarkeit nicht brauchbar sind, kann für max. 1 Minute ein Smartphone via Hotspot die Zeitsynchronisation des Shelly Gen3+ zur Verfügung stellen. Im Skript stehen noch einige Teile, die ggf. nicht gebraucht werden. Dies muss zukünftig die Robustheit des Skripts entscheiden. Code Verbesserungen sind zukünftig möglich.

    Bei Fragen will ich gerne zur Verfügung stehen.

    Die CSS Liste (<style>) ist etwas umfangreicher als es hier benötigt wird - aus einem anderen Projekt genommen und zukünftig vielleicht gut geeignet.

    Dirkys

    Falls du einen Verbraucher ohne WLAN ausschließlich per Bluetooth steuern willst, ist es am einfachsten dafür einen Gen 3/4 Shelly zu verenden. Das kannst du ja mit deinem Plug S Gen 3 einmal testen.

    Wenn du ein Plus Gerät (=Gen 2) dafür nehmen willst, solltest du JavaScript können und dich in das Shelly Skripten einarbeiten. Wenn du das willst und Grundlagenkenntnisse hast, helfe ich dir gerne weiter.

    Dirkys

    Gehören beide Abbildungen nicht zu deinem Rollladen Shelly der Generation 3/4?

    Edit:

    Ich sah soeben, dass diese Abb. zu einem PlugS Gen 3 gehören. Sind diese Optionen bei deinem Rollladen Shelly nicht vorhanden oder gehört Letzterer nicht der Generation 3/4 an?

    Wenn du einen PLugS Gen 3 als Gateway nutzt, dann wird dieser mit einem Rollladen Shelly (vermutlich) nur per WLAN kommunizieren können.

    Szenen arbeiten Cloud basiert. Cloud nicht erreichbar -> Funktion weg. Besser ist es lokal arbeiten zu lassen. Ich habe einen BLU Motion liegen, aber noch nicht ausgepackt. Auf Grund von anderen BLU Geräten und einem Gen 3/4 Shelly habe ich ein kleines Skript erstellt, welches vermutlich auch für deinen Zweck genutzt werden könnte. Das Skript braucht nur auf Grund der Nachricht vom BLU Motion geeignete Nachrichten an das Zielgerät zu senden. Auch der Einsatz eines Timers könnte ggf. nützlich sein.

    Das grundlegende kleine Skript ist mit Anleitung hier zu finden.

    Bei Muße kann ich den BLU Motion dazu mal testen ...

    StefLanT

    Das bewirkt nicht das Gleiche wie die Amazon Cloud Routinen, da einer Routine ein eigener Sprachbefehl zugeordnet ist.

    Bei deiner "Lösung" wird hingegen immer ein weiterer (oder auch mehrere) Rollladen geschlossen, wenn derjenige mit den eingetragenen Actions geschlossen wird. Dies erscheint mir nicht zufriedenstellend.

    Weil ein Sprachbefehl immer über die Shelly Cloud arbeitet, sehe ich auch keine Lösung per Skript. Dort lässt sich nur erkennen, ob der Auslöser die Shelly Cloud war.

    Cephalopod

    Lassen sich Shelly Szenen per Amazon Cloud aktivieren? Wenn ja, wäre dein Workaround treffend, wenn nein leider nicht.