Merging from develop

.github/workflows/pytest-auth.yml

@@ -38,6 +38,12 @@ jobs:
       # checkout the volttron repository and set current direectory to it
       - uses: actions/checkout@v2
 
+      # Install erlang for rabbitmq
+      - name: Install erlang
+        if: matrix.os != 'ubuntu-20.04'
+        run: |
+          sudo scripts/rabbit_dependencies.sh debian ${{ matrix.os }}
+
       # setup the python environment for the operating system
       - name: Set up Python ${{matrix.os}} ${{ matrix.python-version }}
         uses: actions/setup-python@v2
@@ -53,11 +59,17 @@ jobs:
           files: "env/bin/activate"
 
       # This step is only run if the cache wasn't able to be restored.
-      - name: Install dependencies
-        if: steps.check_files.outputs.files_exists != 'true'
+      - name: Install dependencies including rmq
+        if: steps.check_files.outputs.files_exists != 'true'  && matrix.os != 'ubuntu-20.04'
+        run: |
+          pip install wheel
+          python bootstrap.py --all --rabbitmq --force
+
+      - name: Install dependencies other than rmq
+        if: steps.check_files.outputs.files_exists != 'true' && matrix.os == 'ubuntu-20.04'
         run: |
           pip install wheel
-          python bootstrap.py --all  --force
+          python bootstrap.py --all --force
 
       - name: Install volttron
         run: |

.github/workflows/pytest-testutils.yml

@@ -27,6 +27,12 @@ jobs:
       # checkout the volttron repository and set current direectory to it
       - uses: actions/checkout@v2
 
+      # Install erlang for rabbitmq
+      - name: Install erlang
+        if: matrix.os != 'ubuntu-20.04'
+        run: |
+          sudo scripts/rabbit_dependencies.sh debian ${{ matrix.os }}
+
       # Attempt to restore the cache from the build-dependency-cache workflow if present then
       # the output value steps.check_files.outputs.files_exists will be set (see the next step for usage)
       - name: Set up Python ${{matrix.os}} ${{ matrix.python-version }}
@@ -41,12 +47,18 @@ jobs:
         with:
           files: "env/bin/activate"
 
-      # if cache wasn't restored then do an installation of the dependencies
-      - name: Install dependencies
-        if: steps.check_files.outputs.files_exists != 'true'
+      # This step is only run if the cache wasn't able to be restored.
+      - name: Install dependencies including rmq
+        if: steps.check_files.outputs.files_exists != 'true'  && matrix.os != 'ubuntu-20.04'
+        run: |
+          pip install wheel
+          python bootstrap.py --all --rabbitmq --force
+
+      - name: Install dependencies other than rmq
+        if: steps.check_files.outputs.files_exists != 'true' && matrix.os == 'ubuntu-20.04'
         run: |
           pip install wheel
-          python bootstrap.py --all  --force
+          python bootstrap.py --all --force
             
       - name: Install volttron
         run: |

docs/source/driver-framework/drivers-overview.rst

@@ -10,8 +10,8 @@ Platform Driver process.
 
 Driver instances are created by the Platform Driver when a new driver configuration is added to the configuration store.
 Drivers use the following topic pattern `devices/<campus>/<building>/<device id>`.  When a configuration file is added
-to the Platform Driver's store using this pattern, the Platform Driver creates a Driver Agent.  The Driver agent is in turn
-instantiated with a instance of the Interface class corresponding to the `driver_type` parameter in the configuration
+to the Platform Driver's store using this pattern, the Platform Driver creates a Driver Agent.  The Driver agent is then
+instantiated with an instance of the Interface class corresponding to the `driver_type` parameter in the configuration
 file.  The Interface class is responsible for implementing the communication paradigms of a device or protocol.  Once
 configured, the Platform Driver periodically polls the Driver Agent for data which is collected from the interface class.
 Additionally, points can be requested ad-hoc via the Platform Driver's JSON-RPC method "get_point". Points may be set
@@ -21,12 +21,10 @@ by using JSON-RPC with the Actuator agent to set up a schedule and calling the "
 Driver Conventions
 ******************
 
--  Drivers are polled by the Platform Driver agent and values can be set using the `Actuator Agent`
--  Drivers should have a 1-to-1 relationship with a device
--  Driver modules should be written in Python files in the `services/core/PlatformDriverAgent/platform_driver/interfaces`
-   directory in the VOLTTRON repository.  The platform driver will search for a Python file in this directory matching the
-   name provided by the `driver_type` value from the driver configuration when creating the Driver agent.
--  Driver code consists of an Interface class (exactly named), supported in most cases by one or more Register classes
+* Drivers are polled by the Platform Driver agent and values can be set using the `Actuator Agent`.
+* Drivers should have a 1-to-1 relationship with a device.
+* Driver modules should be written in Python files in the `services/core/PlatformDriverAgent/platform_driver/interfaces` directory in the VOLTTRON repository.  The platform driver will search for a Python file in this directory matching the name provided by the `driver_type` value from the driver configuration when creating the Driver agent.
+* Driver code consists of an Interface class (exactly named), supported in most cases by one or more Register classes.
 
 
 .. _Driver_Communication:
