Why have my rules stopped running?

Setup, Configuration and Use Installation
Tags: #<Tag:0x00007efec79d3038>
#1

Hi =)

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

I have the problemn that some of my rules stop working afrter some time. Àll the devices (Z-Wave) still work, but the rules don’t. Als the behaviour is funny, as some rules only work “partially” after some time (2-6 weeks). In most cases, the issue is resolved after a reboot, but that’s no real solution…I want to find the problem =). It also affects not all rules, but only some.

All my rules are in seperate text files (some are together in one). Here is one, that stop’s working after some time, but werks perfectly after reboot…

rule "Badezimmerspiegel Regel"
when
    Item Dimmer_Badezimmerlicht received update
then
    if (Dimmer_Badezimmerlicht.state > 80) {
    Badezimmerspiegel.sendCommand(ON)
    }
    else Badezimmerspiegel.sendCommand(OFF)
end

Did some further investigation…sometimes I don’t get the reports from Z-Wave devices…I’m using Aeotec nano dimmer and used “send hail cc when using external switch” on parameter 80…is this correct? I don’t wanted to overload z-wave network with reports an keep it fast…

#2

Start with Why have my Rules stopped running? Why Thread::sleep is a bad idea

1 Like
#3

Okay changed thanks :slight_smile:

#4

Ohhh sorry I misunderstood! I will go through the link and see if there is something applying to me…but I meanwhile think it’s a problem with z-wave reporting settings… because rule starts working when using basic reports again…

#5

Well, the first thing to with a rule that doesn’t run is to see if the event that you expected to make it run, really happened.
Your events.log is useful for seeing Item state changes.

#6

Yes I think the event is missing because “hail cc” doesn’t seem to work anymore…

#7

Generally, don’t use hail unless your device doesn’t support associations. It’s a very old concept - use associations if the device supports them (and I’m sure the nano should).

1 Like
#8

What do you mean by associations? I just want the controller to know if the device is on or of…it’s already associated with the controller in report group one…so I’d rather use basic cc report, or multilevel-switch report?

#9

Take a look at the docs :wink:

But why use Hail then? Hail is a very old concept - it is not used these days for good reasons, so I’d suggest to only use it if you have a very old device. Any ZWave plus device will simply use the lifeline association group.

Associations are the way to configure a device to send reports autonomously to the controller. Hail causes the device to send a hail command to the controller, and then the controller must poll the device - this is inefficient as it results in more than double the traffic.

1 Like
#10

Ohhh okay I see! I seted hail because I thought it would be less traffic…I’m talking about parameter 80 setting for the dimmer…there you can define which type of report it sends…the alternatives are:

  • Send hail cc when using external button (which I have setted now)
  • Send hail cc
  • Send basic cc
  • Send multilevel-switch report
  • Send nothing (this leads OpenHab to not know stats)

Which one should I choose? Multilevel or basic cc?

The device is already associated with the controller In report group one anyways…

#12

I just recognized another Problem with the rules… another rule stopped working that is not dependent on z-wave stats…it’s triggered by the astro-binding…I will post it tomorrow.

#13

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.

#14

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

#15

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.

#16

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
#18

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…

#19

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.

1 Like
#20

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 =).

#21

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 :slight_smile:

2 Likes
#22

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