General Operation

Startup Sequence

The following operations are performed when the gateway is powered on:

• Core modules are imported and core objects are initialized. The gateway will then load the modules and objects specified in the configuration files (See Saved Files). Once this completes, all RPC requests will be registered and available for use. Note that some RPC requests require certain conditions to function properly, such as time to be synchronized or the gateway to be joined to a network.
• The gateway waits for its XBee radio to report that it is joined to a network. Until the radio reports that it is joined to a network, ZigBee communications will be disabled.
• The gateway attempts to synchronize its time with an appropriate time server. Some features of the gateway that rely on knowing the current time, such as those related to Smart Energy events, cannot function until the gateway’s time has been synchronized.

See Asynchronous Message Reference for details on notification messages generated during gateway startup.

Time Synchronization

Before 1.5.0:

Time on the gateway can be synchronized in three ways:

• NTP server
• ZCL time server on the gateway’s ZigBee network
• RPC call (see set_time)

By default, the gateway will choose to use NTP synchronization if it does not have a ZCL time client, and will use ZCL synchronization if it does have a ZCL time client. Additionally, note that ZCL time synchronization cannot occur until the gateway has joined to a ZigBee network and detected a ZCL time server. Time is periodically resynchronized in order to prevent significant drift of the gateway’s clock.

The decision of what type of time synchronization to use, as well as the synchronization period, can be overridden with registry settings (see “Time_Synchronizer” in Registry Settings).

Note

Do NOT use the operating system to configure NTP on the gateway. This may cause serious problems, especially when the gateway is configured to use ZCL time.

As of 1.5.0:

By default, the operating system of the gateway is responsible for synchronizing to NTP and providing the gateway with UTC time. The Python code can still perform NTP synchronization, but the functionality has been deprecated and may be removed in future releases.

The gateway will now store an offset from NTP time to create a network time. The network time is used for all timing of events on the ZigBee network. The NTP UTC time is used for timestamps when communicating over the Internet.

By default, the gateway will set the network offset to zero if it does not have a ZCL time client, and will use ZCL synchronization to set the offset if it does have a ZCL time client. Additionally, note that ZCL time synchronization cannot occur until the gateway has joined to a ZigBee network and detected a ZCL time server. Time is periodically resynchronized in order to prevent significant drift of the gateway’s clock.

The decision of what type of time synchronization to use for the network time, as well as the synchronization period, can be overridden with registry settings (see the “Time_Synchronizer” settings in Registry Settings).

As of 1.6.5:

By default, this registry setting is disabled to ensure timezone continuity during upgrades.

• Disabled: When time synchronization is disabled, the gateway will set the network offset to zero if it does not have a ZCL time client, and will use ZCL synchronization to set the offset if it does have a ZCL time client. Additionally, note that ZCL time synchronization cannot occur until the gateway has joined to a ZigBee network and detected a ZCL time server. Time is periodically resynchronized in order to prevent significant drift of the gateway’s clock.
• Enabled: When time synchronization is enabled, the device uses the OS timezone. You can use set_timezone, clear_timezone, and ZCL attributes to override the OS timezone. The device uses the OS timezone when you do not set a timezone or when you clear the timezone setting using clear_timezone.

To use the OS timezone, enable this registry setting and send clear_timezone to remove previously configured timezone settings.

Remote Device Management

The gateway will keep track of basic information about devices on the network and whether devices appear to be actively communicating.

Device Activity

A remote device is detected as active when it responds to a specific ZDO match descriptor request sent by the gateway. This request is generated when any of the following occurs:

• A non-ZDO message is received by the gateway from a known device that is not currently marked as active.
• A non-ZDO message is received by the gateway from an unknown device, and the gateway is in open joining mode (the default behavior). See also: Explicit Device Add and Open Join
• The periodic refresh period has passed. See also: “ZDO_Device_Manager.refresh_interval” in Registry Settings

A device which is currently active will remain active so long as:

• Transmission errors to the device do not occur. Transmission errors refer specifically to non-success TX status values reported by the XBee radio.
• The device responds to match descriptor requests sent by the periodic refresh.

If communication to a device fails, as described above, a sufficient number of times in a row (see “ZDO_Device_Manager.max_sequential_TX_failures” in Registry Settings), the device will be marked as inactive. Of particular note, this means that devices which have dropped off the network will eventually be marked as inactive due to the periodic refresh.

