...

EdgeX Service Configuration UI

EdgeX API Access

Enabling and Disabling Optional Services

Debugging Failures

...

The configuration parameters of EdgeX micro-services can be accessed through a Consul server on each edge node. The UI is accessible at the address http://node-address:8500/ui. The node address is automatically assigned by Kubernetes and can be confirmed using the kubectl get node -o wide command on the master node.

In order to access the configuration UI a login token is required. This can be acquired using the get-consul-acl-token.sh script in the edgex directory. Execute it as follows and it will print out the Consul access token:

get-consul-acl-token.sh pod-name

The pod-name parameter is the name of the EdgeX pod running on the node. This can be obtained with the kubectl get pod command on the master node. The name of the pod will be shown in the first column of the output, and will be "edgex-nodename-..."

Access the UI address through a web browser running on the master node, and click on the "log in" button in the upper right. You will be prompted to enter the access token. Copy the access token printed by the get-consul-acl-token.sh script into the text box and press enter to log in to the UI. See the EdgeX documentation and Consul UI documentation for more information.

EdgeX API Access

The EdgeX micro-services each support REST APIs which are exposed through an API gateway running on https://node-address:8443. The REST APIs are documented in the EdgeX documentation, and they are mapped to URLs under the API gateway address using path names based on the names of each micro-service. So, for example, the core-data service's ping interface can be accessed through https://node-address:8443/core-data/api/v2/ping. A partial list of these mappings can be found in the EdgeX introduction to the API gateway.

Note that the blueprint does not automatically generate signed certificates for the API gateway, so the certificate it uses by default will cause warnings if accessed using a web browser and require the -k option if using the curl tool.

There is more information about the API gateway in the EdgeX documentation.

Enabling and Disabling Optional Services

Three EdgeX micro-services can be enabled and disabled using variables in the deploy/playbook/group_vars/all/edgex.yml file. Set the variable to true to enable the micro-service the next time the edgex_start.yml playbook is run. Set the variable to false to disable that micro-service. The micro-service controlling variables are listed below:

• device_virtual: Enable or disable the device-virtual service, provided by EdgeX Foundry, used for testing.
• device_lora: Enable or disable the device-lora service, one of the custom services provided by this blueprint, which provides support for receiving readings and sending commands to remote sensors over LoRa low-power radio links.
• sync_app: Enable or disable the sync-app application service, the other custom service provided by this blueprint, which provides a way to forward sensor data to other edge nodes.

Debugging Failures

Consult the sections under Troubleshooting for commands to debug failures. In particular, using the kubectl commands described in Accessing Logs, and changing the log levels of services using the configuration UI described above, which can change the logging level of running services, can be useful.

Reporting a Bug

<TBD>

Uninstall Guide

Stopping EdgeX

...