OpenHAB
/
openhab-docs
mirror of https://github.com/openhab/openhab-docs.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update docs for SmartHome namespace change () 

* Update docs for SmartHome namespace change

Also removes pages for the "IoT Marktplace" and "REST Docs" add-ons which no longer exists in OH3.

Signed-off-by: Wouter Born <github@maindrain.net>

* More fixes

Signed-off-by: Wouter Born <github@maindrain.net>

* Fix collateral damage

Signed-off-by: Wouter Born <github@maindrain.net>
pull/1329/head
Wouter Born 2020-12-19 17:01:06 +01:00 committed by GitHub
parent 45748ee18f
commit a0816a331d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
24 changed files with 132 additions and 298 deletions

22
addons/io.md
View File

@ -52,28 +52,6 @@ Detailed instructions and requirements may be found in the corresponding documen
<td>{{ io.description | markdownify }}</td>
</tr>
{% endfor %}
<tr>
<td>
<h4><a href="{{base}}/configuration/restdocs.html">REST API</a></h4>
</td>
<td>
<p>
The REST API can be used to integrate openHAB with other systems, as it allows read access to items and item states, as well as status updates or the sending of commands for items.
It gives access to sitemaps, so that it is the interface to be used by remote user interfaces (e.g. fat clients or JavaScript-based web clients).
The REST API also supports server-push, so you can subscribe on change notification for certain resources.
</p>
</td>
</tr>
<tr>
<td>
<h4><a href="{{base}}/configuration/eclipseiotmarket.html"><img class="logo" src="{{base}}/images/addons/eclipseiotmarketplace.png" title="Eclipse IoT Marketplace" alt="Eclipse IoT Marketplace" /></a></h4>
</td>
<td>
<p>
The <a href="https://marketplace.eclipse.org/taxonomy/term/4988%2C4396/title">Eclipse IoT Marketplace</a> hosts third-party add-ons that can be browsed and installed to openHAB through this integration.
</p>
</td>
</tr>
<tr>
<td>
<h4><a href="http://www.myopenhab.org/" target="_blank"><img class="logo" src="{{base}}/images/addons/ifttt.png" title="IFTTT" alt="IFTTT" /></a></h4>

4
administration/bundles.md
View File

@ -52,13 +52,13 @@ openhab> bundle:list
Bundles are named according to the following convention:
```text
<prefix>-<type>-<id>
<prefix>.<type>.<id>
```
where
- **prefix** is the first element to categorize the bundle.
For addons this is often `openhab` or `esh`.
For addons this is `org.openhab`.
- **type** is the add-on type, e.g. "binding" or "ui"
- **id** is the identifier for this bundle

3
concepts/units-of-measurement.md
View File

@ -68,8 +68,9 @@ In order to match `NumberItems` and Channels and define a default state descript
The state description pattern "%.1f %unit%" describes the value format as floating point with one decimal place and also the special placeholder for the unit.
## Implementing UoM
When creating QuantityType states the framework offers some useful packages and classes:
The `org.openhab.core.library.unit` package contains the classes `SIUnits`, `ImperialUnits` and `SmartHomeUnits` which provide units unique to either of the measurement systems and common units used in both systems.
The `org.openhab.core.library.unit` package contains the classes `SIUnits`, `ImperialUnits` and `Units` which provide units unique to either of the measurement systems and common units used in both systems.
The `MetricPrefix` class provides prefixes like MILLI, CENTI, HECTO, etc. and the `BinaryPrefix` class provides prefixes like KIBI, MEBI, etc. both of which are wrappers to create derived units.

59
configuration/eclipseiotmarket.md
View File

