Assosiation with FIBARO devices vs. Rule

[wiewior (Jacek)]

I have openHab 2.5.12 running on Raspberry Pi 3+. I know this is not a supported version and I shall switch to the OH3 system and I do really consider that.

Before doing that I wish to understand and improve quite a basic topic which is a delay in communication.

Configuration

In one of my rooms I have FIBARO Motion Sensor which switches two independent and grouped lights controlled by FIBARO Double Switch 2. Control is defined in the rule below. If it is quite dark and motion in the room is being recognised, lights are switched on. If no movement is recognised within 7 min lights will switch off. If the movement will be recognised before time elapses, the timer will be restarted.

This functionality works and this is the rule:

Group:Switch:OR(ON, OFF)    gLightMainOffice                                          "Light"                                          <light>              (Home)                                                           ["Lighting"]

Switch                      BS_Office_Main_Light_1_Switch                             "Light Gosia [%s]"                               <light>              (BS_Office, gLight, gLightOffice, gLightMainOffice)              ["Lighting"]                        {channel="zwave:device:8985008e:node39:switch_binary1"}
Switch                      BS_Office_Main_Light_2_Switch                             "Light Jacek [%s]"                               <light>              (BS_Office, gLight, gLightOffice, gLightMainOffice)              ["Lighting"]                        {channel="zwave:device:8985008e:node39:switch_binary2"}

var Timer timerFlur = null
val int timeoutMinutes = 7

rule "Office Motion Sensor ON" 
when 
    Item BS_Office_Motion changed from OFF to ON 
then
    logInfo("Motion Office", "Luminance in Office: "+ BS_Office_Luminance.state.toString)
    (timerFlur === null || timerFlur.hasTerminated) {
        timerFlur = null
        gLightMainOffice.sendCommand(ON)
        logInfo("Motion Office", "Movement recognised -> Light ON")
    }
    else {
        timerFlur.cancel
        timerFlur = null
        logInfo("Motion Office", "Movement recognised -> Timer restart.")
    }
end

rule "Office Motion Sensor OFF"
when
    Item BS_Office_Motion changed from ON to OFF
then
        logInfo("Motion Office", "No more movement -> Timer start.")
        timerFlur = createTimer(now.plusMinutes(timeoutMinutes), [ |
            timerFlur.cancel
            timerFlur = null
            gLightMainOffice.sendCommand(OFF)
            logInfo("Motion Office", "Timer elapsed -> Light OFF")
        ])
end

The Problem
Sometimes (usually after a longer period of no interaction between sensors) lights are switched on within a few (10-12) sec. delay. I measure it from the time I observe the PIR sensor to flash the light when movement has been recognised.

Target: to eliminate the delay or make ist very very short.

I know there is a possibility to associate the sensor and lights switches so the light is toggled without questioning the controller. Would it improve the situation?

How shall the rule be changed to keep the 7 min wait state and analyze the motion in the room if association will be made? Should it at all or is the rule independent from the communication way?

[rlkoshak (Rich Koshak)]

You need to figure out where the delay is coming from. Bump up the logging for the zwave binding and trace the logs, paying attention to the timestamps.

1. Look to see the delay between the motion sensor changing and the gLightMainOffice receiving the ON/OFF command.

2. Measure the delay from that ON/OFF commands and the binding issuing the command over the Zwave network (you’ll need debug logs from the binding for that).

3. Take note when the lights actually go ON/OFF and measure the delay from when the binding issued the command and the device responding to it.

If the delay is between 1 and 2, the problem is in the rules. If the delay is between 2 and 3, the problem is in your zwave network.

Once you narrow the problem down it will direct where you investigate next.

If the delay is between 2 and 3, the problem is

[wiewior (Jacek)]

@rlkoshak

Bump up the logging for the zwave binding and trace the logs, paying attention to the timestamps

I need to prepare the environment for this. As written it happens usually after long absence in the room. I was able to reproduce this in the morning coming after night to the room hoping on the light to switch on.

Writing this post my intention was to check association (understand it more) as an alternative before sniffing on the zwave protocol and capturing the moment in the morning

[rossko57]

@wiewior

As written it happens usually after long absence in the room. I was able to reproduce this in the morning coming after night to the room hoping on the light to switch on.

There is a known issue with xxx.rules based rules in OH2, which appear to be “rolled out” after long inactivity. Some kind of re-establishment then needs to take place, which takes a few seconds, and is rather like the expected delay on the very first run of a rule. Subsequent re-triggers show no delay.

There is a technique that appears to prevent the mystery “roll-out”.

Idea: hack to avoid rule delay, keep time-critical rules in memory

Maybe the java experts can comment on this… Problem: Rules can take 10-20 seconds to trigger if they not have triggered very recently. My theory is that a JIT compiler runs over them before they are executed, and after some time of not using it, the result is purged from memory. Thus it has to be compiled again, which takes time on my Raspi (3+). My solution: I put this in the rule file that I want to prevent from being recompiled: rule "keep this thing in memory" //use the compiled code in t…

[apella12 (Bob Eckhoff)]

Agree with suggestion to find the delay. Generally even the slowest Zwave messages should not be delayed over a 1 second unless the message did not go through.

As to Association versus rule, I prefer rule as they are more flexible. For instance, I have Fibaro motion device that turns on a light BUT I do not want the light to go between 11 PM and 6AM. That needs a rule. I’m on 3.4M4, so do not seem to have rule delays anyway

I have another motion device that I always want to turn on a light (and it is a distance away from the controller), so I use the Association group to send a basic set for speed and minimizing radio traffic.

There is usually a parameter for motion devices that sets the cancellation (sends an OFF). For the Fibaro it is param 6. You could set to 420 and accomplish the same thing (If I understand correctly).

[wiewior (Jacek)]

@apella12

As to Association versus rule, I prefer rule as they are more flexible. For instance, I have Fibaro motion device that turns on a light BUT I do not want the light to go between 11 PM and 6AM. That needs a rule. I’m on 3.4M4, so do not seem to have rule delays anyway

This is a value, indeed. I understand there are no worries or other technical obstacles using the rule mechanism rather than association group for this kind of use case.

Today morning delay was acceptable but only one light from two in the group switched off. Second one switched on 2 seconds later…

[apella12 (Bob Eckhoff)]

I’d also add (since I see you are asking about a luminance threshold in another posting) that parameters 8 & 9 can be used to send an OFF/ON based on luminance to an association group 2 without a rule at all.

[chris4789 (Christian)]

It’s just my opinion, but I m trying to use associations as much as possible.
If OH is down associations are still working, so you would get a much better WAF for your smart home …