Remove common jekyll references. (#1917)
Signed-off-by: Jerome Luckenbach <github@luckenba.ch> Signed-off-by: Jerome Luckenbach <github@luckenba.ch>pull/1919/head
parent
4ee3ef794a
commit
2ddff112b1
|
@ -10,10 +10,7 @@ They are automatically imported and can be used to execute openHAB-specific oper
|
|||
|
||||
The page is structured as follows:
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Core Actions
|
||||
|
||||
|
|
|
@ -7,10 +7,7 @@ title: Runtime Commands
|
|||
|
||||
It is possible to query and even change the state of entities like items or things. Therefore the console offers commands in various areas:
|
||||
|
||||
{::options toc_levels="3..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
::: tip Note
|
||||
Some of the described commands are executed on the internal database and could break your installation. Please use this functionality only if you know what you are doing!
|
||||
|
|
|
@ -2,7 +2,6 @@
|
|||
|
||||
openHAB is about home automation, but to create home automation we need to define rules.
|
||||
|
||||
- TOC
|
||||
[[toc]]
|
||||
|
||||
## What Are Rules
|
||||
|
|
|
@ -12,18 +12,11 @@ The usual way of developing rules is by coding them like described in the [Textu
|
|||
However, this art of programming may become intimidating early on and shy away away people with few or almost no experience in programming.
|
||||
Therefore openHAB also provides a graphical way of writing rules which allows to put together rules in a rather visual way (even though some programming background may still help).
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
{: #blockly-introduction}
|
||||
[[toc]]
|
||||
|
||||
## Introduction
|
||||
|
||||
The basic idea behind the visual paradigm and representation within openHAB is based on the [Google Blockly Support](https://developers.google.com/blockly) which has been integrated and which provides the basic blocks for programming like the ones on the left and the right side of the below images
|
||||
|
||||
{: #blockly-toolbox}
|
||||
_Blockly toolbox_
|
||||
|
||||

|
||||
|
|
|
@ -15,12 +15,7 @@ However, after some times, you end up writing more and more complex rules, so mo
|
|||
This section intends to provide some hints to get started and how to deals with those challenges.
|
||||
Please read them carefully before asking questions in the forum.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
{: #blockly-before-uding}
|
||||
[[toc]]
|
||||
|
||||
## **OpenHAB Configuration Files**
|
||||
|
||||
|
|
|
@ -13,12 +13,7 @@ title: Rules Blockly - Date Handling
|
|||
Date blocks are used as input parameters for other blocks or can be used to create or compare date.
|
||||
With 3.3.0M6 many blocks were introduced to allow complex tasks with dates
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
{: #blockly-date-handling-overview}
|
||||
[[toc]]
|
||||
|
||||
## Overview of the Date Handling blocks
|
||||
|
||||
|
|
|
@ -17,10 +17,7 @@ For example, a way to determine if today is a weekend, a bank holiday, someone
|
|||
Definition of holidays can be customised through the _ephemeris.cfg_ file.
|
||||
See the [Ephemeris configuration page](https://www.openhab.org/docs/configuration/actions.html#configuration) for more information.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Overview of the Ephemeris blocks
|
||||
|
||||
|
|
|
@ -13,12 +13,7 @@ title: Rules Blockly - Items & Things
|
|||
_Items_ and _Things_ are the [major entities of openHAB](https://www.openhab.org/docs/concepts/) to control and monitor the home.
|
||||
These can be accessed via the "Items & Things" section of the [Blockly Toolbox](/docs/configuration/index.html#blockly-toolbox).
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
{: #blockly-items-and-things-overview}
|
||||
[[toc]]
|
||||
|
||||
## Overview of the Items and Things category
|
||||
|
||||
|
|
|
@ -12,12 +12,7 @@ title: Rules Blockly - Logging
|
|||
|
||||
This section explains only the blocks that have been added to the standard blocks by openHAB
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
{: #blockly-logging-overview}
|
||||
[[toc]]
|
||||
|
||||
## Logging and Output
|
||||
|
||||
|
|
|
@ -15,12 +15,7 @@ Notifications can be used as push message to devices running the openHAB client.
|
|||
|
||||
General information on cloud notification actions can be found [here](https://www.openhab.org/docs/configuration/actions.html#cloud-notification-actions).
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
{: #blockly-notifications-overview}
|
||||
[[toc]]
|
||||
|
||||
## Overview of the Notification blocks
|
||||
|
||||
|
|
|
@ -15,12 +15,7 @@ For more information on persistence, the default service, and its configuration
|
|||
|
||||
The date-blocks shown in this section are described previously in [Date handling blocks](https://community.openhab.org/t/blockly-reference/128785#date-handling-blocks-31).
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
{: #blockly-persistence-overview}
|
||||
[[toc]]
|
||||
|
||||
## Overview of the Persistence blocks
|
||||
|
||||
|
|
|
@ -20,12 +20,7 @@ This section contains several possibilities
|
|||
|
||||
A Script _is_ a Rule too. It’s just a special type of rule that only has a single script action and a “Script” tag.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
{: #blockly-value-storage-overview}
|
||||
[[toc]]
|
||||
|
||||
## Overview of the Run & Process blocks
|
||||
|
||||
|
|
|
@ -12,12 +12,7 @@ title: Rules Blockly - openHAB Extensions to the Standard
|
|||
|
||||
This section explains only the blocks that have been added to the standard blocks by openHAB
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
{: #blockly-standard-extension-overview}
|
||||
[[toc]]
|
||||
|
||||
## Logic
|
||||
|
||||
|
|
|
@ -14,10 +14,7 @@ This chapter explains what these blocks do, sometimes displaying generated code
|
|||
|
||||
More about that topic can be viewed at  [Timers](https://youtu.be/hSRfooBKn9A?t=630).
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
{: #blockly-timers-and-delays-overview}
|
||||
[[toc]]
|
||||
|
||||
## Overview of the Timers and Delays category
|
||||
|
||||
|
|
|
@ -21,12 +21,7 @@ Basically a value storage can be perceived as a global variable for the rule ins
|
|||
- By default the value is _undefined_.
|
||||
To check if a value is undefined, use the special "is undefined"-block
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
{: #blockly-value-storage-overview}
|
||||
[[toc]]
|
||||
|
||||
## Overview of the Value Storage blocks
|
||||
|
||||
|
|
|
@ -20,12 +20,7 @@ Even though (2) is not trivial but after having done that the usage of the funct
|
|||
|
||||
More about that topic can be viewed at  [Playing sounds on audio sinks](https://youtu.be/EdllUlJ7p6k?t=2035)
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
{: #blockly-ephemeris-overview}
|
||||
[[toc]]
|
||||
|
||||
## Overview of the Voice and Multimedia blocks
|
||||
|
||||
|
|
|
@ -8,10 +8,7 @@ title: Editors
|
|||
Currently there are several existing solutions, that can help you configuring your openHAB instance in a textual way.
|
||||
This documentation page can give you some guidance in choosing the right one for you and setting it up.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Network Preparations
|
||||
|
||||
|
@ -24,8 +21,6 @@ If you are using [openHABian]({{base}}/installation/openhabian.html), the networ
|
|||
|
||||
_Attention Windows users:_ Directly accessing network shares (UNC paths) is often not supported. Please be sure to mount the network share to a drive letter.
|
||||
|
||||
{: #openhab-vscode}
|
||||
|
||||
## openHAB VS Code Extension
|
||||
|
||||
openHAB VS Code is an extension for the [Visual Studio Code](https://code.visualstudio.com) editor.
|
||||
|
@ -49,8 +44,6 @@ This extension has the ability to check rules and validate them through a so cal
|
|||
The validation needs a running openHAB installation in your environment and can be activated with some simple steps.
|
||||
You can find all important information in the extensions [readme file](https://github.com/openhab/openhab-vscode#validating-the-rules).
|
||||
|
||||
{: #others}
|
||||
|
||||
## Other Editor Integrations
|
||||
|
||||
The here summarized projects provide syntax highlighting for different text editors, but have no _on top_ functionality.
|
||||
|
@ -60,8 +53,6 @@ The here summarized projects provide syntax highlighting for different text edit
|
|||
mcedit is an editor which comes with mc (Midnight Commander).
|
||||
You can find the syntax files and installation instructions on [openhab-mcedit](https://github.com/CWempe/openhab-mcedit).
|
||||
|
||||
{: #notepadpp}
|
||||
|
||||
### Notepad++
|
||||
|
||||
Notepad++ is a free source code editor for Windows.
|
||||
|
|
|
@ -17,10 +17,7 @@ An Item does not simply store information that is set by software (e.g., `OFF`,
|
|||
But let's not get ahead of ourselves.
|
||||
The rest of this page contains details regarding Items and is structured as follows:
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Introduction
|
||||
|
||||
|
@ -48,8 +45,6 @@ While the way of defining an Item using the graphical, interactive UI is differe
|
|||
It's recommended to edit `.items` files using one of the [openHAB supporting editors]({{base}}/configuration/editors.html).
|
||||
Doing so will provide you with full IDE support including features such as syntax checking, and context assistance.
|
||||
|
||||
{: #syntax}
|
||||
|
||||
## Item Definition and Syntax
|
||||
|
||||
Items are defined using the following syntax:
|
||||
|
@ -87,8 +82,6 @@ The last example above defines an Item with the following fields:
|
|||
|
||||
The remainder of this article provides additional information regarding Item definition fields.
|
||||
|
||||
{: #type}
|
||||
|
||||
### Type
|
||||
|
||||
The Item type defines what kind of state can be stored in that Item and which commands the Item will accept.
|
||||
|
@ -144,8 +137,6 @@ In the example above, if you move the Slider widget to 60%, move the Switch to O
|
|||
|
||||
-->
|
||||
|
||||
{: #name}
|
||||
|
||||
### Name
|
||||
|
||||
The Item name is used to uniquely identify an Item.
|
||||
|
@ -199,8 +190,6 @@ Two naming schemes are established in the community for Group names:
|
|||
| "`Livingroom_Lights`" or "`gLR_Light`" | Group containing all light Items belonging to the living room |
|
||||
| "`Livingroom`" or "`gLR`" | Group for _all_ Items (including lights) belonging to the living room |
|
||||
|
||||
{: #label}
|
||||
|
||||
### Label
|
||||
|
||||
Label text is used to describe an Item in a human-readable way.
|
||||
|
@ -216,15 +205,11 @@ Number Livingroom_Temperature "Temperature [%.1f °C]"
|
|||
|
||||
Channel labels can be overwritten by Item definitions and Item labels can be overwritten in [Sitemaps]({{base}}/ui/sitemaps.html#element-types).
|
||||
|
||||
{: #state}
|
||||
|
||||
### State
|
||||
|
||||
The state of an Item depends on the Item type, the Channel bound to the Item, and internal or external events.
|
||||
A analogy can be drawn between the state of an Item and the value of a variable in a computer program.
|
||||
|
||||
{: #item-state}
|
||||
|
||||
#### Item State
|
||||
|
||||
This section provides information about what a user can expect regarding the behavior of the state of an Item.
|
||||
|
@ -240,8 +225,6 @@ This section provides information about what a user can expect regarding the beh
|
|||
|
||||
_N.B._ Many openHAB users find that it can be very useful to use [Persistence](/addons/#persistence) and [System started]({{base}}/configuration/rules-dsl.html#system-based-triggers) rules so that their systems behaves in a predictable way after an openHAB restart.
|
||||
|
||||
{: #command-vs-status}
|
||||
|
||||
#### Command vs. Status
|
||||
|
||||
Users should bear in mind the difference between an Item used to send a command to a Thing, and an Item that reflects the status of a real-world Thing in the UI.
|
||||
|
@ -262,8 +245,6 @@ You could then, through the appropriate Binding, reflect light level changes thr
|
|||
Then you add the light-level Item to your UI.
|
||||
Now when you send the Switch Item command, and you see a corresponding increase in light level in the room, you know for sure that your command has been received and acted upon, because you have a return status Item in your UI.
|
||||
|
||||
{: #state-presentation}
|
||||
|
||||
#### State Presentation
|
||||
|
||||
The Item definition determines the Item's textual state presentation, e.g., regarding formatting, decimal places, unit display and more.
|
||||
|
@ -291,8 +272,6 @@ Number Livingroom_Clock_Battery "Battery Charge [%d %%]" // e.g. "
|
|||
Location My_Location "My Location [%2$s°N %3$s°E %1$sm]" // e.g. "49.26°N 123.19°E 0m"
|
||||
```
|
||||
|
||||
{: #state-transformation}
|
||||
|
||||
#### State Transformation
|
||||
|
||||
Transformations can be used in the state part of an Item, to translate the raw state of an Item into another language, or to convert technical values into human readable information.
|
||||
|
@ -305,8 +284,6 @@ Contact Livingroom_Window "Ventana del salón [MAP(window_esp.map):%s]"
|
|||
|
||||
Please refer to the article on [Transformations](/docs/configuration/transformations.html) for more usage details and a list of available transformation services.
|
||||
|
||||
{: #icons}
|
||||
|
||||
### Icons
|
||||
|
||||
The icon name is used by openHAB to select the image to display next to an Item name when using one of openHAB's UIs, e.g. Basic UI.
|
||||
|
@ -339,8 +316,6 @@ Note that image files with the wrong file ending will be ignored.
|
|||
|
||||
Users may substitute their own icon for an icon from the default icon set by placing a file in the `$OPENHAB_CONF/icons/classic/` folder with the same filename as the name of the icon being substituted.
|
||||
|
||||
{: #icons-dynamic}
|
||||
|
||||
#### Dynamic Icons
|
||||
|
||||
Some icons are dynamically selected by openHAB depending on the Item's state.
|
||||
|
@ -411,8 +386,6 @@ For a dimmable light (0-100%), you might provide icons as in the example:
|
|||
|
||||
Just as with regular icons, user-defined dynamic icon sets may be configured via the custom icons folder `$OPENHAB_CONF/icons/classic/`.
|
||||
|
||||
{: #groups}
|
||||
|
||||
### Groups
|
||||
|
||||
The Group is a special Item type that can be used to define a category or collection into which you can combine other Items or Groups.
|
||||
|
@ -464,8 +437,6 @@ Using nested group hierarchies such as these allows a rule to iterate through al
|
|||
Because of the hierarchical structure of your group items, the rule will be clean and short.
|
||||
Additionally, the rule will not need to be modified when a new Item is added to the `Temperatures` group.
|
||||
|
||||
{: #group-type}
|
||||
|
||||
### Derive Group State from Member Items
|
||||
|
||||
As you are now aware, an Item can have a state (e.g. "ON", "OFF").
|
||||
|
@ -528,8 +499,6 @@ The `EARLIEST` function returns `now().minusDays(10)`, the `LATEST` function ret
|
|||
|
||||
The last Group counts all members of it matching the given regular expression, here any character or state (simply counts all members).
|
||||
|
||||
{: #tags}
|
||||
|
||||
### Tags
|
||||
|
||||
Tags added to an Item definition allow a user to characterize the specific nature of the Item beyond its basic Item type.
|
||||
|
@ -549,8 +518,6 @@ Tags will be ignored if no Items in the openHAB installation support it.
|
|||
|
||||
See the [Hue Emulation Service](/addons/integrations/hueemulation/) or [HomeKit Add-on](/addons/integrations/homekit/) documentation for more details.
|
||||
|
||||
{: #binding}
|
||||
|
||||
### Binding Configuration
|
||||
|
||||
One of the greatest strengths of an openHAB automation system is the sheer number of devices you can interact with.
|
||||
|
@ -625,16 +592,12 @@ Switch Office_PC {
|
|||
|
||||
The first example shows a symbiosis of the LG webOS Binding and the Wake-on-LAN Binding to interact with a TV.
|
||||
|
||||
{: #parameters}
|
||||
|
||||
#### Parameters
|
||||
|
||||
While the `channel` parameter is used to link an item to a channel of a thing, it is possible to add further parameters for additional features.
|
||||
Parameters are provided as a comma separated list.
|
||||
The order of the parameters does not matter.
|
||||
|
||||
{: #autoupdate}
|
||||
|
||||
|
||||
##### Parameter `autoupdate`
|
||||
|
||||
When left as default, openHAB's `autoupdate` function attempts to predict the outcome of a _command_ on the Item _state_.
|
||||
|
@ -649,8 +612,6 @@ Example:
|
|||
Switch Garage_Gate {channel="xxx", autoupdate="false"}
|
||||
```
|
||||
|
||||
{: #expire}
|
||||
|
||||
##### Parameter `expire`
|
||||
|
||||
This parameter allows to post an update or command to an item after a period of time has passed.
|
||||
|
|
|
@ -12,10 +12,7 @@ Note that there is also a visual way of programming openHAB rules, which may be
|
|||
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.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Defining Rules
|
||||
|
||||
|
@ -119,8 +116,6 @@ end
|
|||
- `<TRIGGER_CONDITION>` - The triggering event upon which the rule logic is executed. A rule is executed in reaction to one or more trigger conditions. Multiple conditions are separated by the keyword `or`. Please see below for different possible triggers.
|
||||
- `<SCRIPT_BLOCK>` - Contains the logic that should be executed when a trigger condition is met, see the [script](#scripts) section for details on its syntax.
|
||||
|
||||
{: #rule-triggers}
|
||||
|
||||
### Rule Triggers
|
||||
|
||||
Before a rule starts working, it has to be triggered.
|
||||
|
@ -135,8 +130,6 @@ There are different categories of rule triggers:
|
|||
|
||||
Here are the details for each category:
|
||||
|
||||
{: #event-based-triggers}
|
||||
|
||||
### Event-based Triggers
|
||||
|
||||
You can listen to commands for a specific item, on status updates or on status changes (an update might leave the status unchanged).
|
||||
|
@ -154,8 +147,6 @@ A simplistic explanation of the differences between `command` and `update` can b
|
|||
When using the `received command` trigger, the Rule might trigger **before** the Item's state is updated.
|
||||
Therefore, if the Rule needs to know what the command was, use the [implicit variable]({{base}}/configuration/rules-dsl.html#implicit-variables-inside-the-execution-block) `receivedCommand` instead of `<ItemName>.state`.
|
||||
|
||||
{: #member-of-triggers}
|
||||
|
||||
### Member of Triggers
|
||||
|
||||
As with Item based event-based triggers discussed above, you can listen for commands, status updates, or status changes on the members of a given Group.
|
||||
|
@ -174,8 +165,6 @@ It does not work with members of nested subgroups.
|
|||
Also, as with Item event-based triggers, when using `received command`, the Rule might trigger before the Item's state is updated.
|
||||
So in Rules where the Rule needs to know what the command was, use the `receivedCommand` implicit variable instead of `triggeringItem.state`.
|
||||
|
||||
{: #time-based-triggers}
|
||||
|
||||
### Time-based Triggers
|
||||
|
||||
You can either use some pre-defined expressions for timers or use a [cron expression](https://www.quartz-scheduler.org/documentation/quartz-2.2.2/tutorials/tutorial-lesson-06.html) instead:
|
||||
|
@ -199,8 +188,6 @@ A cron expression takes the form of six or optionally seven fields:
|
|||
|
||||
You may use the generator at [FreeFormatter.com](https://www.freeformatter.com/cron-expression-generator-quartz.html) to generate your cron expressions.
|
||||
|
||||
{: #system-based-triggers}
|
||||
|
||||
### System-based Triggers
|
||||
|
||||
System-based triggers are provided as described in the table below:
|
||||
|
@ -252,8 +239,6 @@ In openHAB version 3 the System-based Trigger for startlevel had been added, val
|
|||
|
||||
Startlevels less than 40 are not available as triggers because the rule engine needs to start up first before it can execute any rules.
|
||||
|
||||
{: #thing-based-triggers}
|
||||
|
||||
### Thing-based Triggers
|
||||
|
||||
Your rules can take actions based upon status updates or status changes generated by Things.
|
||||
|
@ -280,8 +265,6 @@ Refer to [Thing Status Action](/docs/configuration/actions.html#thing-status-act
|
|||
You need to use quotes around `thingUID` if it contains special characters such as ':'.
|
||||
:::
|
||||
|
||||
{: #channel-based-triggers}
|
||||
|
||||
### Channel-based Triggers
|
||||
|
||||
Some add-ons provide trigger channels.
|
||||
|
@ -317,8 +300,6 @@ then
|
|||
end
|
||||
```
|
||||
|
||||
{: #scripts}
|
||||
|
||||
## Scripts
|
||||
|
||||
The expression language used within scripts is the same that is used in the Xtend language - see the [documentation of expressions](https://www.eclipse.org/xtend/documentation/203_xtend_expressions.html) on the Xtend homepage.
|
||||
|
@ -341,8 +322,6 @@ if (Temperature.state < 20) {
|
|||
}
|
||||
```
|
||||
|
||||
{: #manipulating-item-states}
|
||||
|
||||
### Manipulating Item States
|
||||
|
||||
Rules are often used to manipulate the state of an Item, for example switching lights on and off under certain conditions.
|
||||
|
@ -368,8 +347,6 @@ In most cases, a rule with a trigger of `received update` will fire following th
|
|||
|
||||
Besides the specific manipulator command methods `MyItem.sendCommand(<new_state>)` and `MyItem.postUpdate(<new_state>)`, generic manipulators in the form of `sendCommand(MyItem, <new_state>)` and `postUpdate(MyItem, <new_state>)` are available. The specific versions is normally recommended.
|
||||
|
||||
{: #sendcommand-method-vs-action}
|
||||
|
||||
#### MyItem.sendCommand("new state") versus sendCommand(MyItem, "new state")
|
||||
|
||||
Using the methods `MyItem.sendCommand(<new_state>)` and `MyItem.postUpdate(<new_state>)` is often preferable.
|
||||
|
@ -405,8 +382,6 @@ val index = 5
|
|||
sendCommand("My_Lamp_" + index, ON)
|
||||
```
|
||||
|
||||
{: #using-state-of-items-in-rules}
|
||||
|
||||
### Using the States of Items in Rules
|
||||
|
||||
Often it is desired to calculate other values from Item states or to compare Item states against other values
|
||||
|
@ -445,8 +420,6 @@ There are two ways to discover these methods:
|
|||
These methods can be called in Rules-DSL without the `get` part in name as in `(MyColorItem.state as HSBType).red)`.
|
||||
They retrieve the state of MyColorItem and then casts it as HSBType to be able to use the methods associated with the HSBType.
|
||||
|
||||
{: #conversions}
|
||||
|
||||
#### Working with Item States: Conversions
|
||||
|
||||
_Reminder: For a complete and up-to-date list of what item types are currently allowed in openHAB and the command types each item can accept refer to the section on [items in the openHAB documentation]({{base}}/concepts/items.html)._
|
||||
|
@ -765,8 +738,6 @@ For example, the `NumberItem` class would have a `sendCommand(int)`, `sendComman
|
|||
Each of these separate methods is individually written to handle all of these different types of Objects.
|
||||
MyItem will automatically apply the method that corresponds to the argument type.
|
||||
|
||||
{: #implicit-variables}
|
||||
|
||||
### Implicit Variables inside the Execution Block
|
||||
|
||||
Besides the implicitly available variables for items and commands/states, rules can have additional pre-defined variables, depending on their triggers:
|
||||
|
@ -782,8 +753,6 @@ Besides the implicitly available variables for items and commands/states, rules
|
|||
- `previousThingStatus` - implicitly available in every rule that has a thing-based trigger.
|
||||
- `newThingStatus` - implicitly available in every rule that has a thing-based trigger.
|
||||
|
||||
{: #return}
|
||||
|
||||
### Early returns
|
||||
|
||||
It is possible to return early from a rule, not executing the rest of the statements like this:
|
||||
|
@ -797,8 +766,6 @@ Heating.sendCommand(ON)
|
|||
|
||||
Caveat: Please note the semicolon after the return statement which terminates the command without an additional argument.
|
||||
|
||||
{: #concurrency-guard}
|
||||
|
||||
### Concurrency Guard
|
||||
|
||||
If a rule triggers on UI events it may be necessary to guard against concurrency.
|
||||
|
@ -821,8 +788,6 @@ then
|
|||
end
|
||||
```
|
||||
|
||||
{: #transformations}
|
||||
|
||||
### Transformations
|
||||
|
||||
openHAB [Transformation services](/addons/#transform) can be used in rules to transform/translate/convert data.
|
||||
|
@ -869,8 +834,6 @@ finally {
|
|||
|
||||
For all available Transformation services please refer to the list of [Transformation Add-ons](/addons/#transform).
|
||||
|
||||
{: #logging}
|
||||
|
||||
### Logging
|
||||
|
||||
You can emit log messages from your rules to aid debugging.
|
||||
|
|
|
@ -5,8 +5,6 @@ title: Bindings
|
|||
|
||||
# Developing a Binding
|
||||
|
||||
{:.no_toc}
|
||||
|
||||
A binding is an extension to openHAB that integrates an external system like a software service or a hardware device.
|
||||
The external system is represented as a set of _Things_ and sometimes _Bridges_ with _Channels_.
|
||||
|
||||
|
@ -17,10 +15,7 @@ It makes sense to briefly read over all sections to make you familiar with what
|
|||
|
||||
During development you might come back with specific questions.
|
||||
|
||||
{::options toc_levels="2,3"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Structure of a Binding
|
||||
|
||||
|
|
|
@ -5,17 +5,12 @@ title: Thing Descriptions
|
|||
|
||||
# Binding Definitions
|
||||
|
||||
{:.no_toc}
|
||||
|
||||
In order to work with _Things_ and _Channels_, some meta information about them is needed.
|
||||
|
||||
These are provided through 'ThingType' and 'ChannelType' definitions,
|
||||
which describe details about their functionality and configuration options.
|
||||
|
||||
{::options toc_levels="2,3"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## ThingTypeProvider / ChannelTypeProvider
|
||||
|
||||
|
|
|
@ -5,8 +5,6 @@ title: Coding Guidelines
|
|||
|
||||
# Coding Guidelines
|
||||
|
||||
{:.no_toc}
|
||||
|
||||
The following guidelines apply to all (Java) code of the openHAB project.
|
||||
They must be followed to ensure a consistent code base for easy readability and maintainability.
|
||||
Exceptions can certainly be made, but they should be discussed and approved by a project maintainer upfront.
|
||||
|
@ -16,10 +14,7 @@ To speed up the contribution process, we therefore advice to go through this che
|
|||
|
||||
If you are just keen on binding development, you may skip this document first and come back later.
|
||||
|
||||
{::options toc_levels="2,3"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## A. Directory and File Layout
|
||||
|
||||
|
|
|
@ -5,14 +5,9 @@ title: Automation Modules
|
|||
|
||||
# Developing Automation Modules
|
||||
|
||||
{:.no_toc}
|
||||
|
||||
In this section you will be guided through developing _Module Types_ and corresponding _Module Handlers_ for the automation engine of openHAB.
|
||||
|
||||
{::options toc_levels="2,3"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Module Types and Module Handlers
|
||||
|
||||
|
|
|
@ -5,8 +5,6 @@ title: Equinox
|
|||
|
||||
# Equinox
|
||||
|
||||
{:.no_toc}
|
||||
|
||||
[Equinox][Equinox] is considered to be a reference implementation of the [OSGi Core Release 7][OSGi-core].
|
||||
It is an [open source project][Equinox-repo], part of the [Eclipse project][Eclipse].
|
||||
It provides a set of bundles, that implement various optional OSGi services.
|
||||
|
@ -14,10 +12,7 @@ It provides a set of bundles, that implement various optional OSGi services.
|
|||
The openHAB bundles are deployed on an Equinox runtime.
|
||||
Knowledge about how to start the runtime and execute basic commands will help you to speedup the development process.
|
||||
|
||||
{::options toc_levels="2,3"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Start Equinox Runtime from Eclipse
|
||||
|
||||
|
|
|
@ -5,15 +5,10 @@ title: OSGi
|
|||
|
||||
# OSGi Overview
|
||||
|
||||
{:.no_toc}
|
||||
|
||||
openHAB is being based on [OSGi][OSGi] and understanding of OSGi modular architecture is very important.
|
||||
This page is aimed to help developers, that are going to use OSGi for the first time and contains a basic overview of the OSGi technology.
|
||||
|
||||
{::options toc_levels="2,3"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Concepts
|
||||
|
||||
|
|
|
@ -5,17 +5,11 @@ title: OSGi Declarative Services
|
|||
|
||||
# Declarative Services
|
||||
|
||||
{:.no_toc}
|
||||
|
||||
In the [OSGi Overview article](osgi.html) we have mentioned that a bundle can register, unregister, get and unget services from a central point - the Service Registry.
|
||||
|
||||
In order to simplify the usage of services the [OSGi Alliance](https://www.osgi.org/about-us/) has developed a model of managing services dynamically called _Declarative Services_.
|
||||
|
||||
{::options toc_levels="2"/}
|
||||
|
||||
- TOC
|
||||
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Model & Terms
|
||||
|
||||
|
|
|
@ -5,8 +5,6 @@ title: Event Bus
|
|||
|
||||
# Event Bus
|
||||
|
||||
{:.no_toc}
|
||||
|
||||
The openHAB framework provides an event bus for inter-component communication.
|
||||
The communication is based on events which can be sent and received through the event bus in an asynchronous way.
|
||||
Examples of openHAB event types are _ItemCommandEvent_, _ItemStateEvent_, _ItemAddedEvent_, _ThingStatusInfoEvent_, etc.
|
||||
|
@ -14,10 +12,7 @@ Examples of openHAB event types are _ItemCommandEvent_, _ItemStateEvent_, _ItemA
|
|||
This section introduces the event API and illustrates how to receive such events.
|
||||
Furthermore, the sending of events and the implementation of new event types will be described.
|
||||
|
||||
{::options toc_levels="2,3"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## API Introduction
|
||||
|
||||
|
|
|
@ -5,14 +5,9 @@ title: Internationalization
|
|||
|
||||
# Internationalization
|
||||
|
||||
{:.no_toc}
|
||||
|
||||
In this chapter the openHAB support for internationalization is described.
|
||||
|
||||
{::options toc_levels="2,3"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Folder and File Structure
|
||||
|
||||
|
|
|
@ -10,10 +10,7 @@ Containerization allows one to run a server in its own isolated environment with
|
|||
|
||||
This page is structured as follows:
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Why Docker?
|
||||
|
||||
|
|
|
@ -11,10 +11,7 @@ All instructions can be executed in a terminal or remotely via SSH connection.
|
|||
|
||||
This page is structured as follows:
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
If you are unfamiliar with Linux, SSH and the Linux console or if you want to improve your skills, read up on these important topics.
|
||||
A lot of helpful articles can be found on the internet, for example:
|
||||
|
|
|
@ -7,10 +7,7 @@ title: macOS
|
|||
|
||||
This page is structured as follows:
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
If you're unfamiliar with using the macOS terminal, then feel free to follow the many guides on the internet. For example:
|
||||
|
||||
|
|
|
@ -10,10 +10,7 @@ openHAB has mainly two ways to be accessed:
|
|||
1. Through the command line console, which is done through SSH and thus always authenticated and encrypted. You will find all details about this in the [Console documentation](/docs/administration/console.html).
|
||||
1. Through HTTP(S), which we will look at in the following.
|
||||
|
||||
{::options toc_levels="2..3"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Encrypted Communication
|
||||
|
||||
|
|
|
@ -9,10 +9,7 @@ The following instructions will guide you through the process of setting up open
|
|||
|
||||
This page is structured as follows:
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Preparation of the environment
|
||||
|
||||
|
|
|
@ -7,9 +7,6 @@ title: Help & About Page
|
|||
|
||||
The about page shows general information of your openHAB configuration and allows to configure some client related configuration.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
[[toc]]
|
||||
|
||||
## Top Section
|
||||
|
|
|
@ -35,9 +35,6 @@ Note that there is a tabbar at the bottom that allows you to switch between the
|
|||
|
||||

|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
[[toc]]
|
||||
|
||||
## Bindings
|
||||
|
|
|
@ -8,9 +8,6 @@ title: Automation
|
|||
This is the section to automate openHAB which provides rules, script and a scheduling sectiom.
|
||||
See [What's the Difference Between a Rule, Script, and Schedule?](/docs/tutorial/rules_introduction.html#what-s-the-difference-between-a-rule-script-and-schedule)
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
[[toc]]
|
||||
|
||||
## Rules
|
||||
|
|
|
@ -7,7 +7,6 @@ title: Configuration
|
|||
|
||||
This section allows the configuration of things, items and user interface pages
|
||||
|
||||
- TOC
|
||||
[[toc]]
|
||||
|
||||
Next to the entity the count of that entity is shown, though the Things count is not the number of all configured Things but the count of the Things waiting in the [Inbox](/docs/tutorial/things_simple.html#accept-the-light-bulb-things).
|
||||
|
|
|
@ -7,7 +7,6 @@ title: Other Services
|
|||
|
||||
This is the section of all other services
|
||||
|
||||
- TOC
|
||||
[[toc]]
|
||||
|
||||
## Rule Voice Interpreter
|
||||
|
|
|
@ -7,7 +7,6 @@ title: System Services
|
|||
|
||||
This is the section that of the system services
|
||||
|
||||
- TOC
|
||||
[[toc]]
|
||||
|
||||
## Regional Settings
|
||||
|
|
|
@ -8,10 +8,7 @@ title: Pages - Overview Page
|
|||
MainUI will automatically generate an Overview page (id:overview).
|
||||
This Overview page has four tabs: Overview, Locations, Equipment, and Properties.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Overview Page
|
||||
|
||||
|
|
|
@ -11,10 +11,7 @@ A growing number of very impressive custom widgets have been posted to [Add-ons
|
|||
This page provides just a few examples of custom widgets with an emphasis on the overall approach to developing your own.
|
||||
For a comprehensive reference on creating widgets, please see the [Building Pages]({{base}}/ui/building-pages.html) guide in the docs.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Where to Create Custom Widgets
|
||||
|
||||
|
|
|
@ -7,10 +7,7 @@ title: Getting Started - First Steps
|
|||
|
||||
The following instructions will guide you through the initial steps after first installing openHAB.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Create the Admin User
|
||||
|
||||
|
|
|
@ -9,10 +9,7 @@ As with the Overview Page and individual cards, the way individual Point Items a
|
|||
In general, the steps to do this include navigating to the Item in the Model tree or the Items Settings, clicking on "Add Metadata", and selecting "Default List Widget" to customize how the Item appears in the automatically generated cards on the Overview Page.
|
||||
One can also set the "Default Stand Alone Widget" and "Default Cell Widget" to change how an Item appears in other parts of MainUI.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Expressions
|
||||
|
||||
|
|
|
@ -33,10 +33,7 @@ The semantic model, when set up correctly, will allow openHAB to turn all lights
|
|||
Once created, a model allows one to use [Semantics Actions]({{base}}/configuration/actions.html#semantics) in Rules to e.g. determine the Location of an Item or the related Equipment.
|
||||
This will help one create, generalize, and simplify Rules based on patterns and purpose.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Introduction to the Ontology and Relationships
|
||||
|
||||
|
|
|
@ -11,10 +11,7 @@ Almost everything that can be configured in openHAB can be configured through Ma
|
|||
In addition to being used for the administration of openHAB, MainUI can serve as the interface presented to the users of your home automation system.
|
||||
You can find an example of the MainUI on the [demo page](https://demo.openhab.org/#!/).
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Role Based Access
|
||||
|
||||
|
|
|
@ -18,10 +18,7 @@ Those that are not embedded require the installation and configuration of a sepa
|
|||
|
||||
Note that Persistence only saves Item states.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Persistence Concepts
|
||||
|
||||
|
|
|
@ -9,10 +9,7 @@ Blockly is super powerful and relatively easy to use but at some point there wil
|
|||
Or perhaps the graphical representation is too limiting.
|
||||
For what ever reason, openHAB has you covered with text based Script Actions and Script Conditions.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Languages
|
||||
|
||||
|
|
|
@ -10,10 +10,7 @@ This section describes two ways to build and configure rules without code.
|
|||
Even though you may not be interested in such simple rules, do not skip this section.
|
||||
The concepts presented here will be referred to later on, and the same concepts apply even for text file based rules.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Basic Rules
|
||||
|
||||
|
|
|
@ -22,10 +22,7 @@ Instead it's a higher level example of building a rule step-by-step using Blockl
|
|||
|
||||
For this part of the tutorial we will choose "Design with Blockly".
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Introduction to Blockly
|
||||
|
||||
|
|
|
@ -11,10 +11,7 @@ To create home automation we need to define behaviors.
|
|||
In openHAB behaviors are defined using rules.
|
||||
Almost anything you can think of can be done as long as you have a relevant event to kick it off and access to the data needed to decide what to do.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Event Driven
|
||||
|
||||
|
|
|
@ -21,10 +21,7 @@ Instead, it is publishing metrics regularly on a preconfigured MQTT topic in a s
|
|||
{"light": 5424, "moisture": 30, "temperature": 21.4, "conductivity": 1020, "battery": 100}
|
||||
```
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
|
|
@ -11,10 +11,7 @@ This section will show an example of dealing with a binding where the bridge Thi
|
|||
|
||||
Scenario: you have some Z-Wave devices, including a wall plug and a rollershutter module, and a Z-Wave controller stick connected to the computer running openHAB.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Install the Binding
|
||||
|
||||
|
|
|
@ -20,10 +20,7 @@ This tutorial covers an example of the easiest and most common method for adding
|
|||
Scenario: You have some Philips Hue light bulbs connected to an official Hue bridge.
|
||||
In this case, the Hue binding supports auto-discovery of both the bridge and the bulbs and other devices attached to it.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Install the Binding
|
||||
|
||||
|
|
|
@ -8,10 +8,7 @@ title: Tips and Tricks
|
|||
This section is dedicated to generic tips and tricks to make your use and configuration of openHAB easier.
|
||||
They are discussed in no particular order.
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
## Backups
|
||||
|
||||
|
|
|
@ -16,10 +16,7 @@ Sitemaps are one way to select and compose these elements into a user-oriented r
|
|||
|
||||
This page is structured as follows:
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
[[toc]]
|
||||
|
||||
Sitemaps are text files with the `.sitemap` extension, and are stored in the `$OPENHAB_CONF/sitemaps` directory.
|
||||
Sitemaps follow the syntax described in this article.
|
||||
|
|
Loading…
Reference in New Issue