Dynamic rule builder

[rsopp]

Support for dynamic rules using a newly created JRuleBuilder

• Added JRuleInvocationCallback which is a functional interface that allows to call a anonymous function instead of a predefined method.
• Rule execution refactored, so that it is based on new JRuleInvocationCallback instead of JRule/method.
• Contexts, JRuleModuleEntry, etc. use callback instead of JRule and method.
• Annotation processing in JRuleEngine internally uses JRuleBuilder as well. Method-call is wrapped inside a callback. Behaviour is compatible to existing implementation - no changes needed in existing rule projects
• Rule-uids:
  • Dynamic rules use a random uuid by default (can be over-written using JRuleBuilder::uid()).
  • Static rules set a uid compatible with the existing naming scheme (name.method)
• Added Example (43) to show a simple usage of the new JRuleBuilder

[seaside1]

Thank you for the PR, I'll have a look shortly work with the previous PR:s, but more or less done

[seaside1]

Where did the addRuleClass go? It is removed here and not in JRuleBuilder

[rsopp]

You are totally right. that call somehow got lost. I added it again in the last commit.

[seaside1]

• Good to refactor to move out logic from JRuleEngine to JRuleBuilder
• Good with examples
• Good with tests
• Updated Readme

I have a comment there on the JRuleLoadingStatistics.addRuleClass which is missing?

Quite a big PR, I'm running this in my prod env now to test things out.
Hoping @seime or @querdenker2k can help out to test this before merge.

[querdenker2k]

@rsopp Sorry stupid question, but what's the usecase of this PR?
Is it to create rules in a loop for a few items which i would otherwise put inside a groupitem and listen on the groupitem change?
For what are you using this feature?

[rsopp]

@querdenker2k I use the following setup for the dynamic rules:

• The "configuration" for my home in one big JSON-file
• The configuration e.g. has information about all the rooms.
• For every room, I store information (itemNames, targetValues, etc.) about heating, windows, presence, rollershutters, etc.
• When JRule starts, it reads the config file and creates the rules dynamically, e.g.:
  • if a room has a heating device, I create a set of rules for that room based on the ItemNames stored in the config file.
  • if there are windows and heating, in the room, there will be a rule that lowers the target temperature when a window is opened
  • if there is a presence detector in the room, create a rule that turns off all lights after some minutes without any presence.
  • and many more. At the moment, there are more than 400 rules created dynamically from the config file.
• Since the rules are always the same but with different items for each room (or different timeouts/target values), it saves me a lot of time since I have to implement the rule just once and create it dynamically for every room when needed. Furthermore, I can ensure that the rules are always the same and have the same functionality for every room, especially when I add more rules or change something in an existing rule.
• I am also working on a native android app which reads the same configuration file and is used on a wall-mounted tablet. I am therefore also storing some frontend information in the config, like coordinates of the walls, so that it can display a nice floorplan

[seaside1]

Another example is: seaside1/jrule-sonos@389b985#diff-2cfb4f9fc917e919de336c63834832acefb3c3cfe03c5f6401201edbb7b9b56e

Using The JRuleInvocationCallback

[seaside1]

Looks good.