enrich memberOf with options to just listen on items or groups

[querdenker2k]

@JRuleWhenItemChange(item = GROUP_ITEM, memberOf = true)
changed to
@JRuleWhenItemChange(item = GROUP_ITEM, memberOf = JRuleMemberOf.All)
or
@JRuleWhenItemChange(item = GROUP_ITEM, memberOf = JRuleMemberOf.Items)
or
@JRuleWhenItemChange(item = GROUP_ITEM, memberOf = JRuleMemberOf.Groups)

In some of my rules I have something like that:

if (JRuleItem.forName(event.getMemberName()).isGroup()) {
    return;
}

To not do this inside the rule method, the rule should just be triggered for Items (and not Groups).

Further on the triggered itemName will be in itemName and not in memberName anymore, because #93

[seime]

I like the idea.
And would like to propose a similar extension to listen for events for members in subgroups. Ie
ITEM_A memberOf GROUP_A memberOf GROUP_B

It would be great if I could get changes about ITEM_A if I listen for changes in GROUP_B even if ITEM_A isn't a direct member of GROUP_B but only indirectly via GROUP_A

Use case: Motion sensing in different zones of the premises. If I have multiple sensors in GROUP_A and the group status isn't changed, I do not think listening for memberOf events in GROUP_B triggers.

[seime]

Also remember to update the README with updated/new examples :)

[querdenker2k]

I like the idea. And would like to propose a similar extension to listen for events for members in subgroups. Ie ITEM_A memberOf GROUP_A memberOf GROUP_B

It would be great if I could get changes about ITEM_A if I listen for changes in GROUP_B even if ITEM_A isn't a direct member of GROUP_B but only indirectly via GROUP_A

Use case: Motion sensing in different zones of the premises. If I have multiple sensors in GROUP_A and the group status isn't changed, I do not think listening for memberOf events in GROUP_B triggers.

Thought about the same and started doing it but reverted it again. Maybe we could this in an additional MR. I have to much open MRs and I have to merge them all again in my own developer branch. This should be simply from the user view with additional enums for JRuleMemberOf

[seime]

@querdenker2k could you rebase and resolve conflicts?

[seime]

Is this PR still a draft or ready for review?

[querdenker2k]

not ready yet, have to resolve merge conflicts (therefor the outcommented tests for better debugging) but will not get it to work in the next 5 days.

[querdenker2k]

Ready again, added IT tests.
Currently this is working just for direct members of groups (as before).
Additionaly an *_Recursive could be added to the enum.

[querdenker2k]

PUSH

[seime]

Not tested, but has unit tests

[seime]

@querdenker2k Tested this a bit tonight, and something is not correct.

I replaced all my memberOf = true with memberOf = JRuleMemberOf.All as indicated in the README file.

When using JRuleMemberOf.All, rules listening for changes in a specific group suddenly gets triggered by changes happening to items in unrelated groups.

Here is one example;

The event claims to be for group gFloodSensors, but the member is part of gMovementSensorsHouse. In fact the gFloodSensors group does not have any members at the moment, and the groups are unrelated.

I have also seen my batteryGroup monitoring rules suddenly getting triggered with motion sensor events etc.

Not sure where the problem is; either parsing of which groups contains which members or the rule filtering mechanism.

Changing from All to Items seem to stop this erratic behaviour, but not really sure if this makes it correct.

[querdenker2k]

Damn, will look into it. Could already create a negative test which describes your behaviour.

[querdenker2k]

fixed this, problem was very stupid

[seime]

Appears to be working as expected now!

Thanks @querdenker2k