@@ -51,19 +49,19 @@ The diagram features several entities that comprise the platform and its connect
   message bus is built around existing message bus software; currently VOLTTRON supports RabbitMQ and ZeroMQ. The
   VOLTTRON integration includes Pub/Sub and JSON RPC interfaces for agent and driver communication.
 * VOLTTRON Platform Agents and Subsystems - These agents and subsystems are installed on the platform to manage the
-  platform. They provide many user facing functions, aid in communication and manage other agents and drivers.
-* User's Agents - These agents are either agents included in the core repository but installed by a user, or user built
+  platform. They provide many user facing functions, aid in communication, and manage other agents and drivers.
+* User's Agents - These agents are either agents included in the core repository but installed by a user or built by an end-user's
   agent modules. They may perform a huge variety of user specified tasks, including data collection, device control,
   simulation, etc.
-* Platform Driver Agent - This agent is installed by a user to facilitate communication with drivers. Drivers should not
-  communicated with directly - the platform driver implements several features for communicating with drivers to ensure
+* Platform Driver Agent - This agent facilitates communication with drivers. Agents should not
+  communicate directly with drivers. The platform driver implements several features for communicating with drivers to ensure
   smooth operation and consistent driver behavior.
-* Actuator agent - This agent is installed by user to provide scheduling capability for controlling drivers. The
+* Actuator agent - This agent provides scheduling capability for controlling drivers. The
   Platform Driver does not include protections for race conditions, etc. It is always recommended to use the Actuator
   agent to set values on a device.
 * Device Driver - Drivers are special purpose agents which provide an interface between the platform driver and devices
-  such as Modbus, and BACnet devices. Drivers implement a specific set of features for protecting device communication
-  ensuring uniform behaviors across different devices.
+  such as Modbus and BACnet devices. Drivers implement a specific set of features for protecting device communication and
+  ensure uniform behaviors across different devices.
 * Device - Devices may be low level physical computers for controlling various systems such as PLCs (Programmable Logic
   Controller), devices which communicate on the local network (such as a Smart T.V.), or devices which are accessed via
   a remote web API (other smart devices).
@@ -76,9 +74,9 @@ Connectivity of the platform follows the following paradigm:
 
 * Platform agents (including the Platform Driver and Actuator), subsystems, and user agents communicate with the message
   bus via a publish/subscribe system.
-* Agents can communicate "directly" to each other via JSONRPC calls - JSONRPC calls use the VOLTTRON message bus router
+* Agents can communicate "directly" to each other via JSONRPC (RPC). A JSONRPC call uses the VOLTTRON message bus router
   to "direct" messages to an intended recipient. RPC calls from an agent specify a function for the recipient to
-  perform including input parameters, and the response to the sender should contain the value output by the specified
+  perform including input parameters; the response to the sender should contain the value output by the specified
   function.
 * The Platform Driver will periodically poll device drivers. This functionality is intentionally not user-facing. The
   Platform Driver iterates over the configured drivers and calls their respective "scrape_all" methods. This will trigger
@@ -151,7 +149,7 @@ Installing the Fake Driver
 **************************
 
 The Fake Driver is included as a way to quickly see data published to the message bus in a format that mimics what a
-true driver would produce.  This is a simple implementation of the VOLTTRON driver framework.
+real driver would produce.  This is a simple implementation of the VOLTTRON driver framework.
 
 See :ref:`instructions for installing the fake driver <Fake-Driver-Install>`
 

docs/source/driver-framework/platform-driver/platform-driver.rst

@@ -88,7 +88,7 @@ The easiest way to install the requirements for drivers included in the VOLTTRON
 Platform Driver Configuration
 =============================
 
-The Platform Driver Agent configuration consists of general settings for all devices. The default values of the Master
+The Platform Driver Agent configuration consists of general settings for all devices. The default values of the Platform
 Driver should be sufficient for most users.  The user may optionally change the interval between device scrapes with the
 driver_scrape_interval.
 
@@ -152,13 +152,13 @@ The following settings are required for all device configurations:
     - **driver_config** - Driver specific setting go here. See below for driver specific settings.
     - **driver_type** - Type of driver to use for this device: bacnet, modbus, fake, etc.
     - **registry_config** - Reference to a configuration file in the configuration store for registers
