From 48175f0dc24c0fdbf53b7ba7b062aee37d5cba1e Mon Sep 17 00:00:00 2001 From: Melody Date: Tue, 4 Feb 2025 17:56:36 +0800 Subject: [PATCH] fix: remove WalkthroughDeviceService on docs Signed-off-by: Melody --- .../Ch-WalkthroughDeviceProfile.md | 2 +- .../Ch-WalkthroughDeviceService.md | 72 ------------------- .../walk-through/Ch-WalkthroughProvision.md | 5 +- mkdocs.yml | 1 - 4 files changed, 3 insertions(+), 77 deletions(-) delete mode 100644 docs_src/walk-through/Ch-WalkthroughDeviceService.md diff --git a/docs_src/walk-through/Ch-WalkthroughDeviceProfile.md b/docs_src/walk-through/Ch-WalkthroughDeviceProfile.md index a43a1e7a8e..fbb327ad89 100644 --- a/docs_src/walk-through/Ch-WalkthroughDeviceProfile.md +++ b/docs_src/walk-through/Ch-WalkthroughDeviceProfile.md @@ -140,4 +140,4 @@ Click on the link below to download and save the device profile (YAML) to your s #### Test the GET API If you make a GET call to the `http://localhost:59881/api/{{api_version}}/deviceprofile/all` URL (with Postman or curl) you will get a listing (in JSON) of all the device profiles (and all of its associated `deviceResource` and `deviceCommand`) currently defined in your instance of EdgeX, including the one you just added. -[](Ch-WalkthroughDeviceService.md){: .md-button } +[](Ch-WalkthroughProvision.md){: .md-button } diff --git a/docs_src/walk-through/Ch-WalkthroughDeviceService.md b/docs_src/walk-through/Ch-WalkthroughDeviceService.md deleted file mode 100644 index 8d2f16db44..0000000000 --- a/docs_src/walk-through/Ch-WalkthroughDeviceService.md +++ /dev/null @@ -1,72 +0,0 @@ -# Register your device service - -Our next task in this walkthrough is to have the device service register or define -itself in EdgeX. That is, it can proclaim to EdgeX that "I have arrived -and am functional." - -## Register with Core Configuration and Registration - -Part of that registration process of the device service, indeed any -EdgeX micro service, is to register itself with the [core configuration & -registration](../microservices/configuration/ConfigurationAndRegistry.md). In this process, the micro service provides its location -to the Config/Reg micro service and picks up any new/latest -configuration information from this central service. Since there is no -real device service in this walkthrough demonstration, this part of the inter-micro -service exchange is not explored here. - -## Device Service - -See [core metadata API](../../api/core/Ch-APICoreMetadata) for more details. - -At this point in your walkthrough, the device service must create a representative instance of itself in core -metadata. It is in this registration that the device service is -given an address that allows core command or any EdgeX service to communicate with it. - -The name of the device service must be unique across all of EdgeX. When registering a device service, the initial admin state can be provided. The administrative state (aka admin state) provides control of the device service by man or other systems. -It can be set to `LOCKED` or `UNLOCKED`. When a device service is set to -`LOCKED`, it is not suppose to respond to any command requests nor send -data from the devices. See [Admin State documentation](../microservices/device/details/DeviceDiscovery.md#admin-state) for more details. - -### Walkthrough - Device Service - -Use either the Postman or Curl tab below to walkthrough creating the `DeviceService`. - -=== "Postman" - - Make a POST request to `http://localhost:59881/api/{{api_version}}/deviceservice` with the following body: - - ``` json - { - "apiVersion" : "{{api_version}}", - "service": { - "name": "camera-control-device-service", - "description": "Manage human and dog counting cameras", - "adminState": "UNLOCKED", - "labels": [ - "camera", - "counter" - ], - "baseAddress": "camera-device-service:59990" - } - } - ``` - - Be sure that you are POSTing **raw** data, not form-encoded data. If your API call is successful, you will get a generated ID for your new `DeviceService` in the response area. - -=== "Curl" - - Make a curl POST request as shown below. - - ``` shell - - curl -X 'POST' 'http://localhost:59881/api/{{api_version}}/deviceservice' -d '[{"apiVersion" : "{{api_version}}","service": {"name": "camera-control-device-service","description": "Manage human and dog counting cameras", "adminState": "UNLOCKED", "labels": ["camera","counter"], "baseAddress": "camera-device-service:59990"}}]' - - ``` - - If your API call is successful, you will get a generated ID for your new `DeviceService`. - -#### Test the GET API -If you make a GET call to the `http://localhost:59881/api/{{api_version}}/deviceservice/all` URL (with Postman or curl) you will get a listing (in JSON) of all the device services currently defined -in your instance of EdgeX, including the one you just added. - -[](Ch-WalkthroughProvision.md){: .md-button } diff --git a/docs_src/walk-through/Ch-WalkthroughProvision.md b/docs_src/walk-through/Ch-WalkthroughProvision.md index b1e9ae0c92..4081e3191c 100644 --- a/docs_src/walk-through/Ch-WalkthroughProvision.md +++ b/docs_src/walk-through/Ch-WalkthroughProvision.md @@ -18,8 +18,7 @@ For the sake of this demonstration, the call to core metadata will provision the human/dog counting monitor camera as if the device service discovered it (by some unknown means) and provisioned the device as part of some startup process. To create a `Device`, it must be associated to a -[`DeviceProfile`](./Ch-WalkthroughDeviceProfile.md), a -[`DeviceService`](./Ch-WalkthroughDeviceService.md), and +[`DeviceProfile`](./Ch-WalkthroughDeviceProfile.md) and contain one or more `Protocols` that define how and where to communicate with the device (possibly providing its address). When creating a device, you specify both the admin state (just as you did for a device service) and an operating state. The operating state (aka op state) provides an indication on the part of EdgeX about the internal operating status of the device. The operating state is not set externally (as by another system or man), it is a signal from within EdgeX (and potentially the device service itself) about the condition of the device. The operating state of the device may be either `UP` or `DOWN` (it may alsy be `UNKNOWN` if the state cannot be determined). When the operating state of the device is `DOWN`, it is either experiencing some difficulty or going through some process (for example an upgrade) which does not allow it to function in its normal capacity. @@ -88,4 +87,4 @@ all devices associated to a given `DeviceProfile`. curl -X GET http://localhost:59881/api/{{api_version}}/device/profile/name/camera-monitor-profile | json_pp ``` -[](Ch-WalkthroughCommands.md){: .md-button } +[](Ch-WalkthroughCommands.md){: .md-button } diff --git a/mkdocs.yml b/mkdocs.yml index bfd26efefd..1272bdcee6 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -367,7 +367,6 @@ nav: - walk-through/Ch-WalkthroughSetup.md - walk-through/Ch-WalkthroughUseCase.md - walk-through/Ch-WalkthroughDeviceProfile.md - - walk-through/Ch-WalkthroughDeviceService.md - walk-through/Ch-WalkthroughProvision.md - walk-through/Ch-WalkthroughCommands.md - walk-through/Ch-WalkthroughReading.md