i recently startet with openhab3 and got a question about DSL rules. I wanted to make 1 rule for all the lights in the flat which are turned on or off when another light is switched. For example when i turn on the main light in the kitchen, the lights under the cabinets turn also on. So i made a rule, with all the possible triggers and one DSL “script” where everything is in one place. It works… but its not really fast and gets worse over time untill a reboot. There is always a delay of about a second, the longest i saw was about 7 seconds…
I read in another thread that it could help to add this line in the runtime.cfg: org.eclipse.smarthome.threadpool:ruleEngine=30
i´m not quite sure but i think its a little better but still with a delay which gets worse the longer the system runs.
Now i clicked the rules togehter in the gui and it works perfectly fine… its really fast - instant, but now i have 6 rules instead of 1 and there have to be a lot more to cover everything… Perhabs someone here has an idea?!
Raspberry 4 - 4GB with an SSD
Raspian Buster
OH3 main branch
the DSL rule:
switch(triggeringItemName)
{
case "Steuerung_Schlafzimmerlicht":
{
if (Steuerung_Schlafzimmerlicht.state == ON)
{
sendCommand(Ventilatorlampe_SZ, ON)
}
if (Steuerung_Schlafzimmerlicht.state == OFF)
{
sendCommand(Ventilatorlampe_SZ, OFF)
}
}
case "Kuechenlicht":
{
if (Kuechenlicht.state == ON)
{
sendCommand(Kuechentresen, ON)
}
if (Kuechenlicht.state == OFF)
{
sendCommand(Kuechentresen, OFF)
}
}
case "Flurlicht":
{
if (Flurlicht.state == ON)
{
sendCommand(lampe_flur_w_01_helligkeit, 100)
sendCommand(lampe_flur_w_02_helligkeit, 100)
sendCommand(lampe_flur_rgb_01, "0,0,100")
}
if (Flurlicht.state == OFF)
{
sendCommand(lampe_flur_w_01_helligkeit, 0)
sendCommand(lampe_flur_w_02_helligkeit, 0)
sendCommand(lampe_flur_rgb_01, "0,0,0")
}
}
}
OH 3 doesn’t have a threadpool for rules anymore. Each rule get’s its very own thread now.
@Guard, add logging to your rule to determine if the delay is in the rule itself triggering at all, or if the rule is triggering but taking a long time to run.
And as rossko57 indicated, knowing the full rule, which includes the triggers, is critical for us to begin to help. Don’t redact your code thinking it helps us. It almost never does.
Why is this a problem though?
The rule shown triggers on any of X,Y, Z. Then it figures out which it was, X say. Then it acts on X without any reference to Y or Z.
There’s no disadvantage to having separate rules for each X or Y or Z case, there is no pricing per rule.
It does look like it should logically break into three rules though, not six.
Why 6 rules: 3 lights should turn on or off. So i get 6. But thats just the beginning… with the script i have only one rule for all the lights, another for all thermostats and so on… you are right, there is no limit but i think its much cleaner and normally it works
Well, if you think there is a timing problem you should start looking to see where it occurs.
Your events.log will give you timestamps for Item commands and changes, the triggers and products of your one-rule.
If you add logging to your rule, you will get timestamped messages in your openhab.log that you can use to show when the rule starts and when it gets to certain points.
One other note, when posting a rule to the forum, please click on the Code tab and paste the text. Screen shots and pictures of rules are generally useless to us and they are never complete.
You definitely do what feels the best for you, but for future readers, in general best practice in openHAB and in programming in general, more short and simple rules is preferred over one rule that does three or six completely different things depending on what Item triggered the rule. The only time when rules should be combined into one is when the same thing is done, perhaps on a different set of Items, no matter what Item triggered the rule.
This is particularly important in UI created rules because if you, as in this example, put all your different lights behaviors into one rule:
that one rule becomes more difficult to read, understand, and debug
a mistake will kill the behaviors for all your lights, not just the one set of behaviors that has the error
you can’t enable/disable individual behaviors, only all the lights or non of the lights behaviors (for example, you may have extra lighting behavior at Christmas time, if that behavior is in it’s own rule you can enable that rule when you need it and disable it for the rest of the year with a simple flip of a switch or based on the date or what have you)
Thanks, didn´t know that in the code part contains the triggers choosen in the gui. That was the reason for the screenshot.
I understand your points how rules “should” be made or are better to read! In my case i would like to have all the lights which are not connected to the main switches in the room, but should also switched on or off in one rule… so extra lights clearly will be in other rules.
But its not really the reason for my problem, isn´t it?!
I´ll try to figure out what the problem is. Shorten the rule or make one for each room, and see if it helps with my problem.
Indeed. Add some logging so that you can see when the rule begins or gets to crucial points. Compare with the events.log timestamp of the trigger events.
On a healthy system multithreading it is possible for rules to run even before the trigger gets logged, on occasion.
