Beiträge von eiche

Wenn ich in ca. einer Woche Muße dazu haben werde, kann ich voraussichtlich dafür ein kurzes Skript erstellen. Dazu werde ich deine MQTT Nachricht kennen müssen (Topic und Payloadstruktur). Derzeit bin ich leider verhindert.

I'd try a Shelly 0-10V dimmer including an add-on and DHT22. A H&T reacts relatively slowly to changes in measured values.

to the device

Perhaps this can be achieved in a user-friendly way with a H&T. You'll have to figure that out. I don't have a 0-10V dimmer. It can probably be configured appropriately. A script will certainly work.

Ein Skript, welches auf Änderungen beider Eingänge wie folgt reagiert. Für beide Endlagenschalter gleich.

1. Bei Änderung dieselbe, also welcher Eingang, feststellen.
2. Eingang und dessen Status speichern.
3. Danach bspw. 50ms warten und denselben Eingang abfragen. Ist der neue Status gleich dem gespeicherten Status, Aktionen auslösen und Nachrichten senden.

Ich weiß allerdings derzeit nicht, wie man aus einem Skript eine Push Nachricht sendet. Vermutlich nutzt du dafür die Cloud. Das kannst du ja auch weiterhin tun und auf eine der Aktionen reagieren lassen.

Es mag andere Wege geben ...

Bspw. eine Hardwarelösung per RC Integrierglied. Ich täte die Skriptlösung bevorzugen.

Fritzneu

Mein Eindruck: Du bist viel zu hektisch.

Zitat von Fritzneu

komme leider trotzdem nicht voran

Womit kommst du nicht voran? Wer nicht präzise schreiben kann, kann wahrscheinlich auch nicht präzise lesen.

Also:

1. einen Tee trinken oder bei Vorliebe einen Schnaps
2. entspannen - zu neudeutsch relaxen
3. Bedienungsanleitung sorgfältig lesen, ggf. eigene Notizen machen.
4. App erstmal beiseite lassen, mit dem Access Point des Shelly verbinden und einen Web-Browser verwenden : http://192.168.33.1 ...
5. Die Navigation auf der WebUI kennenlernen und nutzen.

Später kannst du dich dann mit der Cloud versuchen. Direkt per App alles zu erledigen mag schneller gelingen können, kann aber auch dazu neigen, den Nutzer ein Stück zu verblöden. In aller Freundschaft.

Ich hatte noch nie Probleme beim einbinden eines Shelly in ein WLAN via WebUI des Shelly. Warum immer wieder eine App dazu gebraucht wird, ist mir ein Rätsel. Etwas anderes liegt vor, wenn der Shelly in die Cloud eingebunden werden soll. Davon schreibt der TE aber bisher nichts.

Zitat von Turbo

Wenn der Shelly ausfällt, durch Defekt oder weil kein WLAN verfügbar kann ich die Markise nicht bewegen.

Da sind schonmal 3 mögliche Ausfallursachen zu unterscheiden.

1. Kein Strom - nicht relevant, weil dann auch kein Markisenantrieb an Netzspannung arbeiten kann.
2. Shelly defekt -> Austausch des Shelly oder für zügige Reparatur Shelly raus, Taster/Schalter wieder einbauen bzw. rückverdrahten.
3. WLAN ausgefallen -> dazu die Frage: Hast du ggf. vorhandene Taster/Schalter weiter genutzt und mit den Shelly Eingängen verbunden? Wenn ja, ist der Markisenantrieb immer per Taster/Schalter zu steuern.

Zu 2. und 3. Solltest du solche Fälle berücksichtigen wollen, dann ist zunächst immer der Einbau von Tastern oder Schaltern zielführend. Was du dabei bevorzugst, hängt von deiner Vorliebe bzgl. Bedienung ab. Eine Steuerung am betreffenden Shelly vorbei halte ich für wenig wahrscheinlich möglich, bin dbzgl. allerdings unbeleckt.

Zitat von ofbeardsandmen

Braun/Blau (Ausgang "M3") geht hoch zum Motor.
Rot/Schwarz (Eingang "PV1") kommt anscheinend von den Solarzellen.

Für jemand Uneingeweihtes wie mich.

