Do you check the item state before sending a command?

Do you do this?

if (ItemName.state != ON) {

or do you just do:


I know just sending the command can reset an expire timer if one exists, but in the case where it doesn’t matter, which would you do?

I basically always use the former, and only in some very special cases use the latter.

The state of the item according to OH might not be the actual state of the device. (Due to various reasons) Then I should still be able to turn it on without having to do some tricks.
Turning something on that is already on, rarely costs you anything, while the second option, checking if something isn’t on before turning it on, might be slower.

Your choice can depend on external factors … where does this command end up? You might choose to avoid transmitting many redundant messages/responses over, say, zwave or other technology, eating up your bandwidth.

I totally understand the implications.

I’m just curious what would you do. Would you create redundant messages / using up bandwidth, etc. in order to have brevity in your code? When I first started, I checked first, but lately I have been becoming lazier and just send the command without checking.

As others have said, it depends on the context. But in the scripted automation, there is a sendCommandIfDifferent (or something like that) function so you can have brevity and check before sending command.

1 Like

Bingo! Is this documented somewhere?

I suppose with jython I can always create a function to do this

Same thing

Not really… Jython is an example of a JVM language that provides a javax.script.ScriptEngineFactory compatible with scripted automation.

This function is only available in the Jython core helper libraries, so it is not available in Kotlin, jRuby, Groovy, JavaScript, etc. unless someone builds the libraries. This would be a wasted effort though, since the Scripting API will provide all languages access to the functionality available in the Jython libraries.

1 Like

Thank you! I can now do

from core.utils import *
sendCommand("item", "ON")

Where previously I had to do

events.sendCommand("item", "ON")

It is cleaner to only import what you need…

from core.utils import sendCommand

Is there a specific reason? Performance? naming conflict?

Performance (script load time), memory usage/waste, there could be naming conflicts caused by blindly importing everything (there could be something hidden in there stepping on a local name), etc. And it’s just cleaner code!

There are lots of things that come up in a search!

1 Like

Even in Rules DSL you will get a warning when you import *. It’s best practice in most programming languages I’m familiar with to only import what you need, never import it all.

I have experienced that testing an item state to determine whether to issue a comnand or not speeded up my scenario rules: it seems that sending a command is quite a slow task.