LONG_PRESSED Events kommen nicht mehr im Openhab an

Geflasht oder ungeflasht ...

Moderator: seppy

Benutzeravatar
udo1toni
Beiträge: 10566
Registriert: 11. Apr 2018 18:05
Answers: 146
Wohnort: Darmstadt

Re: LONG_PRESSED Events kommen nicht mehr im Openhab an

Beitrag von udo1toni »

Wenn eine Rule über Channel triggered ausgelöäst wird, steht die implizite Variable receivedEvent zur Verfügung, in welcher das Event stehen müsste.

Der einfachste Weg wäre also, Deine Rule zunächst abzuändern:

Code: Alles auswählen

rule "Shelly Button1"
when
    Channel 'shelly:shellybutton1:OGBadMusikplay:status#button' triggered 
then
    logInfo("shellyButton","received event: {}",receivedEvent)
    switch(receivedEvent.toString) {
        case "s" : { // S
            logInfo("shellyButton","1 x kurz erkannt")
        }
        case "SS" : { // SS
            logInfo("shellyButton","2 x kurz erkannt")
        }
        case "SSS" : { // SSS
            logInfo("shellyButton","3 x kurz erkannt")
        }
        case "L" : { // L
            logInfo("shellyButton","lang erkannt")
        }
        case "SL" : { // SL
            logInfo("shellyButton","kurz-lang erkannt")
        }
        case "LS" : { // LS
            logInfo("shellyButton","lang-kurz erkannt")
        }
        default : logInfo("shellyButton","Event ist nicht zugeordnet!")
    }
end
Wenn Du die Tasten entsprechend drückst, müsstest Du eine passende Meldung zu sehen bekommen.
Im jeweiligen Block kannst Du dann die jeweilige Aktion unterbringen. Es braucht dazu nicht mehrere Rules.
Alternativ kannst Du natürlich auch getrennte Rules für die verschiedenen Aktionene anlegen und bei jeder Rule das Event mit angeben.

Achtung: Es ist nicht gesagt, dass die receivedEvents tatsächlich 1:1 dem Inhalt von "Letztes Ereignis" entsprechen, auch wenn das naheliegend wäre. Also vorher testen. Eventuell gibt es auch Ereignisse für Drücken und loslassen der Taste (z.B. PRESSED und RELEASED).
openHAB3.3.0 in einem Debian-Container (Proxmox, LXC)

dcridaz
Beiträge: 10
Registriert: 20. Jun 2022 16:16

Re: LONG_PRESSED Events kommen nicht mehr im Openhab an

Beitrag von dcridaz »

Hallo udo1toni,

erstmal vielen Dank für deinen Support. Leider hatte ich gestern Abend keine Möglichkeit mehr, die abgeänderte Rule zu testen.
Dies werde ich aber heute Abend ausgiebig testen und dann auch ein Feedback geben.
Aber noch "By-the-way", so wie ich es im vorherigen Post gefragt habe, funktioniert es in einer Rule den String mit der Textdefinition
im Auslöser zu berücksichtigen? Also

Code: Alles auswählen

...
then
if (OGBadMusikplay_LetztesEreignis.state = S) {   // der State "S" wird ja auch in der Channel Definition angezeit
OGBadMusikplayerToggle.sendCommand (ON)
}
Oder heisst der Vergleich .....state == "S", ?
Egal was ich versucht habe, wenn der String eine Zahl hat (Größenvergleich mit =,<,>) funktionieren andere Rules.
Ich hatte gedacht, dass das auch mit Buchstaben gehen könnte.

Aber wie gesagt, dein Template werde ich heute Abend testen und Dir dann eine Rückmeldung geben.


Vielen Dank schonmal / nochmal

und Liebe Grüße
Openhab3 auf einem Raspberry-PI4, Wemos D1 mini über MQTT, AVM Fritz!, Wifi LED, Diverse Shelly Produkte, Gardena Smart Produkte, Reolink-IP Cams, Wansview-IP Cams, Foscam-IP Cams.

