Beiträge von eiche

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

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

Zitat

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!

Ich habe in Ruhe noch einmal über die Situation nachgedacht und will einige Gedanken festzurren.

1. Status Quo
   1. Der Antriebsmotor ist nicht unmittelbar ansteuerbar.
   2. Ausschließlich über einen einzelnen Taster kann derzeit der Rollladen manuell gesteuert werden.
   3. Ziel: Ein geeignetes Shelly Gerät soll folgendes (wieder)herstellen.
      1. Eine vormals vorhandene Bedienbarkeit, wenn auch mit anderen Endgeräten (Benutzer Frontends).
      2. Die Nutzung von Zeitplänen, incl. Sonnenauf- und Sonnenuntergang.
2. Als Shelly Gerät ist kein dafür von Herstellerseite vorgesehenes Gerät geeignet, weil diese unmittelbar am Antriebsmotor angeschlossenen werden müssen.
3. Als Gerät ist (ausschließlich) ein Gerät mit potentialfrei schaltbarem Ausgang geeignet, der statt des vorhanden Tasters einzusetzen ist - bspw. ein Shelly Plus 1 ohne PM!
4. Der vorhandene Taster oder ersatzweise ein anderer Taster ist zur Ansteuerung des Shelly einzusetzen. Dies gewährleistet bereits die aktuell vorhandene Funktion, ohne dem Ziel nähergekommen zu sein.
5. Eine zielführende Implementation gelingt ausschließlich per Skript(e), welche(s) eine passende Anzahl an Tastendrücken emulieren - also ein Workaround darstellen.

Die Implementation per Skripte gelingt vermutlich am besten mit zwei Skripten.

1. Ein Skript "adapt", welches als Adapter dient. Dieser Adapter nimmt Steueraufträge entgegen und steuert die Elektronik des Rollladenantriebs so, dass dieser wie gewünscht arbeitet.
2. Ein Skript "control" mit klassischer Ansteuerung des Rollladenantriebs, aber, statt verfügbare Shelly Firmware Methoden zu nutzen, Aufträge an "adapt" weiterreicht.

Eine solche Aufteilung macht die Funktion jedes Skripts transparent und unterstützt die Pflege des Projektes. Ich bin davon überzeugt, dass das Ziel hiermit erreichbar ist, mit o.a. Einschränkungen (s. 1.3 und folgendes). Insbesondere die in der Web UI und der Cloud vorgesehenen Bedienungselemente sowie die Nutzung von Sprachassistent-Routinen werden damit nicht zur Verfügung stehen. Eine hiermit unmögliche Kalibrierung wäre durch Zeitmessungen zu ersetzen, deren Zeitspannen für die Skripte zu konfigurieren wären. Es könnte optional ein drittes Skript zum Zuge kommen, welches eine anwendungsgerechte Webseite zur Verfügung stellt und so per Web Browser nutzbar wäre, notfalls sogar bei Ausfall des WLAN.

Das Anlegen von Zeitplänen müsste hierzu zunächst ohne App oder Web UI vorgenommen werden. Nach dem Anlegen solcher Zeitpläne bietet die Web UI genügend Optionen, solche Zeitpläne umzugestalten. Hierfür kann ich bei Bedarf zusätzliches darlegen.

Insgesamt ist dieses Projekt ein etwas größerer Brocken und nicht mal eben schnell implementierbar, jedenfalls nicht für mich.

ursi29

Das folgende Skript kann für das Workaround allenfalls als Grundlage angesehen werden. Für deinen Zweck muss es abgeändert werden, da hier kein Component "cover" vorkommen wird. Stattdessen ist als Component "switch" zu verwenden. Ich habe die entsprechende Zeile im Event Handler ergänzt.

Vielleicht ist es zielführender, hier ein völlig neues Skript zu kreieren. Vielleicht kann es aber auch per Adapterfunktion ergänzt werden, welche eine definierte Anzahl an Schaltimpulsen ausgibt. Ich will mal darüber nachdenken. Bisher habe ich solches noch nicht implementiert, scheue mich aber nicht vor einer neuen Herausforderung. Es bleibt die Frage, wie du den Rollladen steuern willst. Per Sprachassistent wird es voraussichtlich nicht gelingen, aber Zeitpläne werden möglich sein.

