SWPROT-8953: zpc: doc: Add reference to UnifySDK online doc

applications/zpc/how_to_implement_zwave_command_classes.rst

@@ -961,8 +961,8 @@ Mapping Z-Wave to Dotdot UCL with .uam file
 
 You should have some basic knowledge about clusters and UAM files.
 
--  :doc:`Cluster attributes <../../doc/unify_specifications/Chapter02-ZCL-in-uic>`
--  :doc:`.uam file documentation <../../doc/how_to_write_uam_files>`
+-  `UnifySDK: Cluster attributes <https://siliconlabs.github.io/UnifySDK/doc/unify_specifications/Chapter02-ZCL-in-uic>`_
+-  `UnifySDK: .uam file documentation <https://siliconlabs.github.io/UnifySDK/doc/how_to_write_uam_files>`_
 -  :doc:`Z-Wave specific .uam files documentation <how_to_write_uam_files_for_the_zpc>`
 
 Now that our attribute store is correctly defined and sending the right
@@ -1179,9 +1179,11 @@ Let's look at the ``Level`` cluster definition :
 
 We see that we have access to 2 int attributes : ``CurrentLevel`` and
 ``CurrentFrequency``. We can decide to map the current volume to
-``CurrentLevel`` and current tone ID to ``CurrentFrequency`` (even if
-its make little sense). We'll see how to implement our own cluster if we
-need more accuracy :doc:`here <../../doc/how_to_write_new_cluster>`.
+``CurrentLevel`` and current tone ID to ``CurrentFrequency`` 
+(even if it makes little sense).
+We'll see how to implement our own cluster if we need more accuracy check
+`UnifySDK: How to write new cluster <https://siliconlabs.github.io/UnifySDK#/doc/how_to_write_new_cluster>`_
+.
 
 Both ZCL attributes have a min and a max values, so we need to map those
 as well.
@@ -1443,8 +1445,9 @@ the second endpoint, etc.
 This is why we needed to add ``ep[0]`` before ``zwMANUFACTURER_ID`` and
 the other attributes in ``def aeotec_doorbell``. Since its evaluated in
 the ``ATTRIBUTE_NODE_ID`` context the only attribute directly available
-is the ``ATTRIBUTE_ENDPOINT_ID``. You can find more information about
-this in :doc:`How to write UAM files <../../doc/how_to_write_uam_files>`
+is the ``ATTRIBUTE_ENDPOINT_ID``.
+You can find more information about this in
+`UnifySDK: .uam file documentation <https://siliconlabs.github.io/UnifySDK/doc/how_to_write_uam_files>`_
 
 So we need to map the second endpoint (``ep[1]``) tone play value to
 match the first one (``ep[0]``) but ONLY when the device is the Aoetec
@@ -1957,7 +1960,7 @@ Next, you should have ZPC running to include the CTT devices.
 
 .. note:: 
    If you use WSL
-   `usbipd<https://learn.microsoft.com/en-us/windows/wsl/connect-usb>`__
+   `usbipd <https://learn.microsoft.com/en-us/windows/wsl/connect-usb>`__
    can help you connect your Z-Wave controller to ZPC.
 
 **You can skip Step 5 - CTT includes DUT and move to the next step DUR

applications/zpc/how_to_interact_with_clusters.rst

@@ -1,9 +1,10 @@
 How to interact with clusters
 =============================
 
-Unify internal model works with DotDot ZCL clusters. More info on this
-in :doc:`chapter 2 <../../doc/unify_specifications/Chapter02-ZCL-in-uic>` that
-describes how clusters are implemented in Unify and how to use them.
+Unify internal model works with DotDot ZCL clusters.
+More info on this in
+`UnifySDK specifications chapter 2 <https://siliconlabs.github.io/UnifySDK/doc/unify_specifications/Chapter02-ZCL-in-uic>`_
+that describes how clusters are implemented in Unify and how to use them.
 
 ZPC attributes are not exposed to MQTT bus by default. To be able to interact 
 with ZPC with the MQTT broker we must map ZPC values to cluster attributes.

applications/zpc/how_to_write_uam_files_for_the_zpc.md

@@ -12,7 +12,8 @@ they can also be used to:
 
 ### Guide for UAM files
 
