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.
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.
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.
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. 
Zweiter Nachteil: Für das Steuern des Rollladens ist Ein-Knopfbedienung erforderlich.
Das könnte ich ggf. per Skript anders lösen.
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.
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:°CDamit wird die Payload der MQTT Nachricht folgende Komponenten haben.
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.
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.
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
Geeignetes Verfahren
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.
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.
Die Nutzung eines Shelly Gen 3 zur Weiterleitung von BLU H&T Nachrichten gelingt vorzüglich und relativ leicht.
Alternativ zu den MQTT Nachrichten durch das System kann man Actions nutzen. Inzwischen gelingt es mir auf unterschiedliche Weise, per Actions und sehr einfaches Skript Nachrichten frei zu gestalten. Hiermit kann ich auch den doofen Schlüssel "bthomesensor:<id>" vermeiden und "leicht verdauliche" Schlüssel in der JSON Payload selbst kreieren.
Sind die 18V Gleich- oder Wechselspannung?
18V DC zur Versorgung eines Shelly Plus 1 habe ich nie versucht. Dazu kann sicher thgoebel etwas mitteilen. Ich kann dir aber dafür einen Shelly Plus Uni empfehlen. Der arbeitet sehr gut mit 18V, hat u.a. zwei binäre Eingänge und zwei per Optokoppler potentialfrei schaltende Ausgänge. Dies habe ich afaik bereits weiter oben angemerkt.
Alternativ kannst du sicherheitshalber zur Shelly Plus 1 Versorgung einen (einstellbaren) Gleichspannungswandler 18V DC -> 12V DC nutzen.
und den freien SW für den Magnetschalter verwende
Das geht dann jedenfalls, wenn der Magnetschalter funktioniert. Letzteres stelle ich auf Grund deiner dbzgl. Probleme an Analog In in Frage.
Die per Shelly Generation 3 vom System gesendete MQTT Nachricht für Sensordaten:
Hinweis
Ich nutze Node-RED und kann damit über ein Workaround per Stringverarbeitung, was suboptimal ist, aus der Payload den Schlüssel "bthomesensor:xxx" in "bthomesensor" transformieren. Ich kenne derzeit keine andere Möglichkeit.
Ich verstehe absolut nicht, warum im Schlüssel die id enthalten ist. Das ist in anderen Components auch so. Dies ist redundant, weil im dazugehörigen Wert (ein Objekt) noch einmal die id enthalten ist. Aber das ist ein anderes Thema.
Nun weiß ich allerdings noch immer nicht, wie ich diese Daten per RPC abfragen kann.
Auch täte ich diese gerne in eine Action packen, bspw. um diese einer Skriptfunktion als Parameter zu übergeben.
Ein Eventhandler bekommt von den BLU Daten leider nicht mitgeteilt.
???
Heureka, ich glaube, es gefunden zu haben ...
In der MQTT Konfiguration "Generic status update over MQTT" aktivieren.
Dann kommen mit anderen Id die Werte, der Rest ist Selektion.
Ich gab wohl hier mal bereits nach 2h vorläufig auf, was ich sonst sehr selten tue.
Also zunächst Problem gelöst. 
Ich experimentiere mit Shelly BLU Geräten. Ich nutze die Web UI der Shelly Geräte. Auf einem Shelly 1 Gen 3 habe ich unter Components u.a. den Shelly BLU H&T hinzugefügt. Die Web UI zeigt mir brav gemessene Werte (Temperatur, rel. Luftfeuchtigkeit) an. Diese Werte möchte ich ohne Cloud übertragen lassen.
Ziel: Ereignisse, auch denen der BLU Geräte, per Topic <Shelly Pretopic>/events/rpc mit Nutzdaten per MQTT empfangen
Das gelingt mir bisher: Ich erhalte MQTT Nachrichten, in denen folgendes enthalten ist - am Beispiel BLU H&T:
Damit kann ich für mein Ziel nichts anfangen. Ich konnte bisher nicht herausfinden, wie ich per Shelly Gen 3 die Nutzdaten übertragen bekomme. Auch per Action gelingt mir das noch nicht, auch nicht, wenn ich per Methode Script.Eval eine Skriptfunktion aufrufen lasse. Ich weiß schlicht nicht, wie ich an die Daten herankomme. Per Eventhandler (Skript) gelingt mir das auch nicht.
Frage: Wie gelange ich an die Daten eines BLU Gerätes zwecks Übertragung, ob per MQTT oder HTTP?
Dann möchte ich ergänzen.,dass (Shelly) BLU Geräte Nachrichten von einem skriptfähigen Shelly, wie Plus 1 oder Plus Uni oder ..., per Auswahl aus bereits vorhandener Skripten verarbeitet werden können. Alle diese Skripte, wovon man nur ein oder zwei braucht, müssen für eigene Zwecke angepasst werden.
Btw, Michael (Nickname: ostfriese) hat mal ein Skript für Ruuvi Sensoren erstellt, welches eine komfortable Weboberfläche und darüber Einstellmöglichkeiten bietet. Die Ruuvi sind erheblich genauer kalibriert - Michael sprach gar von "geeicht", als die Shelly BLU Sensoren.
Das sei nur der Information wegen mitgeteilt.
Wer vorgegebenen Shelly Konsumstandard nutzen will, muss, wie horkatz feststellte, die Cloud mit deren eingeschränkten Möglichkeiten nutzen.