Device Discovery

The gateway will maintain information about all known devices on the network. This is performed through ZDO discovery.

When a device is first detected as active, the following ZDO queries are sent:

• Node Descriptor
• Power Descriptor
• Active Endpoints

When the active endpoints response is received, the following is generated for each reported endpoint:

• Simple Descriptor

In this way, the gateway determines which clusters are available on each remote device. This information is used by the gateway primarily to pair local ZCL server and client clusters with their remote counterparts. This matching is in turn used as an alternative to requiring ZDO bind requests.

If the gateway receives communication from a remote device for an endpoint that did not previously detect, the gateway will send a ZDO active endpoints request to that device followed by simple descriptor requests as appropriate. Similarly, if the gateway receives communication from a remote device for a cluster that it did not previously detect, the gateway will send a ZDO simple descriptor request.

The ZDO discovery information about devices on the network will be retained when devices are marked inactive. Specifically, if a remote device is marked inactive and then later marked active again, ZDO queries will not be re-sent. However, discovery information is not power safe and will be queried again if the gateway is restarted.

SE Server Clusters and Device Activity

If an SE server cluster on the gateway is notified of a matching client cluster on a remote device, that client cluster will be added to the list of known SE client clusters for that particular SE server cluster. The server cluster uses its list of known client clusters when performing certain SE server operations, such as sending out new SE events to all clients.

SE server clusters will try to guarantee that client devices receive events. If an event is not sent successfully to an active client device, or if a client device becomes active after an event has been sent and does not request the server’s events, the server will send its events to the client after some amount of time. See “SE_Server.event_retransmission_check_interval” in Registry Settings for details on configuration.

When a remote device is marked as inactive, any SE client clusters on the device will be removed from lists kept by the gateway’s corresponding SE server clusters.

SE Client Clusters and Device Activity

If an SE client cluster on the gateway is notified of a matching server cluster on a remote device, that server cluster will be added to the list of known SE server clusters for that particular SE client cluster. Additionally, when this notification occurs the SE events of the server cluster will be queried by the client automatically. The client cluster will also attempt to do a ZDO bind to the remote server cluster, in case the server cluster requires that clients bind to it. Afterwards, the client cluster uses its list of known server clusters when performing certain SE client operations, such as requesting or confirming events.

When a remote device is marked as inactive, any SE server clusters on the device will be removed from lists kept by the gateway’s corresponding SE client clusters.

Explicit Device Add and Open Join

The gateway can be in either open join or explicit device add mode. When in open join mode, any device can be marked active (see Device Activity). Devices that become active will be added to the gateway’s list of known devices. When in explicit device add mode, only devices which have previously been added as known devices can become active. In either mode, devices can be added to the list of known devices by using the RPC add_device command.

The gateway defaults to open join mode. (see “ZDO_Device_Manager.require_explicit_device_add” in Registry Settings)

ZCL Reporting

The gateway supports the sending and receiving of ZCL attribute reports. Any ZCL attribute on the gateway which is not write-only may be reported.

Attribute reporting configurations, and particularly their timers, are handled independently per attribute. This means that:

• Timeouts and min/max intervals of a given configuration will not affect other configurations.
• RPC messages (received_attribute_report_collection*) will be generated as reports are received for each attribute, and will not be combined.

Pseudo Reporting

The gateway supports a simulated report receiving mode called “pseudo reporting.” When a reporting configuration is set up to use pseudo reporting, periodic ZCL read attributes requests are sent to the remote device, rather than configuring the remote device to send reports on its own. These reads are processed in order to generate reports based on the specified min/max interval and delta change. As such, from an RPC interface perspective, pseudo reporting is typically indistinguishable from normal reporting. This allows a user to set up attribute reporting behavior on attributes which do not normally support ZCL reporting, in exchange for slightly more ZigBee traffic overhead. Also note that, unless explicitly disallowed, pseudo reporting will be used as a fallback if a normal ZCL reporting configuration request sent to a remote device is unsuccessful. For details on using pseudo reporting, see the start_receiving_reports RPC request.

Automatic Reconfiguration on Timeout

For normal ZCL reporting, should the gateway not receive a report from the remote device within the timeout specified by its configuration, it will re-send the configuration to the remote device. The intention is to cover for the remote device losing its configuration due to power loss or other fatal error.