-Refer to [How to write UAM files](../../doc/how_to_write_uam_files.rst)
+Refer to 
+[How to write UAM files](https://siliconlabs.github.io/UnifySDK/doc/how_to_write_uam_files)
 
 ### Attribute types
 

applications/zpc/readme_certification.md

@@ -787,8 +787,8 @@ The ZPC controls partially the Multilevel Switch Command Class. It is possible
 to set and see the current level of a Multilevel Switch supporting node.
 
 However, the model on which the Unify system and
-[Dev GUI](../dev_ui/dev_gui/readme_user.md) operate is based on
-The Dotdot model.
+[Dev GUI](https://siliconlabs.github.io/UnifySDK/applications/dev_ui/dev_gui/readme_user)
+operate is based on The Dotdot model.
 
 This means that Multilevel Switch supporting node will be represented with both
 an OnOff and a Level functionality. The Level setting can be changed
@@ -848,7 +848,7 @@ states/events to the ZPC.
 Due to the very diverse nature of the Notifications states and events that
 can be reported via the Command Class, information from the command class is
 displayed in a few different places in the
-[Dev GUI](../dev_ui/dev_gui/readme_user.md).
+[Dev GUI](https://siliconlabs.github.io/UnifySDK/applications/dev_ui/dev_gui/readme_user)
 
 
 #### Node status
@@ -1057,7 +1057,7 @@ network vicinity.
 
 The ZPC supports including other nodes using SmartStart. Detailed
 steps to manipulate the SmartStart list are also given in the
-[Dev GUI User's Guide](../dev_ui/dev_gui/readme_user.md).
+[Dev GUI User's Guide](https://siliconlabs.github.io/UnifySDK/applications/dev_ui/dev_gui/readme_user).
 
 ### SmartStart List Format
 

applications/zpc/readme_user.md

@@ -88,7 +88,7 @@ all information about the network and need to probe all nodes in the network.
 The best way to run ZPC is using the Systemd service that is
 installed with the Debian installer.
 For more information, see the
-[Unify Framework User guide](../../doc/unify_readme_user.md).
+[Unify Framework User guide](https://siliconlabs.github.io/UnifySDK/doc/unify_readme_user).
 
 ## Running ZPC From the Command Line
 
@@ -173,13 +173,14 @@ echo 2 > /dev/ttyUSB0
 
 The ZPC has the capability to perform Firmware Updates of end devices.
 Performing firmware updates requires
-[Image Provider](../image_provider/readme_user.md) application to be
-run and configured correctly. The section below discuss how to construct
+[Image Provider](https://siliconlabs.github.io/UnifySDK/applications/image_provider/readme_user) 
+application to be run and configured correctly.
+The section below discuss how to construct
 UIID and VERSION information that are required to perform a firmware update of an
 end device.
 
 Firmware updates can be triggered by providing the
-[Image Provider](../image_provider/readme_user.md)
+[Image Provider](https://siliconlabs.github.io/UnifySDK/applications/image_provider/readme_user) 
 with compatible firmware images and meta data information.
 
 Once the firmware update is successfully performed on an end device, the ZPC
@@ -259,12 +260,15 @@ The resulting version string will be "3.14.15".
 ### Examples
 
 This section provides an example using the
-[Image Provider](../image_provider/readme_user.md) and
-[Developer GUI](../dev_ui/dev_gui/readme_user.md) to perform a firmware update of a PowerStrip sample application.
+[Image Provider](https://siliconlabs.github.io/UnifySDK/applications/image_provider/readme_user) 
+and
+[Developer GUI](https://siliconlabs.github.io/UnifySDK/applications/dev_ui/dev_gui/readme_user)
+to perform a firmware update of a PowerStrip sample application.
 
 First, make sure that the ZPC,
-[Image Provider](../image_provider/readme_user.md) and
-[Developer GUI](../dev_ui/dev_gui/readme_user.md)
+[Image Provider](https://siliconlabs.github.io/UnifySDK/applications/image_provider/readme_user) 
+and
+[Developer GUI](https://siliconlabs.github.io/UnifySDK/applications/dev_ui/dev_gui/readme_user)
 are running.
 
 Flash a PowerStrip application on a Z-Wave module with the OTA bootloader
@@ -293,7 +297,9 @@ pi@unify:/var/lib/uic-image-provider/updates $ ls -l
 
 Then, use the found UIID to configure the _image.json_ file from the image
 provider. Remember to set a version string as well as calculate the Md5 as
-described in the [Image Provider User Guide](../image_provider/readme_user.md):
+described in the
+[Image Provider](https://siliconlabs.github.io/UnifySDK/applications/image_provider/readme_user) 
+:
 
 ```json
 {