// created by Gerhard Eichelsdörfer alias eiche, 2024-04-13
// Application for a roller shutter controlled by a single button

// Succ beinhaltet zu einem Schlüssel (key) die Nachfolgemethode als Wert (value)
// Die Struktur jedes Eintrags ist Schlüssel:Wert.
// Weil die Methode nach "stopped" vom letzten Schlüssel abhängt, ist der Wert von "stopped" ein zusammengesetztes Objekt
// bestehend aus zwei Einträgen. Jeder Eintrag beinhaltet als Schlüssel einen möglichen vorherigen Schlüssel.
// Damit ist für diese Anwendung eine hierarchische Struktur aus Einträgen konfigurierbar,
// in welcher jeder Eintrag einen einfachen Wert (einstufig) oder eine Struktur (zweistufig) mit einfachen Werten enthält.
// Diese Konfiguration wird anwendungsgerecht von eventHandler() verarbeitet.
let Succ = {
  "opening":"Cover.Stop",
  "closing":"Cover.Stop",
  "stopped":{"opening":"Cover.Close","closing":"Cover.Open"}, // Nach "stopped" gibt es zwei mögliche Nachfolgemethoden.
  "closed":"Cover.Open",
  "open":"Cover.Close"
};

let last = null, // für das letzte Ereignis (event)
next = null; // für die auf das letzte Ereignis folgende Methode

function eventHandler(e) {
  //print(e.name);
  switch(e.name) {
    // case "cover": // only for cover mode at Shelly Plus 2PM
    case "switch": // for Shelly Plus 1
      e = e.info.event;
      //print(e);
      if(e===undefined) return;
      if(Succ[e]===undefined) return;
      let s = Succ[e];
      switch(typeof(s)) {
        case "string": next = s; break;
        case "object": next = s[last]; break;
        default: return;
      }
      last = e;  
      print("last: "+last+", next: "+next);
      break;
    case "input": // Diesen Teil habe ich nicht getestet.
      if(typeof(next)==="string")
        Shelly.call(next, {id:0}, function(res, errc, errm) {
          if(errc) print(errc, errm);
        });
      break;
  }
}

Shelly.addEventHandler(eventHandler);

1. Das lässt darauf schließen, dass der Funk gestört bzw. die Funkanlage ausgefallen ist.
   Hast du mal den dazugehörigen Leitungsschutzschalter (Sicherung) aus und wieder eingeschaltet? Dies sollte ein Power On Reset für die Schaltelektronik ergeben.
2. Wenn der Rollladen noch per Taster steuerbar ist, kann hier ggf. ein Shelly Skript als Workaround genutzt werden. Das Skript müsste ggf. mehrere Tastendrücke nacheinander auslösen, um eine bestimmte Reaktion der Anlage zu erzeugen. Ich habe mal in einem anderen Thread einen ersten Entwurf zu einem Eintastenbetrieb auf einem Shelly Plus 2PM gepostet und kann diesen Skriptentwurf bei Bedarf auch hier als Grundlage zur Verfügung stellen.

zu 2. Stehen dir an der Position des Tasters L und N zur Verfügung bzw. kannst du beide Leitungen dort verfügbar machen? Wenn ja, kannst du mal mit einem Shelly Plus 1 (ohne PM, potentialfrei schaltend) experimentieren. Dazu sind die Ausgangsklemmen parallel zum Taster zu verdrahten. Der Rest muss dann das Skript übernehmen, welches jeweils die letzten beiden Aktionen speichert, um daraus die nächste Aktion zu generieren.

Jedenfalls ist der übliche Einsatz eines Shelly Plus 2 im Shutter Modus hier ungeeignet.

Zitat

Ist echt schlimm, man soll mit >80 nichts mehr machen.

Dieser Aussage widerspreche ich vehement!

Zitat

z.B. runter - stop - rauf - stop - runter usw.)

Dann bliebe allenfalls die Simulation des manuellen Tastendrucks per Shelly ab zweiter Generation und Skript. Dazu wäre zusätzlich die Information erforderlich, wie der Antrieb nach einem Stromausfall auf einen solchen Tastendruck reagiert. Nach deiner Beschreibung ist die obige Schaltskizze aber fehlleitend, weil statt des Motors der Funkempfänger einzutragen wäre.

