[SOLVED] [Rule] How to catch String Item in rule

Regarding to this posts:


it should be possible to catch a string item change in the when clause of a rule

rule "string test"
    when
        Item stSummerType changed from "UNDEF"
    then
        logInfo("Logger", "Inside of the rule")
end

Log:

2019-01-19 11:53:27.234 [vent.ItemStateChangedEvent] - stSummerType changed from UNDEF to SUMMER_1x

This rule is not triggered. As a workaround I use

rule "string test"
    when
        Item stSummerType changed
    then
        if(triggeringItem.state.toString == "UNDEF")
            return;

This is working. But is it possible to solve it with my first version?

UNDEF is a state, there is no need for the ""

rule "string test"
    when
        Item stSummerType changed from UNDEF
    then
        logInfo("Logger", "Inside of the rule")
end

And, in addition to @vzorglub, the string will rarely ever, if at all after first instantiation or after system start up, be UNDEF.
So effectively you are creating a rule that triggers once after the system started.

sorry for confusing everyone. UNDEF is just used by me.

neither one of this is working/triggering the rule

Item stSummerType changed from UNDEF
Item stSummerType changed from "UNDEF"

I use expire binding to set the string back to UNDEF after it is set to something else by a rule.

String stSummerType                         "SummerType [%s]"                   (gMAPDB)        { expire="1s,command=UNDEF" }

To be more clear I change it now to “DoNothing”, now it is working as expected. Looks like UNDEF was a bad choose from my side.

String stSummerType                         "SummerType [%s]"                   (gMAPDB)        { expire="1s,command=DoNothing" }

    when
        Item stSummerType changed from "DoNothing"
    then

Commands do not directly change an Item’s state. But your Item does have autoupdate enabled, by default.
So autoupdate will see the command UNDEF issued by the expire binding, and do something about it. I’m not sure what it does, mind! Autoupdate’s job is to “guess” what might result from a command e.g send ON to a Dimmer and autoupdates says 100.
It could set the Item state to UNDEF or it might realize this is a String Item and make it “UNDEF”.

{ expire="1s,state=UNDEF" }
might work differently

Just saying there are subtleties at work here, your workaround looks like a better idea anyway. (as you can distinguish deliberate states from system invoked states due to error)

Edit - thinking on it a bit more, UNDEF isn’t a valid command to send to anything. Results unpredictable.