-
Notifications
You must be signed in to change notification settings - Fork 4
Rules
How to work with automation rules
openHAB has a highly integrated, lightweight but yet powerful rule engine included. On this page you will learn how to leverage its functionality to do real home automation.
Rules are placed in the folder ${openhab.home}/configurations/rules
. The runtime already comes with a demo file called demo.rules
, which has a couple of examples, which can be a good starting point.
A rule file can contain multiple rules. All rules of a file share a common execution context, i.e. they can access and exchange variables with each other. It therefore makes sense, to have different rule files for different use-cases or categories.
The openHAB Designer offers full IDE support for rules, which includes syntax checks and coloring, validation with error markers, content assist (Ctrl+Space) incl. templates etc. This makes the creation of rules very easy!
Note: The rule syntax is based on Xbase and as a result it is sharing many details with Xtend, which is built on top of Xbase as well. As a result, we will often point to the Xtend documentation for details.
A rule file is a text file with the following structure:
[Imports]
[Variable Declarations]
[Rules]
The Imports section contains import statement just like in Java. As in Java, they make the imported types available without having to use the fully qualified name for them. For further details, please see the Xtend documentation for imports.
Example:
import org.openhab.core.library.types.*
The Variable Declarations section can be used to declare variables that should be accessible to all rules in this file. You can declare variables with or without initial values and modifiable or read-only. For further details, please see the Xtend documentation for variable declarations.
Example:
// a variable with an initial value. Note that the variable type is automatically inferred
var counter = 0
// a read-only value, again the type is automatically inferred
val msg = "This is a message"
// an uninitialized variable where we have to provide the type (as it cannot be inferred from an initial value)
var Number x
The Rules section contains a list of rules. Each rule has the following syntax:
rule "rule name"
when
<TRIGGER CONDITION1> or
<TRIGGER_CONDITION2> or
<TRIGGER_CONDITION3>
...
then
<EXECUTION_BLOCK>
end
A rule can have any number of trigger conditions, but must at least have one. The EXECUTION_BLOCK contains the code that should be executed, when a trigger condition is met. The content of the EXECUTION_BLOCK is in fact a script, so please refer to the scripts documentation for details.
There are different categories of rule triggers:
- Item(-Event)-based triggers: They react on events on the openHAB event bus, i.e. commands and status updates for items
- Time-based triggers: They react at special times, e.g. at midnight, every hour, etc.
- System-based triggers: They react on certain system statuses.
Here are the details for each category:
You can listen to commands for a specific item, on status updates or on status changes (an update might leave the status unchanged). You can decide whether you want to catch only a specific command/status or any. Here is the syntax for all these cases (parts in square brackets are optional):
Item <item> received command [<command>]
Item <item> received update [<state>]
Item <item> changed [from <state>] [to <state>]
You can either use some pre-defined expressions for timers or use a cron expression instead:
Time is midnight
Time is noon
Time cron "<cron expression>"
Currently, you schedule rules to be executed either at system startup or shutdown. Note that newly added or modified startup rules are executed once, even if openHAB is already up and running. They are simply executed once as soon as the system is aware of them. Here's the syntax for system triggers:
System started
System shuts down
Besides the implicitly available variables for items and commands/states (see the script documentation), rules can have additional pre-defined variables, depending on their triggers:
- Every rule that has at least one command event trigger, will have the variable
receivedCommand
available, which can be used inside the execution block. - Every rule that has at least one status change event trigger, will have the variable
previousState
available, which can be used inside the execution block.
Taking all the information together, an example rule file could look like this:
// import the decimal type as we refer to it in a rule
import org.openhab.core.library.types.DecimalType
var Number counter
// setting the counter to some initial value
// we could have done this in the variable declaration already
rule Startup
when
System started
then
counter = 0
end
// increase the counter at midnight
rule "Increase counter"
when
Time cron "0 0 0 * * ?"
then
counter = counter + 1
end
// tell the number of days either at noon or if a button is pressed
rule "Announce number of days up"
when
Time is noon or
Item AnnounceButton received command ON
then
say("The system is up since " + counter + " days")
end
// sets the counter to the value of a received command
rule "Set the counter"
when
Item SetCounterItem received command
then
counter = receivedCommand as DecimalType
end
Installation
Community
- Support
- News Archive
- Presentations
- How to Contribute
- IDE Setup
- How to Implement a Binding
- How to Implement an Action
- Projects using openHAB
- User Interfaces
- Classic UI
- iOS Client
- Android Client
- GreenT UI
- CometVisu
- Bindings
- Asterisk Binding
- Astro Binding
- Bluetooth Binding
- Comfo Air Binding
- CUL Binding
- CUPS Binding
- digitalSTROM Binding
- DMX512 Binding
- EnOcean Binding
- Epson Projector Binding
- Exec Binding
- Fritz!Box Binding
- Fritz AHA Binding
- GPIO Binding
- HDAnywhere binding
- Heatmiser Binding
- Homematic Binding
- HTTP Binding
- IHC / ELKO Binding
- Insteon Hub Binding
- Insteon PLM Binding
- Ir-Trans Binding
- KNX Binding
- Koubachi Binding
- MAX!Cube-Binding
- MiLight Binding
- Modbus TCP Binding
- MPD Binding
- MQTT Binding
- MQTTitude binding
- Neohub Binding (Preview)
- Netatmo Binding
- Network Health Binding
- Nibe Heatpump Binding
- Nikobus Binding
- Novelan/Luxtronic Heatpump Binding
- NTP Binding
- One-Wire Binding
- Onkyo AV Receiver Binding
- Open Energy Monitor Binding
- OpenPaths presence detection binding
- OpenSprinkler Binding
- OSGi Configuration Admin Binding
- Philips Hue Binding
- Piface Binding
- Pioneer-AVR-Binding
- Plugwise Binding
- PLCBus Binding
- Pulseaudio Binding
- RFXCOM Binding
- Samsung TV Binding
- Serial Binding
- Snmp Binding
- Squeezebox Binding
- System Info Binding
- Somfy URTSI II Binding
- Sonos Binding
- Swegon ventilation Binding
- TCP/UDP Binding
- Tellstick Binding
- TinkerForge Binding
- VDR Binding
- Velleman-K8055-Binding
- Wake-on-LAN Binding
- Withings Binding
- XBMC Binding
- xPL Binding
- Z-Wave Binding
- Persistence
- db4o Persistence
- rrd4j Persistence
- MySQL Persistence
- MongoDB Persistence
- Sen.Se Persistence
- Cosm Persistence
- Logging Persistence
- Exec Persistence
- MQTT Persistence
- Automation
- Scripts
- Rules
- Actions
- Misc
- REST-API
- Security
- Google Calendar Support
- Twitter Action
- Service Discovery
- Dropbox Bundle
Samples
- Item definitions
- Sitemap definitions
- Binding configurations
- Rules
- REST Examples
- Tips & Tricks
- FAQ
- XSLT Transforms
- Scripts
- Integration with other applications
- Syntax highlighting for external editors
- Update-Scripts
- Samples-Comfo-Air-Binding
- Samples WAC Binding
Release Notes