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

[HomeAutomation]

Regarding to this posts:

Escaping string in 'when' clause

I am surprised that your rule triggers at all… Items are objects that carry state (and other info) that needs to be converted to make it useable As far as I can tell, what I’m doing is supposed to work, as per: https://docs.openhab.org/configuration/rules-dsl.html#event-based-triggers There is no need to convert state to string, as it is done implicitly. I could check it in the ‘then’ clause, which is exactly what I’m doing now, but that is kind of ugly and requires me to duplicate rules. T…

String state handling

All, In OH1 I used a rule triggered by a string state: rule "Abus Status monitoring Set" when Item Abus_Status changed to "Set" then ... This rule was not triggered in OH2 until I changed it to: (removing the “”) rule "Abus Status monitoring Set" when Item Abus_Status changed to Set then ... So obviously the state handling of strings changed, right?

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?

[vzorglub (Vincent Regaud)]

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

[RolfV (Rolf Vermeer)]

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.

[HomeAutomation]

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

[rossko57]

@HomeAutomation

{ expire=“1s,command=UNDEF” }

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.