Skip to content

Commit dac9f94

Browse files
committed
SWPROT-8953: zpc: doc: Add reference to UnifySDK online doc
Align to ver_1.7 github pages just deployed Origin: SiliconLabsSoftware#36 Signed-off-by: Philippe Coval <[email protected]>
1 parent d61af47 commit dac9f94

File tree

5 files changed

+36
-25
lines changed

5 files changed

+36
-25
lines changed

applications/zpc/how_to_implement_zwave_command_classes.rst

Lines changed: 11 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -961,8 +961,8 @@ Mapping Z-Wave to Dotdot UCL with .uam file
961961

962962
You should have some basic knowledge about clusters and UAM files.
963963

964-
- :doc:`Cluster attributes <../../doc/unify_specifications/Chapter02-ZCL-in-uic>`
965-
- :doc:`.uam file documentation <../../doc/how_to_write_uam_files>`
964+
- `UnifySDK: Cluster attributes <https://siliconlabs.github.io/UnifySDK/doc/unify_specifications/Chapter02-ZCL-in-uic>`_
965+
- `UnifySDK: .uam file documentation <https://siliconlabs.github.io/UnifySDK/doc/how_to_write_uam_files>`_
966966
- :doc:`Z-Wave specific .uam files documentation <how_to_write_uam_files_for_the_zpc>`
967967

968968
Now that our attribute store is correctly defined and sending the right
@@ -1179,9 +1179,11 @@ Let's look at the ``Level`` cluster definition :
11791179
11801180
We see that we have access to 2 int attributes : ``CurrentLevel`` and
11811181
``CurrentFrequency``. We can decide to map the current volume to
1182-
``CurrentLevel`` and current tone ID to ``CurrentFrequency`` (even if
1183-
its make little sense). We'll see how to implement our own cluster if we
1184-
need more accuracy :doc:`here <../../doc/how_to_write_new_cluster>`.
1182+
``CurrentLevel`` and current tone ID to ``CurrentFrequency``
1183+
(even if it makes little sense).
1184+
We'll see how to implement our own cluster if we need more accuracy check
1185+
`UnifySDK: How to write new cluster <https://siliconlabs.github.io/UnifySDK#/doc/how_to_write_new_cluster>`_
1186+
.
11851187

11861188
Both ZCL attributes have a min and a max values, so we need to map those
11871189
as well.
@@ -1443,8 +1445,9 @@ the second endpoint, etc.
14431445
This is why we needed to add ``ep[0]`` before ``zwMANUFACTURER_ID`` and
14441446
the other attributes in ``def aeotec_doorbell``. Since its evaluated in
14451447
the ``ATTRIBUTE_NODE_ID`` context the only attribute directly available
1446-
is the ``ATTRIBUTE_ENDPOINT_ID``. You can find more information about
1447-
this in :doc:`How to write UAM files <../../doc/how_to_write_uam_files>`
1448+
is the ``ATTRIBUTE_ENDPOINT_ID``.
1449+
You can find more information about this in
1450+
`UnifySDK: .uam file documentation <https://siliconlabs.github.io/UnifySDK/doc/how_to_write_uam_files>`_
14481451

14491452
So we need to map the second endpoint (``ep[1]``) tone play value to
14501453
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.
19571960

19581961
.. note::
19591962
If you use WSL
1960-
`usbipd<https://learn.microsoft.com/en-us/windows/wsl/connect-usb>`__
1963+
`usbipd <https://learn.microsoft.com/en-us/windows/wsl/connect-usb>`__
19611964
can help you connect your Z-Wave controller to ZPC.
19621965

19631966
**You can skip Step 5 - CTT includes DUT and move to the next step DUR

applications/zpc/how_to_interact_with_clusters.rst

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,10 @@
11
How to interact with clusters
22
=============================
33

4-
Unify internal model works with DotDot ZCL clusters. More info on this
5-
in :doc:`chapter 2 <../../doc/unify_specifications/Chapter02-ZCL-in-uic>` that
6-
describes how clusters are implemented in Unify and how to use them.
4+
Unify internal model works with DotDot ZCL clusters.
5+
More info on this in
6+
`UnifySDK specifications chapter 2 <https://siliconlabs.github.io/UnifySDK/doc/unify_specifications/Chapter02-ZCL-in-uic>`_
7+
that describes how clusters are implemented in Unify and how to use them.
78

89
ZPC attributes are not exposed to MQTT bus by default. To be able to interact
910
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

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,8 @@ they can also be used to:
1212

1313
### Guide for UAM files
1414

