-
Notifications
You must be signed in to change notification settings - Fork 4
How To Implement An Action
NOTE: This page is still under construction!!!
Actions are simple Java methods (or rather a set of methods) that are made available to scripts and rules. So whenever you want to implement a complex functionality that is reusable and useful in many situations or if you need to access third-party Java libraries, implementing an action is the way to go.
For information about how to setup a development environment, please see the according wiki page.
The openHAB runtime distribution comes only with a limited set of actions. All other actions are considered to be "add-ons", which the user can optionally install by putting it in the "addons" folder of the runtime. As a consequence of this, an action should usually be a single file and as a file corresponds to an OSGi bundle, an action should be a single bundle.
As openHAB makes use of the Xbase framework to allow interpreting scripts at runtime, the actions need to be integrated with Xbase. openHAB provides all means for that so that the only thing you have to do is to register an OSGi service which implements the ActionService interface. This service then only has to provide the action class name and instance. All public static methods of this action class are then automatically made available to the script engine.
As explained above, an action should correspond to one bundle. The naming convention for the action bundle is "org.openhab.action.<name>
". To create a working action skeleton one should use the maven archetype which facilitates the creation process. The following steps have to be performed:
- run a full build (meaning run
mvn clean install
in the topmost directory) cd ./bundles/archetype/./org.openhab.archetype.action
mvn clean install
cd ../../action
mvn archetype:generate -B -DarchetypeGroupId=org.openhab.archetype -DarchetypeArtifactId=org.openhab.archetype.action -DarchetypeVersion=1.4.0 -Dauthor=<author> -Dversion=<target-version-of-binding> -DartifactId=org.openhab.action.<action-name-in-small-caps> -Dpackage=org.openhab.action.<action-name-in-small-caps> -Daction-name=<action-name-in-camel-case>
- import newly created project by issuing 'Import->Existing Java project'
- active the new plugin in !RunConfiguration 'Run Configurations->openHAB Runtime->Plugins->activate your plugin->Auto-start true'
- active the new plugin in !RunConfiguration 'Run Configurations->openHAB Designer (xxx)->Plugins->activate your plugin->Auto-start true'
Another possibility is to copy an existing action and do a search&replace for the name.
Many actions might require configuration data. The generated action service class therefore already implements the !ManagedService interface and registers as such an OSGi service. This has the effect that you can add configuration data like <action-name-in-small-caps>:<property>=<value>
in your openhab.cfg, which will then be automatically passed into the updated()
method of your action service. In there you can store the configuration data and make it available to your action class.
After IDE setup and creating/testing your action, you may want others to use it. For this, you can use the Eclipse export function as follows:
- Right-click on your binding project
- Select Export
- Choose Plug-in Development->Deployable plug-ins and features
- Fill "Directory" with the Path where you want your jar-file to appear
- Check "Use class files compiled in the workspace" on the "Options" tab
- Click Finish and check your directory
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