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