Solar switch

[Vayatoalla (Chema)]

This template creates a very simple rule that will allow you to control the state of a device based on the electricity that your house is spending. I will call this device ‘the load’. The goal is to have a ‘Solar Switch’ that switches on/off the load only when your solar panels are generating enough power.

The rule should run every x minutes while the solar switch is on. This is achieved with another rule that you can create with the ‘Threshold Alert and Open Reminder’ template (thanks Rich).

So, hands on, here are the steps to create the ‘Solar Switch’.

In Configuration, Model Menu, select a location and Add one Equipment. In the new Equipment you just created, add three points:

• Create the ‘Solar switch’, call it (for example) ‘VSolarSwitchforXXDevice’: Add a point of type ‘switch’, and semantic class status. This will be the switch that you will use to activate the rule, and thus, the device, but only when there is enough solar production. Add a Metadata to define the type of switch that you prefer to use (here I use Default Cell Widget → Default oh-cell).
• ‘Switch off Threshold’: Add a point of type ‘number’ and semantic class power. Add in Metadata the type of control you want to use here (I sugest to add ‘Default List Item Widget’ → ‘Stepper List Item’ - oh-stepper-item).
• ‘Switch on Threshold’: Add a point of type ‘number’ and semantic class power. Add in Metadata the type of control you want to use here (again, I sugest to add ‘Default List Item Widget’ → ‘Stepper List Item’ - oh-stepper-item).

Now we can begin with the Rules. We will need two rules.

• Rule 1, based on this ‘Solar Switch’ template. This rule will Switch the load On/off depending on the energy consumption of the house and will take into account posible overides in the control of the load (if someone switches on / off the load directly, the rule will deactivate the solar switch and notify you). To complete the template, you will need the points that we defined above. The rule asks for your email account. This is optional: if you set an account (and if you have the Openhab APP instaled), the rule will notify you when thiere is a change in the states of the load or the solar switch.

• Rule 2 - base on the ‘Open Reminder’ template. This rule will Run rule 1 every n minutes (the number of minutes is up to you). The trigger item will be ‘Solar Switch’, the alert state would be OFF (as the Open Reminder template explains, this rule will work as long as the switch value is not OFF). In the Alert Rule field we must put the ‘solar control rule’ that we created before (with the Solar Switch template). The only two values left to add to this template would be the default initial timeout and the repeat period; I usually set them to 5 minutes (PT5m). Additionally, you can take advantage of this template to configure the times in which we want to leave the system activated (for example, it could be used to turn on the air conditioning in the morning, but only when there is solar energy).

And thats all for this rule. The final point is to find a good balance in the thresholds. You will need to choose between the precision of the values of power consumption that you want to achieve and the number of times that the load will be switching.

Changelog

Version 0.1

• initial release

Version 0.2

• Included some changes suggested by ricoshack.

Resources

https://raw.githubusercontent.com/Vayatoalla/oh-solarswitch-template/main/code.yaml

[rlkoshak (Rich Koshak)]

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.

[Vayatoalla (Chema)]

Thank you for your comments. I will take them into account in the review. Keep in mind that it is still a work in progress. I have been using the ruler for months, but creating the template is something new for me.

[Vayatoalla (Chema)]

A bunch of changes implemented and tested. So, I’m releasing this template as stable.