Is it possible to force a LUX sensor to update?

Setup, Configuration and Use Scripts & Rules
, ,
1

Hi,

I’m relatively new to this and am not a programmer by any means.

I have a landing light set to turn on and off based on motion and lux sensor (Fibaro Multisensor).
This works fine, however I would like to improve it a little as the light is currently set to come on if the lux sensor is <70, which is a little too light for my liking!

I did lower the lux sensor condition to be <60 after checking the logs to see at which point the light should be triggered.
However, this caused an interesting problem. Once the light had been triggered on, then turned itself off again due to no motion the lux sensor had logged the new value of 65 (while the light was on) then does not update quick enough after the light has been switched off to allow the light to turn back on if motion is detected in a short time frame.
It’s main use is for if anyone goes to the bathroom in the night, so the light turns on fine when going to the bathroom, turns off while in the bathroom then does not always turn on again when leaving the bathroom due to the lux sensor being above 60 while the light was turned on.

Is there a way to force the lux sensor to update after the light has turned off?

Any help would be greatly appreciated.

Paul.

Items:
Switch land_motion “Landing Motion” {channel=“zwave:device:***”}
Number land_lum “Landing Luminous” {channel=“zwave:device:***”}
Switch LandLight “Landing Light” {channel="zwave:device:***}

Rules:
// Turn Landing Light on when motion detected
rule “Landing Motion”
when
Item land_motion changed to ON

then
if (land_lum.state < 70) {
logInfo(loglight, “Landing Light switch ON”)
LandLight.sendCommand(ON)
}
end

// Turn off Landing Lights based on no motion with a 20 second delay.
rule “motiondetOff”
when
Item land_motion changed from ON to OFF

then
Thread::sleep(20000)
if (land_motion.state == OFF) {
logInfo(loglight, “Landing Light switch OFF”)
(LandLight.sendCommand(OFF) ) }
end

2

This is a simple rule but please use How to use code fences when posting rules, items, logs, etc.

This is one of those cases that is surprisingly hard to deal with.

I think your best approach will be to ignore the lux value if the motion detector recently changed. I see other problems with the rules.

  • sleeps longer than 500 are strongly discouraged, use Timers instead
  • if you use Timers, you can keep the light on as long as motion is detected which may let you sidestep the lux issue entirely

Assuming that this light only needs to be controlled by the motion sensor I’d recommend using Design Pattern: Expire Binding Based Timers.

Switch LandLight “Landing Light” {channel="zwave:device:***, expire="20s,command=OFF"} // turn off the light after 20 seconds

You need to set up persistence on LandLight. If you are not already using persistence, use MapDB.

rule "Landing Motion"
when
    Item land_motion changed to ON
then
    // If the light is already on, keep it on for another 20 seconds
    if(LandLight.state == ON) {
        logInfo(loglight, "Landing Light switch kept ON")
        LandLight.sendCommand(ON) // keep the light ON and reset the timer
    }

    // if the light is OFF, turn it on if it is dark OR the light turned OFF less than 5 seconds ago
    else if(land_lum.state < 70 || LandLight.lasUpdate("mapdb").isAfter(now.minusSeconds(5)) {
        logInfo(loglight, "Landing Light switch ON")
        LandLight.sendCommand(ON)
    }
end
3

Thank you @rlkoshak, I don’t have persistence set up so will look into that first. I have added the expire binding to my setup so will be using that quite a bit I think.
I’m assuming I would need to make an individual expire switch Item for each instance within my rules for instance a LandTimer, DoorTimer etc.

Paul.

4

While you cannot query the current lux value, Fibaro FGMS have a parameter (#40) to report illumination whenever it changes by a defineable amount. That should apply when you turn off the light.

5

It depends. For the light above you can just put the expire on the light Item itself because:

  • there only thing that needs to be done is turn off the light when the timer expires
  • the light is always controlled by the motion detector.

If you need to control the light or whatever some other way or you need to do more than simply turn that one on or off you need a separate timer Item.

6

Because of the device you’re using, I think there is a much simpler way to achieve this. Your device has a LOT of configuration parameters for tuning it, so you shouldn’t need to use a timer, the Expire binding, or persistence. If you are using the default settings, it looks like you would want to set parameter 6 to 50 (default 30s + 20s). Also, setting parameter 8 to 2 will allow the motion sensor to only trigger during the night, and setting parameter 9 to 60 should set the lux level for the day/night transition. You’ll probably also want to take Markus’ advice and adjust parameter 40 for the lux reports too. Your rule would then collapse to a simple:

rule “Landing Motion”
when
    Item land_motion changed
then
    LandLight.sendCommand(land_motion.state)
    logInfo(loglight, “Landing Light switch {}”,land_motion.state.toString)
end

But there’s actually no reason to use a rule at all, because the information used is already in the device! Just add the node ID of the light switch to Association Group 2 or 4 (in the motion sensor), depending on it’s capabilities, and the motion sensor will send the ON/OFF directly to the light. Once setup, you wouldn’t even need OH running or your ZWave controller plugged in for the light to turn on with motion. The time between motion detection and the light turning on will also be quicker than going through a controller.

I like your device… but that eye ball creeps me out! :ghost:

Actually, if you send the command RefreshType.REFRESH to an item, the ZWave binding will request the current value from the device.

7

That’s a good one to know. Does it only refresh that one value or all the channels for that Thing?

8

I haven’t looked at the code to confirm, but I think it would be just the channel. This kind of confirms that too…

1 Like
9

Correct.

1 Like