Device Inactivity

Should the remote device involved in the reporting behavior be marked inactive:

• Configurations for receiving reports from that device will not time out. For normal reporting, this means that the configuration will not be re-sent on timeout.
• Pseudo reporting configurations for receiving reports will not send periodic reads to the device.
• Configurations for sending reports to that device will not send reports.

If the device is later marked active, reporting behavior will resume.

Registry

The registry is created when the gateway first boots and contains power-safe global settings to control various elements of gateway behavior. Individual entries can be accessed and modified through the registry_configuration RPC request. A help RPC request can be used to retrieve all available registry entries. Manually editing the registry file and rebooting is also possible but generally should not be necessary. See Registry Settings for a listing of all registry settings.

Power Safety

Certain information is automatically saved to flash in order to maintain gateway functionality in case of a power failure. During normal operations these files do not need to be modified directly. Generally, the following items are power safe:

• Endpoint and cluster configuration
• Certain ZCL attribute values
• Reporting configurations
• Smart Energy events on SE server clusters
• Registry settings
• Alias definitions

See Saved Files for further information.

Upgrade using Device Cloud

Use the following sections when upgrading the Smart Energy Framework, ZigBee radio firmware, and ConnectPort X2e for Smart Energy device firmware.

The following three components work together to create the same product configuration in your environment that Digi tests and certifies for operation of the product as a Smart Energy Gateway.

The three files in recommended installation order consist of:

• SE_Framework.zip - Smart Energy application code
• Radio.ebl - Firmware for the embedded ZigBee radio
• Gateway.bin - ConnectPort X2e for Smart Energy device firmware

Additionally, you will configure the device to the time zone where it will be deployed. This ensures proper handling of Daylight Savings Time start/end from year to year, where applicable.

Use your Device Cloud account to perform steps in the following sections. If you do not have an account, visit http://myacct.digi.com. All operations that we will perform can be accomplished using the free service tier.

Before you begin, do the following: - Make sure any gateways that you need to upgrade are part of your Device Cloud account. - Make sure you complete the steps from the Device Management > Devices tab in Device Cloud.

Upgrade Smart Energy Framework

When completing these steps, do not remove or rename any files other than instructed. All files are necessary to retain your current configuration and functionality.

From the Device Management > Devices tab in Device Cloud:

1. Double-click the gateway that you want to upgrade. The gateway details and configuration options appear.

2. Select Python to display start-up settings and a list of files.

3. Select the existing SE_Framework.zip file and click to red X to delete the file.

4. Click to upload the new SE_Framework.zip file.

5. In the dialog box, select the new SE_Framework.zip and click OK.

   

After uploading the SE_Framework.zip file, the gateway restarts to complete the upgrade.

Configure the Time Zone

The SE Framework application uses the gateway’s internal operating system to set the Smart Energy network time when using the gateway as a coordinator. The time zone setting also updates the gateway time for Daylight saving time (DST) start/end dates.

Note

You need to complete these steps any time you move your gateway to a different time zone.

1. Click Advanced Configuration > Time zone. The Timezone option appears (UTC is the factory default).
2. Select the time zone for the geographic location where you will deploy the gateway.
3. Click Save at the bottom of the page to update the setting.

Note

When using the ConnectPort X2e for Smart Energy as a router, the gateway gets the Smart Energy network local time from a Smart Meter Coordinator, when available. However, the gateway’s time zone setting is still used to manage the DST start/end value. Make sure you correctly configure this setting for proper operation.

Upgrade XBee Firmware

From the Device Management > Devices tab in Device Cloud:

1. Right-click the gateway you want to upgrade.
2. Select Firmware > Update Gateway XBee Radio Firmware.
3. Browse to the Radio.ebl file.
4. Click Update Firmware.

Upgrade ConnectPort X2e for Smart Energy Firmware

From the Device Management > Devices tab in Device Cloud:

1. Right-click the gateway you want to upgrade.

2. Select Firmware > Update Firmware.

3. Browse to the Gateway.bin file.

4. Click Update Firmware.

   The firmware upgrade process on your ConnectPort X2e for Smart Energy begins. Please allow several minutes for the process to complete. Your devices restarts after the upgrading to the new firmware. During this time, it disconnects from Device Cloud and is not immediately available when the update dialog closes.

Note

