I basically always use the former, and only in some very special cases use the latter.
Reasons:
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’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.
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.
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!
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.
Ciao