So etwas erlebte ich letztens auch. Mein Zitat war aber sehr umfangreich. Ich stellte verzögert fest, dass ich es noch nicht gekürzt hatte. Als ich dies nachholen wollte, erhielt ich keinen Zugriff darauf und dann war der nur aus dem Zitat bestehende Beitrag plötzlich weg. Ich vermute, dass ein Moderator diesen "Beitrag" entfernte, was mir schließlich entgegenkam.
Es mag sein, dass ich mit der Technik des Zitierens im Forum noch nicht genügend bewandert bin.
Vielleicht hilft's ein wenig zum Verständnis.
Die Anschlüsse "0&1" heißen richtig I und O.
I bedeutet Input und ist die Eingangsklemme des Shelly internen Schalters.
O bedeutet Output und ist die Ausgangsklemme des Shelly internen Schalters.
Dieser Shelly interne Schalter ist afaik bisher immer ein elektromagnetischer Schalter, auch Relais oder Schütz genannt.
Ein solches Relais in den Shellies ist sehr klein und hat demzufolge nur kleine Kontakte, welche durch Funkenbildung relativ schnell abgenutzt werden können.
Funkenbildung entsteht immer beim Ausschalten von induktiven Lasten (Spulen und Elektromotoren).
Die technische Nutzung der Funkenbildung ist vielleicht bekannt im Ottomotor eines Kfz bei der Erzeugung des Zündfunkens per Unterbrecher und Zündspule.
Bei Gleichstromversorgung hilft gegen Funkenbildung eine sog. Freilaufdiode.
Bei Wechselspannung ist eine solche Diode ungeeignet und würde zudem sofort zerstört. Hier dient in erster Linie ein bipolarer Kondensator (kurz C),
um die Überspannung zwischen den Kontakten des Relais quasi kurzzuschließen, damit sich möglichst kein Funke zwischen den Relaiskontakten bildet.
Ein zusätzlicher Widerstand (kurz R) in Reihe zum Kondensator begrenzt die Stärke des Überspannungsstromes, was afaik den Kondensators vor zu schneller Alterung schützt.
Ein bipolarer Kondensator besitzt keine spezifische Polarität, im Gegensatz zu unipolaren Kondensatoren, die für Wechselspannung/strom ungeeignet sind.
Das RC-Glied kann nahe an der Last, also am geschalteten Verbraucher oder nahe an den Relaiskontakten (hier I und O) angeklemmt werden.
Ergänzung:
Überspannungen beim ausschalten von induktiven Lasten treten sehr kurz aber heftig auf. Heftig bedeutet hier mit sehr hohen Spannungswerten. Insbesondere die kurze Spitze solcher Überspannungen bewirkt das Abstrahlen von elektromagnetischen Wellen, die als Störstrahlung auftreten.
Solche Störstrahlungen können in der Nähe befindliche Elektronik und besonders einen Microcontroller (kurz µC, hier im Shelly verbaut) so beeinflussen, dass sie nicht mehr wie vorgesehen arbeiten. Hierfür genügt u.U. ein einzelnes Bit, welches auf Grund einer solchen Störstrahlung bzw. elektromagnetische Welle umkippt, d.h. aus einer gespeicherten 0 wird eine 1 oder umgekehrt. Ein solches Umkippen kann den µC "falsch" arbeiten lassen oder gar zum "einfrieren" bringen. Die Shellies erscheinen mir recht empfindlich gegen Störstrahlungen.
Vielleicht ist dies hier keine passende Stelle, na ja ... dann halt verschieben. 
Ich möchte einmal an dieser Stelle ein dickes Lob an Allterco Robotics gerichtet aussprechen.
Die praktizierte offene Philosophie gefällt mir außerordentlich. Das ist alles andere als selbstverständlich.
Ich hoffe, dass Allterco noch lange seine Produkte vermarkten kann.
Insbesondere die zweite Generation mit den Scriptmöglichkeiten sagt mir besonders zu. Bis auf weiteres brauche ich nicht auf Tasmota auszuweichen, obwohl mir derzeit Tasmota32 und Berry noch etwas besser gefallen und die aktuelle Firmware 0.10.1 noch Fehler hat.
Die Zielrichtung ist aber sehr überzeugend.
P.S.: Nein, ich werde nichts davon auf FB verlauten lassen. Ich bin kein FB Mitglied und mag FB nicht - sehr zurückhaltend ausgedrückt.
Puh, Software kann schwierig sein - insbesondere, wenn sie auf Kommunikationspartner angewiesen ist. 
Mein Tipp dazu ist Node-RED als Werkzeug. Damit lässt sich auf relativ einfache Weise nach Nachrichten und Fehlern suchen.
Man muss damit keine Anwendung erstellen.
Hallo und guten Tag.
Ich nutze mehrere Shelly i4 zusammen mit Shelly 4fach Tastenfeldern. Diese steuern derzeit überwiegend Rollläden, sind aber auch für andere Zwecke nutzbar, bspw. zum schalten von Lampen.
Hierfür habe ich ein kleines Script erstellt, welches per Konfiguration nutzbar ist. Wer es einsetzen will, braucht nur in der vorgesehenen Datenstruktur für ihn/sie passende Einträge zu erstellen.
Mein Script wertet per Eventhandler die gedrückte Taste (id) und die Dauer des Tastendrucks aus, um daraufhin die gewünschte Nachricht zu senden. Eine solche Nachricht kann derzeit ein HTTP Request oder eine MQTT Nachricht sein.
In der Allterco Terminologie wird ein HTTP Request auch als "IO URL action" oder "Webhook" bezeichnet.
Mein Englisch ist eingeschränkt. Ich bitte ggf. vorhandene englischsprachige Verfehlungen zu entschuldigen oder/und zu korrigieren.
Hinweis - insbesondere für Anfänger: Das folgende Script soll dazu dienen, es per Konfiguration zu verwenden. Die Konfiguration ist in deren Möglichkeiten etwas komplex, kann aber auch relativ einfach zusammengesetzt werden.
Hier mein Script für einen i4:
// MQTT topics
let Pre03 = 'Wohnen-links/'; // 03 means button 0 or button 3 at right hand side
let Cmd03 = Pre03+'cmd';
let Status03 = Pre03+'status';
// HTTP requests
let Url12 = 'http://172.16.3.67/roller/0/command?go=';
let AlterUrl = 'http://172.16.3.65/relay/0?turn=toggle';
// timestamps array for storing at the begin of a button press, one element for each button
let Timestamp = [0,0,0,0]; // id 0 .. 3
// in State the last state of the target device will be stored, if neccesary
let State = ['stopped','stop']; // here: the states of two roller shutters respective there shelly controllers - first a Plus 2, second a 2.5
let Idx = {left:1, right:0}; // assigning left/right to State index
// dependState imports a command value and returns a command value depending of the assigned device state
let dependState = function(id, p){
if(id<0 || id>3) return p;
let i = id===0 || id===3 ? Idx.right : Idx.left;
return p===State[i] ? 'stop' : p;
};
// list with one entry for each input id as index
// Each entry consists of a list of durations bounds (d),
// each followed by an MQTT message (msg), consists of topic (t) and payload (p)
// or an http-request URL (url) followed by a parameter string (p), which may be empty ('').
// Finally there may exist an optional function (pointer f) and an optional index (i) as call parameter to f.
// f may processes a payload respective parameter before sending.
// For useful codings this list entries should be ascending ordered by d values.
let cfg = [ // d=duration bound, msg=mqtt message, url=http request url, t=mqtt topic, p=payload/parameter
[{d:1, msg:{t:Cmd03,p:'open'}, f:dependState, i:Idx.right}], // id 0
[{d:1, url:Url12, p:'open', f:dependState, i:Idx.left}], // id 1
[{d:1, url:Url12, p:'close', f:dependState, i:Idx.left}], // id 2
[{d:1, msg:{t:Cmd03,p:'close'},f:dependState, i:Idx.right}] // id 3
];
// only assigned to button 0 or button 3 (right hand side)
MQTT.subscribe(Status03,
function(topic, payload){
State[Idx.right] = payload;
}
);
// act() publishs an mqtt message (topic, payload) or sends an http request registered in cfg
// with the first d value greater than the imported duration.
function act(id, duration) {
let n = cfg[id].length;
for(let i=0; i<n; ++i){
let entry = cfg[id][i];
if(duration < entry.d){
//print(JSON.stringify(entry));
if(entry.msg!==undefined){
let msg = entry.msg;
if(msg!==null){
let p = entry.f===undefined ? msg.p : entry.f(entry.i, msg.p);
//print(msg.t,p);
MQTT.publish(msg.t, p, 0, false);
return true;
}
}
if(entry.url!==undefined){
Shelly.call('http.get',
{url: entry.url + ((entry.p===undefined) ? ''
: (entry.f===undefined ? entry.p : entry.f(id, entry.p)))},
function(response, errc, errm, i){
//print(response.body);
State[i] = JSON.parse(response.body).state;
}, entry.i
);
return true;
}
}
}
return false;
}
Shelly.addEventHandler(
function (event) {
if(event.name==="input"){
let id = event.info.id;
if(event.info.state) Timestamp[id] = event.info.ts
else{
let ts = Timestamp[id];
if(ts>0){
let dt = event.info.ts - ts;
// true: act could performed, false: nothing done
let done = act(id,dt);
if(!done) {
// do something else
Shelly.call('http.get',{url:AlterUrl});
}
}
}
}
}
)Dieses Script für ein 4fach Tastenfeld steuert zwei Rollläden, einer per Shelly Plus 2, der andere per Shelly 2.5. Zusätzlich wird eine Leuchte damit geschaltet, wenn der Tastendruck einer der 4 Tasten mindestens 1 Sekunde dauert.
Die print() Aufrufe dienen nur der Betrachtung von Laufzeitwerten zwecks Debugging oder Erkenntnisgewinnung. Sie sind bei Bedarf zu "entkommentieren", d.h. die linksseitig terminierten Kommentarsymbole (//) sind dann zu entfernen.
Erforderliche bzw. zweckdienliche Anpassungen im Script:
Zu Punkt 2: Datenstruktur cfg
cfg ist ein Datenfeld (array) aus 4 Einträgen, die komplex sein können - zu jeder Taste ein Eintrag. Die Tasten Id wird als Index zum Zugriff auf das Datenfeldelement verwendet.
In jedem dieser 4 Datenfeldelemente sind im JSON Format in knapper Form die gewünschten Nachrichten und deren Rahmenbedingungen einzutragen. Ein Element darf auch leer sein, wenn es nicht gebraucht wird. Dann ist hier ein Paar eckiger Klammern [ ] einzutragen.
In diesen eckigen Klammern (Datenfeld) können beliebig viele JavaScript Objekte bzw. Strukturen eingetragen werden, jeweils per Komma getrennt.
Die einzelen Eigenschaften (d, i, msg, url, f) der Objekte können auch in anderer Reihenfolge eingetragen werden. Entscheidend sind die Namen der Eigenschaften bzw. keys (d ... f). Die Bedeutung der einzelnen Eigenschaften eines solchen Objektes sind:
Da dieses Script recht vielseitig verwendbar ist ( a generic script ), erscheint dessen Konfiguration etwas gewöhnungsbedürftig.
Wenn bspw. eine Taste für mehrere unterschiedliche Nachrichten in Abhängigkeit deren Druckdauer verwendet werden soll, ist ein Eintrag in cfg folgender Struktur einzusetzen:
[ // Eintrag zu einer id, also zu einer der 4 Tasten
{d:1 /* kürzer als 1s */, url:'http://...', p:...}, // Hier sind f und i weggelassen, was durchaus zulässig ist. http get request
{d:3 /* >1s und <3s */, msg:{t:..., p:...}}, // mqtt message
{d:6 /* >3s und <6s */, url:'http://...', p:...}
]Ich stehe bei Fragen gerne zur Verfügung.
Ich habe keine Erfahrung mit diesen Wipptastern. Ich nutze die Shelly 4fach Taster zur Steuerung meiner Rollläden und mehr.
Meinem Eindruck nach bestehen die Unterschiede des Gira zum Shelly aus den Aufdrucken (nach oben, nach unten) und der gegenseitigen Verriegelung.
Beides brauche ich nicht und würde sogar die vielfältige Nutzbarkeit meiner Shelly Taster einschränken.
Ich sehe keinen Grund, warum die Gira 4fach Wipptaster nicht mit einem i4 kompatibel sein sollten. Es sind schlicht die Eingänge und die Ausgänge der Tastergruppe passend anzuschließen.
Allenfalls unterschiedliche Prelldauern könnten einen Unterschied ausmachen. Gegenwärtig weiß ich nicht, wie eine Prelldauer im i4 konfiguriert werden kann. Vermutlich ist das nicht notwendig.
In solchen Fällen kaufe ich ein Exemplar und teste dieses. Bei Tauglichkeit kaufe ich dann so viele, wie ich brauche.
Habe noch einmal nach-gedacht. 
Die Original-Doku zeigt den/die Schalter am 2.5er wie auch am 1er an L angeschlossen. Nachdem ich mir genauer die Schaltskizzen von thgoebel angeschaut habe, bin ich verunsichert.
Schriftlich nachgedacht:
Warum zeigt die Original Doku von Allterco Robotics keinen Eingangsschalter zwischen SW und N? Der Unterschied zur Beschaltung nach L besteht bei Wechselspannungsbetrieb imho nur in der invertierenden Wirkung.
Vermutlich soll die Doku so einfach gehalten werden wie möglich.
Ich vermute hier keinen Fehler in der Kommunikation, da du die App selbst erstellt hast und somit verlässlich erkennen kannst, wann die http request eintrifft.
Ich habe so etwas per Node-RED nachgebildet und kann damit auch sehr leicht Parameter übermitteln und auswerten, bspw. "http://x.x.x.x/...?on=true" bzw. ...?on=false.
Tja, ich dachte zwischenzeitlich, dass du besser den Schalter zwischen SW und N legen solltest. Das sollte zwar funktionieren aber auch nicht besser als die Verbindung zu L.
Nun geht es bei mir in Richtung "Verzweifelt nach letzten Möglichkeiten suchen".
Du könntest den Schalter versuchsweise zwischen SW und N legen. Ich weiß nicht, wie die Firmware die Action Triggerung auswertet.
Lasse so oder so besser die Last am Ausgang weg und höre auf das Klicken des/der Relais. So sollte eine rückwirkende Störung beim Schalten ausgeschlossen werden können.
Falls die Wirkung dann wie erwünscht sein sollte, kannst du statt induktiver Lasten Signallampen anschließen. Wenn es dann immer noch funktioniert, bleibt die Unterdrückung/Dämpfung der Störung beim schalten von induktiven Lasten per RC-Reihenschaltung (Snubber).
Ich hatte versehentlich einen kompletten Beitrag von thgoebel zitiert, woraufhin dieser als mein Beitrag erschien - ausschließlich aus diesem Zitat bestehend. Nun ist er nicht mehr sichtbar. Ich konnte ihn nicht löschen und als ich ihn bearbeiten wollte, war er nicht mehr zugreifbar.
Nun zu meinem eigentlichen Anliegen.
Hallo thgoebel
Schaltet man Klemme SW/IN(x) gegen Klemme N, fließt ein pulsierender Gleichstrom (eben die Halbwelle, gleichgerichtet durch die beiden Dioden D1 und D2) aus Klemme L über Rx und den Schaltkontakt zu Klemme N. Dabei wird die Diode D1 (auf die kommt's an!) pulsierend leitend und schaltet den Transistor im Shelly 1 durch. (In der Innenbeschaltung gibt es an der Basis des pnp-Transistors einen Kondensator, der die Emitter-/Kollektorstrecke des Transistors dauerhaft leitend läßt.)
Ich habe deinen Beitrag bzgl. Eingangs (SW) Beschaltung interessiert gelesen. und habe dazu (vorläufig) zwei Fragen.
Gruß Gerhard
Laut Google Übersetzer
snubber: an electric circuit intended to suppress voltage spikes.
Wie du obigen Beiträgen entnehmen kannst, sind vermutlich Spannungsspitzen für den Neustart des Shelly verantwortlich. Sei froh, dass er dann neu startet, es gibt schlimmeres.
Zur Fehlersuche ist das Ausschlussverfahren mitunter ein gutes Mittel.
Hier: Klemme einfach mal den einen und dann den anderen Verbraucher ab und prüfe, ob dann der Shelly auch neu startet!
Der bereits erwähnte RC-Snubber ist zum Schutz gegen Störungen nie verkehrt, in deinem Fall evtl. je einen pro Kanal.
Interessant wäre auch eine Antwort auf die Frage von Muetze.
You can also use an LED with a lower consumption, e.g. 2W or lower or an electronic LED, instead of your lamp to check the desired function of shelly 1.
If the function is ok using this LED, the reason for the problem is your power supply.
Ich bin verwundert.
Ich habe bisher die App als reine Cloud App verstanden und erlebt, die allenfalls das Einbinden von lokalen Shellies in die Cloud unterstützt. Dabei geht bei Shellies der ersten Generation bspw. die MQTT Nutzung verloren. Evtl. geht bei schaltenden Shellies noch das Ein-/Ausschalten, mehr aber nicht.
Ich konnte noch nie diese App brauchbar für nur lokale Shellies nutzen. Habe ich da etwas verpasst?
Nebenbemerkung: Ich brauche für die lokale Nutzung die Shelly App auch nicht, falls sie jedoch Komfort in der Gerätenutzung böte, könnte ich mich dafür interessieren.
Ich kann in solchen Fällen bei Shellies der ersten Generation, wovon du schreibst, die lokale Kommunikation empfehlen und ggf. VPN zu verwenden. Ein Raspberry Pi mit Mosquitto als MQTT Broker unterstützt diese Kommunikation imho verlässlich. Man kann auch HTTP requests einsetzen, mein Ding ist das weniger.
Mit Shellies der zweiten Generation kannst du eh Cloud und MQTT zugleich nutzen. Funzt die Cloud mal nicht, steht immer noch die lokale MQTT Kommunikation zur Verfügung.
Ich halte die lokale Kommunikation für verlässlicher. Insbesondere für einen IT ler sollte es kein Problem sein, einen Raspberry Pi als Server 24/7 zu betreiben.
Ich habe kein IPhone, vermute aber, dass es hierfür auch geeignete MQTT Apps als Mensch Maschine Schnittstelle gibt. Auf meinem Android Smartphone nutze ich gerne MQTT Dash, was es aber afaik nicht für IOS gibt.
Du kannst auf einem o.a. Raspberry auch openHAB oder ähnliche Tools installieren. In diesem Zusammenhang sind auch InfluxDB (Zeitreihendatenbank) und Grafana (Web Anwendung für Grafiken auf Basis von Datenbanken) interessant. Mit Node-RED lässt sich sogar ernsthaft programmieren und bei Bedarf MQTT-Adapter bereitstellen. Auch eine WebGUI kann man damit zusammenstellen, die von modernen Browsern dargestellt wird und auf diese Weise schließlich der Shelly App Paroli bieten kann.
Falls du Linux Shellskripte erstellen kannst, kannst du auch kleinere MQTT basierte Dienste bereitstellen (mosquitto_sub, mosquitto_pub, jq, systemctl).
Mit letzterem ist der Arbeitsaufwand größer als bei Nutzung der Shelly App, dafür gibt es deutlich mehr Flexibilität.
Habe ich genug Werbung für Cloud-Alternativen gemacht?
if (daten.info.event === !"undifined")
Schau dir mal deine Zeile an!
! ist der logische not operator. Das sollte nur gehen, wenn "undefined" ein boolescher Ausdruck wäre - und nicht etwa ein String.
Ein Compiler hätte so etwas nicht übersetzt. Bei einer Interpretersprache ist nicht sicher, wie sich der Interpreter verhält.
Schließlich hast du diese Bedingung ja geeignet codiert.
Es passt auch:
if(daten.info.event!==undefined) ...Nun, ich habe meine Idee in knapper Form beschrieben.
Voraussetzung ist eh, dass du dich mit dieser kleinen Scriptsprache beschäftigst und wenigstens eine C bzw. C++ ähnliche Sprache kennst.
Auch die Kenntnisse von anonymen Funktionen sowie insbesondere Formalparameter sind fast Voraussetzung.
Andernfalls wird es sehr mühsam für dich, weil du dich dann noch zugleich mit elementaren Programmiertechniken beschäftigen musst.
Programmieren lernen in 5 Tagen geht heutzutage schlicht nicht.
Darf ich fragen, welche Vorkenntnisse/Erfahrungen du diesbezüglich mitbringst?
Prinzip-Idee:
Last (Power) erfassen. Dies gelingt entweder per Eventhandler oder in der callback-Funktion eines fortlaufende Timers per RPC Abfrage (Shelly.call(...)).
Fortlaufender Timer per Timer.set(Periode, true, callback, ...). Parameter true steht für fortlaufend wiederholen, d.h. die callback Funktion wird nach jeder Periode aufgerufen.
Überschreitet die Last die obere Schwelle, einen fortlaufenden Timer starten, dessen callback-Funktion die Perioden zählt. Sobald die Last die untere Schwelle unterschreitet, den Timer löschen. Überschreitet der Periodenzähler einen Zähler-Endwert, Timer löschen, den Kanal abschalten und Nachricht senden.
Dies ist eine Art Watchdog, der mit Unterschreitung der unteren Schwelle schlafen gelegt wird. Er wird mir Überschreitung der oberen Schwelle geweckt, bellt aber erst, wenn die max. Dauer der Überlast überschritten wird.
Evtl. ist für diesen Zweck eine größere Timer-callback-Funktion zweckmäßig. Globale Variable werden erforderlich sein. Die Parameter sollten bspw. per MQTT einstellbar sein, damit der Anwender dafür nicht im Script Änderungen vornehmen muss. Am besten wäre es, wenn Konfigurationseinträge des Kanals oder Gerätes verwenbar wären, weil diese afaik im NVS (non volatile storage) abgelegt werden.
Die Hysterese obere Schwelle - untere Schwelle ist mitentscheidend für die Eignung des Algorithmus.
Tja, da gibt es etwas zu programmieren, wenn du das so implementieren willst.
Viel Erfolg!
... das Licht schnell eingeschaltet werden können.
Das ist wohl wahr. Wenn dies die höchste Priorität besitzt, ist imho allerdings das Anliegen von FIZZY ohne zusätzlichen Installationsaufwand (Schalter an für Kinder kaum zugänglichen Stelle) nicht zu befriedigen.
Und selbst eine solche zusätzliche Installation ist vermutlich von einem Kind sehr schnell benutzbar, wenn es dem Kind wichtig ist.
Somit widerspricht eine Erschwernis für ein Kind der Prämisse, Licht schnell, und damit leicht, schalten zu können.
Das vermute ich auch. Ich schließe aber eine gewisse Mitwirkung meinerseits nicht aus, abhängig von dessen Rahmenbedingungen.
Zum Ausgangsanliegen, DIYROLLY und MIHO:
Ebendrum täte ich einen Shelly Plus 1 und Skripte favorisieren und nicht solche Speziallösungen per Hardware.
Mit Skripten lässt sich zumeist viel flexibler das Gewünschte implementieren. Auch erwarte ich, dass die zu Grunde liegende Firmware weiter verbessert wird und es evtl. zusätzliche Abfrageparameter und Skript-Funktionen geben wird.
Wenn ein Plus verbaut ist, lässt sich auch per Skript von einem PC aus das Verhalten des Plus erheblich ändern, ohne die Hardware wechseln zu müssen.
Allerdings sind hierzu Programmierkenntnisse erforderlich. Ein Skript kann aber auch von einem Dritten bereitgestellt werden.
Es ist relativ leicht, eine automatisierte, zeitabhängige Ignoranz des Lichtschalters bzw. -tasters per Smartphone (temporär) zu aktivieren oder zu deaktivieren, jedenfalls per MQTT.
Auch deshalb fragte ich FIZZY, womit er/sie den betreffenden Shelly steuert. Entscheidend sind dann die verwendeten Steuerungs-Nachrichten.
Es ist auch bspw. möglich, das Licht nachts ausschließlich per Smartphone einschalten zu können. Vielleicht würde dies für eine Weile helfen.
Meine Empfehlung ist vielleicht nicht so ganz schnell implementierbar, aber sie ist mittel- und langfristig für verschiedenste Zwecke nutzbar.
MIHO: Afaik bist du in der QA Gruppe oder hast einen Draht dorthin. Ich hätte da noch Mängel an der Plus Firmware 0.10.1 anzumerken. Es wäre schön, wenn du das vermitteln könntest.
Es wird alle 60 Minuten eingeschaltet, der Einschalt-Timer ist auf 900s gestellt.
Unter "WENN" steht "ZEITSCHALTUHR" und darunter "Intervall: 60 Minuten".
Unter "MACHEN" steht der Gerätename und darunter "Einschalten das Gerät".
Dass die Szene noch zu aktivieren ist, muss ich dir wohl nicht erklären.
24/7 ist voreingestellt, d.h. die Szene arbeitet an jedem Wochentag von 00:00 bis 23:59.
Noch einmal der Hinweis:
Solange der Shelly nicht mit der Cloud verbunden ist, funktioniert das (temporär) nicht.
Für eine höhere Funktionssicherheit wäre bspw. Tasmota zu flashen und mit dessen Rules zu arbeiten oder ein Shelly Plus 1 mit einem Script zu bevorzugen.
Es gibt auch Spezis, die gerne mal zwei Shellies miteinander koppeln. Das ginge hier auch mit zwei Shelly 1. Shelly A schaltet den SW-Eingang von Shelly B und B schaltet den SW-Eingang von A. Dazu wären die Timer und die Schalter- bzw. Tasterarten passend einzustellen.
Zwischenbericht zur Szenensteuerung 15 Min ein, 45 Min aus.
Die ersten 5 Ein-Aus-Schaltvorgänge waren erfolgreich. Nur der erste war nur 42 Min aus, was vermutlich an meinem manuellen Anstoßen des ersten Einschaltens innerhalb der Szene liegt. Ich kenne mich in Szenen nicht aus, brauche solche auch bisher nicht.
Das Protokoll zeigt ansonsten eine präzise Abfolge der gewünschten Schaltsequenzen. Es wird alle 60 Minuten eingeschaltet, der Einschalt-Timer ist auf 900s gestellt.
Ich würde mich wundern, wenn sich ein Shelly 1 anders verhielte.
Ich suchte und fand soeben, dass ich dies naheliegenderweise auch in der Cloud protokolliert finde, nur nicht so gut dokumentiert wie in meinem Protokoll.
zombo42 : An Hand des Cloud Protokolls kannst du immerhin selbst die Funktionstüchtigkeit eines Szenen gesteuerten Ablaufs überprüfen, ohne dich selbst mit einer Protokollierung zu befassen.
