Solar switch

Add-on Marketplace Rule Templates
,
2

Thank you for posting a rule template!

I’m a little confused about how Threshold Alert fits in here. If you just want to the rule to run every n minutes you don’t need Threshold Alert for that. You can use a simple cron trigger with a condition. In the rule if you click the code tab you’ll see what all the properties were set to when the rule was generated from the tempalte. For example, my humidity alerting rule’s config:

configuration:
  dndEnd: 08:00
  rateLimit: ""
  invert: false
  initAlertRule: ""
  dndStart: 22:00
  alertRule: new_humidity_proc
  endAlertRule: new_humidity_proc
  thresholdState: 35 %
  defaultRemPeriod: PT12H
  operator: <
  hysteresis: 5 %
  reschedule: false
  namespace: humidityAlert
  gkDelay: 250
  defaultAlertDelay: ""
  group: MinIndoorHumidity

I’ve found this incredibly useful.

Maybe showing the configuration of the Threshold Alert would make that more clear. If I’m confused, I’m sure others will be too.

To avoid forcing Item names and such on end users, you should use properties. For example

  - name: email
    label: EMail
    description: Where to send notifications
    type: TEXT
    defaultValue: default
    required: false

I think you can even add a context: email and it will do format checking for you. Then you’d change the following line

var notificationsuser = 'nouser@mail.account';

to

var notificationsuser = '{{email}}';

and the end user gets to set this sort of thing up through properties instead of needing to edit the actual code after creating the rule. See [Do not install] Rule Template Parameters Experiments and Examples for some useful examples of defining various types of properties. When using a context of “item”, “thing” or “rule” you get a nice dialog where you can search through and select from your existing stuff which avoids typos and such and copy/paste errors.

All your variables at the top of the script except logger could be properties so the end users can use what ever Item names they want without needing to change the actual code.

For logger, you should choose your own prefix for the logger name. I use “rules-tools” because it makes it easier for me to help users of the rule control the logging and to help identify the rule template came from me. It’s a reference to openhab-rules-tools which I shortened because it was too long. I also use this prefix in my openhab-rules-tools library. You should choose something of your own. It helps with support as well as branding.

Another thing I’ve found useful in rule templates is to have the template call out to another rule in places where what the user may want to do might vary. For example, lots of users use Telegram instead of email for notifications. If you called a notification rule where the user implements what ever notification they want it might widen the audience for the rule template. Of course it makes setting up the template a little more complex for the end user so a balance needs to be found.

rules.runRule('ruleUID', { "arg1": "value1", "arg2": 2 }, true);

The first argument is the UID of the rule, which can be a property that shows a list of all the rules the user can select from. The second is a map of name/value pairs that get passed into the called rule. The third argument is whether the “But only if…” section of the called rule is applied or skipped. Your rule will block until the called rule completes.

You could eliminate the laststate Item if you use cache.private to store the value instead. However, while that makes it simpler for the end user (one less Item to create and configure in the rule) it will not survive a reloading of the rule or restart of OH. It’s a trade off.

These are just some ideas. They are not required by any means. They are some lessons learned I’ve earned from supporting my own rule templates that have made doing that easier for me and the end users.

1 Like