diff --git a/doc/source/index.rst b/doc/source/index.rst
index c40cca9b..e20d0824 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -44,7 +44,7 @@ SWUpdate Documentation
    mongoose.rst
    suricatta.rst
    hawkbit-setup.rst
-   swupdate-ipc.rst
+   swupdate-ipc-interface.rst
    progress.rst
    bindings.rst
    building-with-yocto.rst
@@ -62,6 +62,7 @@ Utilities and tools
    swupdate-sendtohawkbit.rst
    swupdate-progress.rst
    swupdate-sysrestart.rst
+   swupdate-ipc.rst
 
 ############################################
 Help and support
diff --git a/doc/source/swupdate-ipc-interface.rst b/doc/source/swupdate-ipc-interface.rst
new file mode 100644
index 00000000..bf578de0
--- /dev/null
+++ b/doc/source/swupdate-ipc-interface.rst
@@ -0,0 +1,441 @@
+.. SPDX-FileCopyrightText: 2013-2021 Stefano Babic <sbabic@denx.de>
+.. SPDX-License-Identifier: GPL-2.0-only
+
+===================================
+SWUpdate: API for external programs
+===================================
+
+Overview
+========
+
+SWUpdate contains an integrated web-server to allow remote updating.
+However, which protocols are involved during an update is project
+specific and differs significantly. Some projects can decide
+to use FTP to load an image from an external server, or using
+even a proprietary protocol.
+The integrated web-server uses this interface.
+
+SWUpdate has a simple interface to let external programs
+to communicate with the installer. Clients can start an upgrade
+and stream an image to the installer, querying then for the status
+and the final result. The API is at the moment very simple, but it can
+easy be extended in the future if new use cases will arise.
+
+.. _install_api:
+
+API Description
+===============
+
+The communication runs via UDS (Unix Domain Socket). The socket is created
+at startup by SWUpdate in /tmp/sockinstctrl as per default configuration.
+This socket should, however, not be used directly but instead by the Client
+Library explained below.
+
+The exchanged packets are described in network_ipc.h
+
+::
+
+	typedef struct {
+		int magic;
+		int type;
+		msgdata data;
+	} ipc_message;
+
+
+Where the fields have the meaning:
+
+- magic : a magic number as simple proof of the packet
+- type : one of REQ_INSTALL, ACK, NACK,
+  GET_STATUS, POST_UPDATE, SWUPDATE_SUBPROCESS, SET_AES_KEY
+- msgdata : a buffer used by the client to send the image
+  or by SWUpdate to report back notifications and status.
+
+The client sends a REQ_INSTALL packet and waits for an answer.
+SWUpdate sends back ACK or NACK, if for example an update is already in progress.
+
+After the ACK, the client sends the whole image as a stream. SWUpdate
+expects that all bytes after the ACK are part of the image to be installed.
+SWUpdate recognizes the size of the image from the CPIO header.
+Any error lets SWUpdate to leave the update state, and further packets
+will be ignored until a new REQ_INSTALL will be received.
+
+.. image:: images/API.png
+
+It is recommended to use the client library to communicate with SWUpdate. On the lower
+level with direct socket communication, it cannot be guaranteed that the structures
+will remain compatible in the future. The client library was affected by this issue, too, and it is
+changed to accept an opaque interface that will survive API changes. Compatibility
+layers could be added on-demand in the future due to API changes.
+
+
+Client Library
+==============
+
+Functions to start an update
+----------------------------
+A library simplifies the usage of the IPC making available a way to
+start asynchronously an update.
+
+The library consists of one function and several call-backs.
+
+::
+
+        int swupdate_async_start(writedata wr_func, getstatus status_func,
+                terminated end_func, void *req, ssize_t size)
+        typedef int (*writedata)(char **buf, int *size);
+        typedef int (*getstatus)(ipc_message *msg);
+        typedef int (*terminated)(RECOVERY_STATUS status);
+
+swupdate_async_start creates a new thread and start the communication with SWUpdate,
+triggering for a new update. The wr_func is called to get the image to be installed.
+It is responsibility of the callback to provide the buffer and the size of
+the chunk of data.
+
+The getstatus call-back is called after the stream was downloaded to check
+how upgrade is going on. It can be omitted if only the result is required.
+
+The terminated call-back is called when SWUpdate has finished with the result
+of the upgrade.
+
+Example about using this library is in the examples/client directory.
+
+The `req` structure is casted to void to ensure API compatibility. Am user
+should instantiate it as `struct swupdate_request`. This contains fields that can control
+the update process:
+
+::
+
+        struct swupdate_request {
+                unsigned int apiversion;
+                sourcetype source;
+                int dry_run;
+                size_t len;
+                char info[512];
+                char software_set[256];
+                char running_mode[256];
+        };
+
+A user should first call `swupdate_prepare_req()`
+
+::
+
+        void swupdate_prepare_req(struct swupdate_request *req);
+
+This fills the request structure with default values. After that, the user can fill the
+other fields as:
+
+        - *sourcetype* : one of SOURCE_UNKNOWN, SOURCE_WEBSERVER,
+	  SOURCE_SURICATTA, SOURCE_DOWNLOADER, SOURCE_LOCAL
+        - *dry_run* : one of RUN_DEFAULT (set from command line), RUN_DRYRUN, RUN_INSTALL.
+        - *info, len* : a variable length data that can be forwarded to the progress
+          interface. The installer in SWUpdate does not evaluate it.
+        - *software_set* and *running_mode* : this allows one to set the `selection` for the update.
+
+Functions to set AES keys
+-------------------------
+
+The key for decryption can be set with command line parameter (see `-K`), but it is possible
+to set it via IPC. In this way, each update could have a different key.
+
+::
+
+        int swupdate_set_aes(char *key, char *ivt)
+
+The key is for AES-256. The length for key and ivt are then defined by the algorithm amd they are passed as ASCII string, so the length *must* be 64 bytes for key and 32 bytes for IVT.
+
+Functions to control SWUpdate
+-----------------------------
+
+::
+
+        int ipc_send_cmd(ipc_message *msg);
+
+ipc_send_cmd is used to send a command to a SWUpdate subprocess (as suricatta). The function is synchron,
+that means it clocks until the subprocess has answered with ACK or NACK. This function sets `type` to SWUPDATE_SUBPROCESS.
+The caller must then set the other fields in message according to the destination.
+The msgdata field is a structure as:
+
+::
+
+     struct {
+        sourcetype source; /* Who triggered the update */
+        int	cmd;	   /* Optional encoded command */
+        int	timeout;     /* timeout in seconds if an aswer is expected */
+        unsigned int len;    /* Len of data valid in buf */
+        char	buf[2048];   /*
+                              * Buffer that each source can fill
+                              * with additional information
+                              */
+        }
+
+The caller fills `source` with the subprocess that acceps the command. Values of cmd
+are in `network_ipc.h`.
+
+Messages for suricatta
+----------------------
+
+suricatta accepts messages in JSON format. The message must be formatted in the `buf` field of
+the message data.
+
+Setting the polling time
+........................
+
+::
+
+        { "polling" : <value in seconds, range 0..X>}
+
+Setting it to 0 has the special meaning that the polling time is retrieved from the Backend
+(if this is supported by the server).
+
+Enable / disable Suricatta daemon
+.................................
+
+::
+
+        { "enable" : true }
+        { "enable" : false }
+
+Set custom device attributes for Suricatta (for Hawkbit implementation)
+.......................................................................
+
+::
+
+        { "identify" : [
+            {
+                "name"  : "customizableAttributeOne",
+                "value" : "valueOne"
+            },
+            {
+                "name"  : "customizableAttributeTwo",
+                "value" : "valueTwo"
+            }
+        ]}
+
+New attributes can be added at runtime, and existing attributes can be modified in the same
+way. Changes will be reflected on the server in the next poll iteration.
+
+
+Trigger a check on the server
+.............................
+
+This is useful in case the device is mostly offline, and when it is online, it should check
+immediately if an update exists and run it. In fact, after enabling the suricatta daemon,
+the update follows the usual states, and the daemon waits for a polling time before
+loading the new software. This command forces an update (if available) without changing the
+polling time.
+
+::
+
+        { "trigger" : true }
+
+
+Activate an already installed Software
+......................................
+
+After a software was installed, the new software boots and if everything runs fine,
+an acknowledge should be sent to the hawkBit server. If this feature is used, for example
+to let the end user decide if the new software is accepted, the parameters used by the installation
+should be stored during the update process.
+
+::
+
+        { "id" : <action id>,
+          "finished" : "success", "failure", "none",
+          "execution" : ["closed", "proceeding", canceled", "rejected", "resumed"]
+          "details" : [ ]
+        }
+
+Get hawkBit Server Status
+.........................
+
+To provide the hawkBit server status to other processes, it can be requested by
+sending an empty message with message type CMD_GET_STATUS.
+
+The response is a JSON object containing the hawkBit server status <status>.
+<status> is a number representing the value of the channel_op_res_t enum from
+channel_op_res.h. As the hawkBit server is polled, its status can only be
+updated when it has been polled. Therefore the response also contains the
+time <time>, when the hawkBit server has been polled the last time. It is
+provided as ISO 8601 date and time string. (2021-10-14T13:42:37.000+00)
+
+::
+
+        { "server" : {
+	                "status" : <status>
+			"time" : <time>
+                     }
+        }
+
+An example application can be found under tools/swupdate-gethawkbitstatus.c
+
+API to the integrated Webserver
+===============================
+
+The integrated Webserver provides REST resources to push a SWU package and to get inform about the update process.
+This API is based on HTTP standards. There are to kind of interface:
+
+- Install API to push a SWU and to restart the device after update.
+- A WebSocket interface to send the status of the update process.
+
+Install API
+-----------
+
+::
+
+        POST /upload
+
+This initiates an update: the initiator sends the request and start to stream the SWU in the same
+way as described in :ref:`install_api`.
+
+Restart API
+-----------
+
+::
+
+        POST /restart
+
+If configured (see post update command), this request will restart the device.
+
+
+WebSocket API
+-------------
+
+The integrated Webserver exposes a WebSocket API. The WebSocket protocol specification defines ws (WebSocket) and wss (WebSocket Secure) as two new uniform resource identifier (URI) schemes that are used for unencrypted and encrypted con
+nections, respectively and both of them are supported by SWUpdate.
+A WebSocket provides full-duplex communication but it is used in SWUpdate to send events to an external host after
+each change in the update process. The Webserver sends JSON formatted responses as results of internal events.
+
+The response contains the field type, that defines which event is sent.
+
+.. table:: Event Type
+
+        +-----------+----------------------------------------------------------------+
+        |  type     |   Description of event                                         |
+        +===========+================================================================+
+        | status    | Event sent when SWUpdate's internal state changes              |
+        +-----------+----------------------------------------------------------------+
+        | source    | Event to inform from which interface an update is received     |
+        +-----------+----------------------------------------------------------------+
+        | info      | Event with custom message to be passed to an external process  |
+        +-----------+----------------------------------------------------------------+
+        | message   | Event that contains the error message in case of error         |
+        +-----------+----------------------------------------------------------------+
+        | step      | Event to inform about the running update                       |
+        +-----------+----------------------------------------------------------------+
+
+
+
+Status Change Event
+-------------------
+
+This event is sent when the internal SWUpdate status change. Following status are supported:
+
+::
+
+        IDLE
+        START
+        RUN
+        SUCCESS
+
+
+Example:
+
+::
+
+        {
+	        "type": "status",
+		"status": "SUCCESS"
+	}
+
+Source Event
+------------
+
+This event informs from which interface a SWU is loaded.
+
+::
+
+        {
+	        "type": "source",
+		"source": "WEBSERVER"
+	}
+
+The field `source` can have one of the following values:
+
+::
+
+        UNKNOWN
+        WEBSERVER
+        SURICATTA
+        DOWNLOADER
+        LOCAL
+
+Info Event
+------------
+
+This event forwards all internal logs sent with level=INFO.
+
+::
+
+        {
+	        "type": "info",
+		"source": < text message >
+	}
+
+Message Event
+-------------
+
+This event contains the error message in case of failure.
+
+
+.. table:: Fields for message event
+
+        +-----------+----------------------------------------------------------------+
+        |  name     |   Description                                                  |
+        +===========+================================================================+
+        | status    | "message"                                                      |
+        +-----------+----------------------------------------------------------------+
+        | level     | "3" in case of error, "6" as info                              |
+        +-----------+----------------------------------------------------------------+
+        | text      | Message associated to the event                                |
+        +-----------+----------------------------------------------------------------+
+
+Example:
+
+::
+
+        {
+	        "type": "message",
+		"level": "3",
+                "text" : "[ERROR] : SWUPDATE failed [0] ERROR core/cpio_utils.c : ",
+	}
+
+Step event
+----------
+
+This event contains which is the current step running and which percentage of this step is currently installed.
+
+.. table:: Fields for step event
+
+        +-----------+----------------------------------------------------------------+
+        |  name     |   Description                                                  |
+        +===========+================================================================+
+        | number    | total number of steps N for this update                        |
+        +-----------+----------------------------------------------------------------+
+        | step      | running step in range [1..N]                                   |
+        +-----------+----------------------------------------------------------------+
+        | name      | filename of artefact to be installed                           |
+        +-----------+----------------------------------------------------------------+
+        | percent   | percentage of the running step                                 |
+        +-----------+----------------------------------------------------------------+
+
+Example:
+
+::
+
+        {
+		"type": "step",
+		"number": "7",
+		"step": "2",
+		"name": "rootfs.ext4.gz",
+		"percent": "18"
+	}
diff --git a/doc/source/swupdate-ipc.rst b/doc/source/swupdate-ipc.rst
index bf578de0..f175d744 100644
--- a/doc/source/swupdate-ipc.rst
+++ b/doc/source/swupdate-ipc.rst
@@ -1,441 +1,71 @@
-.. SPDX-FileCopyrightText: 2013-2021 Stefano Babic <sbabic@denx.de>
+.. SPDX-FileCopyrightText: 2021 Stefano Babic <sbabic@denx.de>
 .. SPDX-License-Identifier: GPL-2.0-only
 
-===================================
-SWUpdate: API for external programs
-===================================
+swupdate-ipc
+============
 
-Overview
-========
+swupdate-ipc sends a specific command to SWUpdate. The following commands are
+enabled:
 
-SWUpdate contains an integrated web-server to allow remote updating.
-However, which protocols are involved during an update is project
-specific and differs significantly. Some projects can decide
-to use FTP to load an image from an external server, or using
-even a proprietary protocol.
-The integrated web-server uses this interface.
+aes
+---
+send a new aes key to SWUpdate
 
-SWUpdate has a simple interface to let external programs
-to communicate with the installer. Clients can start an upgrade
-and stream an image to the installer, querying then for the status
-and the final result. The API is at the moment very simple, but it can
-easy be extended in the future if new use cases will arise.
-
-.. _install_api:
-
-API Description
-===============
-
-The communication runs via UDS (Unix Domain Socket). The socket is created
-at startup by SWUpdate in /tmp/sockinstctrl as per default configuration.
-This socket should, however, not be used directly but instead by the Client
-Library explained below.
-
-The exchanged packets are described in network_ipc.h
-
-::
-
-	typedef struct {
-		int magic;
-		int type;
-		msgdata data;
-	} ipc_message;
-
-
-Where the fields have the meaning:
-
-- magic : a magic number as simple proof of the packet
-- type : one of REQ_INSTALL, ACK, NACK,
-  GET_STATUS, POST_UPDATE, SWUPDATE_SUBPROCESS, SET_AES_KEY
-- msgdata : a buffer used by the client to send the image
-  or by SWUpdate to report back notifications and status.
-
-The client sends a REQ_INSTALL packet and waits for an answer.
-SWUpdate sends back ACK or NACK, if for example an update is already in progress.
-
-After the ACK, the client sends the whole image as a stream. SWUpdate
-expects that all bytes after the ACK are part of the image to be installed.
-SWUpdate recognizes the size of the image from the CPIO header.
-Any error lets SWUpdate to leave the update state, and further packets
-will be ignored until a new REQ_INSTALL will be received.
-
-.. image:: images/API.png
-
-It is recommended to use the client library to communicate with SWUpdate. On the lower
-level with direct socket communication, it cannot be guaranteed that the structures
-will remain compatible in the future. The client library was affected by this issue, too, and it is
-changed to accept an opaque interface that will survive API changes. Compatibility
-layers could be added on-demand in the future due to API changes.
-
-
-Client Library
-==============
-
-Functions to start an update
-----------------------------
-A library simplifies the usage of the IPC making available a way to
-start asynchronously an update.
-
-The library consists of one function and several call-backs.
-
-::
-
-        int swupdate_async_start(writedata wr_func, getstatus status_func,
-                terminated end_func, void *req, ssize_t size)
-        typedef int (*writedata)(char **buf, int *size);
-        typedef int (*getstatus)(ipc_message *msg);
-        typedef int (*terminated)(RECOVERY_STATUS status);
-
-swupdate_async_start creates a new thread and start the communication with SWUpdate,
-triggering for a new update. The wr_func is called to get the image to be installed.
-It is responsibility of the callback to provide the buffer and the size of
-the chunk of data.
-
-The getstatus call-back is called after the stream was downloaded to check
-how upgrade is going on. It can be omitted if only the result is required.
-
-The terminated call-back is called when SWUpdate has finished with the result
-of the upgrade.
-
-Example about using this library is in the examples/client directory.
-
-The `req` structure is casted to void to ensure API compatibility. Am user
-should instantiate it as `struct swupdate_request`. This contains fields that can control
-the update process:
-
-::
-
-        struct swupdate_request {
-                unsigned int apiversion;
-                sourcetype source;
-                int dry_run;
-                size_t len;
-                char info[512];
-                char software_set[256];
-                char running_mode[256];
-        };
-
-A user should first call `swupdate_prepare_req()`
-
-::
-
-        void swupdate_prepare_req(struct swupdate_request *req);
-
-This fills the request structure with default values. After that, the user can fill the
-other fields as:
-
-        - *sourcetype* : one of SOURCE_UNKNOWN, SOURCE_WEBSERVER,
-	  SOURCE_SURICATTA, SOURCE_DOWNLOADER, SOURCE_LOCAL
-        - *dry_run* : one of RUN_DEFAULT (set from command line), RUN_DRYRUN, RUN_INSTALL.
-        - *info, len* : a variable length data that can be forwarded to the progress
-          interface. The installer in SWUpdate does not evaluate it.
-        - *software_set* and *running_mode* : this allows one to set the `selection` for the update.
-
-Functions to set AES keys
--------------------------
-
-The key for decryption can be set with command line parameter (see `-K`), but it is possible
-to set it via IPC. In this way, each update could have a different key.
-
-::
-
-        int swupdate_set_aes(char *key, char *ivt)
-
-The key is for AES-256. The length for key and ivt are then defined by the algorithm amd they are passed as ASCII string, so the length *must* be 64 bytes for key and 32 bytes for IVT.
-
-Functions to control SWUpdate
------------------------------
-
-::
-
-        int ipc_send_cmd(ipc_message *msg);
-
-ipc_send_cmd is used to send a command to a SWUpdate subprocess (as suricatta). The function is synchron,
-that means it clocks until the subprocess has answered with ACK or NACK. This function sets `type` to SWUPDATE_SUBPROCESS.
-The caller must then set the other fields in message according to the destination.
-The msgdata field is a structure as:
-
-::
-
-     struct {
-        sourcetype source; /* Who triggered the update */
-        int	cmd;	   /* Optional encoded command */
-        int	timeout;     /* timeout in seconds if an aswer is expected */
-        unsigned int len;    /* Len of data valid in buf */
-        char	buf[2048];   /*
-                              * Buffer that each source can fill
-                              * with additional information
-                              */
-        }
-
-The caller fills `source` with the subprocess that acceps the command. Values of cmd
-are in `network_ipc.h`.
-
-Messages for suricatta
-----------------------
-
-suricatta accepts messages in JSON format. The message must be formatted in the `buf` field of
-the message data.
-
-Setting the polling time
-........................
-
-::
-
-        { "polling" : <value in seconds, range 0..X>}
-
-Setting it to 0 has the special meaning that the polling time is retrieved from the Backend
-(if this is supported by the server).
-
-Enable / disable Suricatta daemon
-.................................
-
-::
-
-        { "enable" : true }
-        { "enable" : false }
-
-Set custom device attributes for Suricatta (for Hawkbit implementation)
-.......................................................................
-
-::
-
-        { "identify" : [
-            {
-                "name"  : "customizableAttributeOne",
-                "value" : "valueOne"
-            },
-            {
-                "name"  : "customizableAttributeTwo",
-                "value" : "valueTwo"
-            }
-        ]}
-
-New attributes can be added at runtime, and existing attributes can be modified in the same
-way. Changes will be reflected on the server in the next poll iteration.
-
-
-Trigger a check on the server
-.............................
-
-This is useful in case the device is mostly offline, and when it is online, it should check
-immediately if an update exists and run it. In fact, after enabling the suricatta daemon,
-the update follows the usual states, and the daemon waits for a polling time before
-loading the new software. This command forces an update (if available) without changing the
-polling time.
-
-::
-
-        { "trigger" : true }
-
-
-Activate an already installed Software
-......................................
-
-After a software was installed, the new software boots and if everything runs fine,
-an acknowledge should be sent to the hawkBit server. If this feature is used, for example
-to let the end user decide if the new software is accepted, the parameters used by the installation
-should be stored during the update process.
-
-::
-
-        { "id" : <action id>,
-          "finished" : "success", "failure", "none",
-          "execution" : ["closed", "proceeding", canceled", "rejected", "resumed"]
-          "details" : [ ]
-        }
-
-Get hawkBit Server Status
-.........................
-
-To provide the hawkBit server status to other processes, it can be requested by
-sending an empty message with message type CMD_GET_STATUS.
-
-The response is a JSON object containing the hawkBit server status <status>.
-<status> is a number representing the value of the channel_op_res_t enum from
-channel_op_res.h. As the hawkBit server is polled, its status can only be
-updated when it has been polled. Therefore the response also contains the
-time <time>, when the hawkBit server has been polled the last time. It is
-provided as ISO 8601 date and time string. (2021-10-14T13:42:37.000+00)
-
-::
-
-        { "server" : {
-	                "status" : <status>
-			"time" : <time>
-                     }
-        }
-
-An example application can be found under tools/swupdate-gethawkbitstatus.c
-
-API to the integrated Webserver
-===============================
-
-The integrated Webserver provides REST resources to push a SWU package and to get inform about the update process.
-This API is based on HTTP standards. There are to kind of interface:
-
-- Install API to push a SWU and to restart the device after update.
-- A WebSocket interface to send the status of the update process.
-
-Install API
------------
-
-::
-
-        POST /upload
-
-This initiates an update: the initiator sends the request and start to stream the SWU in the same
-way as described in :ref:`install_api`.
-
-Restart API
------------
-
-::
-
-        POST /restart
-
-If configured (see post update command), this request will restart the device.
-
-
-WebSocket API
--------------
-
-The integrated Webserver exposes a WebSocket API. The WebSocket protocol specification defines ws (WebSocket) and wss (WebSocket Secure) as two new uniform resource identifier (URI) schemes that are used for unencrypted and encrypted con
-nections, respectively and both of them are supported by SWUpdate.
-A WebSocket provides full-duplex communication but it is used in SWUpdate to send events to an external host after
-each change in the update process. The Webserver sends JSON formatted responses as results of internal events.
-
-The response contains the field type, that defines which event is sent.
-
-.. table:: Event Type
-
-        +-----------+----------------------------------------------------------------+
-        |  type     |   Description of event                                         |
-        +===========+================================================================+
-        | status    | Event sent when SWUpdate's internal state changes              |
-        +-----------+----------------------------------------------------------------+
-        | source    | Event to inform from which interface an update is received     |
-        +-----------+----------------------------------------------------------------+
-        | info      | Event with custom message to be passed to an external process  |
-        +-----------+----------------------------------------------------------------+
-        | message   | Event that contains the error message in case of error         |
-        +-----------+----------------------------------------------------------------+
-        | step      | Event to inform about the running update                       |
-        +-----------+----------------------------------------------------------------+
-
-
-
-Status Change Event
--------------------
-
-This event is sent when the internal SWUpdate status change. Following status are supported:
-
-::
-
-        IDLE
-        START
-        RUN
-        SUCCESS
-
-
-Example:
-
-::
-
-        {
-	        "type": "status",
-		"status": "SUCCESS"
-	}
-
-Source Event
-------------
-
-This event informs from which interface a SWU is loaded.
-
-::
-
-        {
-	        "type": "source",
-		"source": "WEBSERVER"
-	}
-
-The field `source` can have one of the following values:
-
-::
-
-        UNKNOWN
-        WEBSERVER
-        SURICATTA
-        DOWNLOADER
-        LOCAL
-
-Info Event
-------------
-
-This event forwards all internal logs sent with level=INFO.
-
-::
+setversion
+----------
+sends a range of versions that can be accepted.
 
-        {
-	        "type": "info",
-		"source": < text message >
-	}
+gethawkbit
+----------
+return status of the connection to Hawkbit.
 
-Message Event
+sendtohawkbit
 -------------
+send data to the Hawkbit Server.  A typical use case is acknowledgement
+for activation by an application or operator after a new software has been installed.
+The tool can forward the result for the activation to the hawkBit server.
 
-This event contains the error message in case of failure.
-
-
-.. table:: Fields for message event
+sysrestart
+----------
+send a restart command after a network update
 
-        +-----------+----------------------------------------------------------------+
-        |  name     |   Description                                                  |
-        +===========+================================================================+
-        | status    | "message"                                                      |
-        +-----------+----------------------------------------------------------------+
-        | level     | "3" in case of error, "6" as info                              |
-        +-----------+----------------------------------------------------------------+
-        | text      | Message associated to the event                                |
-        +-----------+----------------------------------------------------------------+
+SYNOPSIS
+--------
 
-Example:
+swupdate-ipc <cmd> [option]
 
-::
+Where cmd is one of the listed above.
 
-        {
-	        "type": "message",
-		"level": "3",
-                "text" : "[ERROR] : SWUPDATE failed [0] ERROR core/cpio_utils.c : ",
-	}
+DESCRIPTION
+-----------
 
-Step event
-----------
+aes <key> <ivt>
+        AES key to be used for decryption
 
-This event contains which is the current step running and which percentage of this step is currently installed.
+setversion <min> <max> <current>
+        configure the accepted range of versions
 
-.. table:: Fields for step event
+hawkbitcfg
+        configuration for Hawkbit Module
 
-        +-----------+----------------------------------------------------------------+
-        |  name     |   Description                                                  |
-        +===========+================================================================+
-        | number    | total number of steps N for this update                        |
-        +-----------+----------------------------------------------------------------+
-        | step      | running step in range [1..N]                                   |
-        +-----------+----------------------------------------------------------------+
-        | name      | filename of artefact to be installed                           |
-        +-----------+----------------------------------------------------------------+
-        | percent   | percentage of the running step                                 |
-        +-----------+----------------------------------------------------------------+
+-h
+        help
+-p
+        allows one to set the polling time (in seconds)
+-e
+        enable suricatta mode
+-d
+        disable suricatta mode
 
-Example:
+swupdate-sendtohawkbit <action id> <status> <finished> <execution> <detail 1> <detail 2> ..
+        Send Acknolwedge to Hawkbit server after an update if SWUpdate is set to wait for.
 
-::
+sysrestart
+        Used with SWU handler, allow to perform a network restart
 
-        {
-		"type": "step",
-		"number": "7",
-		"step": "2",
-		"name": "rootfs.ext4.gz",
-		"percent": "18"
-	}
+-r
+        optionally reboot the target after a successful update
+-w
+        waits for a SWUpdate connection instead of exit with error
+-s <path>
+        path to progress IPC socket
