If the statement events.sendCommand('DI_LED16_FRONT_DOOR_SAFE', "ORANGE") is active, my script fails with Failed to execute rule '3252e495-2105-4c6d-9382-b9f8800914cb': Fail to execute action: 1.
1.) where can I find more information regarding the error? openhab.log and events.log do not carry enough information
2.) since logger.warn(events) yields the same error, I wildly guess that events is unavailable… how do I get access to events?
Passing the context (events, ir) via the constructor is a clumsy workaround, but I could go on like that, if there is no other solution.
However, it also seems I cannot access OpenClosedType. Executing the version pasted above leads to Error: java.lang.NoClassDefFoundError: org/openhab/core/library/types/OpenClosedType ....
How do I address this?
(You might notice that I also used Object as the type of events because of a similar Error when using the appropriate ScriptBusEvent type. But since ScriptBusEvent resides in an internal package I thought this is unavoidable.
All of my changes have been after the 2.4 release. I’ve done very little with Groovy, but I’m aware of some issues. I have an idea of what the problem is and plan to dig into them sometime this year… possibly over the summer. I plan to build out Groovy and JS helper libraries with the same functionality as the ones for Jython, but I may just put that effort into building out a scripting API that provides that functionality.
You’re migrating from 1.8, but are your rules currently in Groovy? That would be great, as there are very few people using Groovy and your experience could help a lot. @vbierrecently reported a similar issue, so he might have some insight for you.
This is working for me in OH 2.4 and Groovy 2.4.12…
Regarding access to events: it seems that a Rule can access events only if an anonymous class is used, as in all examples found in the docs. However, I prefer named classes which typically get parameters (mostly item names) passed.
access to events works with the following code (anonymous class)
I could switch to anonymous classes for simple use cases, but that would force me to pass my parameters with setters or the like. From a design perspective, this is undesirable: constructor parameters enforce passing (mandatory) values.
Additionally, this does not work for complex cases, where I created my own class hierarchies (MyXyzRule implements Rule with OpenHab 1.8).
I’ve done a lot with Groovy rules, but not a much lately.
IIRC, I bumped into the same issue. I just couldn’t get my rules to do enough common stuff easily to make it worth it. Which led me down a path of putting all my base classes directly into the the RuleSupport bundle. Which was kind of a pain, but worked for me. They do a lot of things the various Python libraries do and generally make it easy (or easier at least) to do the common things you want to do in a rule script.
It’s been on my list for a while to port these from 1.x to 2.x, and was mostly done. But with upcoming org/package changes in 2.5 (which is a good thing) plus potential rules changes in 3.x I decided to hold off on that for now. Plus, work has been really busy and my free time has been limited.
The Python rules have come a long way in the past couple of years (thanks @5iver) and I’ve had “learn Python” on my to-do list for a while. So I decided to just go ahead and port my rules to Python. It took a bit longer than I wanted, since I was learning the language at the same time. And moving from OH1 to OH2. But I’ve got most of my rules converted now.
Sorry that doesn’t help with your problem right now. But I thought I should at least chime in as you seem to be bumping into much of the same issues.
I wish there was a way to dynamically add Groovy classes to the Rules Engine at runtime like you can the way JSR support is set up for JPython. I never was able to figure out a way to do that to my satisfaction (I could dynamically compile objects, but not use them to in extending a base class.)
Post for any questions/issues you haven’t figured out and I’ll be glad to help!
I still have some tabs in my browser open to circle back to you when looking into building a scripting API to provide helper library functionality for all languages! I probably won’t get to that for a couple months yet.
Thanks for your input. Due to a bunch of new requirements I felt it was the right time to go from OH 1.8 to 2.4… but I am starting to look for alternative ways to implement my complex rules. One idea is a rule generator which generates XText rules based on Groovy/Kotlin code.
I need OH 2.4 since I need (or at least “want to have”) features introduced in Homematic Binding 2.x.
Learning Python was on my list too, it never made it to the top .
That should work as long as the old rule engine is around. If you want to stay on a stable release, then when 2.5 rolls out, setup Jython and the helper libraries (StartupTrigger is included). The StartupTrigger will then be available in the UI or any language that you are using.