Rules issue in OH2. Is it my rules or OH2?

Setup, Configuration and Use Runtime
7

Please please please use Designer people. All of the problems mentioned so far would have been pointed out in Designer before you even saved the file. The error messages in OH are too cryptic to efficiently work without it.

Have you been following the migration tutorial. In particular the “Necessary Changes” section tell you what you need to modify in your rules between OH 1 and OH 2.

You should look into lambdas so your logic only has to be written once. It greatly reduces the chances of messing something up with “copy and paste find and replace” coding.

What I don’t see posted are any logs. When you see this sort of behavior add a ton of logging to your rules, log out the states of everything relevant, and log every other line so you can see where in the rule a rule may have failed.

You say the rules are not working but without the logs we don’t know whether the rule simply never fired which would indicate one type of problem, or failed in the middle of execution which would be another type of error.

Also, you should post your Items because sending “Active” to an Item named “Switch” is counter intuitive. I assume this is a String Item but if not that line would be another error.

  • extraneous or after `Item TVRoomPresenceGroup received update
  • not an error but the following is simpler and therefore easier to understand if(TVRoomPresenceSwitch.state != "Active)
  • not an error but it is safer to use TVRoomPresenceSwitch.sendCommand(“Active”) instead of the Action; it is a long explanation I won’t go into here as @rossko57 indicated. However, while it is very odd to use them , the ( ) in this case is not an error.

Except for the extraneous “or” I see nothing particularly wrong with this rule. This rule will be triggered more than once for every update to an Item that is a member of TVRoomPresenceGroup but that should not cause the

Rule 2:

  • what is TVRoom_Ceiling_Lights_OUT_counter? It looks like a Timer. Where is this Timer created?

I see nothing else glaringly wrong. The code itself can use some tightening up (see below) but nothing glaringly wrong. This lends evidence to @MikeJMajor’s guess. The sometimes it works and sometimes it doesn’t also lends evidence to this conclusion.

If this is the case, the “problem” is that OH 2 is much more efficient at processing commands than it was in OH 1.

What hardware are you running on?

Rewrite of Rule 2 so show what I mean about how it can be tighter:

rule "TVRoom Ceiling Light Mode Selection"
when
    System started or
    Item TVRoomPresenceSwitch received command
then
    logDebug("TVRooom", "Lighting Ceiling - Mode Selection - Starting")

    var mode = 0
    switch TVRoomPresenceSwitch.state {
        case "Startup":  mode = 1
        case "Standby":  mode = 12
        case "Active":   mode = 2
        case "Manual":   mode = 9
        case "Inactive": mode = 10
    }

    logDebug("TVRoom", "Lighting Ceiling - Mode Selection - " + TVRoomPresenceSwitch.state + " Mode Number " + mode)
    TVRoom_Ceiling_LightingAutomation.sendCommand(mode)

    switch mode {
        case 12, case 2, case 9: {
            logDebug("TVRoom", "Lighting Ceiling - Mode Selection " + TVRoomPresenceSwitch.state + " Mode - TVRoom Lights OUT Timer Canceled")
            TVRoom_Ceiling_Lights_Out_counter.cancel
            TVRoom_Ceiling_Lights_Out_counter = null
        }
    }
end

51 lines of code to 27. The fewer the lines of code usually the easier it is to understand, debug, and update. In the above the only functionality removed is the second log statement after the sendCommand.

Note that a Switch is a way to write a bunch of if else if statements in a more readable manner.

An personally I would create a map file and replace the first switch statement with:

transform("MAP", "roompresence.map", TVRoomPresenceSwitch.state)

With the contents of transformations/roompresence.map:

"Startup"=1
"Standby"=12
"Active"=2
"Manual"=9
"Inactive"=10

which would bring the new code count down to 20.

Alternatively I would update TVRoom_Ceiling_LightingAutomation to take the “Active”, “Standby” et al instead of a number for the state and eliminate the need for the switch or transform in the first place.

2 Likes