You can upgrade gateway firmware on a ConnectPort X2e gateway. However, you cannot downgrade to an older firmware version.

Smart Energy Plug-ins

Smart Energy networks contain a variety of devices: thermostats, load controllers, smart plugs, and so on. Many devices have functions beyond what is covered by the Smart Energy standard. For example, thermostats expose the capability to set schedules, adjust set-points, and read the current temperature; these capabilities are not defined in the Smart Energy standard. Digi provides plug-ins, which are software components—also known as drivers—that can expose additional functionality for many devices in Smart Energy networks.

Use the instructions in the following sections to install plug-ins or update them when your application does not update them automatically.

Note

If you use a custom application from a third-party service provider, do not update the plug-ins yourself. Contact your service provider for the required plug-in updates.

Available Plug-ins

For the devices in the list below, you must install a driver if you want to access additional capabilities (beyond what is covered in the Smart Energy standard). The list includes Digi-tested Smart Energy devices with driver support.

The complete list of Smart Energy plug-ins available from Digi are as follows: - Plug-in Manager (required before installing all other plug-ins) - Common Clusters Plug-in - Common Clusters Secure Plug-in - Computime Thermostat Plug-in - Energate Z100 Thermostat Plug-in - ERT Smart Energy Bridge Plug-in - Proxy Cluster Plug-in - Safe Plug Plug-in - Schneider EER56x00 Thermostat Plug-in - Thermostat Schedule Plug-in - Carrier Comfort Choice Thermostat Plug-in

For the devices listed in the following table, you must install a driver if you want to access additional capabilities (beyond what is covered in the Smart Energy standard). The list includes Digi-tested Smart Energy devices with driver support. If your device is not listed, Digi has not written a plug-in to support the device. Do not attempt to write your own plug-in. To add your device to the list, contact your Digi salesperson to request pricing for a custom driver.

Install Plug-in Manager

The Plug-in Manager is a software component that extends the Smart Energy Framework installed on your gateways. Install the Plug-in Manager before any other plug-ins so you can install, remove, and query the status of the other installed plug-ins.

To install Plug-in Manager:

1. Visit http://www.digi.com/support/productdetail?pid=5448&type=driver and click Drivers.
2. Download Digi Smart Energy Framework Plug-in: Plug-in Manager.
3. Extract the contents from the plug-in .zip file.
4. Sign in to your Device Cloud account.
5. Select the Device Management > Devices tab.
6. Double-click your gateway.
7. Select Python and click the upload file icon.
8. Navigate to the extracted buildspython2.7 folder for the Plug-in Manager.
9. Upload the plug-in package to the /WEB/python directory.

Install Plug-ins

Before installing a plug-in, you need a device equipped with the Smart Energy Framework and install the Plug-in Manager.

If a plug-in has dependent plug-ins, you must install the dependencies on the gateway first. Each plugin.yml file lists its plug-in dependencies.

The following table lists plug-in dependencies.

To install a plug-in package:

1. Visit http://www.digi.com/support/productdetail?pid=5448&type=driver and click Drivers to download the appropriate plug-in package.
2. Extract the contents from the plug-in .zip file.
3. Sign in to your Device Cloud account.
4. Select the Device Management > Devices tab.
5. Double-click your gateway.
6. Select Python and click the upload file icon.
7. Navigate to the extracted buildspython_2.7 folder for the plug-in package.
8. Upload the plug-in package(s) to the /WEB/python directory.
9. In Device Cloud, select Documentation > API Explorer.
10. Select POST in the HTTP method section.
11. Paste the following Install package request XML code into the text box, replacing $deviceId with the Device ID of your gateway and $packageName with the name of the plug-in package:

<sci_request version="1.0">
        <send_message>
                <targets>
                        <device id="$deviceId"/>
                </targets>
                <rci_request version="1.1">
                        <do_command target="RPC_request">
                                <install_package synchronous="true">
                                <filename type="string">$packageName</filename>
                                </install_package>
                        </do_command>
                </rci_request>
        </send_message>
</sci_request>

Install Existing Plug-ins

Examples for each of the commands used in this procedure are listed in the following Plug-ins Command Reference section.

1. Restart the gateway so all plug-in uploads take effect.
2. Stop all the plug-ins and their dependent processes by running stop_plugin.
3. Uninstall the plug-in you want to update by running uninstall_plugin.
4. Update the plug-in file using Device Cloud to perform a file upload.
5. Install the updated plug-in using install_package.
6. Restart the gateway to restart all the plug-ins that you stopped in Step 1.

