Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correct typos #1190

Merged
merged 3 commits into from
Apr 11, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions addons/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ These are described under *Installation of Add-ons* below

## Installation of Add-ons

Depending on the [package]({{base}}/configuration/packages.html) you have choosen during your first time setup, there are already some pre-installed add-ons.
Depending on the [package]({{base}}/configuration/packages.html) you have chosen during your first time setup, there are already some pre-installed add-ons.
Additional add-ons can be installed in the different ways, described below.

### Through Paper UI
Expand Down Expand Up @@ -79,7 +79,7 @@ With this information we can now edit the *addons.cfg* file in the `$OPENHAB_CON
The path is depending on your installation.
You can find out the correct locations on the corresponding documentation pages, e.g. [Linux]({{base}}/installation/linux.html#file-locations) or [Windows]({{base}}/installation/windows.html#file-locations).

The file could look like this (depending on your choosen package and already installed add-ons):
The file could look like this (depending on your chosen package and already installed add-ons):

```text
package = standard
Expand Down
6 changes: 3 additions & 3 deletions concepts/audio.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,14 +9,14 @@ title: Audio & Voice

Audio and voice features are an important aspect of any smart home solution as it is a very natural way to interact with the user.

openHAB comes with a very modular architecture that enables all kinds of different use cases.
openHAB has a very modular architecture that enables many different use cases.
At its core, there is the notion of an *audio stream*.
Audio streams are provided by *audio sources* and consumed by *audio sinks*.

![](images/audio.png)

- *Audio Streams* are essentially a byte stream with a given *audio format*.
They do not need to be limited in size, i.e. it is also allowed to have continuous streams, e.g. the input from a microphone or from an Internet radio station.
- *Audio Streams* are essentially byte streams with a given *audio format*.
They do not need to be limited in size, i.e. it is allowed to have continuous streams, e.g. the input from a microphone or from an Internet radio station.
- *Audio Formats* define the container (e.g. WAV), encoding, bit rate, sample frequency and depth and the bit order (little or big endian).
- *Audio Sources* are services that are capable of producing audio streams.
They can support different formats and provide a stream in a requested format upon request.
Expand Down
6 changes: 3 additions & 3 deletions concepts/discovery.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,11 +9,11 @@ title: Thing Discovery

Many devices, technologies and systems can be automatically discovered on the network or browsed through some API. It therefore makes a lot of sense to use these features for a smart home solution.

In openHAB bindings therefore implement _Discovery Services_ for Things, which provide _Discovery Results_. All _Discovery Results_ are regarded as suggestions to the user and are put into the _inbox_.
openHAB bindings therefore implement _Discovery Services_ for Things, which provide _Discovery Results_. All _Discovery Results_ are regarded as suggestions to the user and are put into the _inbox_.

### Background Discovery

A couple of discovery services support automatic discovery in the background, while for others a scan needs to be triggered manually.
Some discovery services support automatic discovery in the background, while for others a scan needs to be triggered manually.
Services that support background discovery usually have it enabled by default.
It is possible to override this setting and deactivate background discovery for individual services by setting `discovery.<serviceid>:background=false`, where `serviceid` is usually identical to a binding id, e.g. the LIFX background discovery can be disabled through `discovery.lifx:background=false`.

