StringType comparison in drools rules (bug?)

[Juanker Atina]

Are string Items really working on rules? I mean, if you want to
execute a rule with a condition like this:

StateEvent( itemName == "MyCoolNumberItem", newState == "2")

It will run nicely. If this item has this value, the rule fires and
the action is executed.

Now, if you want to do the same with a Text Item. It will never run.
The condition is never satisfied. (¡)

StateEvent( itemName == "MyCoolTextItem", newState == "testing")


I know that newState is State type, so in the first rule it will be
DecimalType and in the second one will be StringType. So, do you know
why StringTypes are never equal in rules? Is there a bug in equal
method, maybe?


Regards

[Thomas Eichstädt-Engelen]

Hi Juanker,

> I know that newState is State type, so in the first rule it will be
> DecimalType and in the second one will be StringType. So, do you know
> why StringTypes are never equal in rules? Is there a bug in equal
> method, maybe?

i added a new StringTypeTest UnitTest which proofs, that hashCode() and equals() are working as expected. Unfortunately i am no drools-expert so i cannot help with the StateEvent-Problem.

Regards,

Thomas E.-E.

[Juanker Atina]

Thanks Thomas, I can make it work by using toString() method in
condition.

StateEvent( itemName == "MyCoolTextItem", newState.toString ==
"testing")

This way the rule is fired nicely, but i can't understand why it's
working with DecimalType, for example, but not with StringType.

Kai, can you guess what's happening here?

On 9 feb, 20:54, Thomas Eichstädt-Engelen <teich...@googlemail.com>
wrote:

[Kai Kreuzer]

> Kai, can you guess what's happening here?

I guess the difference here is that DecimalType extends "Number" and
thus Drools can figure out how to apply compare methods on it.
StringType in contrast does not extend "String" (as this is final) and
hence Drools has no idea how to compare instances of that type. Maybe
it would help if we implement the interface CharSequence (or even
Comparable<String>) in the StringType?

> On 9 feb, 20:54, Thomas Eichstädt-Engelen <teich...@googlemail.com>
> wrote:
>> Hi Juanker,
>>
>> > I know that newState is State type, so in the first rule it will be
>> > DecimalType and in the second one will be StringType. So, do you know
>> > why StringTypes are never equal in rules? Is there a bug in equal
>> > method, maybe?
>>
>> i added a new StringTypeTest UnitTest which proofs, that hashCode()
>> and equals() are working as expected. Unfortunately i am no
>> drools-expert so i cannot help with the StateEvent-Problem.
>>
>> Regards,
>>
>> Thomas E.-E.
>

> --
> You received this message because you are subscribed to the Google
> Groups "openhab" group.
> To post to this group, send email to ope...@googlegroups.com.
> To unsubscribe from this group, send email to
> openhab+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/openhab?hl=en.
>
>

[Juanker Atina]

Yes Kai, that was my first thought looking at the code.

I've played with the same rule working with different item types and
my results are always the same.

- If you try to compare newState with a String --> doesn't work. For
example:

StateEvent( itemName == "MyCoolContactItem", newState == "OPEN")

- If you try to compare newState with the same object type --> works.
For example:

StateEvent( itemName == "MyCoolContactItem", newState ==
OpenClosedType.OPEN)


This is the right behaviur, of course, and it makes sense with
discrete item types (open/closed, on/off) as their values are concrete
and you can directly access them. But it's unuseful when you deal with
StringType.

So yes, i suggest to add this feature to StringType, i mean, to
compare these states with any String, like the DecimalType does.

Maybe you can change the equal method to achieve this?

[Kai Kreuzer]

> So yes, i suggest to add this feature to StringType, i mean, to
> compare these states with any String, like the DecimalType does.
>
> Maybe you can change the equal method to achieve this?

I have just pushed a change so that the StringType.equals() method works as expected when passing a java.lang.String.