Benutzeravatar
udo1toni
Beiträge: 10566
Registriert: 11. Apr 2018 18:05
Answers: 146
Wohnort: Darmstadt

Re: LONG_PRESSED Events kommen nicht mehr im Openhab an

Beitrag von udo1toni »

Der Vergleich muss so aussehen:

Code: Alles auswählen

...
then
    if(OGBadMusikplay_LetztesEreignis.state.toString == "S" ) {
        OGBadMusikplayerToggle.sendCommand (ON)
    }
end
Ein Status ist erst mal ein Status und eben kein String. openHAB "errät" in vielen Fällen korrekt, welchen Typ es verwenden muss, manchmal geht das aber auch schief. Deshalb ist es immer besser, das explizit hinzuschreiben. Genauso ist das mit dem Casting eines Status nach Number

Code: Alles auswählen

val MeinWert = MeinNumberItem.state as Number
Dieses Casting ist wichtig, damit openHAB weiß, welchen Datentyp es verwenden soll (auch wenn das gewöhnlich funktionieren wird). Aber Achtung! Ein Item kann auch den Wert NULL enthalten, dann geht das Casting schief, deshalb ist es unerlässlich, in einem ersten Schritt auf den Typ zu testen

Code: Alles auswählen

if(MeinNumberItem.state instanceof Number)
erledigt das.

= vs. ==:

a = b -> Der Variablen a wird der Wert in der Variablen b zugewiesen.
a == b -> Bool'scher Ausdruck. WAHR, falls a den gleichen Wert hat wie b. FALSCH, falls der Wert in a vom Wert in b abweicht.
openHAB3.3.0 in einem Debian-Container (Proxmox, LXC)

dcridaz
Beiträge: 10
Registriert: 20. Jun 2022 16:16

Re: LONG_PRESSED Events kommen nicht mehr im Openhab an

Beitrag von dcridaz »

Hallo udo1toni,

ich danke Dir von ganzen Herzen für deine Ausführliche Antwort. Genau jetzt, nach 4 Jahren Openhab-Nutzung, hat es endlich *klick* gemacht.
Ich habe schon in mehreren Beiträgen diese Definition "state.toString == WERT" gelesen, aber scheibar immer wieder diese Definition "überlesen".

Zu der vorgenannten Rule mit CASE-abfragen:
Komischerweise reagiert kein ITEM auf die Definitionen, die das "Letze-Ereignis" S=Short-Press vom Shelly Button ausgibt.
Im Log habe ich dann die Trigger "SHORT_PRESSED", "DOUBLE_PRESSED", "TRIPLE_PRESSED","LONG_PRESSED" usw. gesehen.
Dann habe ich die Rule angepasst:

Code: Alles auswählen

rule "Shelly Button1"
when
    Channel 'shelly:shellybutton1:OGBadMusikplay:status#button' triggered 
then
    logInfo("shellyButton","received event: {}",receivedEvent)
    switch(receivedEvent.toString) {
        case "SHORT_PRESSED" : { // S
            logInfo("shellyButton","1 x kurz erkannt")
            OGBadMusikplayerToggle.sendCommand (ON)
        }
        case "DOUBLE_PRESSED" : { // SS
            logInfo("shellyButton","2 x kurz erkannt")
           OGBadSchlafzimmerVolumioPlay_OGBADMusiknextHTTPBefehl.sendCommand (ON)
        }
        case "TRIPLE_PRESSED" : { // SSS
            logInfo("shellyButton","3 x kurz erkannt")
            OGBadSchlafzimmerVolumioPlay_OGBADMusikprevHTTPBefehl.sendCommand (ON)
        }
        case "LONG_PRESSED" : { // L
            logInfo("shellyButton","lang erkannt")
        }
        case "SL" : { // SL
            logInfo("shellyButton","kurz-lang erkannt")
        }
        case "LS" : { // LS
            logInfo("shellyButton","lang-kurz erkannt")
        }
        default : logInfo("shellyButton","Event ist nicht zugeordnet!")
    }
end

Nun funktioniert es genauso, wie ich es wollte.
Also nochmals vielen, vielen lieben Dank für deinen treuen und sehr kompetenten Support.

