Why have my rules stopped running?

[Bruce_Osborne]

@bf8392

I run OpenHab in a docker-container (2.5.9) on a almost freshly installed pi with hypriot os.

Which type of Docker image? Debian is recommended instead of alpine on the Pi. In fact there is not alpine image for the Pi in OH3.

[bf8392]

@Bruce_Osborne

Which type of Docker image?

I use openhab:2.5.9 → is the “standard tag” the Debian or the alpine image?

[Bruce_Osborne]

@bf8392

is the “standard tag” the Debian or the alpine image?

It is Debian which is preferred because it uses zulu java.

I am interested in your astro rule. On my Pi test system I just installed 2.5.10 Docker to experiment with remote docker in OH3.

I currently have the astro binding installed in the 2.5.10 container.

[bf8392]

This is my rule involving the astro-binding…it worked perfectly and then suddenly stopped…

rule "Fensterladen schließen Rule"
when                                                                                   
    Item AlarmanlageRolloRaufRunter_Input1Alarm received update ON or
    Item Szenen_Item received command  rollosrunter or
    Channel "astro:sun:local:set#event" triggered END
then
    BRofensterladen_BlindsControl.sendCommand(100)
    BRotRfensterladen_BlindsControl.sendCommand(100)
    KChenfensterladen_BlindsControl.sendCommand(100)
    Esszimmerfensterladen_BlindsControl.sendCommand(100)
    Terrassenfensterladen_BlindsControl.sendCommand(100)
    Wohnzimmerfensterladen_BlindsControl.sendCommand(100)
    SchlafzimmertRfensterladen_BlindsControl.sendCommand(100)
    Schlafzimmerfensterladen_BlindsControl.sendCommand(100)
end

rule "Fensterladen öffnen Rule"
when
    Item AlarmanlageRolloRaufRunter_Input2Alarm received update ON or
    Item Szenen_Item received command rollosrauf
then
    BRofensterladen_BlindsControl.sendCommand(0)
    BRotRfensterladen_BlindsControl.sendCommand(0)
    KChenfensterladen_BlindsControl.sendCommand(0)
    Esszimmerfensterladen_BlindsControl.sendCommand(0)
    Terrassenfensterladen_BlindsControl.sendCommand(0)
    Wohnzimmerfensterladen_BlindsControl.sendCommand(0)
    SchlafzimmertRfensterladen_BlindsControl.sendCommand(0)
    Schlafzimmerfensterladen_BlindsControl.sendCommand(0)
end

[bf8392]

By the way i figured out that for the z-wave devices, the trigger doesn’t fire,bcause reports do not work properly. I have associated the devices in group one/lifeline to the controller, and now I just have to decide which kind of automatic report to choose for group one:
would ou choose:

• basic cc OR
• multilevel-switch report

because thanks to @chris he told me that hail cc is not an option…and send nothing in report group one leads to not fireing triggers…

[chris (Chris Jackson)]

@bf8392

would ou choose:

basic cc OR
multilevel-switch report

It probably doesn’t really matter since the binding will likely treat them the same (depending on the device), but multi-level is probably safer.

[bf8392]

Okay really cool thanks =) Im really interessted in the z-wave topic =) If you want I would be happy to know the difference between them =). Because the hail cc, basic cc and so on appear everywhere and you were the first one who could tell me how hail cc works =).

[chris (Chris Jackson)]

Basic is a kind of “standard” command - it’s used as a compatible command set between things like lights, switches, and sometimes other devices. Normally it’s used to provide some basic function in a compatible way without devices needing to know too much about each other (eg if you have a wall switch that you want to directly send commands to a light).

Multilevel switch, or binary switch send specific command functions - On/Off, a dimmer level, etc. There is normally a lot more functionality available. Normally some simple part of this is mapped to the basic command class.

The binding can be configured (through the database) to interpret the basic command in different ways - so it is probably configured to interpret a basic command received from a dimmer as if it was actually a multilevel switch command.

I hope that makes some sense

[bf8392]

Yes that was exactly what I was looking for! Great great thanks

[bf8392]

If someone has a solution for the not always working rules, it is still not resolved, as the z-wave reports was only part of the solution…also the astro-binding-triggered rule seems to stop working sometimes…

Some additional info:

I keep my rules in separated files for example:

• Fensterläden.rules
• Licht.rules

Does this affect performance?

[bf8392]

Just as an update…a reboot resolved everything (hail cc test-devices start working again, and all rules are operational). I don’t know the cause yet, but I will wait untill it happens again. Meanwhile I switch my report-method to multilevel-switch…thanks @chris =)

[bf8392]

Okay as a summing up solution for the issue, I have Here the steps to follow when your rules stopped working. Thanks to @rlkoshak @chris @Bruce_Osborne @rossko57

1. read the guide for rules: Why have my Rules stopped running? Why Thread::sleep is a bad idea (only applies for OpenHab 2.5, and no longer required in 3.0)

2. make sure that your trigger runs by checking events.log. If you use z-wave, make sure that you have the report group 1 setup to basic or multilevel-switch reports and associated with the controller. Do not use hail cc

3. If you copy some rules, make sure to keep names different! If you don’t, one rule may exclude the other from running (figured this out yesterday after weeks of searching! So be careful with names when you have many different rules)

If someone has another point to add/modify, feel free to post, and I’m gonna edit this

[rlkoshak (Rich Koshak)]

1. only applies for OH 2.5 and before. 3.0 does not have a limited thread pool so long running rules blocking other rules from running is no longer a problem.

[Bruce_Osborne]

@rlkoshak

long running rules blocking other rules from running is no longer a problem.

What does this recent PR fix then? Still trying to learn…

[automation] Make rule engine use a threadpool

[Andrew_Rowe]

you might find more info in this thread Bruce

Openhab 3 - New thread per trigger? / Where do we discuss-ask questions about the openhab-core?

We presently don’t have a subtopic in the development area for questions about the core. I don’t think github is the right place to ask questions (but tell me if I am wrong). Now for the question. I am playing around with adding something to the rules engine and wanted to verify something that I was seeing in the latest code. It appears (at least from what I can see) is that every trigger attached to every rule now has its own thread. Is that the correct interpretation?

[Andrew_Rowe]

@rlkoshak

3.0 does not have a limited thread pool so long running rules blocking other rules from running is no longer a problem.

My question Rich is wouldn’t long running rules or rules that never return still be a problem? We seem to have simply removed the first sign/symptom of the problem

[rlkoshak (Rich Koshak)]

That does change things but I can’t tell from my phone or experience to say. There are a lot of “it depends”. How big is the thread pool? Is it fixed sized or does it grow? I can’t get the answers to these from the PR itself as the thread pool comes from somewhere else in core.

[Bruce_Osborne]

Looking at the referenced thread, I think they want to use a shared thread pool rather than have a bunch of threads that are idle most of the time.

[rlkoshak (Rich Koshak)]

That’s what a thread pool does. What I can’t say yet is how big is the pool? The default according to the code it five which puts us right back to only five simultaneous rules that can run at the same time. It doesn’t appear to grow if you need more so it looks like they reintroduced the limited number of simultaneous rules problem.

[Bruce_Osborne]

I would have expected a major change like this to be required to be tested in a snapshot rather than break a milestone, especially this late in the development cycle.