feat: update docs for edgex 3.0 update

docs_src/automated-checkout-services/application_services.md → docs_src/automated-vending-services/application_services.md

@@ -1,12 +1,12 @@
 
 # Application Services
 
-The **Automated Checkout** reference implementation utilizes two application services that are used to consume event data from the EdgeX framework.
+The **Automated Vending** reference implementation utilizes two application services that are used to consume event data from the EdgeX framework.
 
 ## List of application services
 
 - Controller Board Status – Handles events coming from the controller board device service.
-- Vending – The main business logic for the Automated Checkout application. This service handles events directly from the card reader device service and inference engine as well as coordinates data between each of the microservices.
+- Vending – The main business logic for the Automated Vending application. This service handles events directly from the card reader device service and inference engine as well as coordinates data between each of the microservices.
 
 ## Controller board status application service
 
@@ -118,7 +118,7 @@ If the `door_closed` property is different than what `as-vending` currently beli
 
 ### `POST`: `/resetDoorLock`
 
-The `POST` call will simply reset the Automated Checkout's internal `vendingState`. This API endpoint has no logic to process any input data - it just responds to a simple `POST`.
+The `POST` call will simply reset the Automated Vending's internal `vendingState`. This API endpoint has no logic to process any input data - it just responds to a simple `POST`.
 
 Simple usage example:
 

docs_src/automated-checkout-services/device_services.md → docs_src/automated-vending-services/device_services.md

@@ -1,6 +1,6 @@
 # Device Services
 
-The **Automated Checkout** reference implementation utilizes three device services that are used to communicate hardware event data to underlying EdgeX framework.
+The **Automated Vending** reference implementation utilizes three device services that are used to communicate hardware event data to underlying EdgeX framework.
 
 ## List of device services
 
@@ -12,7 +12,7 @@ The **Automated Checkout** reference implementation utilizes three device servic
 
 ### Card reader description
 
-The `ds-card-reader` device service is an EdgeX device service that allows a USB-based RFID card reader to grant access to the Automated Checkout. At a high level, this device service is responsible for discovering a specific card reader device, watching for input from that device, parsing that input, and then forwarding the input into the EdgeX framework.
+The `ds-card-reader` device service is an EdgeX device service that allows a USB-based RFID card reader to grant access to the Automated Vending. At a high level, this device service is responsible for discovering a specific card reader device, watching for input from that device, parsing that input, and then forwarding the input into the EdgeX framework.
 
 There are two different modes available to this device service:
 
@@ -118,7 +118,7 @@ curl -X PUT -H "Content-Type: application/json" -d '{"lock1":"0"}' http://localh
 This `PUT` command will operate magnetic `lock2`. Depending on the numeric value of `lock2` (boolean `0/1`), the lock state will either be locked or unlocked.
 
 !!! note
-    Currently `lock2` has no purpose. During the initial architect/design phase of Automated Checkout, there were two locks. This was later reduced to a single mag-lock.
+    Currently `lock2` has no purpose. During the initial architect/design phase of Automated Vending, there were two locks. This was later reduced to a single mag-lock.
 
 Sample usage:
 
@@ -265,12 +265,12 @@ The following picture illustrates the flow to calculate the inventory deltas bet
     <img src="../images/delta.png">
 </p>
 
-The Automated Checkout architecture uses three MQTT topics:
+The Automated Vending architecture uses three MQTT topics:
 
 | Topic                       | Description                                                                                             |
 | ----------------------------- | ------------------------------------------------------------------------------------------------ |
 | Inference/CommandTopic                  | All events pushed from EdgeX's command API are fed into this topic. The [`as-vending`](https://github.com/intel-iot-devkit/automated-checkout/blob/master/as-vending) and [`as-controller-board-status`](https://github.com/intel-iot-devkit/automated-checkout/blob/master/as-controller-board-status) are two services that make requests to this API, typically for making door close/open and heartbeat events. |