Liebe Grüße
Tim
Openhab3 auf einem Raspberry-PI4, Wemos D1 mini über MQTT, AVM Fritz!, Wifi LED, Diverse Shelly Produkte, Gardena Smart Produkte, Reolink-IP Cams, Wansview-IP Cams, Foscam-IP Cams.

mad-mike
Beiträge: 190
Registriert: 6. Jan 2021 18:05
Answers: 1

Re: LONG_PRESSED Events kommen nicht mehr im Openhab an

Beitrag von mad-mike »

Hallo zusammen, ;)

Was bedeutet die Funktion
Gruss mad-mike

Openhabian 3.3.0

Benutzeravatar
udo1toni
Beiträge: 10566
Registriert: 11. Apr 2018 18:05
Answers: 146
Wohnort: Darmstadt

Re: LONG_PRESSED Events kommen nicht mehr im Openhab an

Beitrag von udo1toni »

case ist keine Funktion :)

Es geht hier um bedingte Verzweigungen. Nehmen wir an, Du hast ein Item, dessen Status Du nutzen willst, um unterschiedliche Dinge zu tun. Bei einem Item mit zwei möglichen Zuständen (z.B. Switch) ist das einfach, entweder der eine Zustand trifft zu oder der andere, also

Code: Alles auswählen

if(Item.state == OFF)
// mach was
else
//mach was anderes
Aber vielleicht hat das Item mehr als zwei Zustände, z.B. ein Item, welches per Selection Widget vier Zustände annehmen kann, der Einfachheit halber 1, 2, 3 oder 4.
Möglichkeit eins:

Code: Alles auswählen

     if(Item.state == 1)    // mach was
else if(Item.state == 2)    // mach was anderes
else if(Item.state == 3)    // mach noch was anderes
else                        // mach noch was völlig anderes
Für den vierten Fall ist es schon etwas kritisch, einfach davon auszugehen, dass es nur die definierten vier Zustände gibt. :) Aber auch sonst ist das Konstrukt eher unbefriedigend, weil immer und immer wieder der Vergleich auf der einen Seite identisch angegeben wird, der einzige Unterschied ist der konkrete Wert.
Da kommt die bedingte Verzweigung mit switch() ins Spiel:

Code: Alles auswählen

switch(Item.state.toString) {
    case "1" : // mach was
    case "2" : // mach was anderes
    case "3" : // mach noch was anderes
    case "4" : // mach noch was völlig anderes
    default  : // beschwere dich über einen nicht zulässigen Wert
}
Wie immer wird jeweils nur ein Befehl ausgeführt, sollen es mehrere Befehle sein, so müssen diese als Block mit {} markiert werden.
Deshalb müssen auch die einzelnen case Schlüsselworte gemeinsam in einem Block stehen :)
default kümmert sich um alle Fälle, die nicht vorher abgehandelt wurden, weshalb es auch am Schluss stehen muss. Das funktioniert natürlich genauso auch mit if() und else, aber man spart sich etwas Tipparbeit (und intern funktioniert es natürlich etwas anders weil der Vergleichswert eben nicht immer wieder in das passende Register geladen werden muss, sondern einfach vom Stack geholt wird, das geht also aus Computersicht viel schneller. Der Anwender wird den Geschwindigkeitsvorteil aber nicht bemerken ;)

Wichtig: Wenn Du switch() mit einem numerischen Status einsetzt, musst Du Dich entscheiden. Entweder Du prüft, ob es sich tatsächlich um eine Zahl handelt und gibst dann das as Number mit an, dann kannst Du auch die Zahl direkt vergleichen (wobei man leider nicht unmittelbar < oder > verwenden kann), oder Du sorgst mit .toString dafür, dass der Status ein String wird (.toString steht immer zur Verfügung, es gibt dann also auch keinen Fehler), dann musst Du natürlich beim Vergleich auch Strings angeben. 1 -> eine Zahl. "1" -> ein String. Man könnte auch (1).toString schreiben ;) aber da sind die Anführungszeichen dann vielleicht doch etwas einfacher...

