Danke, aber muss das dann Niederspannung sein?
So wie der hier?
https://www.livolo-deutschland.de/p/einfacher-ta…ld-vl-c701ch-13
Oder "Normal" so wie der hier?
https://www.livolo-deutschland.de/p/einfacher-ta…old-vl-c701b-13
Aus der Anleitung:
I1, I2, I3, I4: Switch/button/potentiometer
input terminals for light control
Es ist für mich einfach nicht klar, was ich da am Besten anschließe und als normalen Wandschalter / -taster verwenden kann.
Hallo, ich bin mir immer noch nicht sicher welche Art von Taster ich in der Wand verbauen soll. 
Würde der hier von Bseed funktionieren um den RGBW PM zu schalten und zu dimmen?
Ich denke, der Editor mag es auch nicht, wenn während der Registrierung bereits Einträge beim "outgoing websocket" vorhanden sind.
OK, ich glaub ich hab's verstanden.
Nach dem Anschlussdiagramm wird der Taster direkt am Contoller angeschlossen und der Trafo steht unter Dauerstrom.
Wenn das nicht so ist, bin ich für einen Tip dankbar.
Hallo,
zwar habe ich diesen Post zum Them gefunden:
aber richtig schlau hat der mich nicht gemacht
Ziel:
Ich möchte meine LED Streifen schalten.
Klingt einfach! Aber ich tu mich schwer, weil ich nur 2 Möglichkeiten sehe.
Bei 1. ist WIFI zwingend notwendig, bei 2. funktioniert nix, wenn der Trafo aus ist.
Ein Dilemma! Oder? Wie geht's am Besten?
Jetzt kann ich natürlich den Trafo z.B. mit einem 1PM schalten und so von hinten durch die Brust in's Auge... Aber das kann es doch nicht sein. 
BTF Lighting war für mich eine gute Wahl. Die Auswahl ist riesengroß und durch direkte Bestellung beim Hersteller (China) war es auch günstig.
Für mich waren es am Ende diese:
Kein COB aber mit 60 led / m und Diffusor echt gut.
Was die Relation von Preis und Qualität angeht kann ich nur spekulieren, dass die (meisten) deutschen Händler auch China Ware (aber deutlich teurer) verkaufen.
Und NEIN, ich bekomme keine Provision 
Alle Tips hier solltest du, bei dem unübersichtlichem Angebot, als unverbindlich und ohne jegliche Relevanz betrachten.
Ich habe eine React / Nodejs Applikation für das Monitoring und die Kontrolle von Shellies entwickelt und sie als Open Source zur Verfügung gestellt.
https://github.com/akreienbring/s-central
Hier, als Einstieg, ein Auszug aus dem Github Text. Software und Release kann ab sofort verwendet werden. Über Feedback und vielleicht sogar Mithilfe würde ich mich natürlich freuen.
------------------------------
S-Central is a client (React) / server (nodejs) application to monitor and control your Shelly devices. The server collects all relevant information about your devices by using RPC calls and websocket connections. The client is a webapplication that makes monitoring and controlling your Shellies easy.
S-Central is cloudless. That means it makes you (sort of) independent from the Shelly Cloud Control Center.
The server must run in your local network and acts as a broker between your Shellies and the client application. The communication with the client is strictly websocket based.
S-Central supports English, Spanish and German.
Managing many Shellies in a network is a challenge. The original Shelly Control app is a good choice. But it is cloudbased. Hence you need an internet connection to control your devices. S-Central needs only Wifi and your local network. It is Open Source and transparent. You are welcome to participate and enhance the features.
OK! Vergiss das was ich oben geschrieben habe. Der RGBW PM ist selbst ein Bluetooth Gateway.
Evtl. ist das hier ein Ausgangspunkt für dein BLE Scanner Script:
https://www.shelly.com/de/blogs/scrip…on1-integration
Bei den RPC calls müsstest du dann mit der lokalen IP 127.0.0.1 arbeiten können.
Bsp:
http://127.0.0.1/light/0?turn=on&brightness=60
Hallo, zwar besitze ich den Shelly BLU RC Button nicht, aber wenn der so funktioniert wie die anderen BLU Button, dann brauchst du ein Gateway (wie z.b. den I4 oder 1PM) um mit einem BLE Scanner Script die Push Events auf deine RPC calls an den RGBW PM zu mappen.
Und die RPC calls werden über das WLAN gesendet.
Kurzform: Ich glaube, das was du willst geht einfach nicht. 
Hi, ich kann dir hier die Basics beschreiben:
Wenn das Script startet, fügst du einen "EventHandler" hinzu
Shelly.addEventHandler(
eventCallback
);
Der Handler wertet dann die Events der Buttons aus und dort fügst du einfach deinen Code hinzu. Beispiel:
/*
Reacts on the event from a button push.
Add more reactions here for more functionality.
'id' is the id of the button (1 - 4)
'event' is the type of push (btn_down, btn_up, single_push, double_push, triple_push, long_push)
*/
function eventCallback (event) {
//log('Received Event: ' + JSON.stringify(event));
if (typeof (event.info) !== 'undefined') {
if (event.info.event == 'single_push' && (event.info.id == 1 || event.info.id == 2)){
log('button: ' + event.info.id);
};
};
}
Klar! Danke! Wieder mal den Wald vor lauter Bäumen nicht gesehen. 
Habe eine Frage zu Sommer- / Winterzeit.
Auch ich erzeuge mit dieser Funktion verschiedene Date / Time Formate:
function getCurrentDateTime(nType, nDateTimeInput) {
const nCurrentDateTime = (Shelly.getComponentStatus("sys").unixtime + 2 * 3600) * 1000;
let nDateTime = nDateTimeInput;
if(nDateTime == 'undefined') nDateTime = nCurrentDateTime;
const dDateTime = new Date(nDateTime);
switch(nType) {
case 1:
return nCurrentDateTime; //return as number
break;
case 2:
return dDateTime; //return as date
break;
case 3:
return dDateTime.toISOString(); //return as string
break;
case 4:
return dDateTime.toISOString().slice(0,10) + ' ' + dDateTime.toISOString().slice(11,19); //return date and time
break;
case 5:
return dDateTime.toISOString().slice(11,19); //return only time
break;
default:
log('undefined DateTime Type: ' + nType);
return 'undefined';
}
}
Problem: Das stimmt nur im Sommer Also während der Sommerzeit. Hat jemand eine Idee wie die Umschaltung automatisch berücksichtigt werden kann?
Tja, du Glücklicher! Bei mir wurden die Shellies nicht einmal vom Script Editor gefunden. Ich glaube, dass die VSCode Erweiterung nicht weiterentwickelt wurde und daher möglicherweise mit der aktuellen Firmware nicht mehr funktioniert.
verweigert sich Shelly (noch) hartnäckig...
Hast du dir mal Script.eval angeschaut?
Ich geselle mich zur Gruppe der "PM Mini Gen3 schaltet sich von selbst ein" leidgeprüften. Ziemlich sicher sind das irgendwelche "Impulse" aus dem Stromnetz. Hab ich jetzt durch einen Gen2 ersetzt.
Mal sehen, ob das wieder vorkommt...
Ohne es versucht zu haben, dennoch meine Gedanken dazu:
Ohne ein übergeordnetes System wird das wahrscheinlich schwierig bis unmöglich. Denn die Frage ist: Wie kommst du an den Code? Der muss entweder geladen werden (REST Zugriffe) auf deine Domain oder von außen geschrieben (Script.PutCode...).
Ein einfaches Laden (wie in HTML / Javascript) sehe ich hier nicht.
Hallo, ich habe in letzter Zeit gute Erfahrungen mit node.js (pur Javascript) gemacht. Die Kommunikation mit den Shellies läuft über die rpc Aufrufe oder über die outbound und inbound Websockets. (Nebst Authenfifizierung, wenn mit Passwort geschützt.
Auf den Shellies lauften Scripte, die dann bei Bedarf auch mit der node.js Lösung Daten austauschen.
Beschreib mir gerne mal, was du brauchst. Evtl. kann ich unterstützen.
Danke! Vielleicht sollte ich dazu sagen, dass die Antwort in meinem speziellen Fall vernachlässigt werden kann. Mir geht's gerade vorallem um das Setzen von Switch / RGBW Werten.
Aufrufe möglichst reduzieren. (tlw. machen bei zuvielen Calls die Gegenseite temporär dicht)
DAS stimmt! Ich setze die white, brightness, rgb Werte mit Hilfe von (Javascript) Slidern und übertrage sie direkt an den Shelly. Ohne einen Schutz verweigert der Shelly ruckzuck die Arbeit.
Falls mal jemand das Problem hat: debouncing hilft. Es verringert die Anzahl der Requests an den Shelly.
Hat jemand noch eine Einschätzung zur Performance der verschiedenen Möglichkeiten?
Dies ist zwar nicht wirklich eine Scripting-, sonder mehr eine API Frage. Aber wo wäre sie besser aufgehoben?
Bekanntlich gibt es mindestens drei Wege mit den (Gen2) Shellies zu kommunizieren (RPC Calls auszuführen)
Habt ihr Erfahrung mit der Performance der einzelnen Methoden? Ich kann mir vorstellen, dass ein offener Websockt schneller ist, als einzeln abgesetzt HTTP Requests. Hab's aber eben noch nicht getestet...
Danke vorab
Zum RPC Call Limit gibt es einen Workaround in der Toolbox von Dekat. Er puffert die Calls, wenn nötig.
Hab auf die Schnelle aber nur diesen Beitrag dazu gefunden:
Vielleicht kommst du von da aus weiter.