Mal unabhängig von Vorschriften und sonstigen Sicherheitsbedenken über das "Problem" von zu starken Strömen über einen Stromkreis fremden Nullleiter für den Shelly nachgedacht.

Dies soll keine Empfehlung für den TE Godspeed sein!

Solange dieser Nullleiter ausschließlich zum betreiben eines Shelly dienen soll, ist ja nur dessen Versorgungsströmchen wirksam und hat nichts mit den zu schaltenden Geräten zu tun.

Habe ich da etwas übersehen?

Vorweg: Ich habe keinerlei Erfahrung mit funkgesteuerten Rollladenantrieben. Beim Einbaue meiner Rollläden achtete ich darauf, einfache Motoranschlüsse für meine Selbstbau Smart Home Installation zu haben, was sich bestens bewährt.

Ich sehe in der Schaltskizze von ontario00 nur einen Taster, welcher offenbar der manuellen Bedienung des Rollladens dient. Auf der Rademacher Webseite zu Fernotron Programmierzentrale 2411 sehe ich aber insgesamt fünf Teile abgebildet. Diese sind vermutlich als Abbildungsrepräsentanten für alle möglichen Teile dieses Systems zu verstehen. In der Gebrauchsanleitung auf Seite 7 sind verschiedene Teile und deren Zuordnungen zu drei Funktionskategorien aufgeführt. Ich werde mir, ohne selbst eine solche Anlage zu haben, nicht die Mühe machen, diese Gebrauchsanleitung zu durchforsten. Deshalb meine Fragen.

1. Wozu dient der in der Schaltskizze dargestellte einzelne Taster? Dessen Funktion ist mir bisher unbegreiflich.
2. Nach meinem Eindruck ist der Funkempfänger eines Rollladenantriebs separat installiert und schaltet den Motor. Dann sollten die Motoranschlüsse erreichbar sein und vermutlich aus drei Anschlussleitungen bestehen (+ PE). Dies scheint die obige Schaltskizze auch zu zeigen. Wenn dem so ist, kann ein Elektriker leicht den Funkempfänger abklemmen und die Funktion der drei Anschlussleitungen testen. Die Ergebnisse eines solchen Tests wären grundlegend für die Nutzbarkeit von Shelly Plus 2PM Geräten - oder auch der älteren Shelly 2.5.

Ich könnte vielleicht weiterhelfen, wenn meine Fragen eindeutig beantwortet werden.

Zitat

Zu 2: Kreuzschaltungen waren schon immer meine Nemesis. Verzeih mir wenn ich so doof nachfrage, aber wenn bei einer Kreuzschaltung jemand über einen der Schalter das Licht ausschaltet, dann kommt doch bei der Lampe kein Strom mehr an. Wenn ich jetzt also statt der Lampe den Shelly anschließe, dann hätte der ja auch keinen Saft mehr und könnte doch gar nicht schalten. Oder was raffe ich hier grad nicht?

Dafür braucht der Shelly Dauerphase. Die Kreuzschalter schalten dann ausschließlich das Eingangssignal (SW) des Shelly, welcher durchläuft. Auf Grund des Eingangssignals schaltet der Shelly die Lampe genauso wie es zuvor die Kreuzschaltung tat.

Edit: Als Installationsanleitung für zwei unterschiedliche Situationen

1. An der entscheidenden Stelle eines Schalters (oder Tasters) gibt es Dauerphase und N.
   Dann kannst du zumindest elektrisch dort einen Schalt-Shelly montieren. Die Leitung, welche bisher zur Lampe führt, muss an den schaltenden Ausgang des Shelly umgeklemmt werden. Eine kurze Leitung vom Schalterausgang muss zum SW-Eingang des Shelly führen.
