In addition to Matthias’s suggestion, you could use Design Pattern: Associated Items or Design Pattern: Encoding and Accessing Values in Rules to save you constants and have one rule to process all the sensors.
You should never duplicate a rule with the only difference slightly different constants. That leads to a huge amount of work up front and in the long term.
Have you looked at Rules - Introduction | openHAB? I find the biggest problem most old users of OH have when adopting new OH 3 concepts is failing to read the Getting Started Tutorial.
OK, so in your rule create a Script Action and code your formatting using Blockly.
This belies some confusion. In the UI a rule has three parts: triggers, actions, and conditions. In Rules DSL, a rule has two parts, triggers (stuff between when
and then
) and the action (stuff between the then
and end
). The only thing different in the UI is it adds one new concept (conditions) and you can have more than one Action. Other than that, it’s the same as you’ve always done. You can even write your Script Actions in Rules DSL.
If what you are really after is a “simple UI rule” (see Rules - Basic | openHAB) you can’t. There simply is not that degree of capability in simple UI rules. You will have to write a Script Action in the language of your choice. Blockly is a good choice or, since your rules are already in Rules DSL, there is no harm in keeping them as Rules DSL if you want.
This also shows some confusion. A script action cannot exist without a rule. In the UI you’ll see a section called “Scripts” which consist of rules that only have a single Script Action with no triggers and no conditions. But they re still rules like any other.
However, it is possible for rules to call another rule. And when you do so using a Blockly or JS Scripting Script Action you have the option to pass it data.
So it actually is possible for you to create the one “alerting” Script and have your rules call it with the data it needs to construct and send the message.