Soweit ich dich verstand willst du die PV Versorgung komplett abtrennen und durch eine Netzspannungsversorgung + Netzteil (12V DC) ersetzen. Wenn ich richtig verstand, täte ich folgendes.

Probelauf eines Rollos bei gleichzeitigem Messen der Spannung zwischen den M3 Klemmen, Hoch und Runterlauf. Es ist zu erwarten, dass diese Spannung eine Gleichspannung ist und sich in der Polarität umkehrt.

Die Höhe der Spannung ist von Belang!

Falls diese 12V beträgt und du konsequent auf smart umrüsten willst, brauchst du die Steuereinheit nicht mehr.

Voraussetzung: Du willst die Rollos nur zum öffnen und zum schließen fahren, ohne Anweisung auf x% Öffnungsgrad, was ein Kalibrieren voraussetzt. Ggf. zwischendurch anhalten ist möglich.

Da du auch Sprachsteuerung vorsehen möchtest, bleiben in der Shelly Familie ausschließlich die Rollladen Shelly 2.5 (alt) und 2PM (neu) - im Zweifelsfall die neueste Generation. Dann ist die bereits von thgoebel beschriebene Umrüstung auf 12V zu basteln, wobei deren Garantie verloren geht.

Es gibt zumindest eine Alternative, mit welcher die Garantie nicht verloren geht und auch gebastelt werden muss. Hinzu käme noch wenigstens die Konfiguration in einem übergeordneten System (Home Assistant, ioBroker, openHAB, ...). Mehr Freiheiten hat man mit Node-RED (einfache Programmierumgebung) und ggf. zusätzlicher Skript-Programmierung, was ich nur der Vollständigkeit wegen erwähne. Bei all diesen Alternativen wirst du vermutlich die Sprachsteuerung verlieren, auch wenn dies bei unbedingtem Willen per Node-RED gelingen könnte. Auch eine Kalibrierung via Zeitmessungen kann prinzipiell mit Programmierung nachgebildet werden, was jedoch nicht ganz an die Shelly eigene Kalibrierung heranreichen wird.

Fazit: Wenn du eine einfache und schnelle Lösung suchst, vergiss dein Vorhaben! Ansonsten gibt es (fast) nichts, was nicht geht.

Afaik können die Rollladen Shelly mit 24V Gleichspannung, nicht aber mit 12V betrieben werden und schalten nicht potentialfrei.

Wenn deine Rollo mit 12V betrieben werden, kann vielleicht thgoebel weiterhelfen, ggf. mit Gleichrichtung und Shelly Modifikation. Kalibrierbar sind sie dann aber keinesfalls mehr.

Fazit: Mit geringem, Aufwand wird es vermutlich nicht gelingen.

Sorry, ich landete auf Seite 1 und sah nicht, das der Thread bereits sehr viel weiter ist.

martner

Dann verweise ich auf #11, ergänzt durch bei Bedarf folgendes Verfahren.

Beispiel mit 3 gekoppelten Shelly Generation 3.

(Bin gegenwärtig im Krankenhaus und kann nicht testen. Vielleicht geht das auch mit Actions. Szenen täte ich nicht einsetzen.)

In den Skripten der 3 Gen 3 Shelly werden kurze Verzögerungen eingebaut. Das ist skalierbar, sollen heißen auf mehr Shelly Gen 3 ausdehnbar.

ShellyA: keine Verzögerung, ShellyB 2ms Verzögerung, ShellyC 4ms Verzöherung.

Alternativ können diese Verzögerungen auch zufällig generiert werden, wobei dann aber auch 2 der Gen 3 Shelly mal zeitgleich senden könnten. Auf diese Weise kommen die Nachrichten am master nicht gleichzeitig an und er hat Zeit, seine Queue zu bearbeiten. Vermutlich genügt auch ein Verzögerungsabstand von 1ms. Die Gen 3 kommunizieren ja per WLAN.

Dazu muss man halt etwas planen und evtl. auch dokumentieren, damit der Überblick nicht verloren geht - bei bspw. 8 solcher Gen 3 Shelly.

Das ist von mir nur eine Idee, die ich schon mangels derzeitiger Ausstattung nicht testen kann. Das Skript in #6 bildet bereits die Basis für die Slaves. Ob man für die Kommunikation MQTT oder HTTP nutzt, bleibt dem Anwender/Entwickler überlassen. MQTT bietet den Vorteil, dass dafür keine IP Adresse gebraucht wird, bei Austausch eines Kommunikations Shelly nur das Topic wiederverwendet werden muss und der dafür erforderliche Skriptteil leichter zu codieren ist.

