Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Eclipse SmartHome » New Modular Rule Concept  () 1 Vote
New Modular Rule Concept [message #1477164] Mon, 17 November 2014 17:30 Go to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
The current rule engine that derives from openHAB 1 has a couple of constraints:

  • it requires EMF/Xtext/Xbase on the runtime, which is not ideal for constrained devices
  • it does not allow to build rule GUIs on top as all rules are purely textually defined.
  • it does not allow to reuse and share rules or logic blocks between users / solutions.

We therefore would like to introduce a new rule concept into Eclipse SmartHome. The overall idea is to have reusable rule components that are formally described, so that they can be handled in GUIs and combined into rules. These must be provided as a kind of template, that can easily be shared and instantiated by a user through a UI.

Think a bit along the idea of IFTTT (https://ifttt.com), which makes it easy to share "recipes", which are a kind of rule template and which works by simply combining a trigger and an action into a rule. For Eclipse SmartHome, the simplest version of a rule should be similar to this, while still allowing more complex setups as well, which will definitely include the possibility to write scripts. As such, it should also be implemented backward compatible to the current DSL-based rules.

As usual for Eclipse SmartHome, a major requirement is to provide a flexible framework that can be used by different solutions in different ways. The main work therefore is to define a modular structure where bits and pieces are formally described, so that they can be used by dynamic UIs. Extensions will then have a clearly defined interface and thus could be used within different solutions based on Eclipse SmartHome.

Another requirement is that this framework should be as platform-independent as possible, i.e. the declarative parts of it should not refer to Java or OSGi specifically. Instead, it should be potentially possible to use rule/template definitions on other systems like a cloud-server as well.

Since the Eclipse SmartHome REST API makes use of JSON, it seems to be a good choice to use this format as well for the new rule concept.

We have internally started some discussion already and would like to share some initial ideas for further public discussion.

Let's start with some terminology:
A rule instance is a list of modules that are linked to each other and that can pass data. A rule has three main blocks: "on", "if" and "then".
The "on" block contains triggers, which is a specific sub-type of module. Triggers contain logic that can fire a rule, usually based on some event.
The "if" block contains conditions, which is a specific sub-type of module. A condition can block the rule execution - only if all conditions evaluate to true, the "then" block is entered.
The "then" block contains processors and actions, which are again both sub-types of module. While processors are meant to contain complex processing logic that transform input into some output, actions are "leafs", that execute something that corresponds to the main use case of the rule (and thus likely cause some external effects on devices etc.).

A simple rule instance could e.g. described like this.
Note that this is not a file that anybody (especially no user) would write manually. Instead, the same could be transformed into a rule template.
Based on such a template, a user could simply create his personal rule instance.
Of course this could be created through a GUI, based on the information in the template.

What I left out so far is how single modules are declared (with their input and output parameters and possibly and that we need to define templates for the "on", "if" and "then" blocks separately in order to reach an architecture that allows IFTTT-like use cases that do not use complete recipes, but rather allow the combination of a single trigger with an action.
This will be a topic for the upcoming weeks, but I wanted to start the public discussion and induce your participation and feedback on it - I am looking forward to it!

Cheers,
Kai
Re: New Modular Rule Concept [message #1477295 is a reply to message #1477164] Mon, 17 November 2014 19:57 Go to previous messageGo to next message
Davy Vanherbergen is currently offline Davy VanherbergenFriend
Messages: 15
Registered: March 2014
Junior Member

Hi Kai,

Thanks for sharing your ideas. Here are some of my (random) thoughts:

* I'm quite happy to see the EMF/XText dependencies go and like the JSON approach
* I really like the idea of rule templates and rule sharing a lot Smile
* Why focus on maintaining backwards compatibility with the current DSL based rules? Won't this limit the implementation options? As an alternative, why not provide a migration utility to convert existing rules to the new syntax/style?
* Will it be possible to run the SmartHome without this rule engine? Maybe I want to use a simple rule flow like Node-RED or even bring a full blown rule engine software if I want to manage all the rules for a skyscraper...
* The new rule engine should be fast and if possible not need any warm up time, i.e. the very first execution of a rule should have the same performance as when it is executed frequently.

But most importantly, I believe the rule engine should be well isolated and not use any other link into SmartHome Items other than via the event bus. Please do not use StateChangeListeners on the items like was done in openHAB.

Kind regards,

Davy

Re: New Modular Rule Concept [message #1478162 is a reply to message #1477295] Tue, 18 November 2014 12:45 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Hi Davy, thanks for your feedback!
Regarding your questions:
* Backward compatibility: Note that there is no integrated scripting possibility in the suggested solution. Instead, I foresee an (optional) "XbaseScriptAction" module, which would have the script as a string configuration parameter - rule instances could be created directly from the DSLs, mapping the "when" part of the DSL to the new triggers and the "then" part to such a script module. Note that this will directly create rule instances, so there won't be any templating involved. A similar action type could be introduced for JavaScript, to allow scripting without any EMF/Xtext dependencies. It is hence up to the solution whether it wants to support XbaseScriptActions or not - for openHAB 2, this will very likely be the case, for solutions that target average users probably not.
* Yes, the rule engine should be an option module that can be left out.
* Warm up time: Well, the rule engine itself should not have any impact on the performance. It will be the different modules that matter. And thus there will not be a general answer.

Regarding link to SmartHome interna/items: As the example files already show, I doubt that it will be possibly to NOT provide access to the item registry as you will always have the need to get the current state of some item during rule evaluation. After all, this is what the item registry is made for. Could you maybe give more details on your concerns regarding this point?

Regards,
Kai
Re: New Modular Rule Concept [message #1478426 is a reply to message #1478162] Tue, 18 November 2014 17:22 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
It could be interesting to have a look at the IDE of Loxone to understand what kind of inputs and outputs the define on their function blocks. Their approach to the IDE (interconnecting blocks with lines etc) is interesting, and they have function blocks that mimic the behaviour of some of our bindings.

Question: what kind of functions or variables would you take available in the execution block? cfr. the discussion on how to determine which Item of a group caused a trigger to be triggered, or, looping through a bunch of items (e.g. I could imagine definite a "filter block" in which you would specify the parameters that have to match for the Item/... to be considered) . How to feed outputs of one rule as input to another rule?

I certainly like the template aspect because there is often a need to copy/paste a rule on a large number of items.

More questions to follow - it needs a bit of reflection Wink
Re: New Modular Rule Concept [message #1486709 is a reply to message #1477164] Tue, 25 November 2014 08:28 Go to previous messageGo to next message
Jan Koehnlein is currently offline Jan KoehnleinFriend
Messages: 760
Registered: July 2009
Location: Hamburg
Senior Member
I am a bit said to hear Xbase is perceived too heavy weight for your usecase. I always considered the "programming" approach of openHAB the second major benefit (after the unification) over proprietary point-and-click solutions.

Here are just a few very biased (as an Xtext committer) thoughts on that:

1) Graphical tool
There is really nothing more heavy weight and inflexible than a graphical editor. Describing a control flow graphically is really painful and works only for the most simplistic cases. The things you currently describe with Xbase expressions are exactly the points where you need the full power of expressions.

2) Function blocks
Limiting expressions to perceived common usecases will drive the user nuts in the long run. First they are going to need arithmetics, e.g. to AND connect boolean conditions, then they'd need to call helper methods, e.g. to process just a substring of the message sent by a device. When expressions grow larger, type safety becomes interesting. It is hard to put a limit on that. If you do, your solution is unlikely to provide better functionality than the existing proprietary solutions you want to replace. If you decide not to limit that, you're going to end up with something close to Xbase.

3) JSON
JSON is just XML in a 2010s dress. Not apt for human interaction, as opposed to the Xtext approach.

Maybe one could also try to improve the Xtext/Xbase solution. E.g. adding some sort of function concept should allow reuse of behavior easily.

But maybe the Xtext/Xbase approach is too much an entry barrier for 'common' users.


---
Get professional support from the Xtext committers at www.typefox.io
Re: New Modular Rule Concept [message #1486930 is a reply to message #1486709] Tue, 25 November 2014 12:01 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
As a java programmer I even find the usage of Xtext/Xbase not that easy, well, certainly the fact that the OH Editor is not an IDE after all. It makes the learning curve so steep....

In my ideal world I would like to be able to write Rules and Scripts in pure full-fledged Java, which is either interpreted at run-time in combination with some clever java reflection by the OH runtime, or provided as pre-compiled jars, or... One could argue that this can be already done today, by writing a kind of virtual binding/add-on that snoops the Item Registry and other places, but a lot of that could be factored out in something common. I think such an approach could be fine for the more advanced user, knowing that most Rules code is "write once and deploy" anyways.
Re: New Modular Rule Concept [message #1488655 is a reply to message #1486709] Wed, 26 November 2014 20:20 Go to previous messageGo to next message
Dennis Nobel is currently offline Dennis NobelFriend
Messages: 166
Registered: September 2014
Senior Member
Jan Koehnlein wrote on Tue, 25 November 2014 09:28
I am a bit said to hear Xbase is perceived too heavy weight for your usecase. I always considered the "programming" approach of openHAB the second major benefit (after the unification) over proprietary point-and-click solutions.

Here are just a few very biased (as an Xtext committer) thoughts on that:

1) Graphical tool
There is really nothing more heavy weight and inflexible than a graphical editor. Describing a control flow graphically is really painful and works only for the most simplistic cases. The things you currently describe with Xbase expressions are exactly the points where you need the full power of expressions.

2) Function blocks
Limiting expressions to perceived common usecases will drive the user nuts in the long run. First they are going to need arithmetics, e.g. to AND connect boolean conditions, then they'd need to call helper methods, e.g. to process just a substring of the message sent by a device. When expressions grow larger, type safety becomes interesting. It is hard to put a limit on that. If you do, your solution is unlikely to provide better functionality than the existing proprietary solutions you want to replace. If you decide not to limit that, you're going to end up with something close to Xbase.

3) JSON
JSON is just XML in a 2010s dress. Not apt for human interaction, as opposed to the Xtext approach.

Maybe one could also try to improve the Xtext/Xbase solution. E.g. adding some sort of function concept should allow reuse of behavior easily.

But maybe the Xtext/Xbase approach is too much an entry barrier for 'common' users.


I fully agree that a text-based approach like Xbase is the most powerful and flexible way to define rules. A graphical user interface can not cover every use case, or it will be so generic, that it is graphical programming at the end.

But the goal of the new Rule Engine concept is to provide at least the possibility to create UIs that allow a more "user-friendly" (yes I know "user-friendly" depends on the user Wink) way to create rules. These UIs will definitely not be so much powerful as the DSL was, but they can be used by "non-technical" users. And there are a lot of simple rules, which cover a lot of typical uses cases. Eclipse SmartHome understands itself as framework also for commercial end-user SmartHome solutions. If Xbase would be the core part of the Rule Engine, the UI would have to deal with parsing Xbase in the frontend. So we decided to create a more generic approach, that allows to create UIs too, but also has scripting support.

At the moment there is no plan to fully remove Xbase or the textual way of defining rules, but it will be only one way of defining a complex logic as an XbaseScriptAction for example. In addition there probably will be a JavaScriptAction. So at least openHAB users are still able to specify their complex rules textually with an Xtext-based DSL.
Re: New Modular Rule Concept [message #1490865 is a reply to message #1488655] Fri, 28 November 2014 14:06 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
@Jan: I fully agree with your points. As Dennis says, this new concept does not at all mean that Xbase for rules will disappear. Currently, the rule DSL already structures rules into triggers and an Xbase action block. With the new concept, this will be more formalized and it will be possible to add new kinds of triggers to the system as well. Having an XbaseScriptAction available will allow you to do the same as today, but better: You can actually remove your specific item names from it and use placeholders instead - and this makes all your code reusable for others. This will make it much easier e.g. for openHAB users to exchange their rules.
At the same time, Xbase becomes an option for ESH-based solutions, so if a vendor decides against textual rule possibilities, he is not forced to carry this (significant) part of the software stack with him.
Wrt JSON: This format is not meant to be written by developers/users, but rather by web UIs. So the human-readability is not that important - it must be rather easy to handle by (web) clients and for them JSON seems to be the best option.

@Karel: In theory, any logic should be possible within the modules. So a "GroupTrigger" could have as an output value the item that has made the group change its state. You can also have modules that do filtering etc. Modules are supposed to be compatible, if the output parameters of one match the input parameters of another. We will come up with more details on this soon.
Module Description [message #1497026 is a reply to message #1490865] Wed, 03 December 2014 13:32 Go to previous messageGo to next message
Benedikt Niehues is currently offline Benedikt NiehuesFriend
Messages: 6
Registered: December 2014
Junior Member
Hi all!
I've created a gist with a proposal on describing modules. As Kai mentioned in his first post this was left out - until now.
In advance the proposal deals with the same description approach for each kind of module, they only will be separated by their type (trigger, condition, processor, action).
(btw. I would handle processors as actions with output parameters)
The proposal plans with three kinds of parameters which can be defined for a module:

    config : these parameters are meant as user-editable. The parameters types should only be primitive types.
    input : input-parameters should refer to output-parameters of other modules.
    output : parameters which are provided for other modules


The Gist can be found here:
gist.github.com/BenediktNiehues/bb8a3abda32aab3f2538
(sorry, I am not allowed to create external links...)

As you can see, there are files for each module-type (trigger, action, condition), but it should not be a must to separate them.
Block-Templates [message #1497046 is a reply to message #1490865] Wed, 03 December 2014 13:53 Go to previous messageGo to next message
Benedikt Niehues is currently offline Benedikt NiehuesFriend
Messages: 6
Registered: December 2014
Junior Member
Additionally to templates for whole rules it might be useful to share templates for each kind of "block" (on, if and then).
These templates are meant as a kind of module-definition. The intention is to use these "block-templates" as modules within a rule definition. This provides the opportunity to specialize kinds of more abstract modules like the compare module. For example such a block template can be "check if the items state is ON with just the item as config-parameter. Or it is possible to provide a script-action which then could be parameterized for special use-cases. Or the combination of a set of triggers could be a useful template.
A proposal for such "block-template"-definitions can be found here:
gist.github.com/BenediktNiehues/712138deab15aa695a2c
(sorry, I am not allowed to post external links)
Question regarding Config and Input parameter [message #1497057 is a reply to message #1490865] Wed, 03 December 2014 14:04 Go to previous messageGo to next message
Benedikt Niehues is currently offline Benedikt NiehuesFriend
Messages: 6
Registered: December 2014
Junior Member
There is an open question regarding config/input parameters within a rule definition:
Example:
There is a Module defined with some config parameters e.g. a condition with configParameter itemName. But it could be possible that the ItemName is defined by user manually as well as it could be a result of a previous module e.g. a Trigger.
Question:
Should the property itemName be defined as input or as config parameter? And how should it look in the rule definition? Or should there be two different modules (what I wouldn't prefer): one with itemName as config-parameter and one with itemName as input-parameter?

Let's discuss it here!
Re: Question regarding Config and Input parameter [message #1497142 is a reply to message #1497057] Wed, 03 December 2014 15:20 Go to previous messageGo to next message
Marin Mitev is currently offline Marin MitevFriend
Messages: 22
Registered: December 2014
Junior Member
Hi,
the word block is better than module and the rule can consist of several trigger blocks, several condition blocks and several action blocks.
In addition there are block templates: template for action/actions, for conditions and triggers. There could also be templates for rules which only need small modifications by their configuration parameters - like itemName or timeInterval
Re: Question regarding Config and Input parameter [message #1498079 is a reply to message #1497142] Thu, 04 December 2014 06:51 Go to previous messageGo to next message
Benedikt Niehues is currently offline Benedikt NiehuesFriend
Messages: 6
Registered: December 2014
Junior Member
@Marin: your post shows that we definitely have to declare the terminology, soon. In my thoughts a block should be a kind of container for several modules of the same type, like a list of triggers....
Re: Question regarding Config and Input parameter [message #1498123 is a reply to message #1498079] Thu, 04 December 2014 07:32 Go to previous messageGo to next message
Yoradan Mihaylov is currently offline Yoradan MihaylovFriend
Messages: 1
Registered: November 2014
Junior Member
In my opinion blocks are parts of the modules. We have trigger blocks, condition blocks, processors blocks and action blocks. We can group them into trigger module which contains all trigger blocks, condition module - all condition blocks, processor and action modules. In this way Rule will be build up to 4 modules
Terminology agreement [message #1508291 is a reply to message #1498123] Fri, 12 December 2014 09:23 Go to previous messageGo to next message
Benedikt Niehues is currently offline Benedikt NiehuesFriend
Messages: 6
Registered: December 2014
Junior Member
Following is the agreement for the terminology of the RuleConcept and its components:

All Terms are noted in UPPERCASE:

+ The term for the whole new rule concept should be AUTOMATION, so there will be a new component in Eclipse SmartHome called automation.

The Rule consist of SECTIONS for RULE MODULES:
+ RULE
+ ON --> SECTION for TRIGGERs
+ IF --> SECTION for CONDITIONs
+ THEN --> SECTION for ACTIONs
+ trigger, condition and action are RULE MODULESs

A template for a rule is named RULE TEMPLATE
it consists of
+ CONFIG --> a list of CONFIG PARAMETER descriptions
+ ON-Section
+ IF-Section
+ THEN-Section

MODULE DESCRIPTIONs are descriptions of modules with a set of parameters like id, name, description tags etc. and also a set of parameter descriptions for following purposes:
+ CONFIG --> to describe Configuration parameters for the module
+ INPUT --> to describe input parameters for the module
+ OUPUT --> to describe output parameters for the module

Templates for Rules Modules are named MODULE TEMPLATE in general and specialized
+ TRIGGER TEMPLATE
+ CONDITION TEMPLATE
+ ACTION TEMPLATE
They are specialized forms of MODULE DESCRIPTION and contain one or more Modules of the same type (trigger, condition or action)

A MODULE is a fully configured instance of a ModuleDescription with concrete values for all the needed configuration and input parameters. Concrete values can also be references to output parameters of former modules in the Rule (btw. for modules contained in templates the values can also refer to the templates config and input parameters).

Rule and template description agreement [message #1508300 is a reply to message #1508291] Fri, 12 December 2014 09:32 Go to previous messageGo to next message
Benedikt Niehues is currently offline Benedikt NiehuesFriend
Messages: 6
Registered: December 2014
Junior Member
Following gists show the agreed JSON-format for each component:

Re: New Modular Rule Concept [message #1538309 is a reply to message #1477164] Wed, 31 December 2014 08:48 Go to previous messageGo to next message
Martin Klimke is currently offline Martin KlimkeFriend
Messages: 2
Registered: December 2014
Junior Member
I very much like the proposal of Karel, to use a standard well documented language,e.g. Java, as the bases for creating rules and keeping the proprietary APIs too minimum.

To my experience, the DSL of OPENHAB 1 was a design failure. It did not simplify things, it made it very complicated largely due to missing documentation and inconsistent definitions.

Now considering of a concept which is based on formats which were intended to be machine readable and additionally introducing proprietary constructs will make the situation even worse.
OPENHAB had always the philosophy to keep the intelligence local. The intranet of things for good reason due to privacy protection. To drive the development of the rule engine to be able to be easily cloud extendable, should not be the priority.

Also the idea, of just using only a graphical editor as the only option is not great. Graphical editors may become an option but not the sole approach.
For my experience doing hardware design on schematics, it was a big relieve when VHDL was introduced. In digital logic, only in exceptional case we used graphical editors after this because they kill productivity.

Re: New Modular Rule Concept [message #1540366 is a reply to message #1538309] Thu, 01 January 2015 12:52 Go to previous messageGo to next message
Dennis Nobel is currently offline Dennis NobelFriend
Messages: 166
Registered: September 2014
Senior Member
Hi Martin,

Martin Klimke wrote on Wed, 31 December 2014 09:48
I very much like the proposal of Karel, to use a standard well documented language,e.g. Java, as the bases for creating rules and keeping the proprietary APIs too minimum.

To my experience, the DSL of OPENHAB 1 was a design failure. It did not simplify things, it made it very complicated largely due to missing documentation and inconsistent definitions.


The base of the openHAB 1 rule engine is Xtend (Xbase more precisely), which is a touring-complete programming language comparable to Java and it is documented not that bad (https://www.eclipse.org/xtend/). Without using a programming language a rule engine will never be powerful enough to cover all use cases. But programming languages are always quite complex.

Martin Klimke wrote on Wed, 31 December 2014 09:48
Now considering of a concept which is based on formats which were intended to be machine readable and additionally introducing proprietary constructs will make the situation even worse.


If there would have been an widespread open source format for defining rules which fulfills the requirements for a new rule engine, we would have used it. But as far as I know there no such format at all. So the only possibility is to define a new one, but it should be open and not proprietary.

Martin Klimke wrote on Wed, 31 December 2014 09:48
OPENHAB had always the philosophy to keep the intelligence local. The intranet of things for good reason due to privacy protection. To drive the development of the rule engine to be able to be easily cloud extendable, should not be the priority.


The format allows to have also cloud based implementations, but it can also be implemented in a way that the whole rule logic stays in your intranet. I think the first implementation of the rule engine will support offline use-casey only. but. The philosophy you are talking about is an openHAB philosophy. But Eclipse SmartHome is a framework, that may be used by commercial companies which are interested in having cloud logic.

Martin Klimke wrote on Wed, 31 December 2014 09:48
Also the idea, of just using only a graphical editor as the only option is not great. Graphical editors may become an option but not the sole approach.
For my experience doing hardware design on schematics, it was a big relieve when VHDL was introduced. In digital logic, only in exceptional case we used graphical editors after this because they kill productivity.


As a developer I would also never use a graphical editor for programming. But the users of Eclipse SmartHome based solutions will also be people, which not have technical skills. So they need a graphical user interface to configure their rules. For openHAB the rule engine still provides the possibility to define scripts and rules in a textual manner.

Regards

Dennis

Re: New Modular Rule Concept [message #1540416 is a reply to message #1540366] Thu, 01 January 2015 13:32 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
Kai,

What we might need as well is a way to debug code of the DSL/Rule Concept. Xtend/Xbase is rather hard because there no way to really debug your code. I think a large part of learning a language comes from debugging, and so we have a kind of chicken-or-egg problem. Without a real debugging possibility it is a lot of trial and error, and that is really a source of frustration.

Just a philosophical question, but *could* we (technically) use Java as DSL on ESH?
Re: New Modular Rule Concept [message #1542550 is a reply to message #1540416] Fri, 02 January 2015 18:32 Go to previous messageGo to next message
Dennis Nobel is currently offline Dennis NobelFriend
Messages: 166
Registered: September 2014
Senior Member
Well, I think it is not possible. Because Java must be compiled and can not be interpreted. That means the runtime would need a Java compiler, which is not an option for me. So you can only use languages which can be interpreted at runtime like Javascript, Groovy or Xtend for example.

I believe it will be very hard to realize a debugger for an embedded scripting language, which is interpreted at runtime. Xtend and also Xtext based DSLs support debugging, but only for generated Java code and not for interpreted code. The problem is not the debugging process itself, its the tooling. But I´m not a JVM expert, so maybe someone else can better comment on this.
Re: New Modular Rule Concept [message #1542671 is a reply to message #1540416] Fri, 02 January 2015 20:07 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Quote:
Just a philosophical question, but *could* we (technically) use Java as DSL on ESH?


Well, if you are a developer and you live in the IDE anyhow, the new concept will allow you to code your logic in Java as well - you would then have to export it from the IDE in compiled form and bring it to your runtime, but then remote debugging would be possible. This could be a way for developers to deal with rules, but not for the normal user.
Another option may be Javascript, at least IntelliJ brings support for debugging this on a JVM with Nashorn: http://blog.jetbrains.com/idea/2014/03/debugger-for-jdk8s-nashorn-javascript-in-intellij-idea-13-1/

Regards,
Kai
Re: New Modular Rule Concept [message #1543633 is a reply to message #1542671] Sat, 03 January 2015 09:15 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 Fri, 02 January 2015 15:07

Well, if you are a developer and you live in the IDE anyhow, the new concept will allow you to code your logic in Java as well - you would then have to export it from the IDE in compiled form and bring it to your runtime, but then remote debugging would be possible.


Interesting. How should that work? One creates a new plugin and then instantiate "Rules" in java? And have those interact with the Registries and so forth? So that means you intend to OSGi-fy the new concept completely?

K
Re: New Modular Rule Concept [message #1549806 is a reply to message #1543633] Tue, 06 January 2015 19:05 Go to previous messageGo to next message
Martin Klimke is currently offline Martin KlimkeFriend
Messages: 2
Registered: December 2014
Junior Member
If Javascript is possible and would also improve the debuggging capability, then this is the way to go forward.
Well documented, a lot of code reuse by code sniplets from the internet.
Maybe this approach could also be used to somehow improve the more or less static sitemap definitions.
Re: New Modular Rule Concept [message #1551890 is a reply to message #1543633] Wed, 07 January 2015 22:24 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Quote:
One creates a new plugin and then instantiate "Rules" in java? And have those interact with the Registries and so forth? So that means you intend to OSGi-fy the new concept completely?


Well, yes, instead of specifying a rule through the REST API and some JSON structure, it should be possible to bring them directly included in an OSGi bundle as well. After all, the new concept describes merely the interfaces and the real code could be any language, i.e. also Java. But let's continue this discussion once an initial implementation of this framework is available.
Re: New Modular Rule Concept [message #1619278 is a reply to message #1551890] Mon, 16 February 2015 13:13 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
FTR: There is a PR currently being worked on which shows the current status of discussion regarding a Java API: https://github.com/eclipse/smarthome/pull/190
Re: New Modular Rule Concept [message #1643809 is a reply to message #1542671] Sun, 01 March 2015 19:37 Go to previous messageGo to next message
Gernot Eger is currently offline Gernot EgerFriend
Messages: 1
Registered: July 2009
Junior Member
A concept where Rules are implemented directly as OSGI bundle in my opinion would be best for the programmer type; a lean api would help here, so I propose this concept:

Provide a wrapper that registers as listener to all events and item changes, and call some registered objects provided by the user. A class where generated code can be copied into will serve as static reference to Items if one wants that, but thats optional.
If this would be accompanied with a maven archetype for generating the user bundle it would be a fairly straightforward way to automate things.

I scetched that idea for openhab1, not for eclipse smarthome; but it shows the general idea: on github, look at gernoteger/openhab_contributions in branch "javarules".
The api bundle resides in org.openhab.action.javarule, the user bundle in org.openhab.action.javarule.user

The reason I chose openhab1 was that I wanted to try the concept in my production installation. Anyway it shows how the api and especially the user code could look like.
Beware, this is just a proof of concept, it's by far not ready for a PR!

What do you think about that line of thought?
Re: New Modular Rule Concept [message #1692454 is a reply to message #1643809] Wed, 15 April 2015 21:06 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Hi Gernot,

Sorry for having not answered earlier. I personally think that rules in Java add quite some overhead in terms of compilation, packaging and deployment. In general, this is nonetheless not ruled out by this new rule framework. I would envision the RuleRegistry to be similar to the ThingRegistry, which means that there can be any number of RuleProvider implementations, which serve rules through different means - possibly from Java code.
Note that there is also a related discussion at the moment at https://github.com/openhab/openhab/pull/2378 - this would allow to write rules in Jython, Javascript etc., which could be a more dynamic option over Java.

Best regards,
Kai
Re: New Modular Rule Concept [message #1692865 is a reply to message #1692454] Mon, 20 April 2015 10:00 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, 15 April 2015 17:06
Hi Gernot,

Sorry for having not answered earlier. I personally think that rules in Java add quite some overhead in terms of compilation, packaging and deployment. In general, this is nonetheless not ruled out by this new rule framework. I would envision the RuleRegistry to be similar to the ThingRegistry, which means that there can be any number of RuleProvider implementations, which serve rules through different means - possibly from Java code.
Note that there is also a related discussion at the moment at https://github.com/openhab/openhab/pull/2378 - this would allow to write rules in Jython, Javascript etc., which could be a more dynamic option over Java.

Best regards,
Kai


+1 on this.

I must admit that I personally have troubles getting around the combination of Xtend and the fact that there is no full IDE to develop Rules. Although Xtend is supposed to be a simplification of the Java syntax, I personally feel that it does not bring a lot advantages (who really cares that you can write a piece of code in 20% less lines, if you spend 200% more time debugging it afterwards), and rather creates confusion. Combine that with the fact that you do not have a real IDE/debugger at hand to build and test rules, and one (at least me) gets frustrated very rapidly. I am the only one having this issue?

So, they day we have RuleProvider and other classes place I will be a happy man. Since most rules, at least for me, are "write once, deploy and forget about it", I really do not care about the overhead of compilation and so on.
Re: New Modular Rule Concept [message #1695203 is a reply to message #1692865] Tue, 12 May 2015 15:31 Go to previous messageGo to next message
Markus Rathgeb is currently offline Markus RathgebFriend
Messages: 105
Registered: August 2014
Senior Member

Is the merged automation API (#190) something that could already be used to create some logic or is that PR only the base without an engine?
Re: New Modular Rule Concept [message #1695227 is a reply to message #1695203] Tue, 12 May 2015 20:53 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
No, the API itself cannot be used in any way yet, but if all goes well, an initial implementation should follow within the next two weeks.
Re: New Modular Rule Concept [message #1695906 is a reply to message #1692865] Wed, 20 May 2015 08:46 Go to previous messageGo to next message
Helmut Lehmeyer is currently offline Helmut LehmeyerFriend
Messages: 1
Registered: May 2015
Junior Member
Quote:

I must admit that I personally have troubles getting around the combination of Xtend and the fact that there is no full IDE to develop Rules. Although Xtend is supposed to be a simplification of the Java syntax, I personally feel that it does not bring a lot advantages (who really cares that you can write a piece of code in 20% less lines, if you spend 200% more time debugging it afterwards), and rather creates confusion. Combine that with the fact that you do not have a real IDE/debugger at hand to build and test rules, and one (at least me) gets frustrated very rapidly. I am the only one having this issue?


Hi @Karel,

no, You are not the only one, having this issue!
I often being frustrated about the missing full IDE/debugger in Xtend.
More complex Rules I write in a personal action Binding, some other Functions I externalize over transform("JS",script,value) . To compile is not perfect and breaks the Idea to have a quick real-time script-engine, Transform is not really comfortable, but I can work with all the IDE Helpers and debuggers.

For me this script/rule engine (github.com/openhab/openhab/pull/2378) is the absolutely right way, a revelation!
Later on I dream to test some volatile ideas just quickly alongside in combination with codemirror (codemirror.net/demo/complete.html) or Aca (ace.c9.io/#nav=about) on a Tablet or by Mobile in a Browser.

I think, multiple script/rule engines transfers the flexible binding approach of OH to the rule engine(s). I prefer Java and JavaScript, but several engines unleash endless end users the way to Openhab.

Sure, the disadvantage that new entrants no longer see the forest for the trees, has to be addressed through for Example easily understandable demo configurations.

Wow, Openhab/Smarthome is really cool and gets daily more cool.

Helmut
(aka lewie)


Re: New Modular Rule Concept [message #1696445 is a reply to message #1695906] Tue, 26 May 2015 14:10 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
Kai,

Is there any further progress made on this topic after the initial PR some time ago?

K
Re: New Modular Rule Concept [message #1696446 is a reply to message #1696445] Tue, 26 May 2015 14:13 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Definitely, yes! See https://github.com/eclipse/smarthome/pull/317
I've just started reviewing this PR, feel free to join in Smile

Regards,
Kai
Re: New Modular Rule Concept [message #1696683 is a reply to message #1696446] Wed, 27 May 2015 21:09 Go to previous messageGo to next message
Dan Cunningham is currently offline Dan CunninghamFriend
Messages: 44
Registered: March 2014
Member
Quote:
Showing 129 changed files with 12,877 additions and 126 deletions.

That's going to be one long code review!
Re: New Modular Rule Concept [message #1696943 is a reply to message #1696683] Fri, 29 May 2015 16:02 Go to previous messageGo to next message
Marin Mitev is currently offline Marin MitevFriend
Messages: 22
Registered: December 2014
Junior Member
Hi all
here is a short overview of the automation component implementation, submitted under pull request #317 https://github.com/eclipse/smarthome/pull/317 and explained with examples

Please have a look first at the sample rules file in JSON format here:
https://github.com/marinmitev/smarthome/blob/327416b26d6527f5716bfa0bff404d5596fcea36/bundles/automation/org.eclipse.smarthome.automation.sample.handler.factories/ESH-INF/automation/rules/SampleRuleDefinition.json

The file contains two rules and each rule has some basic information like name,tags,description and three module sections (on,if,then)
The 'on' sections is the trigger (eventing) part, the 'then' part contains the actions which specify what should be executed when the event is received
and the 'if' section lists the conditions which act as a filter for the events - actions of the rule will be executed only if the conditions evaluating the event data are satisfied and return 'true'. In this example above the condition is of type comparator which compares its input data (mapped to the trigger output) agains a constraint (in this example it is any text which is different than the word 'dtag'). So when condition is satisfied the action of type SampleAction will be executed using as input data the output of the trigger.

You can notice that all the modules (triggers, conditions and actions) have property 'type' - this is a reference to the ModuleType - the object which defines the metadata of the module.
Module types in this example are listed in the following JSON file:
https://github.com/marinmitev/smarthome/blob/327416b26d6527f5716bfa0bff404d5596fcea36/bundles/automation/org.eclipse.smarthome.automation.sample.handler.factories/ESH-INF/automation/module.types/SampleModuleTypeDefinition.json

The first moduletype is SampleTrigger which specifies one configuration property "sampleProperty" of type TEXT with some default value and one output object named "triggerOutput" which default value is "Hello World!!!"

The other important module type in this file is "SampleCondition" (at row 48) which defines two configuration properties "operator" and "constraint" and it has one input object which will be compared agains the constraint using the specified operator.

The third important module type is "SampleAction" (at row 74) which has one configuration property "prefix" and one input object "actionInput" of type String

These three module types are of type system which means they have corresponding Java implementation (it is provided in the same bundle org.eclipse.smarthome.automation.sample.handler.factories)
https://github.com/marinmitev/smarthome/tree/327416b26d6527f5716bfa0bff404d5596fcea36/bundles/automation/org.eclipse.smarthome.automation.sample.handler.factories/src/main/java/org/eclipse/smarthome/automation/sample/handler/factories

This means that this rule engine is pluggable - any OSGi bundle can provide implementation for triggers,actions and condition module types and their corresponding metatype definition in JSON format. The action of type "SampleAction" will print the message passed on its input object and will insert a prefix - the message defined in the configuration property. The same bundle also provides implementation for the trigger module type - it is triggered by a text console command typed in the Command Line interface and the parameter of the text console command will be passed as output object of the trigger. If the text command is executed without parameter the trigger will use the default value of the output which is "Hello World!!!".
In the created rule (explained above) the trigger output was connected with the condition input and with the action input. So the condition will evaluate the command parameter and if it is !="dtag" the action will print in the text console the message with the prefix configuration property as defined in the rule. In our example the rule "SampleRule" has configured this prefix to be ">>>".
So we have the following three cases:
1. invoking the text console command without parameter - then the message printed on the console will be ">>> Hello World!!!"
2. invoking the text console command with parameter "dtag" - the condition will not be statisfied and no action will be executed
3. invoking the text console command with another parameter (e.g. "Hi") - the message printed on the console will be ">>> Hi"

You can test these samples and the rule engine if you compile the source code of the bundles and install them on OSGi framework in the following order:
org.eclipse.smarthome.automation.api
org.eclipse.smarthome.automation.commands
org.eclipse.smarthome.automation.core
org.eclipse.smarthome.automation.json.parsers
org.eclipse.smarthome.automation.sample.handler.factories
org.eclipse.smarthome.automation.providers


The console commands to use are
smarthome.automation listRules --> Will list the existing automation rules
smarthome.autotype ls --> Will list the created Trigger Handlers
smarthome.autotype executeTrigger 1 --> Will invoke the first Trigger
smarthome.autotype executeTrigger 2 dtag -> Will invoke the second trigger and will pass "dtag" as output parameter of the trigger

And the expected results from these commands are:


fw>$smarthome.automation listRules

ID UID
----------------------------------------------------------------------------------------------------
1 rule_2
2 rule_3

fw>$smarthome.autotype ls
ID Name
1 SampleTriggerID
2 CustomSampleTriggerID

fw>$smarthome.autotype executeTrigger 1
fw>$[Automation demo] SampleAction/SampleActionID: >>> Hello World!!!




----------------------------------
In the JSON file with the rules you can find a second rule "SampleRule2" (at row 44) which uses a custom module types for action and for the trigger.
The action (at row 83) now refers to another type "SampleAction:CustomAction" and uses a different configuration property "myPrefix"
This action type "SampleAction:CustomAction" is defined in the second file (at row 95). All module types which have in its type the symbol ':' are extensions of the system module types and they can predefine the configuration properties and the input objects of the parent type (in this example the property 'myPrefix' will update the parent property "prefix" which is defined on line 103 ( "context": "$prefix" ) and the input object "customActionInput" is actually a reference to the parent's object "actionInput". This example with rule2 shows how to reuse the same java logic of the system module types by just customizing the configuration properties and the input objects.

Best regards,
Marin
Re: New Modular Rule Concept [message #1696945 is a reply to message #1696943] Fri, 29 May 2015 16:06 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Thanks Marin!
Re: New Modular Rule Concept [message #1697096 is a reply to message #1696945] Mon, 01 June 2015 14:24 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
Just a few questions here, in order to understand things:
- how will it tie into the OH runtime? e.g. how will rules be declared or instantiated/linked to OH "elements" like Groups, Items,...
- in the ModuleType declarations, is there any constraint on the Java "type" that can be used? only primitive types? what in case you want to trigger rules on Groups instead of Items
- in the ActionHandlers, you would expect them to tie into the various Registries (Item, Channel,...) in order to query Items, Groups and so forth. This is not done in the base classes of the API, are we supposed to do that ourselves or will that be factored into the base classes? or is there another architecture here to follow? Does the same hold true for the TriggerHandler or ConditionHandlers?
- Can we have TriggerHandlers that run threads autonomously, e.g. querying one of the Registries for a certain trigger to happen, or does it all have to go through the RuleCallBack ?

K

Re: New Modular Rule Concept [message #1697330 is a reply to message #1697096] Wed, 03 June 2015 08:20 Go to previous messageGo to next message
Marin Mitev is currently offline Marin MitevFriend
Messages: 22
Registered: December 2014
Junior Member
karel goderis wrote on Mon, 01 June 2015 14:24
Just a few questions here, in order to understand things:
- how will it tie into the OH runtime? e.g. how will rules be declared or instantiated/linked to OH "elements" like Groups, Items,...
- in the ModuleType declarations, is there any constraint on the Java "type" that can be used? only primitive types? what in case you want to trigger rules on Groups instead of Items
- in the ActionHandlers, you would expect them to tie into the various Registries (Item, Channel,...) in order to query Items, Groups and so forth. This is not done in the base classes of the API, are we supposed to do that ourselves or will that be factored into the base classes? or is there another architecture here to follow? Does the same hold true for the TriggerHandler or ConditionHandlers?
- Can we have TriggerHandlers that run threads autonomously, e.g. querying one of the Registries for a certain trigger to happen, or does it all have to go through the RuleCallBack ?

K



- I cannot answer regarding the integration with OpenHab project. Maybe Kai can answer this question

- Regarding the java types supported in the input/output objects, currently supported types are:
Integer
Short
Long
Byte
Float
Double
Boolean
Character
String
StringBuffer
Array of the above types
List of the above types
HashMap (keys are String)

Later there will be an option to support any custom types

The above applies only to inputs and outputs objects, however the types in the Configuration object are restricted to the following:

/**
* The data type for a UTF8 text value.
*/
TEXT,

/**
* The data type for a signed integer value in the range of [ {@link Integer#MIN_VALUE},
* {@link Integer#MAX_VALUE}].
*/
INTEGER,

/**
* The data type for a signed floating point value (IEEE 754) in the
* range of [{@link Float#MIN_VALUE}, {@link Float#MAX_VALUE}].
*/
DECIMAL,

/**
* The data type for a boolean ({@code true} or {@code false}).
*/
BOOLEAN;


- Regarding Trigger/Condition/Action Handlers - there should be added an implementation which can work with Item/Thing registries. The initial implementation provided by ProSyst (the bundle org.eclipse.smarthome.automation.sample.handler.factories) is only to demonstrate how to create such Handlers. Anyone can plug its own ModuleHandlerFactory (org.eclipse.smarthome.automation.handler.ModuleHandlerFactory) and registers it as an OSGi service

- Regarding TriggerHandler monitoring the Registries - it is possible to add such logic, but the recommended way is to listen on specific events (see the event concept from Kai here: https://www.eclipse.org/forums/index.php/m/1697230/
Then when the triggerHandler detects such event it should use the RuleEngineCallback to trigger the Rule


Re: New Modular Rule Concept [message #1697339 is a reply to message #1697330] Wed, 03 June 2015 09:54 Go to previous messageGo to next message
Enric GUIHO is currently offline Enric GUIHOFriend
Messages: 2
Registered: April 2015
Junior Member
Quote:
Regarding Trigger/Condition/Action Handlers - there should be added an implementation which can work with Item/Thing registries


Is it a work in progress ? It seems essential to be able to create rules based on the data from the bindings (Item/Thing registries).

Will it be possible to create rules as :
ON item_id state changed IF item_id.state == desired_value THEN item_id2.state = desired_value2
(where "item_id2.state = desired_value2" will be received as a command by the binding which manages this item)
?
Re: New Modular Rule Concept [message #1697359 is a reply to message #1697330] Wed, 03 June 2015 11:41 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 256
Registered: December 2013
Senior Member
I have a question on variables used in a rule. How is it handled if we want to store a state in a rule - eg a counter, or some other state that is persistent across executions of the rule? I assume this is handled as part of the input and output definitions, but do we need to only store such data in an item, or does the automation component provide this? If the automation component system provides this, is there support for local and global scope?

Also, how are such variables defined? I'm wondering if there should be an initialisation and termination block definition that ensures that a rule is initialised correctly, and also if it's disabled, it can appropriately close things down. For example, if we had a rule that controlled a heater, we might want to set up some variables when the rule is first run, and then when it's deactivated for some reason, we might want to ensure that the heater is turned off?

Sorry if this is covered somewhere - I did a search but couldn't see anything. I'm currently looking at porting the current HABmin graphical rule designer over to ESH, so have just started to think about the new rule system Smile

Cheers
Crhis
Re: New Modular Rule Concept [message #1697753 is a reply to message #1697359] Mon, 08 June 2015 07:50 Go to previous messageGo to next message
Dennis Nobel is currently offline Dennis NobelFriend
Messages: 166
Registered: September 2014
Senior Member
Hi Chris,

AFAIK the concepts of persistent variables is not part of the Core Rule Engine. You could do it with a special module handler, that reads and writes variables from a central database.

ButI think there are a lot of uses cases, where variables are an essential part of rules. So maybe we need to think about how to create such rules the best and if should provide some core module handlers for variables.

Regards

Dennis
Re: New Modular Rule Concept [message #1697818 is a reply to message #1697753] Mon, 08 June 2015 15:32 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 256
Registered: December 2013
Senior Member
I think this it's really a necessity to have variables that can maintain state - otherwise the rule system is really only usable for quite simple functions...

One other request - to add a comment member to the different blocks so that we can add some sort of description to the Json files...

Chris
Re: New Modular Rule Concept [message #1697833 is a reply to message #1697818] Mon, 08 June 2015 18:22 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
I think the question here is mainly about what OSGi services are accessible from within modules. We will have to provide a way to access items and things and so you definitely have the possibility to access "stateful information". We could also think here about a dedicated GlobalRuleVariableService. This is not yet defined, but I think there is no need to change anything in the overall concept for this.

Regarding comments: I actually never noticed that JSON is so poor that it does not even allow embedded comments... So I guess what you are asking for is somthing like "_comment" in http://stackoverflow.com/questions/244777/can-i-comment-a-json-file?answertab=votes#tab-top. This might indeed be a valid request. What do others think?

Regards,
Kai
Re: New Modular Rule Concept [message #1697834 is a reply to message #1697833] Mon, 08 June 2015 18:36 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 256
Registered: December 2013
Senior Member
Hi Kai,
Yes - this sounds ok if we can add such a service for variables - I'd personally prefer to avoid using items for this... No-one has commented on the suggestion of an "initialisation" and "termination" block (or is it module - I need to properly acquaint myself with the terminology Smile).

Regarding comments - yes - basically just adding a
"comment": "This is a comment"
element to the object(s). Even if you could add comments to json files, they would not be transferred through the REST interface - I think this is useful so that they can be displayed in any graphical designer (as in the HABmin Blockly implementation - see the second image in the link)...

Chris
Re: New Modular Rule Concept [message #1697888 is a reply to message #1697834] Tue, 09 June 2015 11:10 Go to previous messageGo to next message
Marin Mitev is currently offline Marin MitevFriend
Messages: 22
Registered: December 2014
Junior Member
Hi Chris,
A comment element could be useful feature, but if you want to display it as a description text, then I think it is already covered by the description element which is already present in each building block: the modules, rules, rule templates and module types. So the tooltip shown in Rule designer can display those description elements, and they can be localizable
Re: New Modular Rule Concept [message #1697890 is a reply to message #1697834] Tue, 09 June 2015 11:18 Go to previous messageGo to next message
Marin Mitev is currently offline Marin MitevFriend
Messages: 22
Registered: December 2014
Junior Member
Chris Jackson wrote on Mon, 08 June 2015 18:36
Hi Kai,
No-one has commented on the suggestion of an "initialisation" and "termination" block ...
...
I'm wondering if there should be an initialisation and termination block definition that ensures that a rule is initialised correctly, and also if it's disabled, it can appropriately close things down. For example, if we had a rule that controlled a heater, we might want to set up some variables when the rule is first run, and then when it's deactivated for some reason, we might want to ensure that the heater is turned off?
Chris


This is interesting use-case, but it is not supported in that way currently. Maybe it could be covered by events generated by the engine when rule is executed or disabled, however this will require a separate rule, which may not be very convenient...
Re: New Modular Rule Concept [message #1697896 is a reply to message #1697890] Tue, 09 June 2015 12:35 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 256
Registered: December 2013
Senior Member
Quote:

... but if you want to display it as a description text, then I think it is already covered by the description element which is already present in each building block: the modules, rules, rule templates and module types. So the tooltip shown in Rule designer can display those description elements, and they can be localizable

Ok - I didn't realize that there was a "description" element in all parts of the definition. I'm not completely sure how/why this is localisable though as the input would be free-form input that is entered by the user when they are 'writing' a rule - not something that is defined by a module provider (sorry if I use the wrong terminology). I just say this as I'm worried we might be talking at cross terms? In the HABmin rule designer that I referenced, the comment boxes have information that is entered by the user to describe the rule they are writing so that they can remember how it works when they look at it 12 months later.


Quote:

This is interesting use-case, but it is not supported in that way currently. Maybe it could be covered by events generated by the engine when rule is executed or disabled, however this will require a separate rule, which may not be very convenient...

Yes, I think this would be inconvenient, and prone to error. My example use case is to control a heater - I have a rule that turns the heater, and a fan, on and off depending on different inputs (temperature, humidity and time). When this rule is disabled, I want to ensure the heater is disabled - I think having to add a separate rule and manage the link could go wrong and I would suggest that this should be added to the todo list (maybe not for the first release, but in the pipeline).
Likewise for the initialization - I think there needs to be some way to initialize a rule - the initialization block seems a clean approach, but maybe there's a better/alternative way...

Thanks.

Cheers
Chris
Re: New Modular Rule Concept [message #1697902 is a reply to message #1697896] Tue, 09 June 2015 13:05 Go to previous messageGo to next message
Marin Mitev is currently offline Marin MitevFriend
Messages: 22
Registered: December 2014
Junior Member
Your observation is correct - localized description will be available only for module types and rule templates, but the description for rule instances and rule modules (triggers, conditions, actions) will be set by the user and won't be localized.

We will consider the blocks for rule initialization/deinitialization
Re: New Modular Rule Concept [message #1697903 is a reply to message #1697902] Tue, 09 June 2015 13:24 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Ok, so the description field of modules / rules is enough then and we won't need a comment in the JSON, right? I before didn't know that your question was about showing stuff in the UI, but rather doing a kind of "developer comment" within JSON files that are packed in bundles.

Quote:
I think there needs to be some way to initialize a rule

Maybe we would also need something like prerequisites, before a rule can become enabled? Checking that some items are available, things are ONLINE etc.? This could be achieved if the initialization could also use a callback to declare when it is ready (as the init might not be a synchronous operation).
Re: New Modular Rule Concept [message #1697915 is a reply to message #1697903] Tue, 09 June 2015 15:10 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 256
Registered: December 2013
Senior Member
Quote:

Ok, so the description field of modules / rules is enough then and we won't need a comment in the JSON, right?


If I understood Marin correctly, the "description" is a description of what the block is and it's defined by the provider (and therefore localized). This provides a 'tooltip' type of thing that helps guide the user by telling them what a particular block does (this is effectively your java doc)

What I would also like to see is to have a user defined entry so that they can write some information to remind them what they have used the block for (this is akin to a source code comment).

If I've got this right, then I think we still need it?

Chris
Re: New Modular Rule Concept [message #1697919 is a reply to message #1697915] Tue, 09 June 2015 15:20 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
No, what Marin says is that rule TEMPLATES and module TYPES have a localized description defined by the provider and that rules and modules themselves have a description that can be defined by the user. So I think this should be alright.
Re: New Modular Rule Concept [message #1697920 is a reply to message #1697919] Tue, 09 June 2015 15:21 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
And anyhow, people writing complex rules for themselves are likely to use some scripting modules - and within scripts, you can of course comment as much as you like Smile
Re: New Modular Rule Concept [message #1697927 is a reply to message #1697920] Tue, 09 June 2015 15:49 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 256
Registered: December 2013
Senior Member
Quote:

No, what Marin says is that rule TEMPLATES and module TYPES have a localized description defined by the provider and that rules and modules themselves have a description that can be defined by the user. So I think this should be alright.

Ok - that's fine...

Quote:

And anyhow, people writing complex rules for themselves are likely to use some scripting modules - and within scripts, you can of course comment as much as you like

Maybe, but I don't think we should require this Smile Comments are always good, and these rules are meant to be 'shareable' so describing the rule so others can understand it is (IMHO) desirable... I've been using a block rule designer for some reasonably complex rules for quite a while, and I'd hate to loose comments...

Chris
Re: New Modular Rule Concept [message #1697988 is a reply to message #1697903] Wed, 10 June 2015 07:16 Go to previous messageGo to next message
Marin Mitev is currently offline Marin MitevFriend
Messages: 22
Registered: December 2014
Junior Member
Kai Kreuzer wrote on Tue, 09 June 2015 13:24

Maybe we would also need something like prerequisites, before a rule can become enabled? Checking that some items are available, things are ONLINE etc.? This could be achieved if the initialization could also use a callback to declare when it is ready (as the init might not be a synchronous operation).

Isn't this a duplication of the Condition block - A Rule won't execute the actions unless the condition is satisfied and inside the condition someone could check the system state or the event data or both
Re: New Modular Rule Concept [message #1698559 is a reply to message #1697988] Tue, 16 June 2015 12:09 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Not really - it would be more a life-cycle feature than an execution feature. It could influence the status of a rule (similar to whether a handler is available or not) and define whether a rule is potentially executable at all. My point is that if we introduce some kind of "initialization", we have to ensure that all pre-requisites are fullfilled for doing the initialization at all. If it wants to set set a certain value for an item as a start, we would e.g. have to make sure that this item exists at all.
Re: New Modular Rule Concept [message #1710940 is a reply to message #1698559] Sun, 11 October 2015 14:00 Go to previous messageGo to next message
Smart Home is currently offline Smart HomeFriend
Messages: 109
Registered: February 2015
Senior Member
Some of the module types requires an item name. E.g.:

"ItemStateChangeTrigger":{
			"label": "Item State Trigger",
			"description": "This triggers a rule if an items state changed",
			"config":{
				"itemName":{
					"type":"TEXT",
					"label":"item name",
					"description":"the name of the item which's state change should be observed",
					"required":true
				}
			},


If I want to create a generic UI for modules which will display all item names for the user to select from, how do I know that the field itemName is for item names?
Re: New Modular Rule Concept [message #1710950 is a reply to message #1710940] Sun, 11 October 2015 18:12 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
I think we should use the "context" field of config descriptions for this purpose - i.e. add a <context>item</context> here.
Re: New Modular Rule Concept [message #1711105 is a reply to message #1710950] Tue, 13 October 2015 06:23 Go to previous messageGo to next message
Smart Home is currently offline Smart HomeFriend
Messages: 109
Registered: February 2015
Senior Member
Quote:
i.e. add a <context>item</context> here


Probably we will need other contexts, e.g., date / time, state etc. Are they going to be predefined?

Other issue that I think should be addressed is how to match between triggers and conditions. How do I know which conditions are valid for a specific trigger? E.g., if there is a condition which checks above and below values probably it cannot be used with item event state trigger (e.g., GenericEventTrigger). Use case can be when user selects trigger and now he needs to select condition, in that case, I would like to show only conditions that are valid for the selected trigger.

Also, do you plan to add above / below triggers / conditions to the automation module core?
Re: New Modular Rule Concept [message #1711375 is a reply to message #1711105] Thu, 15 October 2015 12:08 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Quote:
Probably we will need other contexts, e.g., date / time, state etc. Are they going to be predefined?


Yes, that's the plan.

Quote:
Other issue that I think should be addressed is how to match between triggers and conditions.


Correct. Besides the type (as a very simple check if inputs and outputs can be matched), we plan to use the tags for this purpose, where the tags define the semantics of the input/output. As with contexts, a default set of tags will need to be defined.

Quote:
Also, do you plan to add above / below triggers / conditions to the automation module core?


Possibly yes, but I would want trying to keep the set of "core" modules small. Probably it makes sense to start with a "comparison" condition, which has the comparator (=, <, >, !=, <=, >=) as a configuration option.
Re: New Modular Rule Concept [message #1711424 is a reply to message #1711375] Thu, 15 October 2015 21:02 Go to previous messageGo to next message
Smart Home is currently offline Smart HomeFriend
Messages: 109
Registered: February 2015
Senior Member
Quote:
Probably it makes sense to start with a "comparison" condition, which has the comparator (=, <, >, !=, <=, >=) as a configuration option.


I also suggest to add composite conditions, above, below etc. same as state on / off composite conditions. They are very basic and probably widely used.
Re: New Modular Rule Concept [message #1711441 is a reply to message #1711424] Fri, 16 October 2015 07:08 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Yes, you are probably right. So as a basis implementation the comparison condition would be fine and based on this we can add specialized composite conditions.
Re: New Modular Rule Concept [message #1711622 is a reply to message #1711441] Sun, 18 October 2015 14:10 Go to previous messageGo to next message
Smart Home is currently offline Smart HomeFriend
Messages: 109
Registered: February 2015
Senior Member
Is there a way to run a rule not as a result of a trigger? Something like Check Now in IFTTT.
Re: New Modular Rule Concept [message #1711635 is a reply to message #1711622] Sun, 18 October 2015 20:21 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Not yet, but it is a good point. I guess you mean directly running the list of actions without considering triggers and conditions. The only problem would then be that the trigger outputs are missing; if a rule requires them, what should happen?
Re: New Modular Rule Concept [message #1711666 is a reply to message #1711635] Mon, 19 October 2015 07:38 Go to previous messageGo to next message
Smart Home is currently offline Smart HomeFriend
Messages: 109
Registered: February 2015
Senior Member
I think that somehow you need to check the conditions (if applicable). Take for example the condition: ItemStateCondition.

Check now is actually a trigger without parameters. If the condition requires parameters, check now should probably do nothing and actions should not run.
Re: New Modular Rule Concept [message #1711697 is a reply to message #1711666] Mon, 19 October 2015 11:14 Go to previous messageGo to next message
Dennis Nobel is currently offline Dennis NobelFriend
Messages: 166
Registered: September 2014
Senior Member
It depends if "Check now" includes conditions or really just triggers the action. However in both cases you could just give in the required outputs from other modules manually.
Re: New Modular Rule Concept [message #1711716 is a reply to message #1711697] Mon, 19 October 2015 12:35 Go to previous messageGo to next message
Smart Home is currently offline Smart HomeFriend
Messages: 109
Registered: February 2015
Senior Member
Quote:
It depends if "Check now" includes conditions or really just triggers the action


From my POV, check now is a way to execute the rule. It is not meant to run the action explicitly. E.g., it allows the user to check the rule that he has just created or to run the rule without waiting for the trigger (bypass the trigger).

Quote:
However in both cases you could just give in the required outputs from other modules manually.


If I bypass the trigger I don't have the inputs.
Re: New Modular Rule Concept [message #1712304 is a reply to message #1711716] Thu, 22 October 2015 18:11 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
I just want to kick the can a bit further down the road, but is anyone already working on the integration with the userland/space? cfr the initial backward compatibility solution proposed by Kai at the beginning of the thread?
Re: New Modular Rule Concept [message #1712309 is a reply to message #1712304] Thu, 22 October 2015 19:33 Go to previous message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 673
Registered: December 2011
Senior Member
Note that apart from this forum thread, there is a lot of activity on the PR itself here: https://github.com/marinmitev/smarthome/issues
The clear focus is to get the whole framework in a usable state. I have also already spent some thoughts on a migration path of the existing rules, but this is something that I do not plan to finalize for an openHAB 2.0 release. There isn't really any urgency as the current rules work well for anybody who wants to do pure scripting.
Previous Topic:GroupItem Function
Next Topic:Introducing Notifications
Goto Forum:
  


Current Time: Fri Mar 29 12:54:49 GMT 2024

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

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

Back to the top