Wie?
Ich glaube ich stehe gerade extrem auf dem Schlauch…
Vielen Dank Kai für die Einbindung des i3 
Eine Frage: Wie wertet ihr den i3 aus?
Bei jedem Tastendruck verändert sich der Status des jeweiligen Eingangs. Beim Doppelklick allerdings 2x und zusätzlich ändert sich Eingang Ereignis.
Aktualisiert werden die Eingänge und Eingang Ereignisse bei jedem Keep Alive.
Wenn ich jetzt ein Ereignis auf die Änderung des Eingangs lege, wird dies gestartet bevor klar ist, ob es ein Doppelklick wird 
Auf Aktualisierung des Eingang Ereignisses kann ich nicht gehen, wegen Keep Alive und auf Änderung auch nicht, weil sich dies nicht ändert, wenn z.B. mehrere einfache Klicks erfolgen.
Hat jemand eine Idee?
Hast Du mal für Doppelklick probiert:
Änderung Status des Eingangs und als weitere Bedingung (die man ja als Auslöser definieren kann) dann die Änderung des Eingang Ereignis?
Also wenn beides erfüllt ist, dann wird der Trigger erst aktiv.
Ich habe leider kein i3 und kann es somit nicht testen
Ob Du jetzt auf Änderung oder Aktualisierung triggern musst, das muss man herausfinden was genau bei Tastendruck passiert bzw wie sich was ändert oder aktualisiert wird.
Vielen Dank für die schnelle Rückmeldung und die Idee mit den weiteren Bedingungen!
Ich habe weiter probiert. Die Variable Eingang Ereignis schaltet mit einiger Verzögerung nach der Variable Eingang. Dadurch habe ich keine Möglichkeit gefunden eine Bedingung auf diese Variable zu legen.
Dann habe ich versucht in die Variable Eingang Ereignis einen Dummy-Wert zu schreiben und dann auf Änderung dieser Variable zu triggern. Wenn ich immer in dem Script, dass auf Änderung dieser Variable triggert am Ende diesen Dummy-Wert setzte, hätte ich kein Problem, wenn zweimal das gleiche Eingang Ereignis hintereinander kommt. Das erschien mir eigentlich ganz elegant. Aber leider wird diese Variable ständig aktualisiert, so dass der Wert unmittelbar wieder überschrieben wird.
Letztendlich habe ich erst einmal eine neue Variable Button-1 angelegt. Mit einem Script das auf Änderung der Variablen Eingang getriggert ist, warte ich jetzt erstmal 2 Sekunden und schreibe dann den Wert der Variable Eingang Ereignis (ID 15344) in die Variable Button-1 (ID 27623).
Die Scripte mit den eigentlichen Aktionen triggern jetzt auf Aktualisierung diese Variablen.
sleep (2);
$stat = GetValue(15344);
switch($stat){
case 0:
SetValue(27623, "Short");
break;
case 1:
SetValue(27623, "DShort");
break;
case 3:
SetValue(27623, "Long");
break;
default:
SetValue(27623, "NN");
}
Irgendwie etwas umständlich und bei allen Button, die mehr als Short-Press können sollen 2 zusätzliche Sekunden Wartezeit…
Könntest Du mal bitte einen Screenshot machen, wo man sieht welche Variable(n) wann geändert bzw aktualisiert werden?
Also bei ShortPush, 2x ShortPush, LongPush etc?
Anbei die Screenshots. Geschaltet habe ich jeweils Button 1.
Die anderen Variablen wurden durch MQTT aktualisiert.
Die Variable Eingang ändert sich bei jedem Knopfdruck. Bei Doppel-Short wird die Variable Eingang zweimal verändert.
Leider kann ich den Screenshot nicht sehen da ich mit dem Smartphone unterwegs bin und die Grafik nicht in den Beitrag eingefügt ist
Dann würde es doch helfen ein Skript zB auf „Aktualisierung Eingang 1 Ereignis“ zu triggern und im Skript den Zustand von „Eingang 1“ abzufragen, oder?
Oder triggere auf „Bei Änderung von Eingang 1 Ereignis“ und als weitere Bedingung zB „Wert Eingang 1 Ereignis = ShortPush“
So wie ich das alles verstehe (am Beispiel Eingang 1):
Eingang 1 Ereignis wird zyklisch aktualisiert
Eingang 1 wird zyklisch aktualisiert
Eigentlich macht das keinen Sinn das Eingang 1 Ereignis zyklisch aktualisiert wird. Denn hierüber wird ja ausgewertet, um welchen Tastendruck es sich handelt.
Nehmen wir an Du möchtest einen Doppelpush ausführen und zwischen dem 1. und dem 2. Tastendruck wird zyklisch aktualisiert, dann dürfte der Doppelpush ja gar nicht funktionieren.
Es müsste eigentlich so sein, daß die ‚Eingang 1 Ereignis‘ erst aktualisiert wird, wenn der getätigte Befehl (Push, Doppelpush, LongPush) ermittelt wurde.
Aus diesem Grund (da man zB auch 2 identische Eingaben hintereinander ausführen möchte, zB 2x ShortPush), müsste man auf Aktualisierung triggern (da sich der Zustand nicht ändert). Hier könnte man zB auf ‚Aktualisierung Eingang 1 mit weiterer Bedingung Shortpush‘ triggern.
So könnte man zB über die ‚Aktualisierung Eingang 1 Ereignis mit weiterer Bedingung Shortpush‘ zB eine Lampe ein und auch wieder ausschalten.
Wenn jedoch die Variable ‚Eingang 1 Ereignis‘ zyklisch aktualisiert wird, dann würde das Skript laufend aufgerufen und das Licht würde zyklisch an und ausgehen, das macht keinen Sinn.
Auf Änderung der Variable ‚Eingang 1 Ereignis‘ kann man ebenfalls nicht triggern, da sich diese mitunter ja gar nicht ändert (zB bei ShortPush und darauffolgenden nochmaligem ShortPush (zB Licht an, Licht aus).
An der Variablen ‚Eingang 1‘ kann man nicht ausmachen ob ein ShortPush, LongPush etc ausgeführt wurde, diese stellt ja nur den Zustand des Hardware Eingangs dar, ob nun Spannung am Eingang anliegt oder nicht.
Ich wüsste hier auch keine Lösung, ausser das die Variablen ‚Eingang x Ereignis‘ nicht zyklisch aktualisiert werden dürfen (was auch keinen Sinn ergibt).
Vielen Dank für deine ausführliche Rückmeldung.
Ich denke auch, dass die zyklische Aktualisierung der Variable Eingang Ereignis nicht hilfreich ist. Ich versuche es mal im Shelly-Forum. Vielleicht kann ja der Hersteller noch mal überlegen, ob es nicht besser nicht, die Variable Eingang Ereignis nur zu aktualisieren, wenn Taster erkannt werden…
Ich denke auch das es die einzige Möglichkeit wäre, wenn die Aktualisierung von ‚Eingang x Ereignis‘ nicht zyklisch, sondern erst bei einer Änderung stattfindet.
Ich kann mir auch nicht erklären, was hier eine zyklische Aktualisierung bewirken soll…
Damit ist der i3 über MQTT ja gar nicht sinnvoll nutzbar, oder habe ich jetzt einen Denkfehler?
Ich habe mit einem Shelly2.5 auch etwas gebastelt, da ich über LongPush ein Timer Skript starte. Die Variable ‚Longpush‘ wird auf true gesetzt und bleibt auch auf true, nachdem sie ausgelöst wurde und zwar so lange bis das wieder ein ShortPush erfolgt. Erfolgt nach einem LongPush kein ShortPush, so bleibt die Variable ‚Longpush‘ in true.
Hier habe ich das so gelöst, daß bei ‚Aktualisierung von Longpush‘ und weiterer Bedingung ‚Longpush=true‘ das Timer Skript gestartet wird. Da bei einem ShortPush auch ‚LongPush‘ aktualisiert wird, jedoch die weitere Bedingung nicht erfüllt ist, wird das Timer Skript nicht gestartet.
Hier wird jedoch nicht zyklisch aktualisiert (was ja auch Sinn ergibt).
Ich hatte gerade überlegt, ich könnte ja auch einbauen, dass die Variable nur aktualisiert wird, wenn sie sich wirklich ändert, aber dann bekommt man auch nicht mit, ob die selbe Taste nochmal ausgelöst wurde.
Wenn jemand eine Idee hat, wie ich das im Modul anpassen kann, dann teilt es mir mit.
Grüße,
Kai
Ich denke das kann man über das Modul gar nicht realisieren. Wie Du schon sagtest, würde dann ein identisch folgender Tastendruck nicht erkannt bzw ausgewertet.
Das dürfte mit der Hilfsvariable aber auch nicht funktionieren, die hier aus der Not heraus erstellt wurde denn diese aktualisiert sich zwar nicht zyklisch aber auch nicht bei identisch folgenden Tastendrücken.
Im Grunde genommen dürfte die Variable ‚Eingang x Ereignis‘ nur aktualisert werden wenn sich der Wert von der Variablen ‚Eingang x‘ ändert, das dann aber zeitverzögert…oder? Wobei auch das nicht richtig funktionieren dürfte…
Dasselbe Problem dürfte ja auch beim Button1 bestehen (oder erfolgt hier keine zyklische Aktualisierung der Variablen (eventuell bei Batteriebetrieb nicht, aber bei Betrieb über externe Spannungsversorgung!)
Ist eigentlich blöd gelöst, denn eigentlich hätte es für die einzelnen Tastendrücke eigene Variablen geben müssen, die sich dann bei Auslösung und auch wiederholter Auslösung aktualisieren. Sprich Variable ‚Eingang 1 Ereignis ShortPush‘, ‚Eingang 1 Ereignis 2x ShortPush‘, ‚Eingang 1 Ereignis LongPush‘ usw usw…
Da muss Allterco wohl ran…
Hallo Kai,
habe den Shelly Button1 eigerichtet.
Jedoch ändert sich der Staus des Einganges nicht.
Habe diesen mal zum Testen mit dem MQTT Configurator erstellt.
Dort werden die Änderungen korrekt angezeigt.
Gruss
Roland
Zum Thema i3 hat sich heute der Support von Allterco gemeldet: We have informed our development team and they will check and fix that in one of the next firmware versions released.
Mit einen bisschen Glück gibt es vielleicht bald eine Lösung vom Hersteller…
Sehr schön! Vielleicht funktioniert dann ja bald alles wie gewünscht
Das hört sich gut gut an.
Grüße,
Kai
Kannst du mir mal ein Debug schicken?
Grüße,
Kai
