Sytaxprobleme in Rule, no viable alternative at input bei negativer Zahl

[bender.ac]

Hallo,

vermutlich ein einfaches Problem, an dem ich mir wieder die Zähne ausgoogle...

Meine ansonsten fertige Rule beginnt so:

Code: Alles auswählen

rule "FingerPrintDoorBell"
when
    Item FingerPrintDoorBellHaus_Ring changed to ON or
    Item FingerPrintDoorBellTor_Ring changed to ON or
    Item FingerPrintDoorBellHaus_Id changed from -1 or
    Item FingerPrintDoorBellTor_Id changed from -1

then
...
end

falls jemand wissen will was das ist:
https://frickelzeugs.github.io/FingerprintDoorbell/ -> Funktioniert super, vielen Dank an meinen Kollegen Tobias

zum Problem:
Diese Defition der Trigger führt zu dieser Meldung im Log

Code: Alles auswählen

2024-12-23 13:32:35.765 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'FingerPrintDoorBell.rules' has errors, therefore ignoring it: [5,50]: no viable alternative at input '-'
[6,49]: no viable alternative at input '-'

Ihm "schmeckt das" das Minus nicht. Und ja mit einer positiven Zahl ist es syntaktisch korrekt aber funktional Quatsch.

Kann mir jemand verraten, wie ich dem Interpreter das Minus an der Stelle verkaufen kann?

Viele Grüße,
Achim

[udo1toni]

Ich fürchte, das wird an dieser Stelle so nicht lösbar sein. Eventuell könntest D uden Wert erfolgreich mit Klammern schreiben, also so:

Code: Alles auswählen

    Item FingerPrintDoorBellHaus_Id changed from (-1) or
    Item FingerPrintDoorBellTor_Id changed from (-1)

aber wetten möchte ich darauf nicht.

Verschiedene Optionen:
1. sorge mit einer passenden Konfiguration dafür, dass das Item statt -1 den Wert UNDEF oder alternativ NULL enthält (z.B. mittels expire). Danach sollte der Trigger auf changed from NULL bzw. changed from UNDEF funktionieren.
2. Verzichte auf das das from und frage es stattdessen innerhalb des Codes ab:

Code: Alles auswählen

if(previousState instanceof Number)
    if((previousState as Number) != -1)
        return;

Die zweistufige Abfrage ist hier wichtig, weil Du ja Items verschiedenen Typs hast.
Man könnte auch zunächst evaluieren, welches Item die Rule getriggert hat (triggeringItemName) und daran festmachen, ob da nun als alter Wert ein -1 stehen muss.

[bender.ac]

Hi,
Deine Vermutung ist richtig. Die Klammer ist auch nicht akzeptiert...
Hi, ich habe mich für die zweite (stumpfe) Variante entschieden und prüfe die Überung auf >= -1 im Code. Nun wird die Rule zwar unnötig oft getriggert aber eine andere andere Möglichkeit bekommich gerade nicht hin.

Ich verstehe warum Du zweistufig abgragst in Deinem Beispiel aber zur zur Sicherheit

Code: Alles auswählen

if(previousState instanceof Number && (previousState as Number) != -1)
        return;

wäre genau so gut, korrekt? Der "&&"-Operator ist wie in C, sobald ein Statement false ist wird die Auswertung beendet, richtig?

Was meinst Du mit "z.B. mittels expire"?

[udo1toni]

Nein, das ist etwas anderes

Das Problem bei Deiner Variante ist, dass die && Verknüpfung auf jeden Fall ausgeführt wird, es werden also immer beide Tests durchgeführt, und damit ist der erste Test obsolet. Nur, dass der erste Test verhindert, dass beim zweiten Test eine nullPointerException auftritt (sobald previousState nicht vom Typ Number ist, wird das Casting nach Number eine solche auslösen)

expire ist eine Eigenschaft, die man in den Metadaten jedes Items setzen kann. Es handelt sich um einen Timer, der gestartet wird, sobald der Status eines Items voneinem vorgebenen Wert abweicht. Wird das Item auf den Wert gesetzt, wird der Timer abgebrochen. Wird das Item nicht auf den Wert gesetzt, wird nach Ablauf des Timers alternativ der Status auf den Wert gesetzt oder ein Befehl gesendet, der dem Wert entspricht.
Eine typische Anwendung wäre z.B. ein Türöffner. Du sendest ein ON an den entsprechenden Ausgang und ein Relais zieht an. Dieses Relais schließt den Stromkreis für den Türöffner und der dort verbaute Elektromagnet entriegelt die Tür. Aber nach spätestens drei Sekunden sollte der Türöffner wieder stromlos geschaltet werden. Dank expire musst Du Dich darum nicht kümmern (wenn korrekt konfiguriert...)
Genauso kann mandafür sorgen, dass ein Sensor, der keine Daten mehr liefert, nicht einfach mit dem letzten gelieferten Wert gespeichert wird, sondern nach einer einstellbaren Zeit das zugehörige Item mit NULL gefüllt wird.