Plug-ins Command Reference

This section (using the terms listed below) describes additional commands to help you manage the plug-ins installed on your gateway.

• A plug-in is enabled if it is configured to load whenever the Plug-in Manager starts.
• A plug-in is active if its configuration has been loaded by the Plug-in Manager. A plug-in becomes active after it is started, and inactive after it stops.

The Plug-in Manager exposes several RPC methods for interacting with plug-ins.

Commands

list_plugins: Gets the name and version of all plug-ins on the gateway.

Request

<sci_request version="1.0">
  <send_message>
   <targets>
    <device id="$deviceId"/>
   </targets>
   <rci_request version="1.1">
    <do_command target="RPC_request">
     <list_plugins synchronous="true"/>
    </do_command>
   </rci_request>
  </send_message>
 </sci_request>

Response

<sci_reply version="1.0">
  <send_message>
   <device id="$deviceId">
    <rci_reply version="1.1">
     <do_command target="RPC_request">
      <responses>
       <list_plugins_response>
        <count type="int">0x1</count>
        <plugins type="list">
         <item type="dict">
          <active type="bool">{TRUE|FALSE}</active>
          <version type="string">$pluginversion</version>
          <enabled type="string">{True|False}</enabled>
          <plugin_name type="string">$pluginName</plugin_name>
         </item>
        </plugins>
       </list_plugins_response>
      </responses>
     </do_command>
    </rci_reply>
   </device>
  </send_message>
 </sci_reply>

plugin_info: Gets the name, version, description, active state, and enabled state.

Request

<sci_request version="1.0">
  <send_message>
   <targets>
    <device id="$deviceId"/>
   </targets>
   <rci_request version="1.1">
    <do_command target="RPC_request">
     <plugin_info synchronous="true">
      <plugin_name type="string">$pluginName</plugin_name>
     </plugin_info>
    </do_command>
   </rci_request>
  </send_message>
 </sci_request>

Response

<sci_reply version="1.0">
  <send_message>
   <device id="$deviceId">
    <rci_reply version="1.1">
     <do_command target="rpc_request">
      <responses>
       <plugin_info_response>
        <active type="bool">{TRUE|FALSE}</active>
        <version type="string">$pluginVersion</version>
        <enabled type="string">{True|False}</enabled>
        <description type="string">$pluginDescription</description>
        <plugin_name type="string">$pluginName</plugin_name>
       </plugin_info_response>
      </responses>
     </do_command>
    </rci_reply>
   </device>
  </send_message>
 </sci_reply>

install_package: Installs a plug-in from a .zip file onto the gateway.

Request

<sci_request version="1.0">
  <send_message>
   <targets>
    <device id="$deviceId"/>
   </targets>
   <rci_request version="1.1">
    <do_command target="RPC_request">
     <install_package synchronous="true">
      <filename type="string">$filename</filename>
     </install_package>
    </do_command>
   </rci_request>
  </send_message>
 </sci_request>

Response

<sci_reply version="1.0">
  <send_message>
   <device id="$deviceId">
    <rci_reply version="1.1">
     <do_command target="RPC_request">
      <responses>
       <install_package_response>
        <plugin_name type="string">$pluginName</plugin_name>
        <version type="string">$pluginVersion</version>
        <active type="bool">{TRUE|FALSE}</active>
        <enabled type="string">{True|False}</enabled>
       </install_package_response>
      </responses>
     </do_command>
    </rci_reply>
   </device>
  </send_message>
 </sci_reply>

uninstall_plugin: Uninstalls a plug-in from the gateway.

Request

<sci_request version="1.0">
  <send_message>
   <targets>
    <device id="$deviceId"/>
   </targets>
   <rci_request version="1.1">
    <do_command target="RPC_request">
     <uninstall_plugin synchronous="true">
      <plugin_name type="string">$pluginName</plugin_name>
     </uninstall_plugin>
    </do_command>
   </rci_request>
  </send_message>
 </sci_request>

Response

<sci_reply version="1.0">
 <send_message>
  <device id="$deviceId">
  <rci_reply version="1.1">
    <do_command target="RPC_request">
     <responses>
      <uninstall_plugin_response>
       <plugin_name type="string">$pluginName</plugin_name>
      </uninstall_plugin_respons>
     </responses>
    </do_command>
   </rci_reply>
  </device>
 </send_message>