2. An der entscheidenden Stelle eines Schalters (oder Tasters) gibt es kein N.
   Dann kannst du - ober besser ein Elektriker - die Leitung vom bisherigen Schalterausgang an die Dauerphase umklemmen.
   Nun das Entscheidende: Du brauchst hier zwei Shelly.
   a) Ein Sensor-Shelly (ohne Relais) welchem das bisherige Schaltsignal (geschaltete Phase) an seinem Eingang zugeführt wird und der mit jedem Schaltvorgang eine Nachricht an den zweiten Shelly (Schalt-Aktor) sendet.
   b) Ein Schalt-Shelly (mit Relais) an der Lampe empfängt die vom Sensor-Shelly gesendete Nachricht und schaltet auf Grund des Nachrichteninhalts die Lampe ein oder aus.
   Die Leitung, über welche zuvor die Phase geschaltet wurde führt also nun die Dauerphase. Die Funktion der zuvor per Leitung geführten Schaltspannung wird hier durch Nachrichten per WLAN/Funksignal ersetzt.

Vielleicht werde ich noch eine Schaltskizze nachreichen.

Yes, event.info.id only contains the component Id and can therefore belong to different components.

Zitat

if (event.info.id === 0)

That is not enough. Instead you should use if(event.component==="switch:0") ...

You should use hysteresis instead of just one threshold, e.g.

let OnValue = 10, OffValue = 3;

And in the event handler:

if(power > OnValue) Shelly.call("Switch.Set", {id: 1, on: true});
else if(power < OffValue) Shelly.call("Switch.Set", {id: 1, on: false});

or

if(power > OnValue || power < OffValue) Shelly.call("Switch.Set", {id: 1, on: power > OnValue});

Max Beckenbach

1. Für alle Shelly brauchst du Dauerphase und N zur Versorgung. Es gibt oder gab zwar auch Shelly, die in die Zuleitung (ohne N) zum Verbraucher genutzt werden können, wozu aber eine Grundlast erforderlich ist und ich nicht empfehlen kann.
2. Wo bspw. ein Zweifachschalter in einer Dose sitzt kannst du ggf. einen Shelly Plus 2PM oder einen Shelly i4 einsetzen. Der 2PM kann sellbst schalten, der i4 nur Nachrichten an einen Schalt-Shelly senden.
3. Bei bestehender Kreuzschaltung brauchst du nur einen Shelly für die Lampe. Dieser wird statt der Lampe angeschlossen, braucht dafür aber Dauerphase und N. Der Shelly schaltet dann seinerseits die Lampe. Das können auch alte Shelly der ersten Generation. Wo du den Shelly platzierst, bleibt dir und der Verfügbarkeit von Dauerphase und N überlassen. Jedenfalls brauchst du hier nicht je Kreuzschalter einen Shelly.
4. Ja, ein Shelly kann prinzipiell per URLs Nachrichten an andere Shelly direkt senden. Es kann aber bei Bedarf auch MQTT genutzt werden.
5. Falls du auf einfache Weise einen bisher nicht vorhandenen Taster wünschst, kann dies per Shelly Button (akku- oder batteriebetrieben) recht einfach gelöst werden.
6. Mit diesen Shelly kannst du die verrücktesten Dinge implementieren - mit und ohne Cloud. Was nicht per Konfiguration gelingen sollte, wird per Skript gelingen.

Flutschi

Kannst du deine extrem kurze Frage präzisieren?

Ich versuche, obwohl ich nicht sicher weiß, wonach du fragst, trotzdem zu antworten.

Angenommen eine Person betritt den Bewegungsmelderbereich. Dann wird die Lampe für eine definierte Dauer eingeschaltet. Weiter angenommen, die Person gelangt erst danach an den Schalter/Taster und will, dass die Lampe eingeschaltet bleibt, weil sich die Person dort länger aufhalten will. Dann ist es zielführend, dass die Lampe erst ausgeschaltet wird, nachdem die Person zu diesem Zweck den Schalter/Taster betätigt. Dann darf die Lampe nicht vorher auf Grund des Ablaufs der definierten Dauer ausgeschaltet werden.

Ich habe mich bisher nicht mit Websockets beschäftigt. Sendet ein ruuvi nicht per Bluetooth?

Für die Werte kann man den Zufallsgenerator nutzen bzw. einen Zufalls-Wrapper programmieren.

Ich verstand noch nicht, warum du Events senden lassen willst. Kommen die Bluetooth-Nachrichten per Event herein?