Port JSR223 bundle to openHAB 2

Tags: #<Tag:0x00007f1824d32d48> #<Tag:0x00007f1824d32c08>

(Ralph Borchers) #101

@Jue_Wis Thanks for your code sample.

Has anybody found out how to create a timer in jython? That seems to be the last roadblock on my way to switch off OH1.

(steve1) #102

Have you tried using standard Python Timers or the sched module? I haven’t tried it (and my computers are packed for a move) but it should work. Also note that one advantage of Jython is that there is no Global Interpreter Lock (GIL) so threaded programs work even better than CPython.



(Ralph Borchers) #103

@steve1 your solution works for me. Thanks for pointing me towards this direction.

Here’s my sample code:

from threading import Timer

def timerScript():
    logging.info("Timer fired")


logging.info("Timer created")

myTimer.cancel() will cancel the running timer.

JSR223 Jyton and Canceling Timers
(Jürgen Wissing) #104

I was trying to replace a bunch of rules with one jython script and added multiple triggers to the list of triggers.
It seems that only the first trigger is registered and executed.
It that the intended behaviour?

ITEMLIST = ['Temperature_GF_Library','Temperature_GF_Wigarden','Temperature_GF_Corridor',
        self.triggers = [Trigger("OnUpdate", "core.ItemStateUpdateTrigger",
                    Configuration({ "itemName": _item})) for _item in ITEMLIST]

(Ralph Borchers) #105

@Jue_Wis I do the same like this:

       self.triggers = []
        for item in list:
            self.triggers.append( ItemStateChangeTrigger( item, None, item ) )

(this is typed from memory, and therefor untested :slight_smile: )

BTW the above is using @steve1 library code.

(steve1) #106

I’m not sure, but it may be a requirement to have a unique identifier for each trigger of a rule (my wrappers generate a unique ID).

(Jürgen Wissing) #107

@steve1, @ralle thank you, appending the name for every trigger was the solution.

(Torpex77) #108

Looks like there has been tremendous progress on this since I last checked in. I pulled down the Docker image of the latest 2.2.0 snapshot, added the experimental rules engine, added the Groovy jar files, and magic, the example script worked. Nice.

I’m going to start playing around with porting my 1.x groovy rules, but need a little guidance.

What is the best and/or easiest way to create a jar file such that the classes are available from my groovy rules?

I have some “base classes” that I have written (in Java) to share common functionality and easily create new rules for specific use cases For OH 1, I had to fork the openhab1-addons repo and add my classes. Since OH2 has significant architecture changes, I thought there might be a better way.



(steve1) #109

I’ve never used Groovy, but it looks like some interesting ideas on this page:

It sounds like it might be possible to put the jars into $OPENHAB_HOME/.groovy/lib too (???).

(Torpex77) #110

It didn’t work under OH1. Something was preventing them from actually getting on the classpath used by the rules. Something with the framework, I think.

Honestly, I should have tried that before I posted… It’s an easy thing to try - create a jar file and throw it in with the rest of the groovy libs. I’ll give it a shot tonight.

(Torpex77) #111

No luck just dropping a jar in with the groovy ones. I think OGSi prevents that. I read a bit about creating “bundles” and whatnot, but looks like I have a lot of reading to do before I can go down that route.


(steve1) #112

Did you try the RootLoader technique described in the article?

(Torpex77) #113

Yes. I thought that had a good shot at working since it wasn’t something I had tried with OH1. It’s also entirely possible I messed something up as there were a fair number of distractions at home when I was trying it. I’ll try it again if I get a chance, as it’s a good technique to have in the toolbox.

For now, I ended up using the same approach I used on OH1, which is just to put them inside the existing rule engine bundle, build via maven, and replace the distribution jar with my own. That took longer than it should have because I didn’t know I needed to delete the OH2 cache directory for it to pick up my changes. (Maybe deleting the cache would have helped with the RootLoader approach?) I wasted a couple of hours because of that.

My current plan is to fork the smarthome repo and push some changes up for comments once I get a little further with my approach.



(Torpex77) #114

In OH1, I could
import org.openhab.core.jsr223.internal.shared.Openhab;
then in my base class do something like:
Openhab.sendCommand(item, commandString);
to access the sendCommand and/or postUpdate functions.
In OH2, sendCommand() and postUpdate() are passed into the JSR223 script in a “magic” events variable, which seems to be of type org.eclipse.smarthome.automation.module.script.defaultscope.internal.ScriptBusEvent

I want to sendCommand() and postUpdate() from my base class, which exists outside of the script.

I searched through a lot of code in the IDE, and I could not find a similar static way to instantiate the events variable - type ScriptBusEvent. There is a BusEvent class, which does have static operations for sendCommand() and postUpdate() but that’s not in the imports for the bundle… It looks very similar to ScriptBusEvent, other than it is has static methods and ScriptBusEvent does not.

Any ideas on how I can call sendCommand() and postUpdate() outside of the scope a script? That is, in my own external base class? I could probably require the events variable to be passed via constructor, but I was hoping just to “take care of it” internally.



(Torpex77) #115

I tried something it little different last night. I used the 000script approach from Simon’s examples to create a Groovy
script that always executes first. In that script, I defined my base class, ItemRule. Since the script has access to the events variable, I can push that into ItemRule, and then it will be able to sendCommand() and postUpdate(). Then in the same file I created a new class extending ScriptExtensionProvider and created a preset with my class in it. Then my other scripts could importPreset(“Doug”) and access my class definition.

    def onRule2 = ItemRule.newInstance("MySwitch")

As convoluted as that sounded, it worked. BUT…
I don’t want to just create a new instance. I want to extend it. But

class ItemRule2 extends ItemRule { }

won’t compile because of “unable to resolve class ItemRule”

I learned a lot, but I think I’m stuck with this approach. I tried a bunch of different things (imports, etc.), but just couldn’t get ItemRule visible as something I could extend.

I think i’m just going to move on and accept that I’m going to pass the events variable in the constructor to my base classes for now.

Anybody know how to find and use an Action from groovy?

I suspect that will be the next thing I bump into. I took a look through Steve’s OSGi python classes, but couldn’t mentally translate that into a Groovy approach due to a lack of experience with bouth OSGi and Python.



(Torpex77) #116

Answering my own question after more than a bit of reading code…

My solution was to just use BusEvent and its static methods in my base class. And I’m using ScriptServiceUtil to get the item registry, so I don’t need to pass that in either.

So, I’m making progress on moving my base classes over from OH1 to OH2.


(Ralph Borchers) #117

@steve1 I noticed you added a rule decorator to your library in openhab.rules. Could you please add an usage example to your Readme? I tried using the decorator in the same way as your decorator for Jython/OH1.8, but that doesn’t work.

(steve1) #118

I’ll add some information soon. Here’s an example of how to use it.

from openhab.rules import rule, addRule
from openhab.triggers import StartupTrigger

class ExampleRule(object):
    def getEventTriggers(self):
        return [ StartupTrigger() ]

    def execute(self, module, inputs):
        self.log.info("rule executed")


The decorator adds the SimpleRule base class and will call either getEventTriggers or getEventTrigger (the OH1 function) to get the triggers, if either function exists. Otherwise you can define a constructor and set self.triggers to your list of triggers.

The decorator also adds a log object based on the name of the rule (self.log, can be overridden in a constructor) and wraps the event trigger and execute functions in a wrapper that will print nicer stack trace information if an exception is thrown.

(Ralph Borchers) #119

@steve1 Thanks. Just one small correction to your example. It needs to import automationManager, not addRule. I sent you a PR.

(steve1) #120

You should pull the latest updates. The addRule import is correct. The openhab.rules module doesn’t export automationManager any more because the module must look it up dynamically from the script-specific scope when addRule is invoked. I changed it after I noticed that rules were not being deleted when a script was reloaded. The addRule function should be equivalent to: