JRule - openHAB Rules using Java

Added ALPHA6
Added Group functionality

1 Like

Wow - I really like JRule - very cool to develop the rules in Java. Just wanted to say thank you here!

Do you have concrete plans for the further development? Would it help to create issues in github? Are you interested in contributions? (As a small example I would love to also implement rules for a channel).

1 Like

Hi!

Glad you like it, I think it is very nice as well to write in java, so much more tools available.

No, I don’t have any concrete plans as such. I’m transforming my own old dsl and python rules to java right now (majority of the rules are done), and as I go I add functionality to jrule.
Any help or contributions are more than welcome, probably the easiest is if you submit a PR on github. I have not been working as much the past couple of weeks, but I plan to pick it up again shortly.

BR S

2 Likes

Hey, nice job! I was really waiting for this :D!

If you’re a java developer it feels like stone age having to write rulesDSL or any of the JSR scripting languages without having full auto-completion, type safety and the full power of the java library world and IDE. Don’t get me wrong, rulesDSL has it advantages for non-devs - the same like the new UI based rule engine. But If you’re a java dev you miss all the good stuff :D.

2 Likes

I wonder why I never came across this thread and started working on my own implementation.

Nice piece. I’ll try it out ASAP.

1 Like

I just gave it a shot. Pretty straightforward to setup and changes on save are quickly pickedup. Nice!
Now sharing configs etc. between rules will be a breeze. I’m now in a phase checking what is missing to move over from my DSL rules. Two things I stumbled across:

  • It would be awesome if for the @JRuleWhen one could specifiy the raw cron expression - like for “every minute” or so. I like the idea of simplicity directly providing hours and minutes, but the cron expression is more flexible
  • I tried to get item state through a group, which results in null for me. Those are windows and have OPEN/CLOSE .- maybe that’s why? I tried on/off… but there all are shown as OFF (although one is “different”). Here’s the snippet:
		_Windows.members().stream().forEach(member -> logInfo(member+":"+_Windows.getState(member)));	

BTW: what would be best for you? Providing feedback here or creating issues on Github?

This could be added. I’ll have a look at it.

Thanks, I corrected that bug and built a new alpha7.

Both will work. Pure bugs can ofc be reported directly on github.

Regards, S

Add build for channel triggers in ALPHA8. Contribution made by @roth

Added an ALPHA9 build with cron expressions. (@vguna see example 18)

Regards S

Amazing, I will give it a try, thanks!

Cronexpression works like a charm, thanks!

Now I’m stuck on

val lastStateChange = Status_Lueftungsposition_Garagentor.lastUpdate("mapdb")

Is something like this possible in JRule already?

Hi!
I have added last update. See example 19.
I’m wrapping the core class PersistenceExtensions. You could without relaying on the binding
use PersistenceExtensions by itself, you would need to add a dependency on openhab-core when developing rules to do so.

I’m thinking it would be nice to use core classes directly also for the types (Player, Switch etc) as pointed out by @J-N-K , but it’s quite a refactoring to get there.

To wrap up, you can use JRulePersistenceExtensions for now without having to add any dependencies.

Regards, S

Hi,

I have installed JRule today and I really like it :slight_smile: . I think, I will port my existing Jython and DSL rules to JRule.

I found one issue with the used directory structure: I have installed openHAB manually from a zip archive. This means, I don’t have an /etc/openhab folder. The correct folder would have been (with an installation stored in /opt/openhab): /opt/openhab/conf/automation/jrule/.

Cheers,
Martin

2 Likes

I think, you made a spelling error in the class name: you named it JRulePersistenceExtentions instead of JRulePersistenceExtensions :slight_smile:

1 Like

@MHerbst Glad you find it useful! I’ll fix the spelling error.

Br S

I like this idea a lot. So, thank you very much.

But I run my openhab inside docker where the paths differ from native installation. This causes:

2021-09-11 08:10:01.989 [INFO ] [tomation.jrule.internal.JRuleFactory] - Initializing Java Rules Engine
2021-09-11 08:10:01.990 [INFO ] [.jrule.internal.handler.JRuleHandler] - Start Initializing JRule Automation
2021-09-11 08:10:01.998 [ERROR] [.jrule.internal.handler.JRuleHandler] - JarFolder can not read or write: /etc/openhab/automation/jrule

The correct path inside docker container would be /openhab/conf/automation/. Where does the information about the location comes from? Is it hardcoded?

Only the default value for workingDirectory is hard coded to /etc/openhab/automation/jrule.
It should be possible to set the property workingDirectory to change it.

This is what the code looks like:

  final String workingDir = (String) properties.get(WORKING_DIR_PROPERTY);
       return workingDir == null ? DEFAULT_WORKING_DIR : workingDir;

The properties are set for the automation bundle on activate:

 @Activate
    public JRuleFactory(Map<String, Object> properties,

So to wrap up, you can set it as a property called: “workingDirectory”
Not sure where you would set that property on the docker file structure.

I would be able to change JRule so it first looks for workingDir property, then check /etc/openhab/automation/jrule and if that does not work try the /openhab/conf/automation/.

Regards, S

@Bjorn_Engel I’ve added a change so it is looking at the system property openhab.conf.
I believe it will work under docker but I haven’t been able to test it yet.
It would be great if you could test it (ALPHA11).

1 Like

Added a new ALPHA12 build with some fixes from @Mistral

/S

After trying so many ways to write rules (Rules DSL, Jython, HABApp, Golang, etc.) I finally seem to have found a way to write rules comfortable with full IDE support and a proper language. That’s outstanding. Great job! This should be part of core IMHO. For me personally it’s by far the best way to write rules. No longer I need to copy & paste the same code over and over again in my rule files.

One thing I noticed is that support for the color item still seems to be missing. For those items only empty classes are generated, which means, that I cannot control my lights. Would it be possible for you in a reasonable amount of time to add support for those item types?

3 Likes