Treppenlicht: Timer + Dauerlicht?

[Dark Angel]

Hi Community,
als nächstes habe ich vor, das Treppenlicht in ioBroker einzubinden.
Da ich mir neben eine Timer Funktion noch die Möglichkeit wünsche, in bestimmte Fälle das Licht als Dauerlicht einzuschalten, bis es wieder ausgeschalten wird habe ich mir überlegt, ob das mit einen einfachen Shelly 1 durchführbar wäre, oder man dazu unbedingt noch den Shelly i3 benötigt.
Das Szenario das ich mir ausgedacht habe:
Wenn Licht aus: kurzes tippen auf dem Taster = Licht für X-Minuten an.
Wenn Licht aus: langes drücken (1-2 Sekunden) = Dauerlicht
Wenn licht an, egal welcher Modus: kurzes tippen auf dem Taster = Licht aus

Ist so etwas überhaupt möglich?
Vielen Dank im voraus.

P.S.: In diesem Video sieht man eigentlich sehr schön erklärt, wie man dem Shelly 1 die "long press" Funktion beibringt. Ich gehe davon aus, dass so etwas ähnliches im ioBroker per Script eingepflegt werden kann.

[Asgothian]

@Dark-Angel
Ob man das dem Shelly direkt beibringen kann weiss ich nicht.

Wenn du die entsprechenden Events (short click, long press) in den ioBroker bekommst sollte es kein Problem sein ein entsprechendes Skript zu hinterlegen.

A.

[Dark Angel]

@Asgothian: habe gerade gelesen, dass der Shelly 1 ab der Firmware Version 1.5.1 "short press" und "long press" unterstützt.

[premo]

@Dark-Angel sagte in Treppenlicht: Timer + Dauerlicht?:

Wenn Licht aus: kurzes tippen auf dem Taster = Licht für X-Minuten an.
Wenn Licht aus: langes drücken (1-2 Sekunden) = Dauerlicht

Für Tasmota hätte ich was mit Rules.

[da_Woody]

@Dark-Angel said in Treppenlicht: Timer + Dauerlicht?:

Firmware Version 1.5.1

öhm, wir sind bei 1.9.x... und da sind alle DP drinnen.

[Dark Angel]

Danke euch vielmals.
Habe mir jetzt 1x Shelly 1 One und 1x Shelly 2.5 bestellt. Sobald sie da sind werde ich mich um die Programmierung kümmer, die wie es ausschaut nun doch um einiges einfacher ist, als ich ursprünglich angenommen habe.
Laut meine Recherche funktioniert die original FW genau so gut wie die Tasmota FW und beide lassen sich problemlos im ioBroker einbinden. Werde sie mal in beide Varianten testen, sofern es ein "zurück" zu original FW gibt, falls mit die Tasmota FW doch nicht zusagen sollte.

[da_Woody]

@Dark-Angel deine recherche ist richtig. der vorteil der original FW ist halt, falls dir der ioBroker abschmiert, hast du immer noch die App um deine shellys zu steuern als backup. und mit tasmota hast du sicher weniger möglichkeiten.

[Dark Angel]

Nun... Shelly 1 ist programmiert und eingebaut und wollte ein etwas anderes Szenario ausprobieren: ShortPress - LED Leiste ein/aus schalten; LongPress - Küchenlicht (DS-102 Schalter) ein/aus schalten...
Leider funktioniert es nicht wirklich zuversichtlich und ich bin mir nicht mal sicher, ob es am Script liegt, oder viel eher an dem Shelly.
Habe folg. Blockly Script "auf die Schnelle" gebaut und bin mir auch ziemlich sicher, dass er richtig funktioniert. Solange ich unter Objekte den Longpress Status manuell auf true setze macht er auch genau das was er machen soll: Das Licht in der Küche wird je nach aktuellen Status dieser umgeschalten und der LongPress Status wird wieder auf false gesetzt.

Sobald ich es allerdings am Schalter versuche durchzuspielen, passieren die wildesten Schaltungen:
Licht in der Küche wird umgeschalten, gleich danach wieder ausgeschalten.
Beim weiteren Versuch, wird sie zwar umgeschalten, dafür geht aber die LED Leiste (die eigentlich nur bei ShortPress umgeschalten werden sollte) wird umgeschlaten.
Im ioBroker Log sieht der Schaltvorgang dann so aus:

javascript.0	2020-12-20 21:34:12.065	info	(1241) script.js.common.Shelly_Kueche: setForeignState(id=shelly.0.SHSW-1#40F5200028B6#1.Relay0.longpush, state={"val":false,"ack":true})
javascript.0	2020-12-20 21:34:09.567	info	(1241) script.js.common.Shelly_Kueche: setForeignState(id=sonoff.0.Licht_Kueche.POWER, state={"val":false,"ack":false})
javascript.0	2020-12-20 21:34:09.066	info	(1241) script.js.common.Shelly_Kueche: setStateDelayed: no running timers
javascript.0	2020-12-20 21:34:09.065	info	(1241) script.js.common.Shelly_Kueche: setStateDelayed(id=sonoff.0.Licht_Kueche.POWER, state=false, isAck=false, delay=500, clearRunning=true)
javascript.0	2020-12-20 21:34:09.063	info	(1241) script.js.common.Shelly_Kueche: setStateDelayed: clear 1 running timers
javascript.0	2020-12-20 21:34:09.062	info	(1241) script.js.common.Shelly_Kueche: setStateDelayed(id=shelly.0.SHSW-1#40F5200028B6#1.Relay0.longpush, state=false, isAck=true, delay=3000, clearRunning=true)
javascript.0	2020-12-20 21:34:07.364	info	(1241) script.js.common.Shelly_Kueche: setForeignState(id=sonoff.0.Licht_Kueche.POWER, state={"val":true,"ack":false})
javascript.0	2020-12-20 21:34:06.863	info	(1241) script.js.common.Shelly_Kueche: setStateDelayed: no running timers
javascript.0	2020-12-20 21:34:06.862	info	(1241) script.js.common.Shelly_Kueche: setStateDelayed(id=sonoff.0.Licht_Kueche.POWER, state=true, isAck=false, delay=500, clearRunning=true)
javascript.0	2020-12-20 21:34:06.860	info	(1241) script.js.common.Shelly_Kueche: setStateDelayed: no running timers
javascript.0	2020-12-20 21:34:06.859	info	(1241) script.js.common.Shelly_Kueche: setStateDelayed(id=shelly.0.SHSW-1#40F5200028B6#1.Relay0.longpush, state=false, isAck=true, delay=3000, clearRunning=true)

Kann es unter Umstände villeicht an dem Taster liegen?
Verbaut habe ich den Busch-Jäger Wipptaster-Einsatz 1-polig, Schließer (Arbeitsstrom) 2020

[da_Woody]

@Dark-Angel sicher das am shelly alles richtig eingestellt ist? warum machst du das mit blockly, wenns der shelly mit i/o url actions kann?

[Dark Angel]

@da_Woody, hab das überhaupt nicht verstaden, wie das mit den URLs funktioniert.
Werde mich dann wohl noch mal damit beschäftigen müssen.
Habs ja nur ganz kurz angeschaut und da ich nicht auf Anhieb wusste, woher ich die richtigen URLs bekomme, habe ich mich gleich auf Blockly gestürzt.

[da_Woody]

@Dark-Angel das ding das du ansprichst muss ja eine ip haben+den verweis auf den datenpunkt.
zum lesen

[Dark Angel]

@da_Woody, vielen Dank.
Der DS-102 (Lichtschalter Küche) läuft mit Tasmota 9.x, daher musste ich einen kurzen Blick in der Tasmota Beschreibung werfen und schon konnte ich das Problem lösen.

Nicht desto Trotz, würde ich gern in Erfahrung bringen wollen, woran genau das liegt, dass es per Script in ioBroker nicht wirklich funktioniert.
Ich konnte das Script in Blockly auch zum laufen kriegen, nachdem ich das Protokol auf CoAP eingestellt habe. Mit dem mqtt Protokol gibt es wohl einen Unterschied in dem Object State für LongPress. Bei CoAP ist der State true/false, in mqtt auf ein mal 0/1

Generelle Frage: Welches Protokol ist eigentlich besser für die Kommunikation zw. Shelly und ioBroker?

[da_Woody]

@Dark-Angel gern geschehn!
bei mir lööpt alles über CoAP ohne probleme. nur die diversen gosund und d1mini haben tasmota drauf.

[Dark Angel]

Nachdem das Testprojekt mit dem LongPress ja so gut mit den Hauseigenen Möglichkeiten funktioniert, stellt sich mir die Frage: Wie soll das Ursprungsprojekt realisiert werden, wenn beim Testprojekt schon solche Mängel offenbart wurden?
Die Vorgabe/Ziel lautet nach wie vor:
LongPress = Licht dauerhaft einschalten
ShortPress = Licht mit Timer einschalten / Licht ausschalten, selbst nachdem es mit LongPress eingeschalten wurde.

[Asgothian]

@Dark-Angel
Da ist eine einfache analyse notwendig:

Mach ein Skript welches bei short_press und long_press Events einen Eintrag im log hinterlässt.

Dann löse in zufälliger Folge short_press und Long_press Events aus und vergleiche das mit dem log.

Ich gehe davon aus das der long_press nicht immer sauber erkannt wird und sowohl Short als auch Long press Events auslöst.

Wenn das so ist muss das dein Skript abfangen.

A.

[da_Woody]

@Dark-Angel kann es sein, das das mit der frei einstellbaren longpushtime erkennung zusammen hängt?

[Dark Angel]

@da_Woody, glaube ich nicht.
Werde es aber heute noch prüfen. Da kommt der Shelly 2.5 auf dem Testtisch...

[Dark Angel]

Dank der Hilfe eines Facebook Users ist das Problem mit der Shortpress: "Timer an"/Aus, Longpress: Dauerlicht gelöst.

Falls jemand doch eine Idee hat, wie Timer gesetzt werden kann, ohne die URL Dafür zu "missbrauchen" würde mir das sogar noch besser gefallen

P.S. Eine Kleinigkeit ärgert mich doch noch etwas: Nachdem das Licht dauerhaft AN ist und wieder ausgeschaltet wird, muss ich erst per shortpress einschalten und dann wieder ausschalten, sonst ist der nächste longpress wieder mit Timer versehen.

P.P.S:
Mit der richtigen logischen Reihenfolge funktioniert es zu 100% so wie gewünscht.

[da_Woody]

@Dark-Angel und wenn du glaubst es geht nicht mehr, kommt von wo ne lösung her!
könntest du das als export reinstellen, ich bin bei blockly sogar zu dämlich das nachzubauen...

[Dark Angel]

@da_Woody, aus der Beschreibung "Wenn Licht bereits ein" habe ich noch schnell "Wenn Licht aus" gemacht, denn es beschreibt ja auch richtig die darauf folgende Funktion, ansonsten ist alles wie auf dem Bild oben:

// Kurz
on({id: "shelly.0.SHSW-25#40F520006202#1.Relay0.EventCount"/*Event Counter*/, change: "gt"}, function (obj) {
  var value = obj.state.val;
  var oldValue = obj.oldState.val;
  // Wenn Licht aus
  if (getState("shelly.0.SHSW-25#40F520006202#1.Relay0.Switch").val == false) {
    // Schalte für 5 Minuten ein
    try {
      require("request")('http://192.168.213.205/relay/0?timer=300&turn=on').on("error", function (e) {console.error(e);});
    } catch (e) { console.error(e); }
  } else {
    // Schalte aus
    try {
      require("request")('http://192.168.213.205/relay/0?turn=off').on("error", function (e) {console.error(e);});
    } catch (e) { console.error(e); }
  }
});
// Lang
on({id: "shelly.0.SHSW-25#40F520006202#1.Relay0.longpush"/*Longpush*/, val: true}, function (obj) {
  var value = obj.state.val;
  var oldValue = obj.oldState.val;
  setState("shelly.0.SHSW-25#40F520006202#1.Relay0.Switch"/*Switch*/, true);
});