</sci_reply>

start_plugin: Starts running a plug-in. Applies the configuration in the plugin.yml file and calls the plug-in start hooks.

Request

<sci_request version="1.0">
  <send_message>
   <targets>
    <device id="$deviceId"/>
   </targets>
   <rci_request version="1.1">
    <do_command target="RPC_request">
     <start_plugin synchronous="true">
      <plugin_name type="string">$plugiName
      </plugin_name>
     </start_plugin>
    </do_command>
   </rci_request>
  </send_message>
 </sci_request>

Response

<sci_reply version="1.0">
  <send_message>
   <device id="$deviceId">
    <rci_reply version="1.1">
     <do_command target="RPC_request">
      <responses>
       <start_plugin_response>
        <plugin_name type="string">$pluginName</plugin_name>
        <version type="string">$pluginVersion</version>
        <active type="bool">TRUE</active>
        <enabled type="string">{True|False}</enabled>
       </start_plugin_response>
      </responses>
     </do_command>
    </rci_reply>
   </device>
  </send_message>
 </sci_reply>

stop_plugin: Stops running a plug-in. Reverts the configuration in the plugin.yml file and calls the plug-in’s stop hooks.

Request

<sci_request version="1.0">
  <send_message>
   <targets>
    <device id="$deviceId"/>
   </targets>
   <rci_request version="1.1">
    <do_command target="RPC_request">
     <stop_plugin synchronous="true">
      <plugin_name type="string">$pluginName</plugin_name>
     </stop_plugin>
    </do_command>
   </rci_request>
  </send_message>
 </sci_request>

Response

<sci_reply version="1.0">
  <send_message>
   <device id="$deviceId">
    <rci_reply version="1.1">
     <do_command target="RPC_request">
      <responses>
       <stop_plugin_response>
        <plugin_name type="string">$pluginName</plugin_name>
        <version type="string">$pluginVersion</version>
        <active type="bool">FALSE</active>
        <enabled type="string">{True|False}</enabled>
       </stop_plugin_response>
      </responses>
     </do_command>
    </rci_reply>
   </device>
  </send_message>
 </sci_reply>

enable_plugin: Starts running a plug-in, if not already started, and sets the plug-in to start every time the plug-in manager starts.

Request

<sci_request version="1.0">
  <send_message>
   <targets>
    <device id="$deviceId"/>
   </targets>
   <rci_request version="1.1">
    <do_command target="RPC_request">
     <enable_plugin synchronous="true">
     <plugin_name type="string">$pluginName</plugin_name>
         </enable_plugin>
    </do_command>
   </rci_request>
  </send_message>
 </sci_request>

Response

<sci_reply version="1.0">
  <send_message>
   <device id="$deviceId">
    <rci_reply version="1.1">
     <do_command target="RPC_request">
      <responses>
       <enable_plugin_response>
        <plugin_name type="string">$pluginName</plugin_name>
        <version type="string">$pluginVersion</version>
        <active type="bool">TRUE</active>
        <enabled type="string">True</enabled>
       </enable_plugin_response>
      </responses>
     </do_command>
    </rci_reply>
   </device>
  </send_message>
 </sci_reply>

disable_plugin: Stop running a plug-in (if started) and don’t start the plug-in when the Plug-in Manager starts.

Request

<sci_request version="1.0">
  <send_message>
   <targets>
    <device id="$deviceId"/>
   </targets>
   <rci_request version="1.1">
    <do_command target="RPC_request">
     <disable_plugin synchronous="true">
      <plugin_name type="string">$pluginName</plugin_name>
     </disable_plugin>
    </do_command>
   </rci_request>
  </send_message>
 </sci_request>

Response

<sci_reply version="1.0">
  <send_message>
   <device id="$deviceId">
    <rci_reply version="1.1">
     <do_command target="RPC_request">
      <responses>
       <disable_plugin_response>
        <plugin_name type="string">$pluginName</plugin_name>
        <version type="string">$pluginVersion</version>
        <active type="bool">FALSE</active>
        <disabled type="string">False</disabled>
       </disable_plugin_response>
      </responses>
     </do_command>
    </rci_reply>
   </device>
  </send_message>
 </sci_reply>