Reuse of Rules - How to reduce the numberof Rules?


I learned to use Lambdas as Function definitions to reuse rule code. But it seems that I still have to define one rule for each item * each lambda to get all conditions defined. I’m looking for a way to simplify this too.

I like to explain the problem by an example:

rule "Change Brightness ID 1 Group 1"

	Item Light_1_1_D_0 received command
	ChangeBrightness.apply(1,1) // call the lambda with parameters that could be extracted by the triggered item name!									
rule "Change Brightness ID 1 Group 2"

	Item Light_1_2_D_0 received command

[ and so on ]

What I would prefer is something like this (pseudo code)

rule "Change Brightness"

	Item Light_* received command
  var number,1)	 as DecimalType
  var number,1)	 as DecimalType

[ done for all light items within a certain group or following certain naming conventions ]

SendingItem should define the Item Object which was triggered. I know that the variable receivedCommand exists but i can’t find receivedItem

In the end this rule should be triggered for every Light item and then call a lambda function or even do everything necessary inside the rule.

Is there a way to simplify this? Otherwise in my case if Have to define 2 rules for every light group or within my heating rules around 6 rules for every thermostat.

I aggree. OpenHAB 1 was completely bound to its Xtend language, which can be seen as simplified Java.

The same goes for other projects out there.

Moving to a more convenient configuration style was a game-changer for many opensource projects, like Icinga2. I’ve seen many companies switch to it because they also could reduce a multi-hundrets rule config to just a few lines using wildcards.

Is there something like this in development. If not, would it be possible let an (upcoming) addon binding do this work? This way we could further improve, without changing the whole Eclipse Smarthome base.

My opinion: if you want to solve it once and forever, you should design rules using standardized programming languages, used in automation. Because rules are basically automation.
And what we have there? We have IEC 61131-3 used in millions of PLC. It has 5 different languages in it, so everyone would find language, which is most convenient for him. Also debugging and reuse of rules becomes much easier.

You can do what you want with JSR223 (Jython, for example) in OH1.

OH2 will support some form of templated rules, but I don’t know the details about it.

How would you suggest integrating IEC 61131-3 into an open source platform like openHAB? What open source libraries are available and how would they integrate with Java to access bindings and the OH data model?

[quote=“steve1, post:5, topic:10404, full:true”]

I suggest… not to integrate it at all! Joke, but simpliest way is to use OpenHab as a bridge to different protocols using it’s various bindings. Here is a clear strength of OpenHab. IEC 61131-3 Interpreter Engine should run as a separate process, probably even on separate hardware real-time platform and communicate with OH using one of the standard modern protocols, like MQTT or OPC UA. So the task of OpenHab will be to convert all home automation bindings into one protocol and vice versa.
Concerning libraries - just have a look to open-source OSCAT Building Automation Library. Many algorithms from there are much more sophisticated, than all rules, published here. This includes Lightning, Heating or Rollershutter control. Final story - that is completely reusable.
In principle I’m going to establish this concept in my house anyway using Codesys Software.

That sounds very interesting. Especially the Graphic approach of some language “dialects” can be quite useful for beginners but for experts too. I like the “industrial” point of view. When I came in touch with MQTT I found how simple, useful, strong and versatile a communication can be build for supervising oil pipelines that it can end as the standard protocol for IoT, Sensors and many other communication tasks.

It would be great if openHAB opens to a plugin architecture that not only hardware components can be added easily. Adding functionality like programming languages, different UIs and prebuild functionalities like heating or lighting controls could be added. (or is this already possible?)

But it do not help me with my current problem :wink:

So there is no way to find out which item triggered a rule if the rule “when” statements is defined by many “or” conditions!?


This is provided by the JSR223 scripting plugin. Users are writing rules and scripts in Jython (Python), Groovy and Javascript, for example.

You can do it with JSR223 rules. The rule execution includes an event that references the item that triggered the rule.

I saw you were discussing this in the forums about 8 months ago. How much progress have you made? If you’ve made some significant progress, maybe we should start another topic to discuss it.

I looked as OSCAT and it looks interesting. The components appear to be well designed. I’m going to think about whether I could reproduce them in Python as reuseable components and have them run directly in OH using the JSR223 addon.

I did some evaluation of Codesys - it runs on Raspberry quite well. The problem is in communication with Openhab - the only protocol supported by both systems is Modbus TCP, but it’s not suitable for such use in my opinion. So I’m looking to MQTT, but for this I need to check some libraries. I’m going to look into it next Month.

Be careful when doing this. PLC programs are done with assumption that they will run in close to real-time way - e.g. the code should be executed periodically, for example every 100ms, and with relatively low jitter. In this way you can rely on timers, counters etc. So far I can not observe such behavior in OpenHAB - sometimes the rule is executed immediately, sometimes it takes some seconds. This creates significant problems when you need predicted reaction time in range of below one second. For example in my case of precise Jalousie control. That’s why I want to use external solution.

I understand. I’m not trying to create PLC-like performance with openHAB, nor do I need it for the my applications. I’m more interested in the reuseable components, most of which do not require near real-time behavior. By the way, if you need better rule performance you should switch to JSR223 (Jython) and avoid Xtext rules. In any case, OH rules are obviously not intended to be used for complex, near real-time behaviors. Most people implement that in an external device (Arduino, ESP8266, etc.) and then control the device using OH. In your case, it appears the external device would be a “PLC” (Pi running PLC software).

Yeah, but for such case I have different concept, discussed in Intelligent Thermostat as cloud service
If you have a rule, and it’s not needs to be real-time, but you want to have it completely reusable even on different hardware platforms - then the best solution is to have it as a cloud service. E.g. the rule is running on server, to which you connect with OH over internet for example with MQTT. There you can have one, ten, hundreds of instances doing the same stuff for multiple users, like opening and closing shutters on sun brightness/light level, or controlling your heating based on temperature and schedule. You just need to provide your topic names and couple of parameters and you’re done.