Aus meiner Erinnerung, als ich zu Hause damit experimentierte, konnte ich zwei Shelly Gen 3 Geräte mit einem BLU H&T koppeln. Deshalb bin ich zuversichtlich, dass dieses angedachte Verfahren gelingt.

Per Skripte verfolge ich folgende Idee.

Ein "master" Shelly, Gen 2 genügt bereits, empfängt von "slave" Shelly, Gen 3+, die Nachrichten per http.

Der master speichert eine solche Nachricht für bspw. 10s in einer Queue. Danach wird sie gelöscht.

Der/die slave arbeiten wie im obigen Skript und senden statt per MQTT per http - so müssen diese nicht zwingend MQTT nutzen.

Der master prüft bei Empfang, ob bereits die gleiche Nachricht in seiner Queue steckt. Wenn ja, lässt er diese unverarbeitet. Wenn nein, speichert er sie und sendet sie als MQTT Nachricht.

martner

Tja, das muss ich noch testen.

Vielleicht ist ein Mehrfachempfang unerheblich, da ja dann alle beteiligten Gen 3 Geräte die gleiche Nachricht senden täten. Der Subscriber hätte halt zusätzliche Arbeit. Ansonsten muss ich noch genau herausfinden, wie die Pakete identifiziert werden (können). Ich arbeite (morgen vielleicht) wieder daran.

Zunächst ließe sich bei gleicher Id und gleichem timestamp herausfinden, dass die Nachricht bereits empfangen wurde und nicht noch einmal zu verarbeiten sei. Soweit ich mich erinnere sendet die Firmware so etwas wie eine Paket Id, an welcher erkennbar sein soll, ob die Nachricht bereits empfangen wurde. Mal sehen ...

Danke thgoebel.

Das wäre unter Verwendung eines zusätzlichen Shelly, welcher den Sicherheitsschalter realisiert und bspw. zwei BLU Motion für die Terrassentür sehr nützlich. Leider kriege ich in ihrer Wohnung diesen zusätzlichen Shelly nicht unter.

Zitat

Zweiter Nachteil: Für das Steuern des Rollladens ist Ein-Knopfbedienung erforderlich.

Das könnte ich ggf. per Skript anders lösen.

Mistral11

Falls du daran denken solltest, Shelly BLU Geräte zu verwenden, bspw. BLU Door/Window, dann ist ein Shelly ab Generation 3 sehr hilfreich. Deren Firmware unterstützt die Nutzung von BTHome Geräten stark. Der Plus Uni ist leider nur einer der Generation 2. Vielleicht wird es auch einen Plus Uni Generation 3+ geben.

Noch einige Hinweise zu obigem Skript.

Es ist leicht möglich, die vom Anwender in der Component Konfiguration vergebenen Namen in das Topic der MQTT Nachrichten einzubauen.

Beispiel:

Component Name = "Wohnzimmertemperatur:°C"

Daraus ergäbe sich das Topic: "experiment/bthome/Wohnzimmertemperatur"

Bei Bedarf ließe sich der Component Name auch in drei Teile gliedern, wie "Wohnzimmertemperatur:living/temp:°C". Dies kann vom angepassten Skript wie folgt umgesetzt werden.

• Sensorgrößenname: Wohnzimmertemperatur
• Einheit: °C
• Topic: "experiment/bthome/living/temp"

Um dies als Option zu nutzen, kann der Component Name auch ohne Topic Teil zusammengesetzt werden, z.B. "Wohnzimmertemperatur::°C".
Oder ohne Einheit, was bereits obiges Skript toleriert, z.B. "Wohnzimmertemperatur:living/temp".

Hier ist einige Gestaltungsarbeit möglich, wobei der Anwender aber auch Fehler machen kann, indem er in seinem ganzen smart home System Uneindeutigkeiten konfiguriert. Dieses Konzept ist also nicht DAU sicher.

Das in der System MQTT Konfiguration vergebene Pre-Topic wirkt hier übrigens nicht. Dieses gilt ausschließlich in MQTT Nachrichten, welche per System gesendet werden.

Wenn dafür Bedarf besteht, reiche ich ein entsprechend angepasstes kleines Skript gerne nach.

Auch denke ich daran, solche Component Konfigurationen per MQTT auf andere Shelly Generation 3 Geräte verteilen zu können. Hierzu können zwei weitere Skripte genutzt werden - eines zum Senden der lokalen Konfiguration, das andere zum empfangen und automatisiertem Konfigurieren der eigenen Komponenten. Dazu habe ich zwar Ideen, aber noch keine Tests durchgeführt. Die RPC stellen jedenfalls hierfür genügend Methoden bereit.

Weitere Optionen sind umsetzbar.

Nach vielen Experimenten habe ich ein sehr kleines Skript erstellt, welches auf einem Shelly der Generation 3 (oder vermutlich höher) dazu genutzt werden kann, MQTT Nachrichten mit BTHome Sensordaten zu senden, also solche die von Shelly BLU Geräten kommen. Hierfür müssen alle zu beteiligenden Sensoren auf dem Shelly der Generation 3 ... eingerichtet werden - unter Components.

Dort sind anschließend die Sensor Identifier zu sehen - Struktur: "bthomesensor:<id>". Zu jedem per MQTT zu erfassenden Sensor bzw. physikalische Sensorgröße muss eine Action angelegt werden.

http://127.0.0.1/rpc/script.eval?id=<script id>&code="bths(<sensor id>)"

Beispiel:

http://127.0.0.1/rpc/script.eval?id=1&code="bths(202)"

bths() ist die einzige Funktion des kleinen Skripts. Sie holt unter Verwendung der Sensor Id die aktuellen Daten und den in deiner Konfiguration eingetragenen Namen mit optionaler Einheit, stellt diese für die MQTT Payload zusammen und sendet die MQTT Nachricht.

Die Component Namen brauchen mit dem von mir gewählten Separator (Konfigurationsvariable Sep im Skript) die folgende Struktur.

<Sensorname>:<Einheit>

Beispiel:

Wohnzimmertemperatur:°C

Damit wird die Payload der MQTT Nachricht folgende Komponenten haben.

• Sensor Id
• Sensor Wert
• Timestamp der letzten Aktualisierung
• Sensorname
• Einheit

Selbstverständlich muss der Abonnent nicht alle diese Daten nutzen, sie stellen aber imho alle relevant nutzbaren Informationen bereit.

Das Skript

// created by eiche, 2025-05-08
// This script, running on a Shelly generation 3 or higher, sends MQTT messages with data from a BTHome sensor.
// To do this, you need to create an action for each sensor from which you want to retrieve data.
// In each of these actions, you must use the "script.eval" method with the following code: code="bths(<sensor id>)".
// The complete URL is http://127.0.0.1/rpc/script.eval?id=<script id>&code="bths(<sensor id>)",
// e.g. http://127.0.0.1/rpc/script.eval?id=1&code="bths(200)"
// The only function bths() requires a composition of sensor name and optional unit in the component name.
// Sensor name and unit must be separated by a separator containing the variable Sep, e.g. a colon.

// You may do something else with the sensor data, e.g. use the "HTTP.Get" method with an URL.
// But that method can be in an action and does not need a script.
// Have fun with it anyway!

// A small configuration
let
  Topic = "experiment/bthome", // the MQTT topic
  Sep = ':'; // the seperator symbol - it may be a string instead of one character
// end of configuration

// Get BTHome sensor data an send those via MQTT.
function bths(id) {
  //print(id);
  Shelly.call("bthomesensor.getstatus", {id:id}, function(res, errc, errm) {
    if(errc) {console.log(errc, errm); return;}
    //print(JSON.stringify(res));
    let Sensor = {id:res.id, value:res.value, ts:res.last_updated_ts, name:"", unit:""};
    Shelly.call("bthomesensor.getconfig", {id:id}, function(res, errc, errm, s) {
      if(errc) {console.log(errc, errm); return;}
      //print(JSON.stringify(res));
      let n = res.name.split(Sep);
      s.name = n[0];
      if(n.length>1) s.unit = n[1];
      let p = JSON.stringify(s);
      print(p);
      MQTT.publish(Topic, p); // or do something else with object p
    }, Sensor);
  });
}

Dies alles ist mit etwas Konzentration leicht zu konfigurieren. Das Skript kann bei Bedarf so erweitert werden, dass Sensor spezifische Aktionen ausgeführt werden, bspw. MQTT Nachricht versenden oder HTTP Get URL nutzen oder bei Bedarf auch beides. Die flexibelste Variante einer solchen Erweiterung beinhaltet ein Datenfeld aus jeweils der Sensor Id und einer Referenz auf die zu nutzende Funktion zwecks senden der Daten bzw. auslösen einer Aktion.

function f200(p){
  // do something
}

function f201(p){
  // do something
}

let Action = [
	{id:200, f:f200},
	{id:201, f:f201},
	// ...
];

Die Funktionsnamen sind nur formal so gewählt und können selbstverständlich nach Belieben lauten. Alle diese Funktionen müssen ein Objekt als Parameter importieren, welches alle Sensordaten enthält.

Das Datenfeld Action ist nach der aktuell vorliegenden Sensor Id abzusuchen und, wenn gefunden, die zugeordnete Funktion (hier eine Referenz) mit dem aktuellen Sensordaten Objekt als Parameter aufzurufen. Die Funktionsreferenzen haben den Vorteil, dass eine Funktion auch im mehreren Action Einträgen genutzt werden kann.

Bei Fragen gebe ich gerne Auskunft, wenn der Frager wenigstens grundlegendste Kenntnisse hat.

Zitat von edwinrm

Also für „abwärts“ kommt zusätzlich das Relais des zusätzlichen Shellys zum Einsatz.

Genau. Das ist dann allerdings nur für solchen Anwendungsfall geeignet und nicht mehr flexibel für andere Fälle anpassbar.

Stimmt. Wenn stattdessen ein Shelly (Plus) 1 genutzt wird, ist dieser Schalter auch noch smart. Dieser Shelly schaltet dann schlicht die Versorgung des Rollladen steuernden Shelly.

Ob der so geschaltete Rollladen Shelly das lange erträgt, kann ich nicht einschätzen.

homolka

Für ggf. weitere Alternativen musst du uns deine Schaltung genauer beschreiben, am besten per Schaltplan. Ich weiß bisher nicht, wie deine Schaltung verdrahtet ist und arbeitet.

Vermutlich gelingt das nicht ohne Skript und mittlerem Aufwand der Umstellung.

Gründe

1. Ein Sperren des Rolladenfahrens ist nicht vorgesehen.
2. Man kann zwar die Wirkung von Signalen an den Eingängen sperren, nicht aber die Steuerung der Ausgänge per Nachrichten.

Geeignetes Verfahren

1. Das Steuern der Rollläden oder zumindest des betreffenden Rollladens muss geändert werden. Dies verhindert nicht ein Fahren über die ggf. gegebene Cloud Nutzung oder die Web UI des Shelly.
2. Per Skript mit zumindest einem sog. HTTP Endpoint muss alle erforderlichen Kommandos (URL) entgegennehmen und verarbeiten, auch solche, die zum Rollladensteuern verwendet werden. Tatsächlich muss das Skript speziell dafür vom Benutzer festgelegte Kommandos in die API Kommandos transformieren.
3. Zwei zusätzliche Kommandos sind erforderlich - eines zum sperren der obigen Kommandoverarbeitung und eines zum freigeben derselben.
   Das kann auch eine simple Skriptfunktion tun.
4. Per zweier Schedule Jobs sind dann diese zusätzlichen Kommandos zu nutzen.

Dies lässt sich alles implementieren, wenn man will und kann. (Ich könnte solches, brauche es aber nicht.) Solange Standard mittel so etwas nicht vorsehen, sehe ich keinen anderen Weg. Es sollte auch ohne HTTP Endpoints gelingen, was allerdings von weniger eingeweihten Nutzern noch schwieriger einsetzbar wäre.

Zitat von horkatz

Wozu brauche ich eine Fernbedienung, wenn ich einen Shelly verbaut habe?

Jo, so denke ich auch.

Aber offensichtlich gibt es Zeitgenossen, die sich so sehr an Fernbedienungen gewöhnt haben, dass sie solche gerne nutzen.

Ein Pro Argument zu FB:
Es mag auch Mitbewohner geben, die das "moderne Zeug" nicht mögen, aber FB.