-| Inference/ResponseTopic  | The Automated Checkout cv inference service will respond to published messages on the `Inference/CommandTopic` topic on the `Inference/ResponseTopic` topic. |
+| Inference/ResponseTopic  | The Automated Vending cv inference service will respond to published messages on the `Inference/CommandTopic` topic on the `Inference/ResponseTopic` topic. |
 | Inference/DataTopic                | The cv inference service publishes delta SKUs on this topic, then the MQTT device service converts them into EdgeX event readings, and finally the [`as-vending`](https://github.com/intel-iot-devkit/automated-checkout/blob/master/as-vending) service processes the event readings and pushes them to downstream services. |
 
 ### CV inference APIs
@@ -279,7 +279,7 @@ The Automated Checkout architecture uses three MQTT topics:
 
 #### `GET`: `http://localhost:59982/api/v2/device/name/Inference-device/inferenceHeartbeat`
 
-The `GET` call to the EdgeX MQTT device service's `inferenceHearbeat` command will act as a health-check for the Automated Checkout cv inference service. It must return `200 OK` upon swiping an RFID card in order for the vending workflow to begin. If it does not, the [`as-vending`](https://github.com/intel-iot-devkit/automated-checkout/blob/master/as-vending) service will enter maintenance mode.
+The `GET` call to the EdgeX MQTT device service's `inferenceHearbeat` command will act as a health-check for the Automated Vending cv inference service. It must return `200 OK` upon swiping an RFID card in order for the vending workflow to begin. If it does not, the [`as-vending`](https://github.com/intel-iot-devkit/automated-checkout/blob/master/as-vending) service will enter maintenance mode.
 
 Simple usage example:
 

docs_src/automated-checkout-services/micro_services.md → docs_src/automated-vending-services/micro_services.md

@@ -1,11 +1,11 @@
 # Other Microservices
 
-The Automated Checkout reference implementation utilizes three services that expose REST API endpoints. These three services handle business logic for the Automated Checkout reference implementation, and are somewhat generic in their design patterns, so for the purposes of the reference implementation, we simply refer to them  "microservices".
+The Automated Vending reference implementation utilizes three services that expose REST API endpoints. These three services handle business logic for the Automated Vending reference implementation, and are somewhat generic in their design patterns, so for the purposes of the reference implementation, we simply refer to them  "microservices".
 
 ## List of microservices
 
 - [Authentication](#authentication-service) - Service that takes a card ID number and returns authentication/authorization status for the card number.
-- [Inventory](#inventory-service) - Service that manages changes to the Automated Checkout's inventory, including storing transactions in an audit log.
+- [Inventory](#inventory-service) - Service that manages changes to the Automated Vending's inventory, including storing transactions in an audit log.
 - [Ledger](#ledger-service) - Service that stores customer financial transactions.
 
 ## Authentication service
@@ -16,7 +16,7 @@ The `ms-authentication` microservice is a service that works with EdgeX to expos
 
 This repository contains logic for working within the following schemas:
 
-- _Card/Cards_ - swiping a card is what allows the Automated Checkout automation to proceed with its workflow. A card can be associated with one of 3 roles:
+- _Card/Cards_ - swiping a card is what allows the Automated Vending automation to proceed with its workflow. A card can be associated with one of 3 roles:
   - Consumer - a typical customer; is expected to open the vending machine door, remove an item, close the door and be charged accordingly
   - Stocker - a person that is authorized to re-stock the vending machine with new products
   - Maintainer - a person that is authorized to fix the software/hardware
@@ -78,7 +78,7 @@ This repository contains logic for working within the following schemas:
   - `minRestockingLevel` - the minimum allowable number of units of this type to be stored in the vending machine
   - `createdAt` - the date the inventory item was created and catalogued
   - `updatedAt` - the date the inventory item was last updated (either via a transaction or something else)
-  - `isActive` - whether or not the inventory item is "active", which is not currently actively used by the Automated Checkout reference implementation for any specific purposes
+  - `isActive` - whether or not the inventory item is "active", which is not currently actively used by the Automated Vending reference implementation for any specific purposes
 - _Audit Log_ - an audit log entry contains the following attributes:
   - `cardId` - card number
   - `accountId` - account number

docs_src/configuration.md

@@ -1,29 +1,13 @@
 # Configuration
 
-This page lists all of the relevant configuration parameters for each service in the Automated Checkout reference implementation.
+This page lists all of the relevant configuration parameters for each service in the Automated Vending reference implementation.
 
 !!!info
     Note that this document likely does not cover EdgeX-specific configuration parameters. Application and device service SDK documentation can be found in the [EdgeX Foundry GitHub repositories](https://github.com/edgexfoundry) or in the [official EdgeX documentation here](https://docs.edgexfoundry.org/2.2/).
 
 ## Environment overrides
 
-The simplest way to change one of the configuration values described below is via the use of environment variable overrides in the docker compose file. The value of each configuration item in a service's configuration can be overridden with an environment variable specific to that item. The name of the environment variable is the path to the item in the configuration tree with underscores separating the nodes. The character case of each node in the environment variable name must match that found in the service's configuration. Here are a few examples for the `DriverConfig` section:
-
-```toml
-[DriverConfig]
-  VID = "65535" # 0xFFFF
-  PID = "53"    # 0x0035
-```
-
-```yaml
-Driver_VID: "256" ** Good **
-Driver_PID: "26"  ** Good **
-
-DRIVER_VID: "256" ** BAD **
-driver_pid: "26"  ** BAD **
-```
-
-These overrides are placed in the target service's environment section of the compose file. Here is an example:
+The simplest way to change one of the configuration values described below is via the use of environment variable overrides in the docker compose file. The value of each configuration item in a service's configuration can be overridden with an environment variable specific to that item. The name of the environment variable is the path to the item in the configuration tree with underscores separating the nodes. The character case of each node in the environment variable name must match that found in the service's configuration. These overrides are placed in the target service's environment section of the compose file. Here is an example:
 
 ```yaml
   ds-card-reader:
@@ -39,7 +23,7 @@ These overrides are placed in the target service's environment section of the co
 
 ## Card reader device service
 
-The following items can be configured via the `DriverConfig` section of the service's [configuration.toml](https://github.com/intel-iot-devkit/automated-checkout/blob/master/ds-card-reader/res/configuration.toml) file. All values are strings.
+The following items can be configured via the `DriverConfig` section of the service's [configuration.yaml](https://github.com/intel-retail/automated-vending/blob/Edgex-3.0/ds-card-reader/res/configuration.yaml) file. All values are strings.
 
 - `DeviceSearchPath` - the bash globstar expression to use when searching for the raw input device, default is `/dev/input/event*`
 - `VID` - the `uint16` value (as a base-10 string) corresponding to the Vendor ID of the USB device (run `lsusb` to list VID and PID values of connected USB devices). For example, if the VID is `ffff` in the output of `lsusb`, it is `"65535"` in the configuration file
@@ -48,7 +32,7 @@ The following items can be configured via the `DriverConfig` section of the serv
 
 ## Controller board device service
 
-The following items can be configured via the `DriverConfig` section of the service's [configuration.toml](https://github.com/intel-iot-devkit/automated-checkout/blob/master/ds-controller-board/res/configuration.toml) file. All values are strings.
+The following items can be configured via the `DriverConfig` section of the service's [configuration.yaml](https://github.com/intel-retail/automated-vending/blob/Edgex-3.0/ds-controller-board/res/configuration.yaml) file. All values are strings.
 
 - `DisplayTimeout` - The value in seconds corresponding to the display timeout length before resetting the display to the status display.
 - `LockTimeout` - The value in seconds corresponding to the lock timeout used to automatically lock the door in case no lock command was sent
@@ -58,19 +42,15 @@ The following items can be configured via the `DriverConfig` section of the serv
 
 ## EdgeX MQTT device service
 
-This reference implementation uses the [MQTT Device Service](https://github.com/edgexfoundry/device-mqtt-go) from EdgeX with custom device profiles. These device profiles YAML files are located [here](https://github.com/intel-iot-devkit/automated-checkout/blob/master/res/device-mqtt/profiles/inference-mqtt-device-profile.yml) and are volume mounted into the device service's running Docker container.
+This reference implementation uses the [MQTT Device Service](https://github.com/edgexfoundry/device-mqtt-go) from EdgeX with custom device profiles. These device profiles YAML files are located [here](https://github.com/intel-retail/automated-vending/blob/Edgex-3.0/res/device-mqtt/profiles/inference-mqtt-device-profile.yml) and are volume mounted into the device service's running Docker container.
 
-The following items can be configured via `MQTTBrokerInfo` section of the service's [configuration.toml](https://github.com/intel-iot-devkit/automated-checkout/blob/master/res/device-mqtt/configuration.toml) file. All values are strings.
+The following items can be configured via `device-mqtt.environment` section of the service's [docker-compose.edgex.yml](https://github.com/intel-retail/automated-vending/blob/Edgex-3.0/docker-compose.edgex.yml) file.
 
-`MQTTBrokerInfo`
+`device-mqtt.environment`
 
-- `Schema` - Data schema type, aka protocol
-- `Host` - Host name of the response MQTT Broker
-- `Port` - Port number of the response MQTT Broker
-- `Qos` - Quality of service agreement between sender and receiver
-- `KeepAlive` - Keep alive duration for the response MQTT Broker
-- `ClientId` - Client ID for the response MQTT Broker
-- `ResponseTopic` - Subscribe topic for the response MQTT Broker
+- `MQTTBROKERINFO_HOST` - Host name of the response MQTT Broker
+- `MQTTBROKERINFO_INCOMINGTOPIC` - Subscribe topic for incoming data from MQTT Broker
+- `MQTTBROKERINFO_RESPONSETOPIC` - Subscribe topic for the response MQTT Broker
 
 ## CV inference device service
 
@@ -101,7 +81,7 @@ Example:
 
 ## Controller board status application service
 
-The following items can be configured via the `ControllerBoardStatus` section of the service's [configuration.toml](https://github.com/intel-iot-devkit/automated-checkout/blob/master/as-controller-board-status/res/configuration.toml) file. All values are strings.
+The following items can be configured via the `ControllerBoardStatus` section of the service's [configuration.yaml](https://github.com/intel-retail/automated-vending/blob/Edgex-3.0/as-controller-board-status/res/configuration.yaml) file. All values are strings.
 
 - `AverageTemperatureMeasurementDuration` - The time-duration string (i.e. `-15s`, `-10m`) value of how long to process temperature measurements for calculating an average temperature. This calculation determines how quickly a "temperature threshold exceeded" notification is sent
 - `DeviceName` - The string name of the upstream EdgeX device that will be pushing events & readings to this application service
@@ -112,7 +92,7 @@ The following items can be configured via the `ControllerBoardStatus` section of
 - `NotificationEmailAddresses` - A comma-separated values (CSV) string of emails to send notifications to
 - `NotificationLabels` - A comma-separated values (CSV) string of labels to apply to notifications, which are handled by EdgeX
 - `NotificationReceiver` - The human-readable string name of the person/entity receiving the notification, such as `System Administrator`
-- `NotificationSender` - The human-readable string name of the person/entity sending the notification, such as `Automated Checkout Maintenance Notification`
+- `NotificationSender` - The human-readable string name of the person/entity sending the notification, such as `Automated Vending Maintenance Notification`
 - `NotificationSeverity` - A string tag indicating the severity of the notification, such as `CRITICAL`
 - `NotificationName` - A string that is a short label that may be used as part of a URL to delineate the notification subscription, such as `sys-admin`. The EdgeX official documentation says, _"Effectively a name or key that labels the notification"_.
 - `NotificationSubscriptionMaxRESTRetries` - The integer value that represents the maximum number of times to try creating a subscription in the EdgeX notification service, such as `10`
@@ -124,7 +104,7 @@ The following items can be configured via the `ControllerBoardStatus` section of
 
 ## Vending application service
 
-The following items can be configured via the `ApplicationSettings` section of the service's [configuration.toml](https://github.com/intel-iot-devkit/automated-checkout/blob/master/as-vending/res/configuration.toml) file. All values are strings.
+The following items can be configured via the `ApplicationSettings` section of the service's [configuration.yaml](https://github.com/intel-retail/automated-vending/blob/Edgex-3.0/as-vending/res/configuration.yaml) file. All values are strings.
 
 - `AuthenticationEndpoint` - Endpoint for authentication microservice
 - `ControllerBoarddisplayResetCmd` - EdgeX Command service command for Resetting the LCD text
@@ -157,6 +137,6 @@ For this particular microservice, there are no specific configuration options. F
 
 ## Ledger microservice
 
-The following items can be configured via the `[ApplicationSettings]` section of the service's [configuration.toml](https://github.com/intel-iot-devkit/automated-checkout/blob/master/ms-ledger/res/configuration.toml) file. All values are strings.
+The following items can be configured via the `[ApplicationSettings]` section of the service's [configuration.yaml](https://github.com/intel-retail/automated-vending/blob/Edgex-3.0/ms-ledger/res/configuration.yaml) file. All values are strings.
 
 - `InventoryEndpoint` - Endpoint that correlates to the Inventory microservice. This is used to query Inventory data used to generate the ledgers.