Beiträge von eiche

VPN/Proxy erkannt

Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.

    Stelle ich Dir gerne zur Verfügung, Gerhard!

    Grien. Schauen wir mal Thomas! Wenn wir gelegentlich wieder zusammentreffen, nehme ich gerne einen bzw. das "Team" der Shelly. ;)

    Kann ich dir sonst schicken und du schreibst das Skript. Ein bezahltes Versandedikett lege ich für den Rückversand auch dazu.

    Das wäre zuviel Aufwand. Ich halte mich dann lieber an Thomas. Zumal ich noch anderes im RL zu erledigen habe. Meine todo Liste ist lang und schrumpft nicht von alleine. Und in eine "nottodo Liste", wie sie das Känguru von Marc Uwe Kling pflegt, kann ich sie nicht verwandeln. ;)

    Zunächst sollte eine Zweipunktregelung mit Hilfe zweier Aktionen auf dem EM genügen. Diese solltest du paarweise um weitere Schwellen erweitern können, wodurch die Regelung stufenweise feiner wird.

    stoppeljody

    Nun bist du auf dem Weg zu deinem Ziel, sehr gut.

    Das Umschalten bzw. Ein-/Ausschalten geschieht schlagartig. Wenn du eine allmähliche (schleichende) Veränderung an der Heizung erreichen willst, sollten dafür die Methoden "Light.DimUp" und "Light.DimDown" geeignet sein.

    Für eine (fast) kontinuierliche Regelung ist ein Skript erforderlich. Wenn ich irgendwann einmal einen Shelly Pro 3EM und einen Shelly Plus 0-10V Dimmer habe, kann ich dafür ein Skript erstellen.

    Nun das Skript - auf einem Shelly Generation 2 getestet.

    Wenn mehrere Nachrichten, auch bspw. auf Grund anderer Events gesendet werden sollen, ist die Config Struktur anders zu gestalten.

    RiverRaid

    Frage: Soll dies mit jeder Quelle des Einschalten erfolgen oder ausschließlich bei Verwendung des Wall Switch?

    Ich setzte mal Ersteres voraus. Zunächst das Prinzip eines geeigneten Skripts.

    1. Der sog. Eventhandler erfasst das Einschalten des Ausgangs.
    2. Dann wird 3s gewartet.
    3. Nach Ablauf dieser Zeitspanne wird per Methode "http.get" die gewünschte Nachricht gesendet.

    Das ist sehr einfach zu implementieren.

    Also doch über die Cloud als Szene?

    Nein, bitte keine Cloud zur Steuerung und somit keine Szenen verwenden!

    Du experimentierst offenbar zu wenig. Die Elektrik musst du als Elektriker hinreichend beherrschen und absichern. In allem anderen solltest du dich auf Experimente einlassen.

    Rhetorische Frage: Hat "man" dir das Experimentieren abgewöhnt und durch ein "nach Rezepten handeln" angewöhnt?

    Ich versuche mal, dir eine erste Orientierung zu geben. Du solltest unbedingt meine Darlegungen lesen, damit du dich darin zurechtfinden kannst. Weiter unten folgen Beispiele.

    1. Der Shelly Dimmer muss die DC Ausgangsspannung bereitstellen. Dazu braucht er in deinem Fall keine Beschaltung der Eingänge sondern Nachrichten, die ihn zum einstellen seiner Ausgangsspannung veranlassen. Diese Nachrichten müssen von einem anderen Gerät kommen, welches die entscheidenden Parameter (hier: Messwerte) kennt. Das ist in deinem Fall der Shelly Pro 3EM.
    2. Der Shelly Pro 3EM (kurz: EM) muss, abhängig von seinen Messwerten, bei Bedarf Nachrichten an den Dimmer senden. Dazu sind zwei Nachrichtenarten (Fachwort: RPC Methoden, RPC = Remote Procedure Call) geeignet.
      1. Ausgang ein-/ausschalten -> Heizung binär an oder aus.
      2. Ausgang analog steuern -> Heizung auf (fast) beliebige Leistung stellen.

    Es gibt also in der Kommunikation zwischen zwei Shelly immer einen Auftraggeber und einen Auftragnehmer.

    RPC ist eine "Nachrichtenphilosophie", durch die ein Gerät einem anderen Informationen mitteilen kann. Die Shelly Geräte ab Generation 2 bieten dafür sog. Methodennamen. Das sind zusammengesetzte Namen mit einem Punkt dazwischen. Durch senden eines solchen Methodennamens an einen Shelly löst dies eine Aktion auf dem empfangenden Shelly aus. Zumeist muss eine solche Nachricht neben dem Methodennamen auch Parameter enthalten.

    Solche Nachrichten können per HTTP über (W)LAN direkt vom Sender (Auftraggeber) zum Empfänger (Auftragnehmer) gelangen.

    Die für deine Ziele geeignete RPC Methoden beschreibt die API Dokumentation, hier speziell für den Dimmer

    1. die Liste an verfügbaren Methoden: https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Light,
    2. zum schalten des Ausgangs oder einstellen der Ausgangsspannung: https://shelly-api-docs.shelly.cloud/gen2/Component…/Light#lightset.

    Beispiele für eine einfache Steuerung

    Damit solltest du ohne M150 und stattdessen am Dimmer Ausgang angeschlossenem Messgerät experimentieren. Als Auftraggeber ist ein Browser geeignet, in welchem du die folgenden - und andere - Zeilen in die Adresszeile eingibst. So kannst du das Verhalten des Dimmers erleben und erlernen. Diese HTTP Zeilen kannst du später in Aktionen des EM einsetzen, damit dieser die Heizung über den Dimmer steuert.

    1. http://<IP Adresse Dimmer>/rpc/light.set?id=0&on=true -> Schaltet den Ausgang ein.
      http://<IP Adresse Dimmer>/rpc/light.set?id=0&on=false -> Schaltet den Ausgang aus.
    2. http://<IP Adresse Dimmer>/rpc/light.set?id=0&brightness=50 -> Stellt die Ausgangsspannung auf 50%, was entweder 5V oder 5,5V bedeutet.

    Es gibt weitere Methoden, die aber zunächst unwesentlich sind und allenfalls in einem Skript auf dem EM zielführend nutzbar wären.

    Auftrag

    Klemme den M150 ab, schließe an den Dimmerausgang einen Spannungsmesser an, gib in der Browseradresszeile obige http Zeilen ein und freue dich über die Reaktionen des Dimmers! ;) Variiere bitte auch die brightness Werte!

    Wenn du diese Kommunikation verstanden hast, bist du reif für die Aktionen auf dem EM - vorher nicht.

    Wenn du diesen Auftrag erledigt hast oder du Fragen dazu hast, melde dich bitte wieder!

    Ich habe das nun

    auf 1 - 5 Volt angeklemmt, damit man dann die 100% erreichen kann. Ist doch richtig, oder?

    Bedenke bitte, dass dein Shelly Dimmer 0-10V ausgeben kann! Um den vollen Hub zu nutzen, sollte an dessen Ausgang ein Spannungsteiler 1:1 liegen. Ich weiß nicht, wie gut der M150 an seinen DC Eingängen gesichert ist. So oder so täte ich für den Anfang am M150 den Eingang 3-12V verwenden.

    An den anderen DC Eingängen sind Leitungen zu sehen. Was tun die dort? Sind diese offen? (So etwas ist ggf. fahrlässig, weil man versehentlich kurzschließen könnte.)

    Kann man damit nun ein Skript schreiben?

    Nicht "damit" aber dafür. ;)

    Versuche es doch erst einmal mit Aktionen! Vermutlich gelingt damit dein Vorhaben bereits. Da ich keine solche Geräte habe, kann ich es nicht testen.

    Ich finde es ziemlich ärgerlich, dass sowas geändert wird. Es gibt auch keinen Hinweis dazu in den Release-Notes.

    Ähnliches hatten wir bereits an anderer Stelle (Datenstruktur) festgestellt. Ich bin Anhänger der Kleinschreibung (Anfangsbuchstabe) von Funktionsnamen. Mich irritiert deshalb diese neue Großschreibung der beiden Methodennamen. Vielleicht wird das bald wieder geändert. Dann müssen auch solche Skripte angepasst werden.

    Ich mag die Weiterentwicklung der Firmware, gewinne aber zunehmend den Eindruck, dass diese Weiterentwicklung mit zu heißer Nadel gestrickt wird. Hier sollte sorgfältige Planung im Vorfeld Einzug halten - mit dem Ziel einer sehr langen Nutzbarkeit. Bei den RPC Methoden erscheint mir dies gelungen.

    Zu BLE.Scanner nachgereicht

    Hier liegen (zumindest) zwei Fehler in der API Dokumentation.

    Richtig lauten die beiden Methoden des BLE.Scanner Objektes zum starten und stoppen

    BLE.Scanner.Start() und BLE.Scanner.Stop(). Großschreibung statt Kleinschreibung!

    Zum Hinweis von tvbshelly in #2

    Die Transformation eines BLE Paketes - zweiter Parameter in der callback Funktion - ist aufwändig. Dies erledigt das Skript ble-shelly-blu.js bestens und muss nicht in das Anwendung Skript eingebaut werden.

    Auch kann der Event Name in diesem Skript in CONFIG bei Bedarf geändert werden, wozu ich bisher keinen Anlass sah.

    tvbshelly

    Das Skript ble-shelly-blu.js ist relativ generisch. Es erledigt Arbeiten auf Basis der BTHome Typencodes, emittiert Events, die leicht zu nutzen sind, und vermeidet die Verarbeitung von wiederholt denselben Bluetooth Nachrichten (dieselbe Packet Id). Ob Letzteres vorkommen kann, habe ich nicht untersucht.

    Die Events können relativ leicht für gewünschte Aktionen genutzt werden. So kann die Arbeit auf zwei Skripte verteilt werden, was die Übersichtlichkeit fördert. Ich nutze somit die bereits gute Arbeit eines Anderen und ergänze um das, was Anwendung spezifisch ist. Da für die Anwendung erforderliche Daten im Event geliefert werden, braucht es keine weitere Kommunikation zwischen den Skripten.

    Zusätzlicher Hinweis

    Kleiner, zumeist unwesentlicher Nachteil gegenüber Lösungen auf Shelly Gen 3+ liegt im nicht Messgröße spezifischen Timestamp. Stattdessen gibt es einen Timestamp, der für alle Messgrößen des BLU Gerätes gilt.

    Ich sah mir die Möglichkeiten an, mit einem Shelly der Generation 2 - hier Shelly Plus Uni - auf relativ einfache Weise Daten von BLU Sensoren zu verarbeiten.

    Dazu bildet das Skript https://github.com/ALLTERCO/shell…e-shelly-blu.js die Grundlage. Neben den Grundfunktionen des Scannens und des Koppelns von Shelly BLU Geräten sendet dieses Skript Ereignisse, welche in anderen, anwendungsorientierten Skripts genutzt werden können.

    In meinem Anwendungsskript lege ich Wert auf möglichst einfachen, übersichtlichen und erweiterbaren Code. Es beinhaltet einen Eventhandler, der die von ble-shelly-blu.js emittierten Ereignisse empfängt und verarbeitet. Der Anwender muss hierfür eine konstante Datenstruktur für seine Zwecke anpassen. Diese enthält zu jedem BLU Gerät, dessen Daten verarbeitet werden sollen, dessen Adresse und benutzerdefinierte Daten. Letztere sind

    1. das zu verwendende MQTT Topic - kann entfallen, wenn MQTT nicht genutzt wird,
    2. den Namen zum Sensor,
    3. zu nutzende Komponenten der Sensordaten in Kurzform - in einem String.

    Getestet habe ich mit einem BLU Door Window und einem BLU H&T.

    Das Anwendungsskript veröffentlicht zu jedem eintreffenden Ereignis eine MQTT Nachricht, deren Payload die selektierten Nutzdaten, den Sensornamen und den Zeitstempel enthält. Diese Nachrichten können bei Bedarf für eigene Zwecke angepasst werden. So kann bspw. auf HTTP statt MQTT umgestellt werden, wofür insbesondere die Funktion getComp anzupassen ist.

    Das grundlegende Anwendungsskript

    Dieses Skript kann bei Bedarf vielseitiger gestaltet werden, indem

    1. die Struktur BLEdev etwas erweitert,
    2. eine weitere Funktion getUrlParam ähnlich der getComp hinzugefügt und
    3. der Eventhandler process erweitert wird.

    Ich habe das original Skript ble-shelly-blu.js etwas komprimiert, damit es kürzer und imho übersichtlicher ist, ohne irgendetwas an dessen Funktionalität zu ändern.

    Das komprimierte Skript

    Wer keinen Antrieb verspürt, sich dieses Skript anzusehen, sollte dessen Ursprungscode nutzen - Link s.o..

    wo die im Speicher noch vorhandene Restenergie gerade noch ausreicht

    Was du auch immer einsetzen willst, sehr hilfreich ist es, wenn der Speicher seine Restenergie per nachrichtlicher Kommunikation preisgibt.

    Eine Näherung per Registrierung der in den Speicher gelangenden Energie mag vielleicht auch geeignet sein. Dann muss diese ständig gemessen werden. So etwas kann prinzipiell von einem Shelly Skript erledigt werden, wobei es zielführend wäre, den Speicher zwecks Kalibrierung des Skriptparameters Wkap (kap = Kapazität) einmal komplett zu leeren und anschließend zu füllen. Das komplette Leeren wird vermutlich der Speicher nicht zulassen, was aber wohl nicht entscheidend sein dürfte. Alternativ ließe sich die theoretisch gegebene Wkap nutzen, welche als Speichereigenschaft vom Hersteller angegeben ist. Diese lässt jedoch im laufe der Zeit nach.

    Btw, die Grafiken von borsti0 sehen stark nach Grafana aus, vermutlich Bestandteil von HomeAssistant. Dann könnte auch ein InfluxDB System Teil von HomeAssistant sein. Ein relationales DB System wäre jedenfalls dafür suboptimal.

    Peruna

    Versuch einer Zusammenfassung, als Ergänzung zu borsti0

    1. Du favorisierst die Nutzung von Shelly i4 Gen 3 hinter jeweils 4 Tasten.
      (Solche nutze ich auch, aber i4 Gen 2.)
      Damit ist das Schalten von je bis zu 4 Lampen über WLAN möglich, nicht aber über Bluetooth.
    2. Das Schalten über Bluetooth kann mit folgenden Shelly BLU Geräten erfolgen, beide nicht fest montierbar.
      https://www.shelly.com/de/products/shelly-blu-rc-button-4 vielleicht können diese irgendwie in der Halterung nicht entfernbar fixiert werden. Vorgesehen ist das aber nicht.
      https://www.shelly.com/de/products/sh…n-tough-1-black kann leicht an Schlüsselanhänger befestigt werden, aber auch leicht entwendbar.
      Beide haben den Nachteil der leichten "Mitnahmemöglichkeit".
    3. Die Nutzung von Bluetooth als Option erscheint nur dann zweckmäßig, wenn ein temporärer Ausfall des (IoT-)WLAN überbrückt werden soll. Dazu müssten die Bluetooth Geräte verfügbar sein und nach dem WLAN Ausfall wieder eingesammelt werden. Mir erscheint das viel zu aufwändig.
    4. Die 1:1 Verbindung eines Tasters (tatsächlich eines i4 Kanals) mit einem Schaltausgang ist ausschließlich per WLAN möglich. Dazu kann das Toggeln, also Umschalten (EIN <-> Aus), verwendet werden. Dies ist konfigurierbar.
    5. Sollte die Steuerung ausfallsicher sein, muss an jedem Eingang eines schaltenden Shelly ein Taster/Schalter angeschlossen werden. Dies erfordert selbstverständlich zusätzliche Verlegung von Leitungen. Dann ist aber das WLAN dafür überflüssig.

    Fazit

    Die fest montierbaren i4 sind für deine Zwecke gut geeignet, können aber ausschließlich über WLAN kommunizieren. Dies stellt imho die kostengünstigste Lösung dar. Zur Steigerung der Sicherheit gegen WLAN Access Point Ausfall kann ein zusätzlicher Access Point genutzt werden, auf welchen die i4 automatisch wechseln, falls der vorgesehene AP ausfällt. Existiert ein erreichbarer, alternativer AP (bspw. für Gäste?), könnte dieser (temporär) genutzt werden.

    Ein weiterer Vorteil der Shelly Kommunikation ist die einfache Erweiterbarkeit und Umkonfigurierbarkeit. Jedem Taster kann eine frei wählbare Aktion zugeordnet werden, im Bedarfsfall auch mehrere Aktionen. Das dafür weder Hub noch Gateway erforderlich ist, weißt du vermutlich inzwischen.

    Wenn du einen Intel Nuc im Schrebergarten stehen hast, sollte es möglich sein, darauf einen VPN Dienst zu installieren. Ich tat solches bisher nicht und kann dabei nicht helfen. An der Machbarkeit sollte es aber keinen Zweifel geben.

    Ansonsten kann selbstredend dafür die Cloud genutzt werden.

    Der Shelly Scanner ist ein sehr gutes Werkzeug. Er kann zwar Stromstärkegrafen anzeigen oder auch Werte speichern, da er aber eine Frontend Anwendung auf einem Arbeitsplatzrechner und kein Serverprozess ist, kann er dies nur, wenn der Rechner läuft und zugleich der Shelly Scanner gestartet ist. Damit ist eine 24/7 Aufzeichnung nur theoretisch möglich, da kein Arbeitsplatzrechner 24/7 läuft.

    Um 24/7 o.ä. Messwerte zu speichern, ist ein 24/7 o.ä. laufender Server erforderlich. Dieser muss die Messdaten entgegennehmen/abfragen und irgendwie speichern, am besten in einer sog. Zeitreihendatenbank - bspw. InfluxDB. Aus den gespeicherten Daten kann per geeignetem Prozess - bspw. Grafana - eine Grafik erzeugt und bspw. per Web Browser dargestellt werden.

    Dies tut auch die Cloud, allerdings in relativ grober zeitlicher Auflösung. Und mangels zur Verfügung gestelltem Cloudspeicher, werden ältere Messdaten relativ frühzeitig komprimiert. Mit eigenem Server ist eine solche Komprimierung alter Daten bei Bedarf ebenfalls nutzbar, der Beginn des, übrigens mehrstufigen, Komprimierens kann aber flexibel festgelegt werden.

    Fazit: Mit einem eigenen Server ist man nicht nur Internet unabhängiger sondern kann erheblich anpassungsfähiger Daten speichern und Grafiken erzeugen lassen.

    Nebenbei können Daten auch innerhalb des eigenen Netzwerks Server basiert zum steuern von Geräten genutzt werden.

    Für den Anfang ist die Cloudnutzung sicher hilfreich, für ausgereiftere Anwendungen ist aber ein eigener Server - bspw. per Raspberry Pi - erheblich besser geeignet.

    Dieter88

    Zum von Wilfried54 angemerkten Shelly Scanner. Dieser ist tatsächlich für verschiedene Zwecke gut geeignet. Er kann zwecks Darstellung nichts anderes tun, als die Daten von den Shelly remote abzufragen.

    Ich täte solches per Node-RED. In einem Flow würden alle interessierenden Geräte abgefragt. Im Node-RED Dashboard (unter einem Menüpunkt) alle Stromstärken aufgelistet. Dies willst du vermutlich nicht.

    Deshalb fragte ich oben, was du mit diesen Stromstärken anfangen willst, außer diese abzulesen. Was ist der Zweck deines Stromstärkeablesens?

    JonniK

    Bei Szenen kann ich dir nicht weiterhelfen, weil ich mich damit nicht eingehender beschäftige. Wie mit der Einschalt-Aktion die Bewegungsmeldung gesperrt werden kann, weiß ich derzeit auch nicht, da ich dies nicht testen kann. Ich kann allenfalls etwas zu einem Skript beitragen. Somit werde ich nun auf weiteres warten.