Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for "Member of" triggers #22

Closed
Dbzman opened this issue Jan 19, 2022 · 9 comments
Closed

Add support for "Member of" triggers #22

Dbzman opened this issue Jan 19, 2022 · 9 comments

Comments

@Dbzman
Copy link
Contributor

Dbzman commented Jan 19, 2022

As a follow-up from the JRule thread, support for "Member of" triggers would be super handy. Also the JRule docs don't explicitly make it obvious that groups are handled in a way that only events are triggered when the group's value changes (not from it's members). But the docs is a rather easy fix, I guess.

@seaside1
Copy link
Owner

seaside1 commented May 3, 2022

I guess you have seen this?
#31

If I would implement this what would you like to have? Like for group items, have a trigger for member of like this:

  @JRuleName("testmemberOf")
    @JRuleWhen(item = _gMyGroup.ITEM, trigger = _gMyGroup.TRIGGER_MEMBER_OF_RECEIVED_COMMAND)
    @JRuleWhen(item = _gMyGroup.ITEM, trigger = _gMyGroup.TRIGGER_MEMBER_OF_RECEIVED_UPDATE)
    @JRuleWhen(item = _gMyGroup.ITEM, trigger = _gMyGroup.TRIGGER_CHANGED)

I guess it would add complexity to allow for triggers like TRIGGER_CHANGED_FROM_ON_TO_OFF etc.

@Dbzman
Copy link
Contributor Author

Dbzman commented May 5, 2022

Yes, I've seen this but I didn't think that far that it would pave the way for the feature here. :)

I think you're right. Having additional triggers would add complexity. What about that?

@JRuleName("testmemberOf")
@JRuleWhen(membersOf = _gMyGroup.ITEM, trigger = _gMyGroup.TRIGGER_RECEIVED_COMMAND)
@JRuleWhen(membersOf = _gMyGroup.ITEM, trigger = _gMyGroup.TRIGGER_RECEIVED_UPDATE)
@JRuleWhen(membersOf = _gMyGroup.ITEM, trigger = _gMyGroup.TRIGGER_CHANGED)

That way we can re-use the triggers but make it explicit that it acts on membersOf the given item. (Or maybe membersOfGroup is even more explicit)

@seaside1
Copy link
Owner

seaside1 commented May 5, 2022

Looks good, would still need to have the item = since it is used to filter out events on the eventbus (hashmap only containing the items that we should subscribe on). Would maybe be possible to use the memberOf in that subscription as well. I can try and take a look

@Dbzman
Copy link
Contributor Author

Dbzman commented May 6, 2022

I see. It would also be fine for me if the member of thingy was a a separate flag or so like:

@JRuleWhen(item = _gMyGroup.ITEM, trigger = _gMyGroup.TRIGGER_RECEIVED_COMMAND, memberOf=true)

I could also imagine to have a kind of triggerFor option which is maybe set to ITEM as default and it's possible to set it to MEMBER_OF, like this:

@JRuleWhen(item = _gMyGroup.ITEM, trigger = _gMyGroup.TRIGGER_RECEIVED_COMMAND, triggerFor=MEMBER_OF)

Oh, and I realized that I used the plural form (membersOf) in my previous post, which maybe does not make too much sense.

@querdenker2k
Copy link
Collaborator

I think JRuleWhen is very overloaded. What about splitting this annotation into something like JRuleWhenItemChanged, JRuleWhenItemUpdated, JRuleWhenMemberOfChanged, ...

@querdenker2k
Copy link
Collaborator

I would now suggest (as well) something like

@JRuleWhenItemChange(item = _MySwitchGroup.ITEM, memberOf=true)
@JRuleWhenItemReceivedCommand(item = _MySwitchGroup.ITEM, memberOf=true)
@JRuleWhenItemReceivedUpdate(item = _MySwitchGroup.ITEM, memberOf=true)

@seaside1
Copy link
Owner

seaside1 commented Nov 5, 2022

Closing this as it is fixed in pr #66

@seaside1 seaside1 closed this as completed Nov 5, 2022
@Dbzman
Copy link
Contributor Author

Dbzman commented Nov 6, 2022

Thanks a lot for implementing this feature! I'm looking forward to try this out. :)

@seaside1
Copy link
Owner

seaside1 commented Nov 6, 2022

You should probably wait a bit. There are a number of major prs that will fix a lot of things (thinking of #77 for instance)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants