diff --git a/DDIA.md b/DDIA.md
deleted file mode 100644
index 4754ae8c1..000000000
--- a/DDIA.md
+++ /dev/null
@@ -1,131 +0,0 @@
-## Direct Device Integration API (HTTP)
-This API is based on HTTP standards and based on a polling mechanism.
-The hawkbit update server provides REST resources which are consumed by the device to retrieve software update tasks.
-
-
-##### Base Poll Resource
-```
-GET /{tenant}/controller/v1/{controllerId}
-```
-In the answer to the baseUrl polling the backend can send action links. A possible action is a deploy command.
-The client makes a GET request on the given link:
-
-_Example Response_
-```
-{
- "config": {
- "polling": {
- "sleep": "00:05:00"
- }
- },
- "_links": {
- "deploymentBase": {
- "href": "http://localhost:8080/default/controller/v1/example/deploymentBase/1?c=644088541"
- },
- "configData": {
- "href": "http://localhost:8080/default/controller/v1/example/configData"
- }
- }
-}
-```
-
-##### Deployment Base Resource
-```
-GET /{tenant}/controller/v1/{controllerId}/deploymentBase/{id}
-```
-_Example Response_
-```
-{
- "deployment": {
- "download": "forced",
- "update": "forced",
- "chunks": [
- {
- "part": "os",
- "version": "1.0.0",
- "name": "Linux",
- "artifacts": [
- {
- "filename": "linux.zip",
- "hashes": {
- "sha1": "46fc56de883ec027759d8513458fe1010aa7e793",
- "md5": "5813e9655bd6871d0c25b8d510fd8605"
- },
- "size": 52167,
- "_links": {
- "download": {
- "href": "http://localhost:8080/default/controller/v1/example/softwaremodules/1/artifacts/linux.zip"
- },
- "md5sum": {
- "href": "http://localhost:8080/default/controller/v1/example/softwaremodules/1/artifacts/linux.zip.MD5SUM"
- }
- }
- }
- ]
- }
- ]
- },
- "id": "1"
-}
-```
-
-
-##### Deployment Feedback Resource
-To every deployment the client can post feedback back to the update-server about the deployment status.
-```
-POST /{tenant}/controller/v1/{controllerId}/deploymentBase/{id}/feedback
-Content-Type: application/json
-```
-_Example Body Deployment Success_
-```
-{
- "id": 1,
- "time": "20140511T121314",
- "status": {
- "execution": "closed",
- "result": {
- "finished": "success",
- "progress": {}
- }
- }
-}
-```
-
-_Example Body Deployment Proceeding_
-```
-{
- "id": "1",
- "time": "20140511T121314",
- "status": {
- "execution": "proceeding",
- "result": {
- "finished": "none",
- "progress": {
- "cnt": 2,
- "of": 5
- }
- },
- "details": [
- "checking hash sums"
- ]
- }
-}
-```
-
-_Example Body Deployment Error_
-```
-{
- "id": 1,
- "time": "20140511T121314",
- "status": {
- "execution": "rejected",
- "result": {
- "finished": "failure",
- "progress": {}
- },
- "details": [
- "something bad happend"
- ]
- }
-}
-```
\ No newline at end of file
diff --git a/DMFA.md b/DMFA.md
deleted file mode 100644
index 6653f3d9f..000000000
--- a/DMFA.md
+++ /dev/null
@@ -1,127 +0,0 @@
-# !!! DRAFT !!! #
-# Device Management Federation API #
-
-This document describes the **DMF API**. This API is based on AMQP [(AMQP-Specification)](ht1tp://www.amqp.org/sites/amqp.org/files/amqp.pdf "AMQP-Specification"). The SP Update server provides a message queue (default: "*dmf_receiver*") on the corresponding Rabbit MQ service, which accepts all incoming messages.
-
-Every Service, which wants to communicate, has to offer a own queue, to which the SP update server can send messages. The name of this queue is sent
-
-## Authentication ##
-???
-
-## Regular update process ##
-
-### Step 1: Creating a Thing on SP ###
-
-At the beginning every connecting service has to register its targets at the Sp update server. During the creating process the service has to send the name of the queue, which accepts messages, which are sent back from the Sp update server.
-
-The message which is sent by the connecting service to the SP update service has to fulfill the following format. The connecting service has to set the attributes in the header. The name of the tenent (*tenant*, an unique identifier of the thing/target (*thingId*) and an string which identifies the sending service (*sender*). Furthermore it has to set the *replyTo*-Property which defines the name of the queue, which receives messages sent by the SP Update Server. The body of the message is not analyzed and can be empty.
-
-**Header**
-
-type=THING_CREATED
-tenant=#TENANTNAME#
-thingId=#ExampleDevice001#
-sender=#CONNECTORSERVICE#
-
-**Properties**
-
-contentType=application/json
-replyTo=#queue.which.accepts.messages.from.sp#
-
-**Example Body**
-
-
-### Step 2: Begin of update process ###
-Afterwards an distribution set can be assigned to the created thing. This can be done on the UI or with the REST API. To start the update process the SP update server sends a message over the registered queue back to the connecting service.
-
-Inside the message send from the Sp update service the header specifies the target which has to be updated. Therefor the *tenent* and the unique *thingId* are used. The body contains an identifier which defines the update process (*actionId*) and the information of the software modules. The *actionId* is important to send the progress of the update process to the server. The information about the software describes all modules which are included in the current update process, their identifier, their type, their version and the corresponding artifacts with the urls where the target can download the artifacts.
-
-**Header**
-
-type=EVENT
-tenant=#TENANTNAME#
-thingId=#ExampleDevice001#
-topic=DOWNLOAD_AND_INSTALL
-
-**Properties**
-
-contentType=application/json
-
-**Example Body**
-
-{
-"actionId":172,
-"softwareModules":[
- {
- "moduleId":6,
- "moduleType":"firmware",
- "moduleVersion":"7.7.7",
- "artifacts":[
- {
- "urls":{
- "coap":"coap://bumlux.test",
- "http":"coap://bumlux.test"}
- }]
- }]
-}
-
-
-### Step 3: Sending the state update process ###
-
-During the update progress the connected service can inform the sp update service about the progress and eventual warnings or errors. Therefore the *actionId* and the *softwareModuleId* are used to specify for which process and for which software module the progress update is for. Additionally in the Body there is a field *actionStatus*. This field is used to describe the type of the progress update and there are several allowed values:
-
-- **RETRIEVED**: general acknowledge message
-- **DOWNLOAD**: describes all messages related to the download prorgess
-- **RUNNING**:
-- **WARNING**: A smaller problem which influence the update process, but no need for stop it.
-- **ERROR**: A big issues which not allows continuing the update process.
-- **FINISHED**: Successfully finished the update process.
-- **CANCELED**: Response to a cancel request, when the process is canceled.
-- **CANCEL_REJECTED**: Response to a cancel request, when canceling is not possible.
-
-The update process is marked as running until the connected Server sends a **FINISHED**, an **ERROR** or a **CANCELED** message. Additionally the connected service can put some human readable information into the message, which describes the state of the action more detailed.
-
-**Header**
-
-type=EVENT
-tenant=#TENANTNAME#
-topic=UPDATE_ACTION_STATUS
-
-**Properties**
-
-contentType=application/json
-
-**Example Body**
-
-
-{
-"actionId":115,
-"softwareModuleId":3,
-"actionStatus":"DOWNLOAD",
-"message":["The download has started"]
-}
-
-
-## Cancel process ##
-
-During the update process the SP update server has the chance to cancel an update. Therefore it sends the following message. This message includes the *tenant* and the corresponding *thingId* on theheader.
-
-**Header**
-
-type=EVENT
-tenant=#TENANTNAME#
-thingId=#ExampleDevice001#
-topic=CANCEL_DOWNLOAD
-
-**Properties**
-
-contentType=application/json
-
-**Example Body**
-
-
-
-
-Receiving this message the connected service has to decide if an update can be canceled or not. If it is the update has to be canceled and a **CANCELED** message has to be sent to the SP server. Otherwise a **CANCEL_REJECTED** message has to be sent.
-
- 
\ No newline at end of file
diff --git a/README.md b/README.md
index 639988af8..4b06a8b05 100644
--- a/README.md
+++ b/README.md
@@ -4,9 +4,14 @@ Build: [](htt
[hawkBit](https://projects.eclipse.org/projects/iot.hawkbit) is an domain independent back end solution for rolling out software updates to constrained edge devices as well as more powerful controllers and gateways connected to IP based networking infrastructure.
+# Documentation
+
+see [hawkBit Wiki](https://github.com/eclipse/hawkbit/wiki)
+
# Contact us
* Want to chat with the team behind hawkBit? [](https://gitter.im/eclipse/hawkbit?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
+* Having issues with hawkBit? Open a [GitHub issue](https://github.com/eclipse/hawkbit/issues).
* You can also check out our [Project Homepage](https://projects.eclipse.org/projects/iot.hawkbit) for further contact options.
@@ -14,7 +19,7 @@ Build: [](htt
We are not providing an off the shelf installation ready hawkBit update server. However, we recommend to check out the [Example Application](examples/hawkbit-example-app) for a runtime ready Spring Boot based update server that is empowered by hawkBit.
-#### Clone and build hawkBit
+#### Clone and build hawkBit
```
$ git clone https://github.com/eclipse/hawkbit.git
$ mvn clean install
@@ -45,11 +50,6 @@ $ java –jar ./examples/hawkbit-mgmt-api-client/target/hawkbit-mgmt-api-client-
* And of course tons of usability improvements and bug fixes.
-# Device Integration
-There are two device integration APIs provided by the hawkbit update server.
-* [Direct Device Integration API (HTTP)](DDIA.md)
-* [Device Management Federation API (AMQP)](DMFA.md)
-
# Modules
`hawkbit-core` : core elements.
`hawkbit-security-core` : core security elements.