Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Eclipse SmartHome » Migration of o.e.s.m.rule.runtime to o.e.s.automation.*(Roadmap? Timing?)
Migration of o.e.s.m.rule.runtime to o.e.s.automation.* [message #1719275] Wed, 06 January 2016 18:07 Go to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
All,

Cfr a post elsewhere on the forum, I now have a bespoke CalDAV server running inside the ESH runtime. The CalDAV server can be used to inject Automation Rules into the runtime using a standard calendaring application like iCal or Outlook, but it also can expose for example Rules from the RuleRegistry.

The interconnect from the CalDAV servlet to the Rule back-end still has to be developed, and hence, my question: If I understand well we have currently two parallel rule engines in the core. The new Automation component, and the old Quartz-based engine driven by the DSL .rules model. In order to focus my efforts, I would like to understand what the migration roadmap is from the old to the new engine, e.g. if this the intention of course. Who can enlighten me?

I can perfectly listen for events emitted by the Quartz scheduler and track that way which rules are getting scheduled in the Quartz scheduler (and then expose them through CalDAV to the user; this is for the *rule.runtime stuff), but I can also listen for Events from the RuleRegistry of the Automation component. I would like to avoid do do both.

From the injection point of view, I would as well add some Trigger Module(s)/Handlers that support RFC 5545 scheduling. In fact, reading up on that matter, it seems that world+dog is in favour if RFC5545 over cron, but the + side is that by defining recurring events in any calendaring app, you would have a 1 on 1 match with the Trigger module that can adhere to such a schema since these days they all use RFC5545 anyways.

Karel
Re: Migration of o.e.s.m.rule.runtime to o.e.s.automation.* [message #1720005 is a reply to message #1719275] Wed, 13 January 2016 16:33 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Hi Karel,

Sorry for the late reply!

Regarding the rule engine: Yes, we currently have two of them and the plan is to get rid off the old one. I would rather like to introduce a new RuleProvider, which reads the DSL rules and creates rules for the new rule engine (which will then also require an XbaseActionHandler that knows how to execute that stuff). Similar things are done here as well (for the Python rule support of openHAB 1): https://github.com/eclipse/smarthome/pull/813. Timewise, I cannot really tell when I could find time for this. If there are others who would be willing to work on this, it would be perfect...

For openHAB 2, I want to introduce the new rule engine as an experimental feature soon already. And as you have powerful enough hardware, I do not see a reason why you shouldn't even run both engines in parallel.
So coming back to your questions: You should definitely head for the new rule engine!

Regarding cron vs. RFC 5545: I have to admit that I hear for the first time about RFC 5545 - but looking at it, I agree that we could drop Quartz, since the main reason for it was its support for cron. Since we want to strip down ESH to Java 8 CP2 and Quartz is a major obstacle on this, I would be actually very happy to have an alternative. But when going for RFC 5545: Do you know about a good open source scheduler library that could be used for this?

Best regards,
Kai
Re: Migration of o.e.s.m.rule.runtime to o.e.s.automation.* [message #1720011 is a reply to message #1720005] Wed, 13 January 2016 17:24 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
Ok - that is clear

I have not explicitly searched for a remplacement for Quartz, but on the other hand, I have written Quartz schedulebuilder/trigger for RFC 5545 expressions. I will put in on the todo list

And oh, I did search for anything that can convert between cron and RFC5545 and there is simply nothing at all. These things are not very compatible from a expression point of view

Regards
Karel
Re: Migration of o.e.s.m.rule.runtime to o.e.s.automation.* [message #1720109 is a reply to message #1720011] Thu, 14 January 2016 13:23 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
Kai,
Just wondering, can we not extend the ThreadPoolManager to include some scheduling functionality? and/or extend the Scheduler we already use. It might be limited in terms of functionality, and just do what we require it to do for the runtime, without all the bells and whistles of Quartz. I presume that we not need (near)-real-time scheduling either, or other complicated scenarios/features.....

K
Re: Migration of o.e.s.m.rule.runtime to o.e.s.automation.* [message #1723398 is a reply to message #1720109] Mon, 15 February 2016 11:46 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Quote:
can we not extend the ThreadPoolManager to include some scheduling functionality?


Well, it already has scheduling using the standard Java scheduled executors.
But FTR: You have done such an enhancement in https://github.com/eclipse/smarthome/pull/959/files?diff=unified#diff-19f627267504b985549cd3de6eae4a52R197 and yes, I think it makes sense to combine this with the thread pool management (after all, Quartz also comes with its own thread pool).
Re: Migration of o.e.s.m.rule.runtime to o.e.s.automation.* [message #1730643 is a reply to message #1720005] Wed, 27 April 2016 10:26 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
Kai Kreuzer wrote on Wed, 13 January 2016 11:33
Hi Karel,

Regarding the rule engine: Yes, we currently have two of them and the plan is to get rid off the old one. I would rather like to introduce a new RuleProvider, which reads the DSL rules and creates rules for the new rule engine (which will then also require an XbaseActionHandler that knows how to execute that stuff). Similar things are done here as well (for the Python rule support of openHAB 1): https://github.com/eclipse/smarthome/pull/813. Timewise, I cannot really tell when I could find time for this. If there are others who would be willing to work on this, it would be perfect...

For openHAB 2, I want to introduce the new rule engine as an experimental feature soon already. And as you have powerful enough hardware, I do not see a reason why you shouldn't even run both engines in parallel.
So coming back to your questions: You should definitely head for the new rule engine!


@kaikreuzer Found it back. Cfr the above, is there anything I can pick up / do?
Re: Migration of o.e.s.m.rule.runtime to o.e.s.automation.* [message #1730774 is a reply to message #1730643] Thu, 28 April 2016 11:53 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
What would be your priority? (1) getting Xtext-DSL rules being executed by the new rule engine or (2) increase the number of available triggers/actions in the new rule engine, e.g. by adding triggers for RFC5545 or actions based on OH1 Action bundles?

If (1), then I think the first step is to process https://github.com/eclipse/smarthome/pulls?q=is%3Apr+is%3Aopen+label%3AAutomation - I am pretty frustrated that I didn't yet review and discuss them in detail and that they are still hanging there waiting. I assume they will be a pre-requisite for getting XbaseModuleTypes implemented nicely.
Re: Migration of o.e.s.m.rule.runtime to o.e.s.automation.* [message #1730826 is a reply to message #1730774] Thu, 28 April 2016 18:48 Go to previous message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
(1) for sure, as (2) I already have parts implemented. Cfr the chat on github, maybe I will have a go at building a RuleProvider that is capable of loading and executing the old-syntax-style Xtext-DSL rules.

There is potentially some overlap between https://github.com/eclipse/smarthome/pull/803 and what I have been cooking Wink

[Updated on: Thu, 28 April 2016 18:49]

Report message to a moderator

Previous Topic:REST api for Group:Switch configuration in eclipse smarthome
Next Topic:MapDB corruption
Goto Forum:
  


Current Time: Tue Apr 16 20:00:22 GMT 2024

Powered by FUDForum. Page generated in 0.24255 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top