Apply bulk automated corrections. 🔧(#1433)
Signed-off-by: Jerome Luckenbach <github@luckenba.ch>pull/1436/head
Jerome Luckenbach
GitHub
parent
e879ad83b3
commit
d509fe56d6
|
|
@ -3,5 +3,6 @@
|
|||
"MD004": { "style": "dash" },
|
||||
"MD013": false,
|
||||
"MD025": false,
|
||||
"MD029": { "style": "one" }
|
||||
"MD029": { "style": "one" },
|
||||
"MD041": false
|
||||
}
|
||||
|
|
@ -106,6 +106,7 @@ All HTTP Actions can have a last `timeout` parameter added in ms. eg. `sendHttpP
|
|||
:::
|
||||
|
||||
For example:
|
||||
|
||||
```javascript
|
||||
val headers = newHashMap("Cache-control" -> "no-cache")
|
||||
val output = sendHttpGetRequest("https://example.com/?id=1", headers, 1000)
|
||||
|
|
@ -158,6 +159,7 @@ if ((thingStatusInfo !== null) && (thingStatusInfo.getStatus().toString() == "ON
|
|||
```
|
||||
|
||||
### openHAB Subsystem Actions
|
||||
|
||||
openHAB has several subsystems that can be accessed from Rules. These include persistence, see [Persistence Extensions in Scripts and Rules]({{base}}/configuration/persistence.html#persistence-extensions-in-scripts-and-rules), transformations, scripts.
|
||||
|
||||
- `callScript(String scriptName)`: Calls a script which must be located in the `$OPENHAB_CONF/scripts` folder.
|
||||
|
|
@ -182,6 +184,7 @@ Three different actions are available:
|
|||
- `sendLogNotification(message)`: Sends a log notification to the `notifications` list at your openHAB Cloud instance. Notifications are NOT sent to any registered devices
|
||||
|
||||
For each of the three actions, there's another variant accepting an icon name and a severity:
|
||||
|
||||
- `sendNotification(emailAddress, message, icon, severity)`
|
||||
- `sendBroadcastNotification(message, icon, severity)`
|
||||
- `sendLogNotification(message, icon, severity)`
|
||||
|
|
@ -189,6 +192,7 @@ For each of the three actions, there's another variant accepting an icon name an
|
|||
Icon and severity can potentially be used by cloud instance clients (such as the openHAB apps for Android or iOS) to be displayed in the list of notifications.
|
||||
|
||||
The parameters for these actions have the following meaning:
|
||||
|
||||
- `emailAddress`: String containing the email address the target user is registered with in the cloud instance
|
||||
- `message`: String containing the notification message text
|
||||
- `icon`: String containing the icon name (as described in [Items]({{base}}/configuration/items.html#icons))
|
||||
|
|
@ -294,6 +298,7 @@ dayset-workday=[MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY]
|
|||
dayset-weekend=[SATURDAY,SUNDAY]
|
||||
dayset-trash=[MONDAY]
|
||||
```
|
||||
|
||||
#### Custom Bank Holidays
|
||||
|
||||
In addition to the ability to define custom daysets, one can define a custom list of holidays or other important days.
|
||||
|
|
@ -314,6 +319,7 @@ The following is an example listing a few custom days.
|
|||
</tns:Holidays>
|
||||
</tns:Configuration>
|
||||
```
|
||||
|
||||
For further examples and to find the list of elements to reference holidays that require more complicated calculations (e.g. holidays based on a lunar calendar, Easter, etc.) see the [XSD that defines the structures of the XML](https://github.com/svendiedrichsen/jollyday/blob/b78fa20e75d48bdf14e3fa8107befe44e3bacf3a/src/main/xsd/Holiday.xsd) or the XML file for your country or others.
|
||||
|
||||
You can place these XML files anywhere on your file system that openHAB has permission to read.
|
||||
|
|
|
|||
|
|
@ -99,7 +99,6 @@ binding = astro,mqtt1,network
|
|||
|
||||
After saving the file, the add-on will be installed.
|
||||
|
||||
|
||||
### Through manually provided add-ons
|
||||
|
||||
> Attention:
|
||||
|
|
|
|||
|
|
@ -180,7 +180,6 @@ To enable binding to all interfaces, uncomment the line
|
|||
|
||||
in `services/runtime.cfg`.
|
||||
|
||||
|
||||
### Change the Port Number
|
||||
|
||||
The SSH port configuration is done through the file `org.apache.karaf.shell.cfg`, located in the `etc` directory as [mentioned above](#console-settings-files-and-directories).
|
||||
|
|
|
|||
|
|
@ -18,7 +18,6 @@ It is possible to query and even change the state of entities like items or thin
|
|||
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!
|
||||
:::
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
Query an item's state:
|
||||
|
|
|
|||
|
|
@ -12,7 +12,6 @@ Join today and find answers for all details of openHAB:
|
|||
|
||||
* [community.openhab.org](https://community.openhab.org)
|
||||
|
||||
|
||||
# FAQs - Frequently Asked Questions
|
||||
|
||||
In the community forum you'll also find a list of recurring questions with short answers, commonly known as FAQs.
|
||||
|
|
|
|||
|
|
@ -33,7 +33,6 @@ A typical example of a bridge is an IP gateway for some non-IP based home automa
|
|||
|
||||
As many Things can be automatically discovered, there are special mechanisms available that deal with the handling of [automatically discovered Things](discovery.html).
|
||||
|
||||
|
||||
## Thing Status
|
||||
|
||||
Each Thing has a status object, which helps to identify possible problems with the device or service.
|
||||
|
|
@ -93,4 +92,3 @@ The following table lists the different status details for each status:
|
|||
<tr valign="top"><td>REMOVING</td> <td>NONE</td><td>No further status details available.</td></tr>
|
||||
<tr valign="top"><td>REMOVED</td> <td>NONE</td><td>No further status details available.</td></tr>
|
||||
</table>
|
||||
|
||||
|
|
|
|||
|
|
@ -57,7 +57,6 @@ The placeholder `%unit%` can be placed anywhere in the state description.
|
|||
|
||||
In order to match `NumberItems` and Channels and define a default state description with unit placeholder the Channel also has to provide an Item type which includes the dimension information:
|
||||
|
||||
|
||||
<channel-type id="temperature">
|
||||
<item-type>Number:Temperature</item-type>
|
||||
<label>Temperature</label>
|
||||
|
|
@ -80,7 +79,6 @@ The `org.openhab.core.library.dimension` and `javax.measure.quantity` packages p
|
|||
|
||||
All units which are currently supported by default are listed in the tables below.
|
||||
|
||||
|
||||
Imperial (base unit symbols):
|
||||
|
||||
| Type | Unit | Symbol |
|
||||
|
|
@ -213,6 +211,7 @@ Binary Prefixes:
|
|||
| Yobi | Yi | 2⁸⁰ |
|
||||
|
||||
To use the prefixes simply add the prefix to the unit symbol - for example:
|
||||
|
||||
* milliAmpere - `mA`
|
||||
* centiMetre - `cm`
|
||||
* kiloWatt - `kW`
|
||||
|
|
|
|||
|
|
@ -72,7 +72,6 @@ binding = astro,network
|
|||
|
||||
After saving the file, the add-on will be installed.
|
||||
|
||||
|
||||
## Through manually provided add-ons
|
||||
|
||||
::: warning Attention
|
||||
|
|
|
|||
|
|
@ -27,6 +27,7 @@ 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.
|
||||
|
|
@ -50,6 +51,7 @@ The validation needs a running openHAB installation in your environment and can
|
|||
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,6 +62,7 @@ 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.
|
||||
|
|
@ -85,4 +88,3 @@ You can find the syntax file and installation instructions on [openhab-syntax-te
|
|||
|
||||
BBEdit is a text and code editor for macOS and the offical successor of TextWrangler.
|
||||
You can find the syntax file and installation instructions on [BBEdit-openHAB-language](https://github.com/mjmeijer/BBEdit-openHAB-language).
|
||||
|
||||
|
|
|
|||
|
|
@ -39,6 +39,7 @@ HABPanel uses service configuration variables to store its data on the openHAB s
|
|||
openhab> config:edit org.openhab.habpanel
|
||||
openhab> config:property-get <property>
|
||||
```
|
||||
|
||||
The following properties are defined:
|
||||
|
||||
- `panelsRegistry`: contains the entire registry serialized in JSON, it is maintained by the application and shouldn't be modified directly (editing it by hand, while possible, is strongly discouraged);
|
||||
|
|
@ -58,6 +59,7 @@ Use the gears icon in the top-right corner to switch between the two modes.
|
|||
|
||||
|
||||
When in edit mode, several features are available:
|
||||
|
||||
* Add a new empty dashboard with the **Add new dashboard** link;
|
||||
* Go to the settings screen (for instance, to switch from local storage to a server-managed panel configuration) by clicking on the **Advanced settings** link;
|
||||
* Adjust the number of columns for the grid of main menu tiles with the slider, from 1 (the default) to 6;
|
||||
|
|
@ -126,6 +128,7 @@ Modifications to the dashboard are not saved automatically, use the **Save** but
|
|||
When a dashboard is running, widgets can be interacted with, and server-sent events are received when items' states are updated, so widgets update automatically in HABPanel.
|
||||
|
||||
The icons in the top-right corner perform the following:
|
||||
|
||||
- the **speech balloon** activates the speech recognition feature and send the results as text to openHAB's default human language interpreter. This implies [some configuration on the server]({{base}}/configuration/multimedia.html#human-language-interpreter), and this icon might not be displayed if the browser doesn't support voice recognition ([mainly only in Chrome and other webkit variants currently](https://caniuse.com/#feat=speech-recognition){:target="_blank"}). It can also be configured in the panel configuration to appear on the bottom of the screen;
|
||||
- the **refresh** button forces HABPanel to retrieve the current state of all items;
|
||||
- the **fullscreen** button tells the browser to go fullscreen, if supported.
|
||||
|
|
@ -136,7 +139,6 @@ Tip: while running a dasboard, append `?kiosk=on` to the URL in the web browser
|
|||
|
||||
Apart from the storage configuration discussed above, the settings screen contains several settings kept as part of the panel configuration (meaning they are set separately):
|
||||
|
||||
|
||||
| Setting | Description |
|
||||
|------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Panel name | An user-friendly name for the panel. It will be displayed in the header of the side drawer. |
|
||||
|
|
@ -157,7 +159,6 @@ Apart from the storage configuration discussed above, the settings screen contai
|
|||
|
||||
*Note: the text-to-speech functionality featured in HABPanel is unrelated to the [TTS services]({{base}}/configuration/multimedia.html#text-to-speech) defined on the openHAB server, and they are not compatible (this is why a String item is required and the `say()` function cannot be used). However, HABPanel will play audio streamed through the ['webaudio' sink]({{base}}/configuration/multimedia.html#audio), including spoken text.
|
||||
|
||||
|
||||
## Widgets
|
||||
|
||||
### Standard widgets
|
||||
|
|
|
|||
|
|
@ -168,4 +168,3 @@ Here are some hints to avoid some common pitfalls when starting out.
|
|||
You can use the import function to import `.items` files or snippets taken from other sources like the openHAB community forum.
|
||||
* Use VS code extensions to [edit rules, items and sitemap files](editors.html).
|
||||
You can also use any text editor or cloud based tool, but VS code extensions will work locally and help you by highlighting and cross-checking the file syntax.
|
||||
|
||||
|
|
|
|||
|
|
@ -51,6 +51,7 @@ It's recommended to edit `.items` files using one of the [openHAB supporting edi
|
|||
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:
|
||||
|
|
@ -89,6 +90,7 @@ 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.
|
||||
|
|
@ -145,6 +147,7 @@ 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,6 +202,7 @@ Two naming schemes are established in the community for Group names:
|
|||
| "`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.
|
||||
|
|
@ -215,12 +219,14 @@ Number Livingroom_Temperature "Temperature [%.1f °C]"
|
|||
Channel labels can be overwritten by Item definitions and Item labels can be overwritten in [Sitemaps]({{base}}/configuration/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.
|
||||
|
|
@ -237,6 +243,7 @@ The Binding may also set the state to `UNDEF` if an error exists in the binding
|
|||
*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.
|
||||
|
|
@ -258,6 +265,7 @@ 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.
|
||||
|
|
@ -286,6 +294,7 @@ Location My_Location "My Location [%2$s°N %3$s°E %1$sm]" // e.g.
|
|||
```
|
||||
|
||||
{: #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.
|
||||
|
|
@ -299,6 +308,7 @@ 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.
|
||||
|
|
@ -332,6 +342,7 @@ 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.
|
||||
|
|
@ -403,6 +414,7 @@ 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.
|
||||
|
|
@ -455,6 +467,7 @@ Because of the hierarchical structure of your group items, the rule will be clea
|
|||
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").
|
||||
|
|
@ -518,6 +531,7 @@ 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.
|
||||
|
|
@ -538,6 +552,7 @@ 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.
|
||||
|
|
@ -609,8 +624,8 @@ Switch Office_PC {channel="lgwebos:WebOSTV:01dd3ac4-62f4-7505-208b-12345679", ch
|
|||
|
||||
The first example shows a symbiosis of the LG webOS Binding and the Wake-on-LAN Binding to interact with a TV.
|
||||
|
||||
|
||||
{: #autoupdate}
|
||||
|
||||
#### Parameter `autoupdate`
|
||||
|
||||
When left as default, openHAB's `autoupdate` function attempts to predict the outcome of a *command* on the Item *state*.
|
||||
|
|
@ -626,6 +641,7 @@ 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.
|
||||
|
|
@ -702,6 +718,7 @@ You have an Item called `Bedroom_Light` that is connected to a Hue lamp
|
|||
```java
|
||||
Color Bedroom_Light { channel="hue:0210:1:bulb1:color" }
|
||||
```
|
||||
|
||||
and a [Rule]({{base}}/configuration/rules-dsl.html) to toggle this light with a serial button:
|
||||
|
||||
```java
|
||||
|
|
|
|||
|
|
@ -30,6 +30,7 @@ New APIs are planned to be implemented in the future, which will provide standar
|
|||
:::: tabs
|
||||
|
||||
::: tab JavaScript
|
||||
|
||||
```js
|
||||
'use strict';
|
||||
|
||||
|
|
@ -54,10 +55,11 @@ sRule.setTriggers([
|
|||
|
||||
automationManager.addRule(sRule);
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
|
||||
::: tab Jython
|
||||
|
||||
```python
|
||||
scriptExtension.importPreset("RuleSupport")
|
||||
scriptExtension.importPreset("RuleSimple")
|
||||
|
|
@ -79,9 +81,11 @@ sRule.setTriggers([
|
|||
|
||||
automationManager.addRule(sRule)
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
::: tab Groovy
|
||||
|
||||
```groovy
|
||||
import org.openhab.core.automation.*
|
||||
import org.openhab.core.automation.module.script.rulesupport.shared.simple.*
|
||||
|
|
@ -105,6 +109,7 @@ sRule.setTriggers([
|
|||
|
||||
automationManager.addRule(sRule)
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
::::
|
||||
|
|
|
|||
|
|
@ -67,6 +67,7 @@ The following strategies are defined internally and may be used in place of `str
|
|||
- `restoreOnStartup`: load and initialize the last persisted state of the Item on openHAB startup (if the Item state is undefined (`UNDEF`)).
|
||||
|
||||
#### Cron Persistence Triggers
|
||||
|
||||
openHAB uses [Quartz](https://www.quartz-scheduler.org/documentation) for time-related cron events.
|
||||
See the [Rules article]({{base}}/configuration/rules-dsl.html#time-based-triggers) for more information.
|
||||
|
||||
|
|
@ -151,8 +152,8 @@ Items {
|
|||
item1, item2 : strategy = everyChange, restoreOnStartup
|
||||
}
|
||||
```
|
||||
It is usually not necessary to restore all Items since there is a good chance that they are no longer accurate (switches may have been toggled, sensor values are likely to have changed), and the restoration may result in unwanted rule actions.
|
||||
|
||||
It is usually not necessary to restore all Items since there is a good chance that they are no longer accurate (switches may have been toggled, sensor values are likely to have changed), and the restoration may result in unwanted rule actions.
|
||||
|
||||
## Persistence Extensions in Scripts and Rules
|
||||
|
||||
|
|
|
|||
|
|
@ -97,6 +97,7 @@ Stop openhab and add this part to ```$OPENHAB_USERDATA/etc/org.apache.karaf.feat
|
|||
<feature>openhab-*-auth</feature>
|
||||
</blacklistedFeatures>
|
||||
```
|
||||
|
||||
Once openhab is restarted authentication will be disabled.
|
||||
|
||||
## Additional Considerations
|
||||
|
|
|
|||
|
|
@ -120,6 +120,7 @@ end
|
|||
- `<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,6 +136,7 @@ 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).
|
||||
|
|
@ -153,6 +155,7 @@ When using the `received command` trigger, the Rule might trigger **before** the
|
|||
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.
|
||||
|
|
@ -172,6 +175,7 @@ Also, as with Item event-based triggers, when using `received command`, the Rule
|
|||
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:
|
||||
|
|
@ -195,6 +199,7 @@ A cron expression takes the form of six or optionally seven fields:
|
|||
You may use [CronMaker](https://www.cronmaker.com/) or the generator at [FreeFormatter.com](https://www.freeformatter.com/cron-expression-generator-quartz.html) to generate cron expressions.
|
||||
|
||||
{: #system-based-triggers}
|
||||
|
||||
### System-based Triggers
|
||||
|
||||
Two system-based triggers are provided as described in the table below:
|
||||
|
|
@ -219,6 +224,7 @@ end
|
|||
```
|
||||
|
||||
{: #thing-based-triggers}
|
||||
|
||||
### Thing-based Triggers
|
||||
|
||||
Your rules can take actions based upon status updates or status changes generated by Things.
|
||||
|
|
@ -243,6 +249,7 @@ You need to use quotes around `thingUID` if it contains special characters such
|
|||
:::
|
||||
|
||||
{: #channel-based-triggers}
|
||||
|
||||
### Channel-based Triggers
|
||||
|
||||
Some add-ons provide trigger channels.
|
||||
|
|
@ -279,6 +286,7 @@ 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.
|
||||
|
|
@ -302,6 +310,7 @@ 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.
|
||||
|
|
@ -321,12 +330,14 @@ The following table summarizes the impact of the two manipulator commands on the
|
|||
|
||||
**Beware:**
|
||||
In most cases, a rule with a trigger of `received update` will fire following the command `sendCommand` as:
|
||||
|
||||
- openHAB auto-updates the status of Items for which the item definition does not contain `autoupdate="false"`
|
||||
- the Thing sends a status update to the Item.
|
||||
|
||||
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.
|
||||
|
|
@ -345,6 +356,7 @@ Using `Myitem.sendCommand(new_state)` or `Myitem.postUpdate(new_state)` will, in
|
|||
|
||||
The Action `sendCommand(MyItem, new_state)` does not provide the same flexibilty.
|
||||
For example, if `new_state` is typed as a primitive (e.g., `var int new_state = 3`) and myItem is of the Object type Dimmer:
|
||||
|
||||
* the following command ***will fail***: ~~sendCommand(MyItem, new_state)~~.
|
||||
* However, the following command **will work**: `MyItem.sendCommand(new_state)`.
|
||||
|
||||
|
|
@ -362,6 +374,7 @@ 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
|
||||
|
|
@ -376,6 +389,7 @@ This section differentiates between command type and state type.
|
|||
For ease of reading, it is possible to simply add “type” to the end of a command type thereby obtaining the state type.
|
||||
For example, a Color Item can receive an OnOffType, IncreaseDecreaseType, PercentType, or HSBType.
|
||||
Therefore the following are all valid commands one can send to a Color Item:
|
||||
|
||||
- `MyColorItem.sendCommand(ON)`
|
||||
- `MyColorItem.sendCommand(INCREASE)`
|
||||
- `MyColorItem.sendCommand(new PercentType(50))`
|
||||
|
|
@ -400,6 +414,7 @@ These methods can be called in Rules-DSL without the "get" part in name as in `(
|
|||
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).*
|
||||
|
|
@ -649,7 +664,6 @@ One can convert from ON and OFF to 1 and 0 with code similar to:
|
|||
val SwitchNum = if (MySwitchItem.state == ON) 1 else 0
|
||||
```
|
||||
|
||||
|
||||
#### Deeper Dive
|
||||
|
||||
While interacting with Item states, care must be taken to understand the difference between Objects and primitives.
|
||||
|
|
@ -688,6 +702,7 @@ Each of these separate methods is individually written to handle all of these di
|
|||
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:
|
||||
|
|
@ -700,6 +715,7 @@ Besides the implicitly available variables for items and commands/states, rules
|
|||
- `receivedEvent` - implicitly available in every rule that has a channel-based trigger.
|
||||
|
||||
{: #return}
|
||||
|
||||
### Early returns
|
||||
|
||||
It is possible to return early from a rule, not executing the rest of the statements like this:
|
||||
|
|
@ -714,6 +730,7 @@ 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.
|
||||
|
|
@ -737,6 +754,7 @@ end
|
|||
```
|
||||
|
||||
{: #transformations}
|
||||
|
||||
### Transformations
|
||||
|
||||
openHAB [Transformation services](/addons/#transform) can be used in rules to transform/translate/convert data.
|
||||
|
|
@ -782,8 +800,8 @@ 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.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,6 @@ title: Next-Gen Rules
|
|||
|
||||
Since openHAB 2.4 another Rule Engine has been added. It works fundamentally different than what you find with our current [Rules](https://www.openhab.org/docs/configuration/rules-dsl.html). It allows Rules to be edited in a graphical fashion and to interact with [JSR223 Scripts (Javascript, Jypthon, etc)](https://www.openhab.org/docs/configuration/jsr223.html).
|
||||
|
||||
|
||||
## Installation
|
||||
|
||||
Install the rule engine from Add-ons → Misc → Rule Engine (Experimental).
|
||||
|
|
@ -79,7 +78,6 @@ A given **Module type** has the following elements:
|
|||
defaultValue - default value for the configuration property when not specified in the rule
|
||||
tags - shows how to be considered a given value. For example, as a Temperature
|
||||
|
||||
|
||||
**Output property** has the following metadata:
|
||||
|
||||
name
|
||||
|
|
@ -346,7 +344,6 @@ There are several ways to add new rules:
|
|||
|
||||
`org.openhab.automation.template.TemplateRegistry` - provides functionality to get templates from the Rule Engine.
|
||||
|
||||
|
||||
## Text console commands
|
||||
|
||||
`automation listModuleTypes [-st] <filter>` - lists all Module Types. If filter is present, lists only matching Module Types.
|
||||
|
|
@ -530,7 +527,6 @@ GenericEventTrigger has 3 configuration paramters: `eventTopic`,` eventSource` a
|
|||
]
|
||||
}
|
||||
|
||||
|
||||
### GenericCompareCondition
|
||||
|
||||
This module type is used to compare a value against a configuration property using an operator like `<, >, =`.
|
||||
|
|
@ -590,7 +586,6 @@ and implement the necessary methods for creation of instances of the supported m
|
|||
Another way to extend the supported module types is by defining composite module types as an extension of the system module types.
|
||||
The composite module type wraps one or more instances of a system module type and defines new configuration parameters, inputs and outputs.
|
||||
|
||||
|
||||
{
|
||||
"uid":"ItemStateChangeTrigger",
|
||||
"label":"Item State Trigger",
|
||||
|
|
|
|||
|
|
@ -163,6 +163,7 @@ sitemap demo label="My home automation" {
|
|||
}
|
||||
}
|
||||
```
|
||||
|
||||
UoM = [Units of Measurment]({{base}}/concepts/units-of-measurement.html)
|
||||
|
||||
- Additional parameters such as `mappings` and `valuecolor` are described below.
|
||||
|
|
@ -197,7 +198,6 @@ Default item=<itemname> [label="<labelname>"] [icon="<iconname>"]
|
|||
Presents an Item using the default UI representation specified by the type of the given Item.
|
||||
E.g., a `Dimmer` Item will be represented as a [Slider](#element-type-slider) element while a `Player` Item will be rendered with player button controls (Previous/Pause/Play/Next).
|
||||
|
||||
|
||||
### Element Type 'Text'
|
||||
|
||||
```perl
|
||||
|
|
@ -336,7 +336,6 @@ This element is a combined control for something like a rgb or rgbw light where
|
|||
The down-button decreases brightness to zero and switches the light off. The up-button sets brightness to full but keeps the previous color (hue).
|
||||
The middle button opens an overlay to finetune your color. A color wheel let you pick the hue and a slider allows to set the brightness.
|
||||
|
||||
|
||||
- `sendFrequency` is used to distinguish between long and short button presses in the classic (web) frontend.
|
||||
This parameter defines the interval in milliseconds for sending increase/decrease requests.
|
||||
|
||||
|
|
@ -393,7 +392,7 @@ Image [item=<itemname>] [icon="<iconname>"] url="<url of image>" [label="<labeln
|
|||
|
||||
This element type is able to present an image.
|
||||
The image must be available on a reachable website or webserver without password or access token.
|
||||
Alternatively, the image file (e.g. YourImageFile.png) may be stored locally in the $OPENHAB_CONF/html folder, and will be accessible through the static route, https://<my.openHAB.device>:8080/static/YourImageFile.png.
|
||||
Alternatively, the image file (e.g. YourImageFile.png) may be stored locally in the $OPENHAB_CONF/html folder, and will be accessible through the static route, `https://<my.openHAB.device>:8080/static/YourImageFile.png`.
|
||||
|
||||
- `item` can refer to either an Image Item whose state is the raw data of the image, or a String Item whose state is an URL that points to an image. Some clients may not (yet) consider `item`.
|
||||
- `url` is the default URL from which to retrieve the image, if there is no associated Item or if the associated item's state is not a URL.
|
||||
|
|
@ -499,7 +498,6 @@ Its power state is represented by a binary Switch Item.
|
|||
Its channel number is a discrete number Item that may only be set to one of three states.
|
||||
By using a Switch or Selection element with a mappings array, you can replace these meaningless values with user-friendly descriptions for display on the user interface.
|
||||
|
||||
|
||||
This mapping changes the displayed power state of the TV from "ON" and "OFF" to the more accurate terms, "on" and "standby".
|
||||
Similarly, mapping above changes the numbers "1", "2", and "3" to "DasErste", "BBC One", and "Cartoon Network" respectively.
|
||||
|
||||
|
|
@ -695,7 +693,6 @@ Location Demo_Location "Location [48.858377,2.294486,66.0]"
|
|||
Number Demo_TV_Channel
|
||||
Color Demo_Color
|
||||
|
||||
|
||||
sitemap demo label="My home automation" {
|
||||
Frame label="Date" {
|
||||
Text item=Date label="Today [Monday, 01. Aug. 2016]"
|
||||
|
|
|
|||
|
|
@ -84,7 +84,6 @@ To help organizing your things, you also may define a location (`Location` in th
|
|||
Inside the square brackets configuration parameters of the thing are defined.
|
||||
The type of the configuration parameter is determined by the binding and must be specified accordingly in the DSL.
|
||||
|
||||
|
||||
**Examples:**
|
||||
|
||||
```xtend
|
||||
|
|
|
|||
|
|
@ -34,6 +34,7 @@ These must be inside the XML escape sequence - eg.
|
|||
```<description><![CDATA[ HTML marked up text here ]]></description>```.
|
||||
|
||||
## XML Structure for Configuration Descriptions
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<config-description:config-descriptions
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ title: Bindings
|
|||
{% include base.html %}
|
||||
|
||||
# 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.
|
||||
|
|
@ -19,6 +20,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}
|
||||
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ title: Thing Descriptions
|
|||
{% include base.html %}
|
||||
|
||||
# Binding Definitions
|
||||
|
||||
{:.no_toc}
|
||||
|
||||
In order to work with *Things* and *Channels*, some meta information about them is needed.
|
||||
|
|
@ -14,6 +15,7 @@ These are provided through 'ThingType' and 'ChannelType' definitions,
|
|||
which describe details about their functionality and configuration options.
|
||||
|
||||
{::options toc_levels="2,3"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
|
|
@ -286,6 +288,7 @@ The following XML snippet defines a list of commands:
|
|||
```
|
||||
|
||||
The user interface can use these values to render
|
||||
|
||||
- a drop down and also represent the current state or
|
||||
- as push buttons to simply send a command to the ThingHandler.
|
||||
|
||||
|
|
@ -548,6 +551,7 @@ The label and descriptions for things, channels and config descriptions should f
|
|||
The label should be short so that for most UIs it does not spread across multiple lines.
|
||||
Guideline is 2-3 words with up to 25 chars.
|
||||
Labels should be capitalized using the following rules:
|
||||
|
||||
- Always capitalize the first and the last word.
|
||||
- Lowercase articles, coordinating conjunctions, and prepositions (`a, an, the, and, as, but, by, for, from, in, into, like, near, nor, of, onto, or, out, over, past, so, till, to, up, upon, with, yet`).
|
||||
- Capitalize all other words.
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ title: Equinox
|
|||
{% include base.html %}
|
||||
|
||||
# Equinox
|
||||
|
||||
{:.no_toc}
|
||||
|
||||
[Equinox][Equinox] is considered to be a reference implementation of the [OSGi Core Release 7][OSGi-core].
|
||||
|
|
@ -16,6 +17,7 @@ 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}
|
||||
|
||||
|
|
|
|||
|
|
@ -13,6 +13,7 @@ openHAB is being based on [OSGi][OSGi] and understanding of OSGi modular archite
|
|||
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}
|
||||
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ title: Event Bus
|
|||
{% include base.html %}
|
||||
|
||||
# Event Bus
|
||||
|
||||
{:.no_toc}
|
||||
|
||||
The openHAB framework provides an event bus for inter-component communication.
|
||||
|
|
@ -16,6 +17,7 @@ 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}
|
||||
|
||||
|
|
|
|||
|
|
@ -6,11 +6,13 @@ title: Internationalization
|
|||
{% include base.html %}
|
||||
|
||||
# Internationalization
|
||||
|
||||
{:.no_toc}
|
||||
|
||||
In this chapter the openHAB support for internationalization is described.
|
||||
|
||||
{::options toc_levels="2,3"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ title: Getting Started - Introduction
|
|||
|
||||
{% include base.html %}
|
||||
|
||||
# Welcome!
|
||||
# Welcome
|
||||
|
||||
Welcome to openHAB.
|
||||
We hope that your journey with openHAB is a rewarding one.
|
||||
|
|
@ -30,7 +30,9 @@ Whilst it is possible to mix the two, for example use the UI for things and file
|
|||
To help you choose between the two approaches, the following is a summary of the pros & cons for each:
|
||||
|
||||
### File-based
|
||||
|
||||
Pros:
|
||||
|
||||
- File based has been the only really practical way to define most objects (things excluded) in previous versions, so a lot of examples in the docs and the forum will assume that approach. However, as time passes there will be more and more UI driven examples.
|
||||
- With file based configs it is easier to make bulk changes and bulk updates, to duplicate similar objects, and to separate domains into distinct files.
|
||||
- The config files can be treated as source files, easing backups and version control. Though that does not mean that source control, backups, and version control cannot be done with UI driven configs.
|
||||
|
|
@ -38,13 +40,16 @@ Pros:
|
|||
- Easier to share configurations between multiple openHAB instances.
|
||||
|
||||
Cons:
|
||||
|
||||
- Config files are more prone to errors. The slightest typo leads to a syntax error that could cause the file to become invalid, which will result in everything defined in that file being removed from the system until you fix it.
|
||||
- The syntax for the config files can be a little overwhelming for novice users, as you have to learn and understand the syntax in addition to openHAB concepts and home automation technologies.
|
||||
- You will see most objects defined in files in the UI but you won't be able to edit them (those objects will have a lock besides their name/label :lock:).
|
||||
- You need to sit in front of a computer with access to the files to make changes.
|
||||
|
||||
### UI-driven
|
||||
|
||||
Pros:
|
||||
|
||||
- Easier to understand for novices. The UI assists you with its built in documents and help. There are fewer opportunities to make mistakes since the syntax is almost impossible to get wrong.
|
||||
- All objects can be altered from anywhere the UI can be reached (including on mobile).
|
||||
- Things can be auto-discovered.
|
||||
|
|
@ -53,6 +58,7 @@ Pros:
|
|||
- A backup of the internal database is created on every change.
|
||||
|
||||
Cons:
|
||||
|
||||
- Can be slower to reach one's goal if you already know what you're doing and if there's a lot of bulk changes or duplicating required.
|
||||
- Harder to remove obsolete stuff.
|
||||
- Some things cannot be configured with the UI yet (e.g. persistence).
|
||||
|
|
|
|||
|
|
@ -169,6 +169,7 @@ Since it's linked to the Color channel of the Hue bulb, the light will reflect t
|
|||
Finish adding Equipment and Points from your Things.
|
||||
|
||||
## Retrofitting Existing Items to the Model
|
||||
|
||||
There may be times where a user needs to add existing Items to their model.
|
||||
Perhaps they are migrating from an older version of OH, they did not follow the advice above to start with the model to begin with, or they are following a tutorial or example that doesn't include the model.
|
||||
In this case all is not lost.
|
||||
|
|
@ -178,6 +179,7 @@ Then add the Point as a member of the appropriate Equipment or Location Group.
|
|||
If the Equipment Group doesn't exist yet, create a Group and use the appropriate Equipment semantic tag first and add the Equipment to the appropriate Location Group.
|
||||
|
||||
## Modifying the Model
|
||||
|
||||
As illustrated here, the model consists mainly of Group membership and tags on Items.
|
||||
To change the location of an equipment or room, simply change the parent Group.
|
||||
To change the type of an equipment or point, simply edit the tags.
|
||||
|
|
@ -189,8 +191,8 @@ Where that's not supported, you can make the changes through the Item's Page.
|
|||
This is a table descibing the Equipment types and point class and type to enable display of badges and measurements on the location cards.
|
||||
This is based off the sources linked below.
|
||||
|
||||
- https://github.com/openhab/openhab-webui/blob/master/bundles/org.openhab.ui/web/src/components/cards/glance/location/status-badge.vue#L63
|
||||
- https://github.com/openhab/openhab-webui/blob/master/bundles/org.openhab.ui/web/src/components/cards/glance/location/measurement-badge.vue#L48
|
||||
- <https://github.com/openhab/openhab-webui/blob/master/bundles/org.openhab.ui/web/src/components/cards/glance/location/status-badge.vue#L63>
|
||||
- <https://github.com/openhab/openhab-webui/blob/master/bundles/org.openhab.ui/web/src/components/cards/glance/location/measurement-badge.vue#L48>
|
||||
|
||||
### Badges
|
||||
|
||||
|
|
|
|||
|
|
@ -26,8 +26,10 @@ Note that Persistence only saves Item states.
|
|||
{:toc}
|
||||
|
||||
## Persistence Concepts
|
||||
|
||||
As previously mentioned, Persistence saves Item states.
|
||||
But the question is, when does it save those Item states?
|
||||
|
||||
- Every time the Item changes?
|
||||
- Every time the Item is updated (an update does not necessarily result in the Item changing state)?
|
||||
- Only when the Item receives a command?
|
||||
|
|
@ -41,6 +43,7 @@ One special persistence strategy is `restoreOnStartup` which will update the Ite
|
|||
The good news here is that if you don't know what you may want to use persistence for, you can just keep the defaults and move to the next step.
|
||||
|
||||
## Persistence Configuration
|
||||
|
||||
Each persistence add-on comes with it's own default persistence strategy.
|
||||
See the documentation for the specific persistence add-on for what the default strategy is.
|
||||
This default can be overridden.
|
||||
|
|
@ -54,12 +57,14 @@ One may not even want to save all their Items, or may want to save different Ite
|
|||
For example, a common approach would be to use [`MapDB`]({{base}}/addons/persistence/mapdb/) only for those Items that should be restored on startup, [`rrd4j`]({{base}}/addons/persistence/rrd4j) with an `everyChange` and every minute strategy for number and binary (Switch, Contact) type Items that are to be charted, and [`Influxdb`]({{base}}/addons/persistence/influxdb) with an `everyUpdate` strategy for analysis with external tools.
|
||||
|
||||
## Default Persistence
|
||||
|
||||
openHAB ships with [`rrdj4`]({{base}}/addons/persistence/rrd4j) as the default persistence database and comes with a default persistence strategy of `everyChange`, `everyMinute`, and `restoreOnStartup` for every supported Item.
|
||||
The good thing about `rrd4j` is that the database never grows beyond a given size, so you never have to clean it up.
|
||||
However, the way it achieves this (replacing ten readings with the average of the ten readings as the data gets older) makes the database not work for all Item types.
|
||||
If you need to `restoreOnStartup` unsupported Item types, `MapDB` might be a better choice for you.
|
||||
|
||||
## Why Bother with Persistence?
|
||||
|
||||
The reason one would set up both the Model discussed in the previous tutorial and Persistence is that it will make creating your user interfaces much easier and much more rich.
|
||||
For example, a set of UI pages will be created automatically in MainUI based on the model.
|
||||
And just about anyplace you can interact with an Item in MainUI, there will be an "Analyze" button that will generate a chart based on the data saved in persistence.
|
||||
|
|
|
|||
|
|
@ -22,17 +22,20 @@ Instead, it is publishing metrics regularly on a preconfigured MQTT topic in a s
|
|||
```json
|
||||
{"light": 5424, "moisture": 30, "temperature": 21.4, "conductivity": 1020, "battery": 100}
|
||||
```
|
||||
|
||||
{::options toc_levels="2..4"/}
|
||||
|
||||
- TOC
|
||||
{:toc}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A basic understanding of how MQTT works (HiveMQ provides a good [tutorial](https://www.hivemq.com/blog/mqtt-essentials-part-3-client-broker-connection-establishment/)
|
||||
- An installed and configured MQTT Broker (e.g. Mosquitto, which can be installed through openHABian if that is how you installed openHAB)
|
||||
- A MiFlora device configured to connect to the MQTT Broker, or an MQTT client application (e.g. [MQTT Explorer](https://mqtt-explorer.com/), [MQTT.fx](http://mqttfx.org/) that allows one to publish and subscribe to MQTT topics
|
||||
|
||||
## Install the Binding and Transformation
|
||||
|
||||
This device publishes JSON formatted messages, so we need to install an add-on that can process JSON: the JSONPath Transformation.
|
||||
A Transformation takes incoming data and transformes is somehow.
|
||||
In this case it will extract certain fields from the JSON.
|
||||
|
|
@ -52,6 +55,7 @@ Click on it, then click Install.
|
|||
Wait for it to disappear from the list, then go back twice to return to the main Settings screen.
|
||||
|
||||
## Create the Bridge Thing
|
||||
|
||||
First we need to add the broker, which is a Bridge.
|
||||
Click on Things.
|
||||
|
||||
|
|
@ -68,6 +72,7 @@ If you need credentials to connect to the broker, click on "Show advanced" to re
|
|||
|
||||
|
||||
## Create the Generic MQTT Thing
|
||||
|
||||
Now we have to add the plant sensor itself as a generic Thing.
|
||||
|
||||
On the Things page, first verify that the broker is indeed present and online; if so, click on the blue "+" button then on the MQTT Binding.
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ Scenario: you have some Z-Wave devices, including a wall plug and a rollershutte
|
|||
{:toc}
|
||||
|
||||
## Install the Binding
|
||||
|
||||
From Settings, go to Things, then click the blue "+" button.
|
||||
|
||||
We need to install the Z-Wave binding.
|
||||
|
|
@ -34,6 +35,7 @@ Wait for it to disappear from the list, then go back.
|
|||
|
||||
|
||||
## Create the Bridge Thing
|
||||
|
||||
Click on the new option: Z-Wave Binding.
|
||||
|
||||
Click on Z-Wave Serial Controller to add the controller.
|
||||
|
|
@ -48,6 +50,7 @@ In certain cases, depending on your system, you will be provided with a list of
|
|||
Choose the correct port, alter the name and/or ID of the controller Thing, then click Add in the top-right corner.
|
||||
|
||||
## Discover Things
|
||||
|
||||
Once back on the Things screen, click on the "+" button then on Z-Wave Binding again.
|
||||
Click scan and all the devices already paired with the Zwave controller will be discovered and appear in the Inbox.
|
||||
To pair a new device, while on this screen, perform the procedure specific to the device to include it in your network.
|
||||
|
|
|
|||
|
|
@ -27,7 +27,6 @@ In this case, the Hue binding supports auto-discovery of both the bridge and the
|
|||
- TOC
|
||||
{:toc}
|
||||
|
||||
|
||||
## Install the Binding
|
||||
|
||||
After logging in as an administrator, click on `Settings` from the sidebar, then click on `Things`.
|
||||
|
|
@ -112,6 +111,7 @@ You can either click on an individual thing to see actions related to it, or you
|
|||
|
||||
|
||||
These actions are:
|
||||
|
||||
- Approve: To promote the candidate from the Inbox to a Thing.
|
||||
- Ignore: To hide the candidate from the list (you will be able to see it again and un-ignore it by clicking on "Show ignored" above the list).
|
||||
- Remove: To remove the candidate from the Inbox (it might be detected again later).
|
||||
|
|
|
|||
Loading…
Reference in New Issue