Expand All @@ -33,7 +33,7 @@ This service is enabled by default but can be disabled by setting `org.eclipse.s

### Auto Approve

If the manual acceptance of discovery results by the user is not wished, it is possible to turn on the auto-approval feature of the inbox.
If the manual acceptance of discovery results by the user is not desired, it is possible to turn on the auto-approval feature of the inbox.
In this case, every new entry gets automatically approved immediately (unless it has been marked as ignored as a duplicate).

The auto approval can be enabled by the setting `org.eclipse.smarthome.inbox:autoApprove=true`; the default is false.
4 changes: 2 additions & 2 deletions concepts/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ title: Concepts

# Concepts

When first thinking about your home automation system, it may be helpful to bear in mind that there are two ways of thinking about or viewing your system; the physical view and the functional view.
When first thinking about your home automation system, it may be helpful to bear in mind that there are two ways of thinking about or viewing your system: the physical view and the functional view.

The physical view will be familiar to you.
This view focuses on the devices in your system, the connections between these devices (e.g. wires, Z-Wave, WiFi hardware), and other physical aspects of the system.
Expand Down Expand Up @@ -49,4 +49,4 @@ To illustrate these concepts, consider the example below of a two-channel actuat
The actuator is a Thing that might be installed in an electrical cabinet.
It has a physical address and it must be configured in order to be used (remember the physical view introduced at the beginning of this article).

In order for the user to control the two lights, he or she access the capability of the actuator Thing (turning on and off two separate lights) through two Channels, that are Linked to two switch Items presented to the user through a user interface.
In order for the user to control the two lights, he or she accesses the capability of the actuator Thing (turning on and off two separate lights) through two Channels, that are Linked to two switch Items presented to the user through a user interface.
2 changes: 1 addition & 1 deletion concepts/items.md
Original file line number Diff line number Diff line change
Expand Up @@ -99,7 +99,7 @@ Examples for derived states on Group Items when declared in the Item DSL:
### QuantityType

A numerical type which carries a unit in addition to its value.
The framework is capable of automatic conversion between units depending on the users locale settings.
The framework is capable of automatic conversion between units depending on the user's locale settings.
See the concept on [Units of Measurement](units-of-measurement.html) for more details.

### HSBType
Expand Down
10 changes: 5 additions & 5 deletions concepts/things.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,12 +41,12 @@ The following table provides an overview of the different statuses:

| Status | Description |
|---------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| UNINITIALIZED | This is the initial status of a Thing, when it is added or the framework is being started. This status is also assigned, if the initializing process failed or the binding is not available. Commands which are sent to Channels will not be processed. |
| INITIALIZING | This status is assigned while the binding initializes the Thing. It depends on the binding how long the initializing process takes. Commands which are sent to Channels will not be processed. |
| UNINITIALIZED | This is the initial status of a Thing when it is added or the framework is being started. This status is also assigned if the initializing process failed or the binding is not available. Commands sent to Channels will not be processed. |
| INITIALIZING | This status is assigned while the binding initializes the Thing. It depends on the binding how long the initializing process takes. Commands sent to Channels will not be processed. |
| UNKNOWN | The handler is fully initialized but due to the nature of the represented device/service it cannot really tell yet whether the Thing is ONLINE or OFFLINE. Therefore the Thing potentially might be working correctly already and may or may not process commands. But the framework is allowed to send commands, because some radio-based devices may go ONLINE if a command is sent to them. The handler should take care to switch the Thing to ONLINE or OFFLINE as soon as possible. |
| ONLINE | The device/service represented by a Thing is assumed to be working correctly and can process commands. |
| OFFLINE | The device/service represented by a Thing is assumed to be not working correctly and may not process commands. But the framework is allowed to send commands, because some radio-based devices may go back to ONLINE if a command is sent to them. |
| REMOVING | The device/service represented by a Thing should be removed, but the binding did not confirm the deletion yet. Some bindings need to communicate with the device to unpair it from the system. Thing is probably not working and commands cannot be processed. |
| REMOVING | The device/service represented by a Thing should be removed, but the binding has not confirmed the deletion yet. Some bindings need to communicate with the device to unpair it from the system. Thing is probably not working and commands cannot be processed. |
| REMOVED | This status indicates that the device/service represented by a Thing was removed from the external system after the REMOVING was initiated by the framework. Usually this status is an intermediate status because the Thing gets removed from the database after this status was assigned. |

The statuses UNINITIALIZED, INITIALIZING and REMOVING are set by the framework, whereas the statuses UNKNOWN, ONLINE and OFFLINE are assigned from a binding.
Expand All @@ -73,7 +73,7 @@ The following table lists the different status details for each status:

<table>
<tr valign="top"><td rowspan="7">UNINITIALIZED</td><td>NONE</td><td>No further status details available.</td></tr>
<tr valign="top"> <td>HANDLER_MISSING_ERROR</td><td>The handler cannot be initialized, because the responsible binding is not available or started.</td></tr>
<tr valign="top"> <td>HANDLER_MISSING_ERROR</td><td>The handler cannot be initialized because the responsible binding is not available or started.</td></tr>
<tr valign="top"> <td>HANDLER_REGISTERING_ERROR</td><td>The handler failed in the service registration phase.</td></tr>
<tr valign="top"> <td>HANDLER_CONFIGURATION_PENDING</td><td>The handler is registered but cannot be initialized because of missing configuration parameters.</td></tr>
<tr valign="top"> <td>HANDLER_INITIALIZING_ERROR</td><td>The handler failed in the initialization phase.</td></tr>
Expand All @@ -98,7 +98,7 @@ The following table lists the different status details for each status:

To provide additional information about the current status a description is used.
The status description is to be specified by the binding.
This description can be used for debugging purposes and should not be presented to the user, as it might contain unreadable technical information (e.g. an HTTP status code, or any other protocol specific information, which helps to identify the current problem).
This description can be used for debugging purposes and should not be presented to the user, as it might contain unreadable technical information (e.g. an HTTP status code, or any other protocol-specific information, which helps to identify the current problem).

### Thing Status API

Expand Down
12 changes: 6 additions & 6 deletions concepts/units-of-measurement.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,8 +17,8 @@ This way the framework and/or the user is able to convert the quantified value t

A weather binding which reads temperature values in °C would use the `QuantityType` to indicate the unit as °C.
The framework is then able to convert the values to either °F or Kelvin according to the configuration of the system.
The default conversion the framework will use is locale based:
Depended on the configured locale the framework tries to convert a `QuantityType` to the default unit of the matching measurement system.
The default conversion the framework will use is locale-based:
The framework tries to convert a `QuantityType` to the default unit of the configured locale.
This is the imperial system for the United States (locale US) and Liberia (language tag "en-LR").
The metric system with SI units is used for the rest of the world.
This conversion will convert the given `QuantityType` into a default unit for the specific dimension of the type.
Expand All @@ -39,19 +39,19 @@ This is:
In addition to the automated conversion the `NumberItem` linked to a Channel delivering `QuantityTypes` can be configured to always have state updates converted to a specific unit.
The unit given in the state description is parsed and then used for conversion (if necessary).
The framework assumes that the unit to parse is always the last token in the state description.
If the parsing failed the locale based default conversion takes place.
If the parsing failed the locale-based default conversion takes place.

Number:Temperature temperature "Outside [%.2f °F]" { channel="...:current#temperature" }

In the example the `NumberItem` is specified to bind to Channels which offer values from the dimension `Temperature`.
Without the dimension information the `NumberItem` only will receive updates of type `DecimalType` without a unit and any conversion.
The state description defines two decimal places for the value and the fix unit °F.
In case the state description should display the unit the binding delivers or the framework calculates through locale based conversion the pattern will look like this:
In case the state description should display the unit the binding delivers or the framework calculates through locale-based conversion the pattern will look like this:

"Outside [%.2f %unit%]"

The special placeholder `%unit%` will then be replaced by the actual unit symbol.
In addition the placeholder `%unit%` can be placed anywhere in the state description.
The placeholder `%unit%` can be placed anywhere in the state description.

#### Defining ChannelTypes

Expand Down Expand Up @@ -99,7 +99,7 @@ SI:

| Type | Unit | Symbol |
|------------------------|----------------------------------|--------|
| Acceleration | Metre per square Second | m/s² |
| Acceleration | Metre per Second squared | m/s² |
| Acceleration | Standard Gravity | ɡₙ |
| AmountOfSubstance | Mole | mol |
| AmountOfSubstance | Deutscher Härtegrad | °dH |
Expand Down
10 changes: 5 additions & 5 deletions configuration/addons.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,8 @@ layout: documentation

# Installation of Add-ons

Depending on the [package](/docs/configuration/packages.html) you have choosen during your first time setup, there are already some pre-installed add-ons.
Additional add-ons can be installed in the different ways, described below.
Depending on the [package](/docs/configuration/packages.html) you have chosen during your first time setup, there are already some pre-installed add-ons.
Additional add-ons can be installed in different ways, described below.

## Through Paper UI

Expand Down Expand Up @@ -59,10 +59,10 @@ The trailing `1` has to be appended for `binding`- and `misc`-addons.
It is *not needed* for other addon types like `persistence`.

With this information we can now edit the *addons.cfg* file in the `$OPENHAB_CONF/services` folder on the machine you are running openHAB on.
The path is depending on your installation.
The path depends on your installation.
You can find out the correct locations on the corresponding documentation pages, e.g. [Linux](/docs/installation/linux.html#file-locations) or [Windows](/docs/installation/windows.html#file-locations).

The file could look like this (depending on your choosen package and already installed add-ons):
The file could look like this (depending on your chosen package and already installed add-ons):

```text
package = standard
Expand Down Expand Up @@ -93,5 +93,5 @@ For this installation option you need a bundles `.jar` file.
One way of retrieving those files is mentioned above in the openHAB console part.

Place the `.jar` file in the `addons` folder on the machine you are running openHAB on.
As described already for the addons.cfg option, the path is depending on your installation.
As described already for the addons.cfg option, the path depends on your installation.
Place the .jar file in the folder Additional add-on files as described in File Locations ([Linux](/docs/installation/linux.html#file-locations), [Windows](/docs/installation/windows.html#file-locations) or [macOS](/docs/installation/macos.html#file-locations)).
Loading