Home » Archived » Eclipse SmartHome » New Modular Rule Concept
() 1 Vote
New Modular Rule Concept [message #1477164] |
Mon, 17 November 2014 17:30 |
Kai Kreuzer 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 |
|
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
* 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 |
Kai Kreuzer 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 #1488655 is a reply to message #1486709] |
Wed, 26 November 2014 20:20 |
Dennis Nobel Messages: 166 Registered: September 2014 |
Senior Member |
|
|
Jan Koehnlein wrote on Tue, 25 November 2014 09:28I 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 ) 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 |
Kai Kreuzer 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 |
Benedikt Niehues 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.
|
|
| | | | | | | |
Re: New Modular Rule Concept [message #1538309 is a reply to message #1477164] |
Wed, 31 December 2014 08:48 |
Martin Klimke 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 |
Dennis Nobel Messages: 166 Registered: September 2014 |
Senior Member |
|
|
Hi Martin,
Martin Klimke wrote on Wed, 31 December 2014 09:48I 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:48Now 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 #1692865 is a reply to message #1692454] |
Mon, 20 April 2015 10:00 |
Karel Goderis Messages: 198 Registered: March 2014 |
Senior Member |
|
|
Kai Kreuzer wrote on Wed, 15 April 2015 17:06Hi 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 #1695906 is a reply to message #1692865] |
Wed, 20 May 2015 08:46 |
Helmut Lehmeyer 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 #1696943 is a reply to message #1696683] |
Fri, 29 May 2015 16:02 |
Marin Mitev 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 #1697096 is a reply to message #1696945] |
Mon, 01 June 2015 14:24 |
Karel Goderis 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 |
Marin Mitev Messages: 22 Registered: December 2014 |
Junior Member |
|
|
karel goderis wrote on Mon, 01 June 2015 14:24Just 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 #1697359 is a reply to message #1697330] |
Wed, 03 June 2015 11:41 |
Chris Jackson 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
Cheers
Crhis
|
|
| | | | | |
Re: New Modular Rule Concept [message #1697890 is a reply to message #1697834] |
Tue, 09 June 2015 11:18 |
Marin Mitev Messages: 22 Registered: December 2014 |
Junior Member |
|
|
Chris Jackson wrote on Mon, 08 June 2015 18:36Hi 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 |
Chris Jackson 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 #1711375 is a reply to message #1711105] |
Thu, 15 October 2015 12:08 |
Kai Kreuzer 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.
|
|
| | | | | | | | | |
Goto Forum:
Current Time: Tue Sep 24 09:23:05 GMT 2024
Powered by FUDForum. Page generated in 0.08157 seconds
|