How to call UI-rule inside a DSL rule

I am using OH 4.1 and would like to extend following dsl rule with a startRule.sendCommand(‘b802f75c90’)

var Timer tTaste = null

rule "WohnenSchlafenTaster_long"

	Item Taster_Wohnen_Schlafen_Eingang_Taster_Wohnen_Schlafen_Eingang changed
	logInfo("Taster WohnenSchlafen", "0: Tastendruck erkannt")
	if(newState == ON) {
		tTaste = createTimer(now.plusNanos(2000000000),[| // 2000 Millisekunden
		// Befehl: langer Tastendruck erkannt
		logInfo("Taster WohnenSchlafen", "langer Tastendruck erkannt")
	} else {
	logInfo("Taster WohnenSchlafen", "1: Tastendruck erkannt")
	if(!(tTaste.hasTerminated)) {
		// Befehl: kurzer Tastendruck erkannt
		logInfo("Taster WohnenSchlafen", "kurzer Tastendruck erkannt")

when do a long press I get following error log:

[INFO ] [e.model.script.Taster WohnenSchlafen] - 1: Tastendruck erkannt
[ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'WohnenSchlafenTaster_long-1' failed: cannot invoke method public boolean

How can I call another rule inside my dsl scripte? The other rule I made with the UI.

You can’t, at least not directly. Rules DSL. There is no way to call another rule from Rules DSL. To do that you need to use a different language (all of the others support calling other rules, even Blockly). It you need to be indirect and create a new Item that when commanded triggers the rule.

In general, all of this type of stuff is documented so if the dice don’t show you how to do something, it’s more likely than but that it doesn’t support it. Don’t guess at the syntax.

Because of it’s idiosyncrasies and lack of support for a lot of things (it’s more than just calling other rules) I recommend against new development of rules in Rules DSL.

Thanks for the answer. In this case I could use an item and than trigger another rule.

When you say, you recommend other idioma than DSL rule, which one (and why) you would consider as the best one for new development in OH4?

There is no “best” one. There are a number of good options depending on your specific requirements.

  • Blockly: for those who don’t really already know programming
  • JS Scripting: probably the most popular
  • jRuby: if you like terse and compact code
  • Groovy: if you want to be closer to the raw Java APIs
  • JRule: if you want to compile your rules
  • HABApp: if you love Python

I recommend avoiding the following for new rules development:

  • Rules DSL: does not support the full openHAB API, has a number of quirks that makes Blockly a better choice for inexperienced programmers
  • Nashorn JavaScript: only provides an ancient version of JS and no helper library
  • Jython: only supports an end of life version of Python, the upstream library appears all but abandoned, the helper library is not a part of the OH project

Ruby code also “reads like English”, or at least it (the language + the helper library) was designed to do so. The helper library is also designed to make writing rules as simple as possible by dealing with a lot of the grunt work for you.

I was not aware about that DSL does not support all - very good to know.
Well in my case I would prefer Python but I also prefer if everything could be done from the UI or you still need to copy specific files (JS, Jruby etc.) to specific folders and/or you can not edit directly from the UI.

Which language except blockly can be managed directly from (over) the UI?

All the supported scripting languages can be managed in the UI

@JimT is correct though JRule, which isn’t an official add-on (yet?) I think is only now starting to add some limited support for UI rules. Of course HABApp is a separate service and Jython and Nashorn are deprecated.

All the rest work in the UI and the add-ons come with the helper library so you don’t need to install or copy anything separate to work with the rules in the UI.

Note, the Blockly rules “compile” into JS Scripting. Blockly can be a good way to figure out how to write rules in JS as you can build the logic in blocks and then examine what it generates in code. In some places it’s a little verbose but for the most part it produces easy to understand code.