Difference between scripts and rules

[SkipMorrow]

Looking over the rules and scripts docs here

Rules

I am trying to start setting up my automation. But I can’t figure out how to get rules to talk to each other. And what are scripts? I get it that rules have a trigger condition and when the trigger condition happens, then that rule is executed. But what if I want to apply some logic and organization to my automation setup? For instance, I can get all of the messages that my alarm system can generate. Arming, disarming, zones violated, different types of arming, alarm sound, etc. I can have one rule to watch for any messages from the alarm system, and it could compare it to a long list of different possible commands, and additional parameters such as zone number and key pad used. One giant rule to parse all of this and then execute follow-on actions.

But I think a better approach would be to have an initial rule that figures out the basic message type received, such as arming or disarming, and then hand off the execution to a different rule, or something (maybe a script???) that only knows how to deal with that particular message type to further parse the message and then to do whatever actions are needed.

[rlkoshak (Rich Koshak)]

@SkipMorrow

But I can’t figure out how to get rules to talk to each other.

Rules don’t talk to each other. Rules are triggered by events which come from Items, Channels, Things, system events (e.g. System started), and time.

If you want Rules to trigger each other see Design Pattern: Separation of Behaviors.

@SkipMorrow

And what are scripts?

Personally I’ve never found much use for Scripts. They are little pieces of Rules code that can be called from one or more Rules. BUT, you cannot pass any arguments to Scripts nor can you get a return value from Scripts. So IMHO they have very little use.

@SkipMorrow

But what if I want to apply some logic and organization to my automation setup?

There are all sorts of ways to apply logic and organization to your automation setup.

@SkipMorrow

For instance, I can get all of the messages that my alarm system can generate. Arming, disarming, zones violated, different types of arming, alarm sound, etc. I can have one rule to watch for any messages from the alarm system, and it could compare it to a long list of different possible commands, and additional parameters such as zone number and key pad used. One giant rule to parse all of this and then execute follow-on actions.

See the DP I linked to above.

Also see Reusable Functions: A simple lambda example with copious notes for another potential approach.

For a lot of these cases you can also just create separate Rules in the first place and avoid this cascading triggering of Rules. For example:

rule "Alarm arming/disarming"
when
    Item Alarm received command "Arming" or
    Item Alarm received command "Disarming"
then
    if(receivedCommand.toString == "Arming"){
        // do arming stuff
    }
    else {
        // do disarming stuff
    }
end

Ultimately, if you are a programmer (which I suspect) you will probably struggle with the Rules DSL a bit. It does not like it when you try to program in it using your typical approaches you might use in a more typical language. If you are willing to learn to do things like the Rules DSL likes to do them it can be a very satisfactory programming environment (see the Design Pattern postings for help on this journey). If not, you will probably be happier using the JSR223 addon and coding your Rules using a more familiar language like Jython, JavaScript, or Groovy.