15-
Refer to [How to write UAM files](../../doc/how_to_write_uam_files.rst)
15+
Refer to
16+
[How to write UAM files](https://siliconlabs.github.io/UnifySDK/doc/how_to_write_uam_files)
1617

1718
### Attribute types
1819

applications/zpc/readme_certification.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -787,8 +787,8 @@ The ZPC controls partially the Multilevel Switch Command Class. It is possible
787787
to set and see the current level of a Multilevel Switch supporting node.
788788

789789
However, the model on which the Unify system and
790-
[Dev GUI](../dev_ui/dev_gui/readme_user.md) operate is based on
791-
The Dotdot model.
790+
[Dev GUI](https://siliconlabs.github.io/UnifySDK/applications/dev_ui/dev_gui/readme_user)
791+
operate is based on The Dotdot model.
792792

793793
This means that Multilevel Switch supporting node will be represented with both
794794
an OnOff and a Level functionality. The Level setting can be changed
@@ -848,7 +848,7 @@ states/events to the ZPC.
848848
Due to the very diverse nature of the Notifications states and events that
849849
can be reported via the Command Class, information from the command class is
850850
displayed in a few different places in the
851-
[Dev GUI](../dev_ui/dev_gui/readme_user.md).
851+
[Dev GUI](https://siliconlabs.github.io/UnifySDK/applications/dev_ui/dev_gui/readme_user)
852852

853853

854854
#### Node status
@@ -1057,7 +1057,7 @@ network vicinity.
10571057

10581058
The ZPC supports including other nodes using SmartStart. Detailed
10591059
steps to manipulate the SmartStart list are also given in the
1060-
[Dev GUI User's Guide](../dev_ui/dev_gui/readme_user.md).
1060+
[Dev GUI User's Guide](https://siliconlabs.github.io/UnifySDK/applications/dev_ui/dev_gui/readme_user).
10611061

10621062
### SmartStart List Format
10631063

applications/zpc/readme_user.md

Lines changed: 15 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -88,7 +88,7 @@ all information about the network and need to probe all nodes in the network.
8888
The best way to run ZPC is using the Systemd service that is
8989
installed with the Debian installer.
9090
For more information, see the
91-
[Unify Framework User guide](../../doc/unify_readme_user.md).
91+
[Unify Framework User guide](https://siliconlabs.github.io/UnifySDK/doc/unify_readme_user).
9292

9393
## Running ZPC From the Command Line
9494

@@ -173,13 +173,14 @@ echo 2 > /dev/ttyUSB0
173173

174174
The ZPC has the capability to perform Firmware Updates of end devices.
175175
Performing firmware updates requires
176-
[Image Provider](../image_provider/readme_user.md) application to be
177-
run and configured correctly. The section below discuss how to construct
176+
[Image Provider](https://siliconlabs.github.io/UnifySDK/applications/image_provider/readme_user)
177+
application to be run and configured correctly.
178+
The section below discuss how to construct
178179
UIID and VERSION information that are required to perform a firmware update of an
179180
end device.
180181

181182
Firmware updates can be triggered by providing the
182-
[Image Provider](../image_provider/readme_user.md)
183+
[Image Provider](https://siliconlabs.github.io/UnifySDK/applications/image_provider/readme_user)
183184
with compatible firmware images and meta data information.
184185

185186
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".
259260
### Examples
260261

261262
This section provides an example using the
262-
[Image Provider](../image_provider/readme_user.md) and
263-
[Developer GUI](../dev_ui/dev_gui/readme_user.md) to perform a firmware update of a PowerStrip sample application.
263+
[Image Provider](https://siliconlabs.github.io/UnifySDK/applications/image_provider/readme_user)
264+
and
265+
[Developer GUI](https://siliconlabs.github.io/UnifySDK/applications/dev_ui/dev_gui/readme_user)
266+
to perform a firmware update of a PowerStrip sample application.
264267

265268
First, make sure that the ZPC,
266-
[Image Provider](../image_provider/readme_user.md) and
267-
[Developer GUI](../dev_ui/dev_gui/readme_user.md)
269+
[Image Provider](https://siliconlabs.github.io/UnifySDK/applications/image_provider/readme_user)
270+
and
271+
[Developer GUI](https://siliconlabs.github.io/UnifySDK/applications/dev_ui/dev_gui/readme_user)
268272
are running.
269273

270274
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
293297

294298
Then, use the found UIID to configure the _image.json_ file from the image
295299
provider. Remember to set a version string as well as calculate the Md5 as
296-
described in the [Image Provider User Guide](../image_provider/readme_user.md):
300+
described in the
301+
[Image Provider](https://siliconlabs.github.io/UnifySDK/applications/image_provider/readme_user)
302+
:
297303

298304
```json
299305
{

0 commit comments

Comments
 (0)