-      on the device. See the `Registry-Configuration-File`_ section below or
-      and the :ref:`Adding Device Configurations to the Configuration Store <Adding-Devices-To-Config-Store>` section in
+      on the device. See the `Registry-Configuration-File`_ section below and/or
+      the :ref:`Adding Device Configurations to the Configuration Store <Adding-Devices-To-Config-Store>` section in
       the driver framework docs.
 
 These settings are optional:
 
-    - **interval** - Period which to scrape the device and publish the results in seconds. Defaults to 60 seconds.
+    - **interval** - Period to scrape the device and publish the results in seconds. Defaults to 60 seconds.
     - **heart_beat_point** - A Point which to toggle to indicate a heartbeat to the device. A point with this ``Volttron
       Point Name`` must exist in the registry.  If this setting is missing the driver will not send a heart beat signal
       to the device.  Heart beats are triggered by the :ref:`Actuator Agent <Actuator-Agent>` which must be running to
@@ -167,7 +167,7 @@ These settings are optional:
 
 These settings are used to create the topic that this device will be referenced by following the VOLTTRON convention of
 ``{campus}/{building}/{unit}``.  This will also be the topic published on, when the device is periodically scraped for
-it's current state.
+its current state.
 
 The topic used to reference the device is derived from the name of the device configuration in the store. See the
 :ref:`Adding Device Configurations to the Configuration Store <Adding-Devices-To-Config-Store>` section of the driver
@@ -239,7 +239,7 @@ is accessible with the Actuator Agent via `PNNL/ISB1/vav1`.
 The name of a registry configuration must match the name used to refer to it in the driver configuration.  The reference
 is not case sensitive.
 
-If the Platform Driver Agent is running any changes to the configuration store will immediately affect the running devices
+If the Platform Driver Agent is running, any changes to the configuration store will immediately affect the running devices
 according to the changes.
 
 Example
@@ -279,7 +279,7 @@ Converting Old Style Configuration
 The new Platform Driver no longer supports the old style of device configuration.  The old `device_list` setting is
 ignored.
 
-To simplify updating to the new format `scripts/update_platform_driver_config.py` is provide to automatically update to
+To simplify updating to the new format, `scripts/update_platform_driver_config.py` is provided to automatically update to
 the new configuration format.
 
 With the platform running run:
@@ -288,12 +288,12 @@ With the platform running run:
 
     python scripts/update_platform_driver_config.py <old configuration> <output>
 
-old_configuration`` is the main configuration file in the old format. The script automatically modifies the driver
+`old_configuration` is the main configuration file in the old format. The script automatically modifies the driver
 files to create references to CSV files and adds the CSV files with the appropriate name.
 
 `output` is the target output directory.
 
-If the ``--keep-old`` switch is used the old configurations in the output directory (if any) will not be deleted before
+If the ``--keep-old`` switch is used, the old configurations in the output directory (if any) will not be deleted before
 new configurations are created.  Matching names will still be overwritten.
 
 The output from `scripts/update_platform_driver_config.py` can be automatically added to the configuration store
@@ -307,7 +307,7 @@ the process of changing and updating a large number of configurations. See the `
 Device Scalability Settings
 ---------------------------
 
-In order to improve the scalability of the platform unneeded device state publishes for a device can be turned off.
+To improve the scalability of the platform, unneeded device state publishes for a device can be turned off.
 All of the following setting are optional and will override the value set in the main platform driver configuration.
 
     - **publish_depth_first_all** - Enable "depth first" publish of all points to a single topic.
@@ -339,8 +339,8 @@ Polling
 
 Once running, the Platform Driver will spawn drivers using the `driver_type` parameter of the
 :ref:`driver configuration <Driver-Configuration-File>` and periodically poll devices for all point data specified in
-the :ref:`registry configuration <Registry-Configuration-File>` (at the interval specified by the interval parameter
-of the driver configuration).
+the :ref:`registry configuration <Registry-Configuration-File>` at the interval specified by the interval parameter
+of the driver configuration.
 
 By default, the value of each register on a device is published 4 different ways when the device state is published.
 Consider the following settings in a driver configuration stored under the name ``devices/pnnl/isb1/vav1``:
@@ -355,14 +355,14 @@ Consider the following settings in a driver configuration stored under the name
         "registry_config":"config://registry_configs/vav.csv",
     }
 
-In the `vav.csv` file is a register with the name `temperature`.  For these examples the current value of the
+In the `vav.csv` file, a register has the name `temperature`.  For these examples the current value of the
 register on the device happens to be 75.2 and the meta data is
 
 .. code-block:: json
 
     {"units": "F"}
 
-When the driver publishes the device state the following 2 things will be published for this register:
+When the driver publishes the device state the following two things will be published for this register:
 
     A "depth first" publish to the topic `devices/pnnl/isb1/vav1/temperature` with the following message: