Timer rule not working right in oh3

Hello,

how do i need to change the rule to work properly again.
i had this in oh2, was working great, and since oh3 i have seen that the timer is always 10min, the SchlafzimmerLichtDauer can be set to 2, but the timer is still 10 min, i get no error in oh3
i know there is something changed in oh3 with the timer, but my skills with scribts not the best

var Timer timer = null
rule "Licht Schlafzimmer bei Bewegung Einschalten"
when
    Item Motion_FF_Bed received update ON
then
       if((timer === null && flagItemsunset.state == ON && Bewegungsmelder.state == ON) || 
       //(timer === null && Light_Sensor_Outdoor.state <= 60 && Bewegungsmelder.state == ON) || 
       (timer === null && Motion_FF_Bed_illuminance.state <= 40 && Bewegungsmelder.state == ON)) {
        var time=Integer::parseInt(SchlafzimmerLichtDauer.state.toString)
        logInfo("FILE", "Setting to ON and creating timer "+time.toString)
        Light_FF_Bed_Ceiling.sendCommand(ON)
        timer = createTimer(now.plusMinutes(time), [|
            logInfo("FILE", "Timer expired and setting to OFF")
            Motion_FF_Bed.postUpdate(OFF)
            Light_FF_Bed_Ceiling.sendCommand(OFF)
            timer = null
        ])
    } 
      else if (timer !== null) {
        logInfo("FILE", "Timer rescheduled")
        timer.reschedule(now.plusMinutes(10))  
    }
      else {
	    logInfo("File","Bewegung erkannt, aber noch Tag oder zu hell: Nichts zu tun")
	}
end

If it’s always 10 minutes that means that huge and complicated if statement at the top is not working as you expect.

Log out everything in that if statement and you will see why it’s not working.

In the process, consider what you can do to simplify that super long if statement. For example, you always look for timer === null and Bewegungsmelder.state == ON. So why test for it over and over?

Nothing changed with Timer. This code will work as is in OH 3. And if there were a change, OH 3 would simply fail the rule with an error. That’s not the problem.

Try breaking it up and adding logging.

if(timer !== null) {
    timer.reschedule(now.plusMinutes(10));
    return;  // rule exits, we don't have to worry about this case again for the rest of the rule
}

if(Bewegungsmelder.state != ON){
    return; // rule exits as there is nothing to do when the Item isn't ON
}

// We now know timer has to be null so we don't have to test for it
// We now know that Bewegungsmelder.state is ON so we don't have to test for it

if(flagItemsunset.state == ON || Motion_FF_Bed_illuminance.state <= 40) {
    // create the timer
}

Sprinkle the above with lots of logging and you will see what’s wrong.

This kind of thing jumps out. Many device channels that were simple numbers in OH2 are now Quantity types in OH3, and come with units. Comparing a Quantity with a simple number does not go well, apples and oranges.
But you will see that if you log values out as already suggested.

1 Like

A question just arose in my mind. What happens if you try to link a plain old Number Item to a UoM Channel? That should generate errors right? So it should be apparent in the logs that something is wrong. At the very least the UI should show the Item as NULL or at least unchanging.

But I could also see it just stripping the units off and passing the number on down which can make these sorts of migration issues trickier to diagnose.

I think it “works”, Numbers can contain Quantities. The Item state is set to 22 kW or whatever. Then comparing 22 kW with 23 fails.

I’m not sure I like that behavior. It’s like failing silently. A Number without UoM should be a number without UoM. I’ll have to experiment with that and maybe file an issue because that’s clearly biting a lot of people in the bum.

1 Like

It’s been there since OH2, you can postUpdate plain Numbers with quantity values from rule or REST. Channel uses same path I believe,

I believe something in the binding XML config can suggest permitted types for linking, but it may not be policed thoroughly. Given that profile transforms could match any to any, we might not want it policed.

I’ll bet the root of the problem here is importing from old xxx.items file, which has always been able to force 'inappropriate’links anyway.

I will check today and give info if all items has a value and what type it is (number or string)

I’m expecting you to find some that are neither, but are quantities instead - a number with a unit.

But who knows, until you look.

Switch flagItemsunset “Tag/Nacht” is triggered by a rule from astro binding.
image

Switch Bewegungsmelder “Bewegungsmelder Haus” is a dummy switch, triggered by myself
image

Number Motion_FF_Bed_illuminance “Bewegungsmelder Schlafzimmer” is a number item from zigbee2mqtt
image

String SchlafzimmerLichtDauer “Schlafzimmer [%s m]” is a string item triggered by myself from sitemap
image

Switch Light_FF_Bed_Ceiling is a switch item from the miio binding
image

i have now checked the state of the items in the api-exlorer, everyone has a value, no item has the state NULL

