Better way of doing this?

Setup, Configuration and Use Scripts & Rules
1

I am getting unused variable warning when I create timer based rules. Is there a better way of doing this? The rules seem to work, but I’m not entirely certain I’m not creating other problems. It seems like the insteon.rules file may be refreshed at least three times…

Here’s the code:

// This rule implements the “going out two hours” command to turn on and off various lights based on a timer
rule "TwoHourOut"
when
Item TwoHourOut received command ON
then
sendCommand(fronthall, ON);
sendCommand(frontporch, ON);

    var Timer timer_lightoff = createTimer(now.plusMinutes(5)) [|
            sendCommand(frontporch, OFF);
            sendCommand(fronthall, OFF);
            logInfo( "rules", "Timer - front porch going off.[{}]", frontporch.state );
    ]

    var Timer timer_lighton = createTimer(now.plusMinutes(120)) [|
            sendCommand(frontporch, ON);
            sendCommand(fronthall, ON);
            logInfo( "rules", "Timer - front porch going back on. [{}]", X10Remote3.state );
    ]

end

Here’s the log file:

2018-01-07 13:12:17.359 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'insteon.rules’
2018-01-07 13:12:27.915 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model ‘insteon.rules’, using it anyway:
The value of the local variable timer is not used
The value of the local variable timer_lightoff is not used
The value of the local variable timer_lightoff is not used
The value of the local variable timer_lighton is not used
2018-01-07 13:12:28.018 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model ‘insteon.rules’

  • Platform information:
    • Hardware: Raspberry Pi B+
    • OS: raspbian
    • Java Runtime Environment: which java platform is used and what version
    • openHAB version:
  • Issue of the topic: please be detailed explaining your issue
  • Please post configurations (if applicable):
    • Items configuration related to the issue
    • Sitemap configuration related to the issue
    • Rules code related to the issue
    • Services configuration related to the issue
  • If logs where generated please post these here using code fences:
2

First, see How to use code fences

The warning is because you are creating a variable (timer_lightoff, and timer_lighton in this case) and you never use them, just like the warning says.

Since you are never using them, why create them?

    createTimer(now.plusMinutes(5), [|
        frontporch.sendCommand(OFF)
        fronthall.sendCommand(OFF)
        logInfo( "rules", "Timer - front porch going off.[{}]", frontporch.state )
    ])

Just throw away the result of createTimer. By using local variables that is what you are doing anyway. You only need to keep the timer in a variable (global variable mind you) if you need to interact with the timer later from another rule or another run of this rule, such as cancelling it or rescheduling it.

3

Ahh! Thanks! And thanks for the tip about code fences.

And also the correction about the number of parameters to createTimer… It seemed like it was working previously, but this makes a lot more sense.

4

It’s a quirk of the language. What you were doing is correct. Both of these are equivalent:

createTimer(now.plusMinutes(5), [| 
    // do some stuff
])

createTimer(now.plusMinutes(5)) [|
    // do some stuff
]

The creators of the base language upon which the Rules DSL builds decided it looks nicer to not have to put the lambda inside the parens so they let you define the lambda outside the parens when the last argument to a method is a lambda. I hate it because it obscures the fact that the lambda is in fact an argument to the method.

5

It’s funny. I used to ascribe to the PERL approach to reality: there should be 10 different ways to do about anything in a language. After all, it mimics natural language to do it that way and that obviously fits brains pretty well. Lately though, I’m becoming more of a fan of strong typing and defined syntax as it seems to create code that is more maintainable. Thanks, Python!!