@ -1,59 +0,0 @@
---
layout: documentation
title: Eclipse IoT Marketplace
---
{% include base.html %}
# Eclipse IoT Marketplace Integration
The [Eclipse IoT Marketplace](https://marketplace.eclipse.org/taxonomy/term/4988%2C4396/title) hosts third-party add-ons that can be browsed and installed to openHAB through this integration.
## Installation
Install the market integration from Add-ons → Misc → Eclipse IoT Market.
![iot marketplace addon](images/eclipseiotmarket_addons.png)
## Usage
With the Eclipse IoT Marketplace installed, you will see additional entries in the "Bindings" tab of the Add-ons menu.
As the new entries come with logos and descriptions, the card layout (instead of the list layout, can be selected in the top right) is best for browsing the entries.
To filter the view to show only third-party add-ons from the marketplace, you can simply type "market" in the search bar:
![entries](images/eclipseiotmarket_listings.png)
Simply use the install/uninstall buttons to add or remove add-ons from your installation.
Alternatively add-ons can be installed right from the catalog on the [Eclipse Marketplace website](https://marketplace.eclipse.org/taxonomy/term/4988%2C4396/title).
Drag the "Install" button from the web page to your add-ons page of the Paper UI to initiate installation.
**Attention:**
Please note that after a system upgrade the installed add-ons are lost and you will need to re-install them.
This behavior will be changed in future.
## Configuration
The marketplace integration can be configured to only provide add-ons of certain types (*Note:* Currently only bindings are supported!) and of a certain maturity level.
To do so, you can add a configuration file `$OPENHAB_CONF/services/marketplace.cfg` with content like:
```conf
# whether to show bindings from the marketplace (default is true)
org.eclipse.smarthome.marketplace:bindings=false
# whether to show rule templates from the marketplace (default is true)
org.eclipse.smarthome.marketplace:ruletemplates=true
# possible values for maturity are
# 0 = Alpha
# 1 = Beta
# 2 = Production/Stable
# 3 = Mature
# default is 1
org.eclipse.smarthome.marketplace:maturity=2
```
Alternatively, these settings can also be done through the Paper UI under Configuration → System → Marketplace:
![entries](images/eclipseiotmarket_configuration.png)

10
configuration/jsr223.md
View File

@ -208,10 +208,10 @@ The `default` preset is preloaded, so it does not require importing.
| `PointType` | `org.openhab.core.library.types.PointType` |
| `StringType` | `org.openhab.core.library.types.StringType` |
| `SIUnits` | `org.openhab.core.library.unit.SIUnits` |
| `ImperialUnits` | `org.openhab.core.library.unit.SmartHomeUnits` |
| `MetricPrefix` | `org.openhab.core.library.unit.SmartHomeUnits` |
| `SmartHomeUnits` | `org.openhab.core.library.unit.SmartHomeUnits` |
| `BinaryPrefix` | `org.openhab.core.library.unit.SmartHomeUnits` |
| `ImperialUnits` | `org.openhab.core.library.unit.ImperialUnits` |
| `MetricPrefix` | `org.openhab.core.library.unit.MetricPrefix` |
| `Units` | `org.openhab.core.library.unit.Units` |
| `BinaryPrefix` | `org.openhab.core.library.unit.BinaryPrefix` |
| `items` | Instance of `java.util.Map&lt;String, State&gt;` |
| `ir` | Alias for `itemRegistry` |
| `itemRegistry` | Instance of `org.openhab.core.items.ItemRegistry` |
@ -368,7 +368,7 @@ Read the JSR223 language specific documentation for examples of using these `Tri
| Parameter | Description |
|-----------|-------------|
| `eventTopic` | Default: "smarthome/\*"<br><br>Events can also be filtered, e.g.<br>Item events: "smarthome/items/\*/"<br>Channel events: "smarthome/channels/\*/triggered"<br>Thing events: "smarthome/things/\*/" |
| `eventTopic` | Default: "openhab/\*"<br><br>Events can also be filtered, e.g.<br>Item events: "openhab/items/\*/"<br>Channel events: "openhab/channels/\*/triggered"<br>Thing events: "openhab/things/\*/" |
| `eventSource` | `Item` name, `ChannelUID`, `ThingUID`, etc. |
| `eventTypes` | `ItemCommandEvent`, `ItemStateEvent`, `ItemStateChangedEvent`, `GroupItemStateChangedEvent`, `ItemAddedEvent`, `ItemRemovedEvent`, `ThingAddedEvent`, `ThingRemovedEvent`, `ThingStatusInfoChangedEvent`, `ThingStatusInfoEvent`, `ThingUpdatedEvent`, etc. |
</details>

28
configuration/multimedia.md
View File

@ -9,7 +9,7 @@ title: Multimedia
## Volume
The framework supports some base [functions](https://www.openhab.org/javadoc/v2.5/org/eclipse/smarthome/model/script/actions/audio#method.summary) to control the audio sinks' volume.
The framework supports some base [functions](https://next.openhab.org/javadoc/latest/org/openhab/core/model/script/actions/audio#method.summary) to control the audio sinks' volume.
### Actions
@ -40,7 +40,7 @@ Additionally, certain bindings register their supported devices as audio sinks,
To check, which audio sinks are available, you can use the console:
```text
openhab> smarthome:audio sinks
openhab> openhab:audio sinks
enhancedjavasound
javasound
webaudio
@ -51,14 +51,14 @@ You can define the default audio sink either by textual configuration in `$OPENH
In order to play a sound, you can use the following command on the console:
```text
openhab> smarthome:audio play doorbell.mp3
openhab> openhab:audio play doorbell.mp3
openhab> smarthome:audio stream example.com
openhab> openhab:audio stream example.com
```
### Actions
Alternatively the [`playSound()`](https://www.openhab.org/javadoc/v2.5/org/eclipse/smarthome/model/script/actions/audio#playSound(java.lang.String)) or [`playStream()`](https://www.openhab.org/javadoc/v2.5/org/eclipse/smarthome/model/script/actions/audio#playStream(java.lang.String)) functions can be used in DSL rules:
Alternatively the [`playSound()`](https://next.openhab.org/javadoc/latest/org/openhab/core/model/script/actions/audio#playSound(java.lang.String)) or [`playStream()`](https://next.openhab.org/javadoc/latest/org/openhab/core/model/script/actions/audio#playStream(java.lang.String)) functions can be used in DSL rules:
- `playSound(String filename)` : plays a sound from the sounds folder to the default sink
- `playSound(String filename, PercentType volume)` : plays a sound with the given volume from the sounds folder to the default sink
@ -91,7 +91,7 @@ In order to use text-to-speech, you need to install at least one [TTS service](/
Once you have done so, you will find voices available in your system:
```text
openhab> smarthome:voice voices
openhab> openhab:voice voices
mactts:Jorge Jorge (es_ES)
mactts:Moira Moira (en_IE)
mactts:Alice Alice (it_IT)
@ -104,12 +104,12 @@ You can define a default TTS service and a default voice to use either by textua
In order to say a text, you can enter such a command on the console (The default voice and default audio sink will be used):
```text
openhab> smarthome:voice say Hello world!
openhab> openhab:voice say Hello world!
```
### Actions
Alternatively you can execute such commands within DSL rules by using the [`say()`](https://www.openhab.org/javadoc/v2.5/org/eclipse/smarthome/core/voice/voicemanager#say(java.lang.String)) function:
Alternatively you can execute such commands within DSL rules by using the [`say()`](https://next.openhab.org/javadoc/latest/org/openhab/core/voice/voicemanager#say(java.lang.String)) function:
```java
say("Hello world!")
@ -137,21 +137,21 @@ Human language interpreters are meant to process prose that e.g. is a result of
There are two implementations available by default:
| Interpreter | Type | Description |
|-------------|------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `rulehli` | Rule-based Interpreter | This mimics the behavior of the Android app - it sends the string as a command to a (configurable, default is "VoiceCommand") item and expects a rule to pick it up and further process it. |
| `system` | Built-in Interpreter | This is a simple implementation that understands basic home automation commands like "turn on the light" or "stop the music". It currently supports only English, German and French and the vocabulary is still very limited. The exact syntax still needs to be documented, for the moment you need to refer to the [source code](https://github.com/eclipse/smarthome/blob/master/bundles/core/org.eclipse.smarthome.core.voice/src/main/java/org/eclipse/smarthome/core/voice/internal/text/StandardInterpreter.java#L37). |
| Interpreter | Type | Description |
|-------------|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `rulehli` | Rule-based Interpreter | This mimics the behavior of the Android app - it sends the string as a command to a (configurable, default is "VoiceCommand") item and expects a rule to pick it up and further process it. |
| `system` | Built-in Interpreter | This is a simple implementation that understands basic home automation commands like "turn on the light" or "stop the music". It currently supports only English, German and French and the vocabulary is still very limited. The exact syntax still needs to be documented, for the moment you need to refer to the [source code](https://github.com/openhab/openhab-core/blob/master/bundles/org.openhab.core.voice/src/main/java/org/openhab/core/voice/internal/text/StandardInterpreter.java#L48). |
To test the interpreter, you can enter such a command on the console (assuming you have an item with label 'light'):
```text
openhab> smarthome:voice interpret turn on the light
openhab> openhab:voice interpret turn on the light
```
The default human language interpreter will be used.
In case of interpretation error, the error message will be said using the default voice and default audio sink.
Again, such a command can also be entered within DSL rules (using the [`interpret()`](https://www.openhab.org/javadoc/v2.5/org/eclipse/smarthome/core/voice/voicemanager#interpret(java.lang.String)) function)
Again, such a command can also be entered within DSL rules (using the [`interpret()`](https://next.openhab.org/javadoc/latest/org/openhab/core/voice/voicemanager#interpret(java.lang.String)) function)
```java
interpret("turn on the light")

81
configuration/restdocs.md
View File

@ -1,81 +0,0 @@
---
layout: documentation
title: openHAB REST API
---
{% include base.html %}
# openHAB REST API
Through the openHAB [REST API](https://en.wikipedia.org/wiki/REST_API) most aspects of the openHAB system can be readily accessed by other programs.
This includes for example, the access to all data related to Items, Things and Bindings as well as the capabilities to invoke actions that can change the state of Items or influence the behavior of other elements of openHAB.
Interactions with the REST API are based on the http protocol.
Access over the Internet to the REST API is possible, but this represents a significant security risk.
Users are encouraged to [ensure safe and secure connections](http://docs.openhab.org/installation/security.html).
Be aware that the documentation of the REST API may not be automatically installed, but once installed it is accessible through the openHAB dashboard.
## REST API Examples
- Retrieve openHAB data from external applications
- Inject data and trigger events in openHAB from external applications (for example, some motion detectors or surveillance cameras)
- Inspect openHAB Bindings/Things or Items, learn about current states, parameters or problems
- Interacting with openHAB from other programs; many programming languages and automation tools can easily make use of REST API
- Using third party software on cell phones, such as tasker to [open your garage door](https://community.openhab.org/t/triggering-items-using-openhab-2s-rest-api-from-tasker/14027)
The openHAB REST API is excellently documented with detailled use instructions.
It would vastly exceed this space to present all possible examples.
Nevertheless, here is some examples using [curl](https://en.wikipedia.org/wiki/CURL), a common command line tool available for many platforms:
- Switching ```My_Item``` OFF by issuing an http [POST](https://en.wikipedia.org/wiki/POST_(HTTP)) request:
```java
curl -X POST --header "Content-Type: text/plain" --header "Accept: application/json" -d "OFF" "http://{openHAB_IP}:8080/rest/items/My_Item"
```
- Setting a Contact item ```My_Item``` to CLOSED by issuing an http PUT request to ```My_Item/state```:
```java
curl -X PUT --header "Content-Type: text/plain" --header "Accept: application/json" -d "CLOSED" "http://{openHAB_IP}:8080/rest/items/My_Item/state"
```
- Retrieving a list of all Items and Groups by issuing a GET request:
```java
curl -X GET --header "Accept: application/json" "http://{openHAB_IP}:8080/rest/items?recursive=false"
```
- Retrieving a list of all sitemaps by issuing a GET request:
```java
curl -X GET --header "Accept: application/json" "http://{openHAB_IP}:8080/rest/sitemaps"
```
- Subscription to events:
```java
// ThingStatusInfoChangedEvent - The status of a thing changed.
curl "http://{openHAB_IP}:8080/rest/events?topics=smarthome/things/{thingUID}/statuschanged"
// ChannelTriggeredEvent - A channel has been triggered.
curl "http://{openHAB_IP}:8080/rest/events?topics=smarthome/channels/{channelUID}/triggered"
```
The commands above have been copied from the REST API documentation for illustration.
## REST API documentation
The REST API documentation is available on your openHAB installation as a custom user interface.
You can add it by opening the PaperUI interace, clicking "Add-ons", selecting "USER INTERFACES".
You will see an addon called "REST Documentation" that can be easily installed.
On the welcome screen of openHAB, you will now see a new interface called "REST API" where you can easily see the documentation of the REST API and test it!
All available commands will be displayed in the REST API documentation as a response to the button "Try me out" (may require some user input for mandatory fields).
## Additional Considerations
The REST API also supports server-push supporting subscriptions on change notification for certain resources.
One final remark - when openHAB's REST API is accessed from another domain the following error may be encountered: [No 'Access-Control-Allow-Origin' header is present on the requested resource](https://community.openhab.org/t/cors-problem-at-rest-api/3712/10).
In this case, it may be necessary to add the line `org.openhab.cors:enable=true` in the file `services/runtime.cfg`.

2
configuration/rules-dsl.md
View File

@ -376,7 +376,7 @@ There are two ways to discover these methods:
- Use the [openHAB VS Code Extension](/docs/configuration/editors.html#editors.html#openhab-vs-code-extension) and the `<ctrl><space>` key combo to list all the available methods
- Look at the JavaDocs for the given type.
For example, the [JavaDoc for HSBType](https://www.openhab.org/javadoc/v2.5/org/eclipse/smarthome/core/library/types/hsbtype) shows getRed, getBlue, and getGreen methods.
For example, the [JavaDoc for HSBType](https://next.openhab.org/javadoc/latest/org/openhab/core/library/types/hsbtype) shows getRed, getBlue, and getGreen 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.

38
configuration/rules-ng.md
View File

@ -297,7 +297,7 @@ The types in the **Configuration** object are restricted to the following:
There are several ways to add new rules:
* using **JAVA API** from package: **org.openhab.automation.api**;
* using **text console commands: smarthome automation**;
* using **text console commands: openhab:automation**;
* using **resource bundles** that provide moduletypes, rules and rule templates stored in **.json** files;
* using **REST API** - see the next chapter bellow.
@ -384,11 +384,11 @@ There are several ways to add new rules:
Bundles that provide rules in json format should have the following folder structure:
`ESH-INF\automation\moduletypes` - folder for .json files with module types;
`OH-INF\automation\moduletypes` - folder for .json files with module types;
`ESH-INF\automation\rules` - folder for .json files with rule instances;
`OH-INF\automation\rules` - folder for .json files with rule instances;
`ESH-INF\automation\templates` - folder for .json files with rule templates.
`OH-INF\automation\templates` - folder for .json files with rule templates.
## Rule Templates
@ -489,20 +489,20 @@ The above example uses two rule configuration properties:
GenericEventTrigger has 3 configuration paramters: `eventTopic`,` eventSource` and `eventTypes` and one output: 'event'.
{
{
"uid":"GenericEventTrigger",
"label":"Basic Event Trigger",
"description":"Triggers Rules on Events",
"configDescriptions":[
{
{
"name":"eventTopic",
"type":"TEXT",
"label":"Topic",
"description":"This is the topic, the trigger will listen to: >>smarthome/*<<",
"description":"This is the topic, the trigger will listen to: >>openhab/*<<",
"required":true,
"defaultValue":"smarthome/*"
"defaultValue":"openhab/*"
},
{
{
"name":"eventSource",
"type":"TEXT",
"label":"Source",
@ -510,7 +510,7 @@ GenericEventTrigger has 3 configuration paramters: `eventTopic`,` eventSource` a
"required":true,
"defaultValue":""
},
{
{
"name":"eventTypes",
"type":"TEXT",
"label":"Event Type",
@ -519,8 +519,8 @@ GenericEventTrigger has 3 configuration paramters: `eventTopic`,` eventSource` a
"defaultValue":""
}
],
"outputs":[
{
"outputs":[
{
"name":"event",
"type":"org.openhab.core.events.Event",
"label":"Event",
@ -591,12 +591,12 @@ Another way to extend the supported module types is by defining composite module
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",
"description":"This triggers a rule if an items state changed",
"configDescriptions":[
{
{
"name":"itemName",
"type":"TEXT",
"context":"item",
@ -605,19 +605,19 @@ The composite module type wraps one or more instances of a system module type an
"required":true
}
],
"children":[
{
"children":[
{
"id":"itemStateChangeTriggerID",
"type":"GenericEventTrigger",
"configuration":{
"eventSource":"$itemName",
"eventTopic":"smarthome/items/*",
"eventTopic":"openhab/items/*",
"eventTypes":"ItemStateEvent"
}
}
],
"outputs":[
{
"outputs":[
{
"name":"event",
"type":"org.openhab.core.events.Event",
"description":"the event of the item state change",

2
configuration/sitemaps.md
View File

@ -85,7 +85,7 @@ openHAB supports these dependencies by providing parameters for dynamic behavior
Be sure to check out the [Dynamic Sitemaps](#dynamic-sitemaps) chapter.
For the technically interested: The Sitemap definition language is an
Xtext Domain Specific Language and the sitemap file model can be found [here](https://github.com/eclipse/smarthome/blob/master/bundles/model/org.eclipse.smarthome.model.sitemap/src/org/eclipse/smarthome/model/Sitemap.xtext).
Xtext Domain Specific Language and the sitemap file model can be found [here](https://github.com/openhab/openhab-core/blob/master/bundles/org.openhab.core.model.sitemap/src/org/openhab/core/model/sitemap/Sitemap.xtext).
### Special Element 'sitemap'

10
developers/bindings/binding-xml.md
View File

@ -7,14 +7,14 @@ title: Binding Descriptions
Every binding has to provide meta information such as binding id or name.
Background information: The meta information of all bindings is accessible through the `org.eclipse.smarthome.core.binding.BindingInfoRegistry` service.
Background information: The meta information of all bindings is accessible through the `org.openhab.core.binding.BindingInfoRegistry` service.
Although binding definitions are usually specified in a declarative way (as described in this section),
they can also be provided as `org.eclipse.smarthome.core.binding.BindingInfo`.
they can also be provided as `org.openhab.core.binding.BindingInfo`.
Any `BindingInfo` must be registered as service at the *OSGi* service registry.
The full Java API for binding definitions can be found in the Java package `org.eclipse.smarthome.core.binding`.
The full Java API for binding definitions can be found in the Java package `org.openhab.core.binding`.
For the declarative way, you add your binding information in form of a `binding.xml` file to the bundle's folder `/src/main/resources/ESH-INF/binding/binding.xml`.
For the declarative way, you add your binding information in form of a `binding.xml` file to the bundle's folder `/src/main/resources/OH-INF/binding/binding.xml`.
### XML Structure for Binding Definitions
@ -52,7 +52,7 @@ For the declarative way, you add your binding information in form of a `binding.
| config-description-ref.uri | The URI of the configuration description for the binding within the ConfigDescriptionRegistry | mandatory |
The full XML schema for binding definitions is specified in the [ESH binding XSD](https://openhab.org/schemas/binding-1.0.0.xsd) file.
The full XML schema for binding definitions is specified in the [Binding XSD](https://openhab.org/schemas/binding-1.0.0.xsd) file.
**Hints:**

10
developers/bindings/config-xml.md
View File

@ -9,14 +9,14 @@ title: Configuration Descriptions
Specific services or bindings usually require a configuration to be operational in a meaningful way.
To visualize or validate concrete configuration properties, configuration descriptions should be provided.
All available configuration descriptions are accessible through the `org.eclipse.smarthome.config.core.ConfigDescriptionRegistry` service.
All available configuration descriptions are accessible through the `org.openhab.core.config.core.ConfigDescriptionRegistry` service.
Although configuration descriptions are usually specified in a declarative way (as described in this section), they can also be provided as `org.eclipse.smarthome.config.core.ConfigDescriptionProvider`.
Although configuration descriptions are usually specified in a declarative way (as described in this section), they can also be provided as `org.openhab.core.config.core.ConfigDescriptionProvider`.
Any `ConfigDescriptionProvider`s must be registered as service at the *OSGi* service registry.
The full Java API for configuration descriptions can be found in the Java package `org.eclipse.smarthome.config.core`.
In addition to this there is a `org.eclipse.smarthome.config.core.validation.ConfigDescriptionValidator` that can be used to validate a set of configuration parameters against their declarations in the configuration description before the actual configuration is updated with the new configuration parameters.
The full Java API for configuration descriptions can be found in the Java package `org.openhab.core.config.core`.
In addition to this there is a `org.openhab.core.config.core.validation.ConfigDescriptionValidator` that can be used to validate a set of configuration parameters against their declarations in the configuration description before the actual configuration is updated with the new configuration parameters.
Configuration descriptions must be placed as XML file(s) (with the ending `.xml`) in the bundle's folder `/ESH-INF/config/`.
Configuration descriptions must be placed as XML file(s) (with the ending `.xml`) in the bundle's folder `/OH-INF/config/`.
## Formatting Labels

4
developers/bindings/faq.md
View File

@ -27,10 +27,10 @@ Shall I design this as one Thing or as a Bridge with multiple Things for the dif
If your system does not provide you any possibility to get hold of such information, but rather only shows you a "logical" view of it, then 1) is also a valid option to pursue.
2. _Do I have to create XML files in `ESH-INF/thing` for all devices or is there any other option?_
2. _Do I have to create XML files in `OH-INF/thing` for all devices or is there any other option?_
No, the XML files are only one way to describe your devices.
Alternatively, you can implement your own [ThingTypeProvider](https://github.com/eclipse/smarthome/blob/master/bundles/core/org.eclipse.smarthome.core.thing/src/main/java/org/eclipse/smarthome/core/thing/binding/ThingTypeProvider.java), through which you can provide thing descriptions in a programmatic way.
Alternatively, you can implement your own [ThingTypeProvider](https://github.com/openhab/openhab-core/blob/master/bundles/org.openhab.core.thing/src/main/java/org/openhab/core/thing/binding/ThingTypeProvider.java), through which you can provide thing descriptions in a programmatic way.
Nonetheless, the static XML descriptions of thing types can be picked up for documentation generation and other purposes.
So whenever possible, static XML descriptions should be provided.

14
developers/bindings/index.md
View File

@ -193,9 +193,9 @@ For example, the Yahoo Weather binding allows configuration of the location and
If you would like to add meta data to your thing, e.g. the vendor of the thing, then you can define your own thing properties by simply adding them to the thing type definition.
The properties section [here](thing-definition.html#Properties) explains how to specify such properties.
To retrieve the properties one can call the operation `getProperties` of the corresponding `org.eclipse.smarthome.core.thing.type.ThingType` instance.
To retrieve the properties one can call the operation `getProperties` of the corresponding `org.openhab.core.thing.type.ThingType` instance.
If a thing will be created for this thing type then its properties will be automatically copied into the new thing instance.
Therefore the `org.eclipse.smarthome.core.thing.Thing` interface also provides the `getProperties` operation to retrieve the defined properties.
Therefore the `org.openhab.core.thing.Thing` interface also provides the `getProperties` operation to retrieve the defined properties.
In contrast to the `getProperties` operation of the thing type instance the result of the thing´s `getProperties` operation will also contain the properties updated during runtime (cp. the thing handler [documentation](thing-handler.html)).
### Handling Commands
@ -525,19 +525,19 @@ Each entity that has a configuration can provide its current configuration statu
This information is available to user-interfaces to present configuration errors to the user.
For this purpose the handler of the entity implements the interface `org.eclipse.smarthome.config.core.status.ConfigStatusProvider`.
For this purpose the handler of the entity implements the interface `org.openhab.core.config.core.status.ConfigStatusProvider`.
### Providing the Configuration Status
A *ThingHandler* as handler for the thing entity can provide the configuration status of the thing by implementing the `org.eclipse.smarthome.config.core.status.ConfigStatusProvider` interface.
A *ThingHandler* as handler for the thing entity can provide the configuration status of the thing by implementing the `org.openhab.core.config.core.status.ConfigStatusProvider` interface.
For things that are created by sub-classes of the `BaseThingHandlerFactory` the provider is already automatically registered as an OSGi service if the concrete thing handler implements the configuration status provider interface.
Currently the framework provides two base thing handler implementations for the configuration status provider interface:
* `org.eclipse.smarthome.core.thing.binding.ConfigStatusThingHandler` extends the `BaseThingHandler` and is to be used if the configuration status is to be provided for thing entities
* `org.eclipse.smarthome.core.thing.binding.ConfigStatusBridgeHandler` extends the `BaseBridgeHandler` and is to be used if the configuration status is to be provided for bridge entities
* `org.openhab.core.thing.binding.ConfigStatusThingHandler` extends the `BaseThingHandler` and is to be used if the configuration status is to be provided for thing entities
* `org.openhab.core.thing.binding.ConfigStatusBridgeHandler` extends the `BaseBridgeHandler` and is to be used if the configuration status is to be provided for bridge entities
Sub-classes of these handlers must only override the operation `getConfigStatus` to provide the configuration status in form of a collection of `org.eclipse.smarthome.config.core.status.ConfigStatusMessage`s.
Sub-classes of these handlers must only override the operation `getConfigStatus` to provide the configuration status in form of a collection of `org.openhab.core.config.core.status.ConfigStatusMessage`s.
#### Internationalization

10
developers/bindings/thing-xml.md
View File

@ -19,9 +19,9 @@ which describe details about their functionality and configuration options.
## ThingTypeProvider / ChannelTypeProvider
Technically, the thing types are provided by `ThingTypeProvider`s (`org.eclipse.smarthome.core.thing.binding.ThingTypeProvider`).
Technically, the thing types are provided by `ThingTypeProvider`s (`org.openhab.core.thing.binding.ThingTypeProvider`).
openHAB comes with an implementation of such a provider that reads XML files from the folder `ESH-INF/thing` of bundles.
openHAB comes with an implementation of such a provider that reads XML files from the folder `OH-INF/thing` of bundles.
Although we refer to this XML syntax in the following, you also have the option to provide directly object model instances through your own provider implementation.
The same applies for the channel types.
@ -607,10 +607,10 @@ Every binding has to provide meta information about which bridges and/or *Thing*
In that way a binding could describe that it requires specific bridges to be operational or define which channels (e.g. temperature, color, etc.) it provides.
Every bridge or *Thing* has to provide meta information such as label or description.
The meta information of all bridges and *Thing*s is accessible through the `org.eclipse.smarthome.core.thing.binding.ThingTypeProvider` service.
The meta information of all bridges and *Thing*s is accessible through the `org.openhab.core.thing.binding.ThingTypeProvider` service.
Bridge and *Thing* descriptions must be placed as XML file(s) (with the ending `.xml`) in the bundle's folder `/ESH-INF/thing/`.
The full Java API for bridge and *Thing* descriptions can be found in the Java package `org.eclipse.smarthome.core.thing.type`.
Bridge and *Thing* descriptions must be placed as XML file(s) (with the ending `.xml`) in the bundle's folder `/OH-INF/thing/`.
The full Java API for bridge and *Thing* descriptions can be found in the Java package `org.openhab.core.thing.type`.
### XML Structure for Thing Descriptions

6
developers/extensionservices/index.md
View File

@ -8,14 +8,14 @@ title: Extension service
# Extension service
openHAB comes with an API that allows implementing a service that manages the installed extensions within a solution.
All that needs to be done is to register an OSGi service that implements `org.eclipse.smarthome.core.extension.ExtensionService`.
All that needs to be done is to register an OSGi service that implements `org.openhab.core.extension.ExtensionService`.
Such a service has to provide a list of available extensions and then can be called in order to install and uninstall them.
What kind of implementation is chosen is completely up to the solution.
Suitable mechanisms might be Apache Felix FileInstall, Apache Karaf FeatureInstaller, etc.
For testing purposes, openHAB comes with a sample implementation in the bundle `org.eclipse.smarthome.core.extension.sample`.
For testing purposes, openHAB comes with a sample implementation in the bundle `org.openhab.core.extension.sample`.
Installation and uninstallation requests are executed by a thread pool named "extensionService".
If an implementation does not support concurrent execution of such operations, the thread pool size should be set to 1.
TODO
TODO

2
developers/guidelines.md
View File

@ -32,7 +32,7 @@ The structure of a binding follows the structure of a typical OSGi bundle projec
|-------- feature.xml Your OSGI feature file
|---- java Your Java code
|-------- org/openhab/[...]
|- src/main/resources/ESH-INF
|- src/main/resources/OH-INF
|---- binding
|-------- binding.xml Binding name, description, author and other meta data
|---- config Configuration description files when not in things files

6
developers/module-types/index.md
View File

@ -46,7 +46,7 @@ public class MyModuleTypeProvider implements ModuleTypeProvider {
private Map<String, ModuleType> providedModuleTypes;
public MyModuleTypeProvider() {
providedModuleTypes = new HashMap<String, ModuleType>();
providedModuleTypes = new HashMap<>();
providedModuleTypes.put(TemperatureTriggerType.UID, TemperatureTriggerType.initialize());
providedModuleTypes.put(PresenceConditionType.UID, PresenceConditionType.initialize());
providedModuleTypes.put(AirConditionerActionType.UID, AirConditionerActionType.initialize());
@ -231,7 +231,7 @@ You will learn an easier way in a moment for statically defined module types
In the last section we learned about the programmatic way of exposing *Module Types*.
It is actually way easier to just descripe your module types in a declarative way via json and bundle them with your addon.
To describe your modules (triggers, conditions, actions), add json files to `src/main/resources/ESH-INF/automation/moduletypes/`.
To describe your modules (triggers, conditions, actions), add json files to `src/main/resources/OH-INF/automation/moduletypes/`.
A module type file can contain one or multiple type descriptions.
For our scenario we go with one file:
@ -635,4 +635,4 @@ like triggering on an item state change or post a command as an action.
Please discover existing module types on your own from within the user interfaces
and by consulting our user documentation.
For rule templates you may just ask in our friendly community or extend this document.
For rule templates you may just ask in our friendly community or extend this document.

20
developers/tests.md
View File

@ -51,11 +51,8 @@ public class MyBindingHandlerTest {
private ThingHandler handler;
@Mock
private ThingHandlerCallback callback;
@Mock
private Thing thing;
private @Mock ThingHandlerCallback callback;
private @Mock Thing thing;
@Before
public void setUp() {
@ -150,14 +147,14 @@ import static org.mockito.MockitoAnnotations.initMocks;
import java.util.ArrayList;
import java.util.List;
import org.eclipse.smarthome.core.items.Item;
import org.eclipse.smarthome.core.items.ItemProvider;
import org.eclipse.smarthome.core.items.ItemRegistry;
import org.eclipse.smarthome.core.library.items.SwitchItem;
import org.eclipse.smarthome.test.java.JavaOSGiTest;
import org.junit.Before;
import org.junit.Test;
import org.mockito.Mock;
import org.openhab.core.items.Item;
import org.openhab.core.items.ItemProvider;
import org.openhab.core.items.ItemRegistry;
import org.openhab.core.library.items.SwitchItem;
import org.openhab.test.java.JavaOSGiTest;
import com.google.common.collect.Lists;
@ -166,8 +163,7 @@ public class JavaItemRegistryOSGiTest extends JavaOSGiTest {
private static String ITEM_NAME = "switchItem";
private ItemRegistry itemRegistry;
@Mock
private ItemProvider itemProvider;
private @Mock ItemProvider itemProvider;
@Before
public void setUp() {

2
developers/transformations/index.md
View File

@ -28,7 +28,7 @@ your needs like `AbstractFileTransformationService`.
```java
@NonNullByDefault
@Component(immediate = true, property = { "smarthome.transform=BRO" })
@Component(immediate = true, property = { "openhab.transform=BRO" })
public class TheBroTransformationService implements TransformationService {
private final Logger logger = LoggerFactory.getLogger(TheBroTransformationService.class);

81
developers/utils/events.md
View File

@ -40,7 +40,7 @@ The payloads of the openHAB core events are serialized with JSON.
Each event implementation provides the payload as high level methods as well, usually presented by a data transfer object (DTO).
A topic clearly defines the target of the event and its structure is similar to a REST URI, except the last part, the action.
The topics of openHAB events are divided into the following four parts: `{namespace}/{entityType}/{entity}/{action}`, e.g. `smarthome/items/{itemName}/command`.
The topics of openHAB events are divided into the following four parts: `{namespace}/{entityType}/{entity}/{action}`, e.g. `openhab/items/{itemName}/command`.
The type of an event is represented by a string, usually the name of the concrete event implementation class, e.g. `ItemCommandEvent`, `ItemUpdatedEvent` .
This string type presentation is used by event subscribers for event subscription (see chapter "Receive Events") and by the framework for the creation of concrete event instances.
@ -49,16 +49,16 @@ The event source is optional and represents the name of the source identifying t
#### Item Events
| Event | Description | Topic |
|----------------------------|---------------------------------------------------------|------------------------------------------------------|
| ItemAddedEvent | An item has been added to the item registry. | smarthome/items/{itemName}/added |
| ItemRemovedEvent | An item has been removed from the item registry. | smarthome/items/{itemName}/removed |
| ItemUpdatedEvent | An item has been updated in the item registry. | smarthome/items/{itemName}/updated |
| ItemCommandEvent | A command is sent to an item via a channel. | smarthome/items/{itemName}/command |
| ItemStateEvent | The state of an item is updated. | smarthome/items/{itemName}/state |
| ItemStatePredictedEvent | The state of an item predicted to be updated. | smarthome/items/{itemName}/statepredicted |
| ItemStateChangedEvent | The state of an item has changed. | smarthome/items/{itemName}/statechanged |
| GroupItemStateChangedEvent | The state of a group item has changed through a member. | smarthome/items/{itemName}/{memberName}/statechanged |
| Event | Description | Topic |
|----------------------------|---------------------------------------------------------|----------------------------------------------------|
| ItemAddedEvent | An item has been added to the item registry. | openhab/items/{itemName}/added |
| ItemRemovedEvent | An item has been removed from the item registry. | openhab/items/{itemName}/removed |
| ItemUpdatedEvent | An item has been updated in the item registry. | openhab/items/{itemName}/updated |
| ItemCommandEvent | A command is sent to an item via a channel. | openhab/items/{itemName}/command |
| ItemStateEvent | The state of an item is updated. | openhab/items/{itemName}/state |
| ItemStatePredictedEvent | The state of an item predicted to be updated. | openhab/items/{itemName}/statepredicted |
| ItemStateChangedEvent | The state of an item has changed. | openhab/items/{itemName}/statechanged |
| GroupItemStateChangedEvent | The state of a group item has changed through a member. | openhab/items/{itemName}/{memberName}/statechanged |
::: tip Note
The `ItemStateEvent` is always sent if the state of an item is updated, even if the state did not change.
@ -71,13 +71,13 @@ It contains the old and the new state of the group item as well as the member.
#### Thing Events
| Event | Description | Topic |
|-----------------------------|---------------------------------------------------|-------------------------------------------|
| ThingAddedEvent | A thing has been added to the thing registry. | smarthome/things/{thingUID}/added |
| ThingRemovedEvent | A thing has been removed from the thing registry. | smarthome/things/{thingUID}/removed |
| ThingUpdatedEvent | A thing has been updated in the thing registry. | smarthome/things/{thingUID}/updated |
| ThingStatusInfoEvent | The status of a thing is updated. | smarthome/things/{thingUID}/status |
| ThingStatusInfoChangedEvent | The status of a thing changed. | smarthome/things/{thingUID}/statuschanged |
| Event | Description | Topic |
|-----------------------------|---------------------------------------------------|-----------------------------------------|
| ThingAddedEvent | A thing has been added to the thing registry. | openhab/things/{thingUID}/added |
| ThingRemovedEvent | A thing has been removed from the thing registry. | openhab/things/{thingUID}/removed |
| ThingUpdatedEvent | A thing has been updated in the thing registry. | openhab/things/{thingUID}/updated |
| ThingStatusInfoEvent | The status of a thing is updated. | openhab/things/{thingUID}/status |
| ThingStatusInfoChangedEvent | The status of a thing changed. | openhab/things/{thingUID}/statuschanged |
::: tip Note
The `ThingStatusInfoEvent` is always sent if the status info of a thing is updated, even if the status did not change.
@ -87,29 +87,28 @@ It contains the old and the new status of the thing.
#### Inbox Events
| Event | Description | Topic |
|-----------------------|-----------------------------------------------------|------------------------------------|
| InboxAddedEvent | A discovery result has been added to the inbox. | smarthome/inbox/{thingUID}/added |
| InboxRemovedEvent | A discovery result has been removed from the inbox. | smarthome/inbox/{thingUID}/removed |
| InboxUpdateEvent | A discovery result has been updated in the inbox. | smarthome/inbox/{thingUID}/updated |
| Event | Description | Topic |
|-----------------------|-----------------------------------------------------|----------------------------------|
| InboxAddedEvent | A discovery result has been added to the inbox. | openhab/inbox/{thingUID}/added |
| InboxRemovedEvent | A discovery result has been removed from the inbox. | openhab/inbox/{thingUID}/removed |
| InboxUpdateEvent | A discovery result has been updated in the inbox. | openhab/inbox/{thingUID}/updated |
#### Link Events
| Event | Description | Topic |
|-----------------------------|----------------------------------------------------------|-------------------------------------------------|
| ItemChannelLinkAddedEvent | An item channel link has been added to the registry. | smarthome/links/{itemName}-{channelUID}/added |
| ItemChannelLinkRemovedEvent | An item channel link has been removed from the registry. | smarthome/links/{itemName}-{channelUID}/removed |
| Event | Description | Topic |
|-----------------------------|----------------------------------------------------------|-----------------------------------------------|
| ItemChannelLinkAddedEvent | An item channel link has been added to the registry. | openhab/links/{itemName}-{channelUID}/added |
| ItemChannelLinkRemovedEvent | An item channel link has been removed from the registry. | openhab/links/{itemName}-{channelUID}/removed |
#### Channel Events
| Event | Description | Topic |
|-----------------------------|----------------------------------------------------------|-------------------------------------------------|
| ChannelTriggeredEvent | A channel has been triggered. | smarthome/channels/{channelUID}/triggered |
| Event | Description | Topic |
|-----------------------------|----------------------------------------------------------|-----------------------------------------------|
| ChannelTriggeredEvent | A channel has been triggered. | openhab/channels/{channelUID}/triggered |
## Receive Events
This section describes how to receive openHAB events in Java.
If you want to receive events "outside" openHAB, e.g. with [cURL](https://en.wikipedia.org/wiki/CURL), please refer to the [REST API Examples](../../configuration/restdocs.html#rest-api-examples) section.
An event subscriber defines the callback interface for receiving events from the openHAB event bus.
The following Java snippet shows how to receive `ItemStateEvent`s and `ItemCommandEvent`s from the event bus.
@ -118,7 +117,7 @@ Therefore, the `EventSubscriber` interface must be implemented.
```java
public class SomeItemEventSubscriber implements EventSubscriber {
private final Set<String> subscribedEventTypes = ImmutableSet.of(ItemStateEvent.TYPE, ItemCommandEvent.TYPE);
private final EventFilter eventFiter = new TopicEventFilter("smarthome/items/ItemX/.*");
private final EventFilter eventFiter = new TopicEventFilter("openhab/items/ItemX/.*");
@Override
public Set<String> getSubscribedEventTypes() {
@ -158,24 +157,24 @@ The filter method `EventFilter.apply()` will be called for each event on the eve
If the filter applies (in the given example for all item events with the item name "ItemX"), the event will be received by the `EventSubscriber.receive()` method.
Received events can be cast to the event implementation class for further processing.
Each event subscriber must be registered via OSGi Declarative Services (DS) under the `org.eclipse.smarthome.event.EventSubscriber` interface.
Each event subscriber must be registered via OSGi Declarative Services (DS) under the `org.openhab.core.event.EventSubscriber` interface.
```xml
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" immediate="true" name="SomeItemEventSubscriber">
<implementation class="org.eclipse.smarthome.core.items.events.SomeItemEventSubscriber"/>
<implementation class="org.openhab.core.items.events.SomeItemEventSubscriber"/>
<service>
<provide interface="org.eclipse.smarthome.core.events.EventSubscriber"/>
<provide interface="org.openhab.core.events.EventSubscriber"/>
</service>
</scr:component>
```
The listing below summarizes some best practices in order to implement event subscribers:
- To subscribe to only one event type openHAB provides the `org.eclipse.smarthome.core.events.AbstractTypedEventSubscriber` implementation.
- To subscribe to only one event type openHAB provides the `org.openhab.core.events.AbstractTypedEventSubscriber` implementation.
To receive an already cast event the `receiveTypedEvent(T)` method must be implemented.
To provide an event filter the method `getEventFilter()` can be overridden.
- openHAB provides an `AbstractItemEventSubscriber` class in order to receive `ItemStateEvents` and `ItemCommandEvents` (more information can be obtained in the next chapter).
- To filter events based on a topic the `org.eclipse.smarthome.core.events.TopicEventFilter` implementation from the openHAB core bundle can be used.
- To filter events based on a topic the `org.openhab.core.events.TopicEventFilter` implementation from the openHAB core bundle can be used.
The filtering is based on [Java regular expression](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/regex/Pattern.html).
- The subscribed event types and the filter should be stored as class members (see example above) due to performance reasons.
- If the subscribed event types are sufficient in order to receive all interested events, do not return any filter (in that case the method getFilter() returns null) due to performance reasons.
@ -189,11 +188,11 @@ Create a thread for long running operations.
### Receive ItemStateEvents and ItemCommandEvents
Due to the fact that receiving `ItemStateEvents` and `ItemCommandEvents` is a common use case, openHAB provides an abstract event subscriber implementation via the core bundle.
The class `org.eclipse.smarthome.core.items.events.AbstractItemEventSubscriber` provides two methods `receiveUpdate(ItemStateEvent)` and `receiveCommand(ItemCommandEvent)` which can be implemented in order to receive and handle such events.
The class `org.openhab.core.items.events.AbstractItemEventSubscriber` provides two methods `receiveUpdate(ItemStateEvent)` and `receiveCommand(ItemCommandEvent)` which can be implemented in order to receive and handle such events.
```java
public class SomeItemEventSubscriber extends AbstractItemEventSubscriber {
private final EventFilter eventFiter = new TopicEventFilter("smarthome/items/ItemX/.*");
private final EventFilter eventFiter = new TopicEventFilter("openhab/items/ItemX/.*");
@Override
public EventFilter getEventFilter() {
@ -298,7 +297,7 @@ The classes are located in the openHAB core bundle.
```java
public class SunEventFactory extends AbstractEventFactory {
private static final String SUNRISE_EVENT_TOPIC = "smarthome/sun/{time}/sunrise";
private static final String SUNRISE_EVENT_TOPIC = "openhab/sun/{time}/sunrise";
public SunEventFactory() {
super(Sets.newHashSet(SunriseEvent.TYPE);
@ -332,7 +331,7 @@ The listing below summarizes some guidelines as illustrated in the example above
The supported event types will be returned by the `AbstractEventFactory.getSupportedEventTypes()` method.
- The event factory defines the topic (`SUNRISE_EVENT_TOPIC`) of the supported event types.
Please ensure that the topic format follows the topic structure of the openHAB core events, similar to a REST URI (`{namespace}/{entityType}/{entity}/{sub-entity-1}/.../{sub-entity-n}/{action}`).
The namespace must be `smarthome`.
The namespace must be `openhab`.
- Implement the method `createEventByType(String eventType, String topic, String payload, String source)` to create a new event based on the topic and the payload, determined by the event type.
This method will be called by the framework in order to dispatch received events to the corresponding event subscribers.
If the payload is serialized with JSON, the method `deserializePayload(String payload, Class<T> classOfPayload)` can be used to deserialize the payload into a data transfer object.

8
developers/utils/i18n.md
View File

@ -41,13 +41,13 @@ You can find detailed information about Java internationalization support and a
The properties files have to be placed in the following directory of the bundle:
```
ESH-INF/i18n
OH-INF/i18n
```
Example files:
```
|- ESH-INF
|- OH-INF
|---- i18n
|------- yahooweather.properties
|------- yahooweather_de.properties
@ -411,7 +411,7 @@ In addition to the default keys the developer can also specify custom keys insid
But with this approach the XML file cannot longer contain the English texts.
So it is mandatory to define a language file for the English language.
The syntax for custom keys is `@text/<key>`.
The keys are unique across the whole bundle, so a constant can reference any key in all files inside the `ESH-INF/i18n` folder.
The keys are unique across the whole bundle, so a constant can reference any key in all files inside the `OH-INF/i18n` folder.
The following snippet shows a binding XML that uses custom keys:
@ -450,7 +450,7 @@ updateStatus(ThingStatus.OFFLINE, ThingStatusDetail.OFFLINE.COMMUNICATION_ERROR,
## I18n Text Provider API
To programmatically resolve texts for certain languages openHAB provides the OSGi service `TranslationProvider`.
The service parses every file inside the `ESH-INF/i18n` folder and caches all texts.
The service parses every file inside the `OH-INF/i18n` folder and caches all texts.
A localized text can be retrieved via the method `getText(Bundle bundle, String key, String default, Locale locale)` (or via the method `getText(Bundle bundle, String key, String default, Locale locale, Object... arguments)` if additional arguments are to be injected into the localized text), where bundle must be the reference to the bundle, in which the file is stored.
The BundleContext from the Activator provides a method to get the bundle.

4
developers/utils/tools.md
View File

@ -10,7 +10,7 @@ Find a few framework utilities listed in this chapter.
# Unique Instance ID
When communicating with external systems, it is often desirable to have a unique identifier.
The `org.eclipse.smarthome.core.id` bundle is a mean to generate such an id, which is automatically persisted.
The `org.openhab.core.id` bundle is a mean to generate such an id, which is automatically persisted.
The persistence is done in the configured `userdata` directory as a file called `uuid`.
The id is provided through a static method and can be retrieved through
@ -22,7 +22,7 @@ The id is provided through a static method and can be retrieved through
# Network Address Service
The `NetworkAddressService` is an OSGi service that can be used like any other OSGi service by adding a service reference to it.
Its OSGi service name is `org.eclipse.smarthome.network`.
Its OSGi service name is `org.openhab.core.network`.
A user can configure his default network address via Paper UI under `Configuration -> System -> Network Settings`.
One can obtain the configured address via the `getPrimaryIpv4HostAddress()` method on the service.
This service is useful for example in the `ThingHandlerFactory` or an `AudioSink` where one needs a specific IP address of the host system to provide something like a `callback` URL.

4
installation/security.md
View File

@ -518,7 +518,7 @@ Log into your DiskStation by SSH.
Use the admin username and password.
Create a .htpasswd file in your openHAB userdata folder (your userdata location may vary, update accordingly):
```shell
htpasswd -c /volume1/SmartHome/openHAB/userdata/.htpasswd username
htpasswd -c /volume1/openHAB/userdata/.htpasswd username
```
Next, add a very simple NGINX configuration similar to that created above, but without the SSL parameters.
DSM comes with vi installed by default, but you may wish to [install nano](https://anto.online/other/how-to-install-nano-on-your-synology-nas/)
@ -555,7 +555,7 @@ server {
allow 127.0.0.1;
deny all;
auth_basic "Username and Password Required";
auth_basic_user_file /volume1/SmartHome/openHAB/userdata/.htpasswd; #Update with your userdata folder if different
auth_basic_user_file /volume1/openHAB/userdata/.htpasswd; #Update with your userdata folder if different
}
}