switch() verhält sich in der DSL etwas anders als in Java gewohnt, man muss am Ende eines Blocks kein break; mit angeben (und darf das auch nicht). Würde man das in Java weg lassen, so würde ab dem zutreffenden Vergleich alles ausgeführt. Hier wird also einfach nur der Block ausgeführt, welcher zutrifft, anschließend wird der Code hinter der } vom switch(){ ausgeführt.

Der < oder > Vergleich geht übrigens auch mit case, nur ist es fragwürdig, ob das so sinnvoll ist:

Code: Alles auswählen

switch(Item.state.toString) {
    case !(Item.state instanceof Number) : // beschwere Dich über ein falsches Format
    case (Item.state as Number) < 2      : // beschwere Dich über zu wenig
    case "3"                             : // mach was 
    case Alarm.state != ON               : // was soll das denn?
    case (Item.state as Number) >= 4     : // beschwere Dic hüber zu viel
}
Man kann also auch konkrete Boolean Ausdrücke angeben, die noch nicht mal einen Bezug auf den ursprünglichen Parameter haben müssen. Aber dann kann man das Ganze auch genauso gut über if() zusammenbauen...
openHAB3.3.0 in einem Debian-Container (Proxmox, LXC)

mad-mike
Beiträge: 190
Registriert: 6. Jan 2021 18:05
Answers: 1

Re: LONG_PRESSED Events kommen nicht mehr im Openhab an

Beitrag von mad-mike »

Moin, danke für diese ausführliche Erklärung.
Gruss mad-mike

Openhabian 3.3.0

Benutzeravatar
udo1toni
Beiträge: 10566
Registriert: 11. Apr 2018 18:05
Answers: 146
Wohnort: Darmstadt

Re: LONG_PRESSED Events kommen nicht mehr im Openhab an

Beitrag von udo1toni »

Immer gerne :)
openHAB3.3.0 in einem Debian-Container (Proxmox, LXC)

mad-mike
Beiträge: 190
Registriert: 6. Jan 2021 18:05
Answers: 1

Re: LONG_PRESSED Events kommen nicht mehr im Openhab an

Beitrag von mad-mike »

Moin.

Wegen einem Netzwerkdrucker habe ich in meine Verkabelung ein Switch zwischen gehangen... Ende vom Lied, die Shelly haben nicht mehr auf die LONG_PRESSED reagiert.


Nun Habe ich eine Fritz im Büro,(Hier auch der OH Pi) diese ist Per LAN verbunden mit Fritz im Keller. Im Zählerschrank sind etliche Shelly verbaut. Bei den Fritzen habe ich das Mesh aktiviert...

lief alles wunderbar...

Nun sind meine LAN Anschlüsse alle belegt gewesen weshalb ich einen Switch im Keller montieren wollte.

Nach dem ich also Fritz 1 -> Kabel -> Switch -> Kabel > Fritz 2 aufgebaut habe, liefen keiner der Longpressed funktionierten mehr.. Warum keine Ahnung... Auch ein Neustart von dem Gesamten System brachte keinen Erfolg.

Ich habe dies nun so realisiert das ich Fritz 1 -> Kabel -> Fritz 2 -> Kabel -> Switch aufgebaut habe. und die Shelly mit Long_pressed funktionieren wieder...


Ich wollte mit diesem Beitrag vielleicht auf ein Problem mit der Netzwerkverbindung hinweisen wenn es Probleme mit den Long_pressed gibt.
Gruss mad-mike

Openhabian 3.3.0

Benutzeravatar
udo1toni
Beiträge: 10566
Registriert: 11. Apr 2018 18:05
Answers: 146
Wohnort: Darmstadt

Re: LONG_PRESSED Events kommen nicht mehr im Openhab an

Beitrag von udo1toni »

Was sind das für Switches? Ich hab ja keinen Schimmer davon, wie die Kommunikation der Shellies läuft, aber es gibt verschiedene Möglichkeiten, wie die Switches einem in die Suppe spucken können,
openHAB3.3.0 in einem Debian-Container (Proxmox, LXC)

Antworten