I don’t argue that it doesn’t work, but it’s very counter intuitive and I’d even argue inconsistent for a Number Item without units to carry a QuantityType at all. That should be an error or, at the very least have the QuantityType converted to a DecimalType. Otherwise you simply cannot ever trust what a plain old Number Item carries. If the binding, at some later date decides to add UoM to a Channel that formerly did not use UoM, rules will start to explode with cryptic errors that you or I could figure out but most average users would not.

Since you get a relatively meaningful error when you try to assign a QuantityType that is incompatible with a Number:X (e.g. try to assign 25 V to a Number:Temperature), to be consistent one would expect trying to assign any QuantityType to a Number would either result in an error, or in the units being stripped off. The fact that the units are retained is a surprise and surprises like this will end up creating a whole lot of work for us here on the forum.

Well, what are going to do now? You’ve already got some logging that shows the path through your rule. You’re even logging out what that time variable is, but the output is still secret from us.
Any of that look wrong to you?

this is now really strange, when i only trigger this rule, i can see it in the log that it is working as it should


i have the same rule also in every other room with different times, also set some to 10, is it possible that the timer is changed by them, or when the motion sensor set more than one ON command?

i am not at home befor friday, but at the weekend, i had checked the time with the smartphone in the bedromm and it was 10min instead of 2

i check the logs from these day

Do all these different Timers share one global variable named ‘timer’ ?

i have found it in the logs:

2021-05-15 23:37:15.305 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SchlafzimmerLichtDauer' changed from 2 to 1
2021-05-15 23:38:53.683 [INFO ] [org.openhab.core.model.script.FILE  ] - Setting to ON and creating timer 2
2021-05-15 23:38:54.438 [INFO ] [org.openhab.core.model.script.FILE  ] - Timer rescheduled
2021-05-15 23:48:54.438 [INFO ] [org.openhab.core.model.script.FILE  ] - Timer expired and setting to OFF

yes, all rule files has the same variable name “timer”, should i change this for every rule to a specific one?

Well, yes. In theory it will be a different ‘timer’ in each file, but all rules in one file will share it. That could lead to weird behaviour as this rule cancels or reschedules that rules timer.

In practice no-one has ever quite trusted the separation of global xx in this file from global xx in that file. It’s just asking for trouble really.

ok, i have for every room a different file, but i will change it and test it, thx for this info

Off-topic

I’ll refine that, I was mistaken - if you link say a Number:Angle channel to a plain Number Item, you get a plain Number state.
It might not be the number you expect, depending on defaults and state descriptions, I haven’t sorted that out yet.

You can postUpdate quantities with units to plain Number Items from rules, but there are definitely odd effects, and they appear to be different to channel linking.

If you have a Number with no [pattern], post what you like.
“37 kW” , “41 rad” , “47 °” , “57”
gives Item states just as requested, with or without the unit as requested.
post “67 bananas”, get log (and no update)
Cannot convert '67 bananas' to a state type which item 'xxxx' accepts: [DecimalType, QuantityType, UnDefType].

If you have a Number with a quantity-like pattern, say [%.0f °], and repeat the updates
“37 kW” is silently ignored completely. No event, no log, weird.
“41 rad” , “47 °” , “57” do the updates as expected.
Of note, radians is not converted to degrees.
“67 bananas” is rejected as before.

Definitely something wrong with “37 kW” behaviour.

1 Like

i have now changed the variable to timerar for this one file that is turning on the light in the workingroom:

var Timer timerar = null
rule "Licht Arbeitszimmer bei Bewegung Einschalten"
when
    Item Motion_GF_Working received update ON
then
       if((timerar === null && flagItemsunset.state == ON && Bewegungsmelder.state == ON) || 
       //(timerar === null && Light_Sensor_Outdoor.state <= 60 && Bewegungsmelder.state == ON) || 
       (timerar === null && Motion_GF_Working_illuminance.state <= 40 && Bewegungsmelder.state == ON))  
       {
        var time=Integer::parseInt(ArbeitszimmerLichtDauer.state.toString)
        logInfo("FILE", "Setting to ON and creating timer")
        Sonoff_Touch_GF_Working.sendCommand(ON)
        timerar = createTimer(now.plusMinutes(time), [|
            logInfo("FILE", "Timer expired and setting to OFF")
            Motion_GF_Working.postUpdate(OFF)
            Sonoff_Touch_GF_Working.sendCommand(OFF)
            timerar = null
        ])
    } 
      else if (timerar !== null) {
        logInfo("FILE", "Timer rescheduled")
        timerar.reschedule(now.plusMinutes(10))  
    }
      else {
	    logInfo("File","Bewegung erkannt, aber noch Tag oder zu hell: Nichts zu tun")
	}
end

and get these error:

2021-05-28 23:27:30.384 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'licht_arbeitszimmer_bei_bewegung_einschalten_nach_sonnenuntergang_oder_bei_dunklen_tagen-1' failed: For input string: "NULL" in licht_arbeitszimmer_bei_bewegung_einschalten_nach_sonnenuntergang_oder_bei_dunklen_tagen