Doc Changes 3 (#5)

Update docs

Author: bwosborne2

docs/src/main/resources/markdown/developers/bindings/index.md

@@ -4,7 +4,7 @@ title: Bindings
 
 # Overview
 
-A binding is an extension to openHAB that integrates an external system like a software service or a hardware device.
+A binding is an extension to OpenSmartHouse that integrates an external system like a software service or a hardware device.
 The external system is represented as a set of *Things* and sometimes *Bridges* with *Channels*.
 
 This chapter covers everything to know about binding development.
@@ -17,19 +17,19 @@ During development you might come back with specific questions.
 # Structure of a Binding
 
 Every binding needs to define a `binding.xml` file.
-Find more information in the respective [binding XML reference](binding-xml.html).
+Find more information in the respective [binding XML reference](binding-xml.md).
 
 # Describing Things
 
-External systems are represented as *Things* in openHAB.
+External systems are represented as *Things* in OpenSmartHouse.
 When starting the implementation of a binding, you should think about the abstraction of your external system.
 Different services or devices should be represented as individual *Things*.
 Each functionality of the *Thing* should be modelled as a `Channel`.
 
-*Thing* and *Channel* structures need to be explained to the openHAB runtime.
+*Thing* and *Channel* structures need to be explained to the OpenSmartHouse runtime.
 This is done in a declarative way via XML files, so called *ThingTypes* and *ChannelTypes*.
 
-Find more information in the respective [Thing & Channel XML reference](thing-xml.html).
+Find more information in the respective [Thing & Channel XML reference](thing-xml.md).
 
 # The ThingHandlerFactory
 
@@ -39,7 +39,7 @@ The `ThingHandlerFactory` is responsible for creating `ThingHandler` instances.
 
 Every binding must implement a `ThingHandlerFactory` and register it as OSGi service so that the runtime knows which class needs to be called for creating and handling things.
 
-When a new *Thing* is added, the openHAB runtime queries every `ThingHandlerFactory` for support of the *ThingType* by calling the `supportsThingType` method.
+When a new *Thing* is added, the OpenSmartHouse runtime queries every `ThingHandlerFactory` for support of the *ThingType* by calling the `supportsThingType` method.
 When the method returns `true`, the runtime calls `createHandler`, which should then return a proper `ThingHandler` implementation.
 
 A weather bindings `WeatherHandlerFactory` for example supports only one *ThingType* and instantiates a new `WeatherHandler` for a given thing:
@@ -124,10 +124,10 @@ The `ThingManager` creates for each Thing a `ThingHandler` instance using a `Thi
 Therefore, it tracks all `ThingHandlerFactory`s from the binding.
 
 The `ThingManager` determines if the `Thing` is initializable or not.
-A `Thing` is considered as *initializable* if all *required* configuration parameters (cf. property *parameter.required* in [Configuration Description](config-xml.html)) are available.
+A `Thing` is considered as *initializable* if all *required* configuration parameters (cf. property *parameter.required* in [Configuration Description](config-xml.md)) are available.
 If so, the method `ThingHandler.initialize()` is called.
 
-Only Things with status (cf. [Thing Status](../../concepts/things.html#thing-status)) *UNKNOWN*, *ONLINE* or *OFFLINE* are considered as *initialized* by the framework and therefore it is the handler's duty to assign one of these states sooner or later.
+Only Things with status (cf. [Thing Status](../../concepts/things.md#thing-status)) *UNKNOWN*, *ONLINE* or *OFFLINE* are considered as *initialized* by the framework and therefore it is the handler's duty to assign one of these states sooner or later.
 To achieve that, the status must be reported to the framework via the callback or `BaseThingHandler.updateStatus(...)` for convenience.
 Furthermore, the framework expects `initialize()` to be non-blocking and to return quickly.
 For longer running initializations, the implementation has to take care of scheduling a separate job which must guarantee to set the status eventually.
@@ -195,7 +195,7 @@ Bindings implementing device configuration should consider providing `ConfigStat
 
 *Things* can have properties.
 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.
+The properties section [here](thing-definition.md#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.
 If a thing will be created for this thing type then its properties will be automatically copied into the new thing instance.
@@ -331,7 +331,7 @@ It is binding specific when the channel should be triggered.
 
 ## Updating the Thing Status
 
-The *ThingHandler* must also manage the thing status (see also: [Thing Status Concept](../../concepts/things.html#thing-status)).
+The *ThingHandler* must also manage the thing status (see also: [Thing Status Concept](../../concepts/things.md#thing-status)).
 If the device or service is not working correctly, the binding should change the status to *OFFLINE* and back to *ONLINE*, if it is working again.
 The status can be updated via an inherited method from the BaseThingHandler class by calling:
 
@@ -340,7 +340,7 @@ updateStatus(ThingStatus.OFFLINE, ThingStatusDetail.OFFLINE.COMMUNICATION_ERROR)
 ```
 
 The second argument of the method takes a `ThingStatusDetail` enumeration value, which further specifies the current status situation.
-A complete list of all thing statuses and thing status details is listed in the [Thing Status](../../concepts/things.html#thing-status) chapter.
+A complete list of all thing statuses and thing status details is listed in the [Thing Status](../../concepts/things.md#thing-status) chapter.
 
 The binding should also provide additional status description, if available.
 This description might contain technical information (e.g. an HTTP status code, or any other protocol specific information, which helps to identify the current problem):
@@ -468,7 +468,7 @@ The Hue gateway is an IP device with an HTTP API, which communicates over the Zi
 In the openHAB model the Hue gateway is represented as a *Bridge* with connected *Things*, that represent the Hue bulbs.
 *Bridge* inherits from *Thing*, so that it also has *Channels* and all other features of a thing, with the addition that it also holds a list of things.
 
-We have a FAQ, dicussing [Thing, Bridge and Channel modelling](faq.html#structuring-things-and-thing-types).
+We have a FAQ, dicussing [Thing, Bridge and Channel modelling](faq.md#structuring-things-and-thing-types).
 
 When implementing a binding with *Bridges*, the logic to communicate with the external system is often shared between the different `ThingHandler` implementations.
 In that case it makes sense to implement a handler for the *Bridge* and delegate the actual command execution from the *ThingHandler* to the *BridgeHandler*.
@@ -549,7 +549,7 @@ Sub-classes of these handlers must only override the operation `getConfigStatus`
 
 The framework will take care of internationalizing messages.
 
-For this purpose there must be an [i18n](../utils/i18n.html) properties file inside the bundle of the configuration status provider that has a message declared for the message key of the `ConfigStatusMessage`.
+For this purpose there must be an [i18n](../utils/i18n.md) properties file inside the bundle of the configuration status provider that has a message declared for the message key of the `ConfigStatusMessage`.
 The actual message key is built by the operation `withMessageKeySuffix(String)` of the message´s builder in the manner that the given message key suffix is appended to *config-status."config-status-message-type."*.
 
 As a result depending on the type of the message the final constructed message keys are:
@@ -652,7 +652,7 @@ TODO
 
 # Implementing a Discovery Service
 
-Bindings can implement the `DiscoveryService` interface and register it as an OSGi service to inform the framework about devices and services, that can be added as things to the system (see also [Inbox & Discovery Concept](../../concepts/discovery.html)).
+Bindings can implement the `DiscoveryService` interface and register it as an OSGi service to inform the framework about devices and services, that can be added as things to the system (see also [Inbox & Discovery Concept]../discovery/index.md)).
 
 A discovery service provides discovery results.
 The following table gives an overview about the main parts of a `DiscoveryResult`:
@@ -792,7 +792,7 @@ If this behavior is not appropriate for the implemented discovery service, one c
 ## Internationalization
 
 The framework will take care of internationalizing labels of discovery results if you extend the `AbstractDiscoveryService`.
-See [i18n](../utils/i18n.html#discovery) for more information.
+See [i18n](../utils/i18n.md#discovery) for more information.
 
 ::: tip Hint!
 To make it work you have to inject references to the `LocaleProvider` and the `TranslationProvider` services into your implementation.
@@ -886,4 +886,4 @@ TODO
 
 # Frequently asked questions / FAQ
 
-Various binding related questions are answered in our [Binding development FAQ](faq.html).
+Various binding related questions are answered in our [Binding development FAQ](faq.md).

docs/src/main/resources/markdown/developers/bindings/thing-xml.md

@@ -59,7 +59,7 @@ Bindings may optionally set the version of a thing type. This may be used within
 
 ### Thing Categories
 
-A description about thing categories as well as an overview about which categories exist can be found in our [categories overview](../../concepts/categories.html).
+A description about thing categories as well as an overview about which categories exist can be found in our [categories overview](../fundamentals/categories.md).
 
 ## Channels
 

docs/src/main/resources/markdown/developers/discovery/index.md

@@ -64,11 +64,11 @@ If an entry is ignored, it will be hidden in the inbox without creating a Thing
 
 OpenSmartHouse offers a service to automatically ignore discovery results in the inbox, whenever a Thing is created manually, that represents the same Thing, as the respective discovery result would create. 
 This Thing would either have the same Thing UID or the value of its representation property is equal to the representation property's value in the discovery result.
-This service is enabled by default but can be disabled by setting `org.eclipse.smarthome.inbox:autoIgnore=false`. 
+This service is enabled by default but can be disabled by setting `org.openhab.inbox:autoIgnore=false`. 
 
 ## Auto Approve
 
 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.
+The auto approval can be enabled by the setting `org.openhab.inbox:autoApprove=true`; the default is false.