controller Release Notes

The controller probe is a core component of the canm robot.
The controller probe is a core component of the
CA Unified Infrastructure Management
  • Controllers schedule, start, and stop the probes that the robot manages. Controllers keep configured probes running according to the probe configurations.
  • Controllers maintain contact with parent hubs and handle CA UIM operations, including hub state, name-lookup services, and licenses.
  • Controllers respond to directives in the
    and the
    files, and to commands issued over the
    : 48000
Two types of hubs and robots are now available—secure (9.10S) and non-secure (9.10 and earlier). Hub and robot versions 9.10 and earlier use the legacy security model. Beginning with CA UIM 9 SP1, secure hub (9.10S) and robot (9.10S) are available, which further enhance the security mechanism in CA UIM.
Support cases might not be visible to all customers.
Revision History
(Included in UIM 20.3.3)
  • (9.32 HF1) Fixed an issue where robots were not falling back to their primary hub and were staying connected to their secondary hub, until the secondary hub was switched off. This behavior was being observed in those scenarios where both the proxy_mode and strict_ip_binding were enabled for the robot. (Support Case: 32302280)
  • Fixed an issue where the Windows blue screen (BSOD) was coming up during the reboot that was caused by controller.exe. Upon rebooting a system, during or immediately after the reboot process, users were observing a Windows crash event. (Support Case: 32467624)
  • Fixed an issue where the UIM Server installation was failing while upgrading from 20.1.0 to 20.3.0. The installation was unable to communicate with the controller probe in the allotted time. (Support Case: 32446423)
  • Fixed an issue where duplicate robots were getting reported in the OC UI; however, the Admin Console UI was showing only one robot. (Support Case: 32450799)
March 2021
November 2020
(Included in UIM 20.3.0)
What's New:
  • (9.20 HF12) Fixed an issue related to a problem closing e2e_appmon.rob on Windows 10 PCs. (Support Case: 20037327)
  • (9.20 HF13) Fixed an issue related to frequent alarms "Unable to communicate with probe 'processes'. Restarting probe". (Support Case: 31784899)
  • (9.20 HF13) Fixed an issue where [PDS] nimalarm do not work with option -c from UIM 9.2.0 on Linux anymore. (Support Case: 20093893)
  • (9.20 HF14) Fixed an issue where primary hub is stopping and forcing all robots to switch to their secondary hub. (Support Cases: 20310110, 31888790)
  • (9.20 HF14) Fixed an issue where robots without discovery_agent probe is being added into CM_DISCOVERY_AGENT. (Support Cases: 20122758, 20197812)
  • (9.20 HF15) Fixed an issue where remote profiles were not getting deployed by MCS. (Support Case: 31819927)
  • (9.20 HF17) Fixed an issue where robot does not execute all application discovery scripts. (Support Case: 32068693)
  • (9.20 HF19) Fixed an issue where robot crashes and becomes unresponsive, and is required to manually restart. (Support Case: 32044603)
  • (9.30 HF1) Fixed an issue while configuring passive robot on the NAT'ed network. (Support Case 20309641)
September 2020
(Included in UIM 20.1.0)
What's New:
  • (7.97 HF6) Fixed an issue in which 7.97 hub was dropping the tunnels and was not allowing the creation of new ones. Hub assigns the port to the tunnel connection by asking the controller. The controller is always assigning the new port and not using previously released ports, which was causing delay in searching for the available port. Optimized it to reuse the previous released ports. (Support Case: 01307453)
  • (7.97 HF7 and 9.20 HF7) Fixed an issue where the secondary hub stopped sending QoS from all probes after the upgrade to 9.20. Added the extra parameter as "restmon_qos" in the RESTMon QoS message and handled the same at the plugin_metric level to identify the RESTMon QoS message to solve this issue. (Support Case: 20058295, 20040794, and 20033089)
  • (7.97 HF8 and 9.20 HF9) Fixed an issue causing the crashes due to the BM UIM ACL handling RCE and Probe DoS vulnerabilities. Added fix for the unauthenticated remote code execution vulnerability in Nimsoft nimbuscontroller. (Support Case: 20093616, 20101721)
  • (9.10 HF1) Fixed an issue where alarms were not getting generated as per CI selected in the alarm policy. Alarms were not getting generated as per the ci_name selected in the alarm policy because plugin_metric always used to get the probe ci_name from niscache. However, the  docker_monitor probe sends ci_name as a part of qos_message. To fix the issue, a functionality in plugin_metric has been added that allows to get the ci_name from qos message if it is not found in the niscache folder. (Support Case: 20051916)
  • (9.20 HF2) Fixed the robot failover issue. Check has been put to accept requests from the primary hub if the robot has been switched to the secondary hub when the proxy mode is enabled in the controller. (Support Case: 20051408)
  • (9.20 HF3) Fixed two issues as part of this hotfix. Fixed the robot failover issue. Also, fixed an issue where the alarm policy alarms did not contain the robot's user tag. (Support cases: 20051408 and 20063366)
  • 9.20S HF3) Fixed an issue where the alarm policy alarms did not contain the robot's user tag. (Support Case: 20063366)
  • (9.20 HF5) and 9.20S HF5) Fixed an issue where multiple instances of robot were running, which was exhausting the CPU resources. (Support Case: 20084151)
  • (9.20S HF4) Fixed an issue where robots were not failing-over in a mixed secure robot environment. The issue is coming as hub sends check-in request to all its robots after coming up. In a secure environment, non-secure robots send robot-up request on 480002 port and hub_adapter runs on 48002 port. hub_adapter is not included in the core component, so it starts after some time. And, before it starts, robot-up request comes and fails. Changes have been made so that hub_adapter process starts right after hub. This allows it to handle all the requests from non-secure robots. (Support Case: 20069927)
  • (9.20S HF7) Fixed the following issues: (Support Cases: 20097684, 20089674, 20093286, 20075343, 20074324, 20058295, 20040794, and 20033089)
    • Controller had special handling for SID expire on robots. Proxy cannot differentiate between the controller and probe, so was giving controller SID to probe upon expire. This was causing permission denied. Fix has been provided to make controller get the SID on its own when the SID expires.
    • Fixed an issue where the secondary hub stopped sending QoS from all probes after the upgrade to 9.20. Added the extra parameter as "restmon_qos" in the RESTMon QoS message and handled the same at the plugin_metric level to identify the RESTMon QoS message to solve this issue.
  • Fixed an issue where CPUs maxed out when robot runs twice. (Support Case: 20084151)
  • Fixed an issue where passive robot (controller) generates illegal SID error. (Support Case: 20100511)
  • Fixed an issue with the Application Error Event with the code 1000 on the robots. (Support Case: 20077272)
  • Fixed a Robot failover issue in UIM 9.1.0. (Support Case: 20051408)
  • Fixed an issue where Robots are not failing over in a mixed secure robot 9.2hf3 environment. (Support Case: 20069927)
March 2020
(Included in CA UIM 9.2.0)
What's New:
  • (7.93 HF16) Fixed an issue in which the robot spooler was not responding when the sysloggtw probe was sending the large amount of data and the error was of the type wsaewouldblock. To resolve this issue, a new parameter
    has been introduced. This parameter lets you specify the number of tries the robot spooler must consider before it stops sending the message. Add this parameter to the spooler.cfg file. (Support Case: 01243127)
(7.97 HF1) Fixed an issue in which plugin_metric was not collecting metrics for the probes (which have new profiles that are created) unless the robot was restarted. This issue has been fixed with this hotfix.
(7.97 HF3) This hotfix resolves the following issues:
  • Fixed an issue in which alarm policies information was not getting added to the plugin_metric.cfg file on some robots. This was creating issues as alarms were not getting generated from these devices when the monitored metrics were exceeding the configured alarm policy thresholds.
  • Fixed an issue in which high memory usage was observed on the controller process after robot was upgraded from 7.93 to 7.97. 
  • Fixed an issue in which after deploying robot 7.97 on top of 7.93 was not updating the version in the controller UI status dialog. (Support Case: 01350012)
  • Fixed an issue in which duplicate device entries were existing for the same device in the UMP portlet. (Support Case: 00889072)
  • Fixed an issue in which the UMP upgrade was failing. (Support Case: 01369904)
  • Fixed an issue in which Admin Console was not installing the dependent package and the deployment was failing immediately. The same deployment was completing successfully if done through IM. (Support Case: 00852608 and 1261671)
  • Fixed an issue in which TOT alarms were not working as expected. For example, with thresholds set at 85% for major and 90% for critical alarms, the alarms were generating for less CPU utilization. (Support Cases: 01269944, 01260949, 01269925, 01287039, 01290918, 01293428, and 01303742)
  • (7.93 HF10) This hotfix supports robot on Ubuntu 18.04 on x86_64 platform. (Support Case: 01242463)
  • Fixed an issue in which robot was not starting and rebooting on an AIX computer. (Support Case: 01187252)
  • Fixed an issue in which when a robot was unable to find a valid IP address in robot.cfg or DNS, it was taking the loopback address. This was disrupting the communication. This issue has been resolved in this release. To resolve this issue, two configurable parameters have been added to robot.cfg: (Support Case: 01219460)
    • max_retry_IfLoopBack_attempt Specifies the maximum number of retries that controller can use to find the system IP address. In the case of loopback IP address, if robot_ip is not configured in robot.cfg, then controller tries to get the system IP. It tries to find the IP address for the number of retries that are specified in the parameter. After trying for the specified count, controller starts again with the loopback IP, resulting into the same initial behavior. The default value is 10.
    • sleep_btwRetry_IfLoopBack_attempt Specifies the maximum interval for which controller waits before trying again for the subsequent attempt. The default value is 2 seconds.
  • Fixed an issue in which users were facing problems with UIM Robot RPM and included systemd unit files. (Support Case: 00913690)
  • (7.93 HF18) Fixed an issue in which recently upgraded robots were giving problems on the AIX computers. When users upgraded robots on AIX systems, most robots worked except the ones that were connecting to an Oracle database. When the upgrade was performed, the robot.cfg file was updated and the LIBPATH value was changed. This hotfix preserves the existing value in LIBPATH when updating a robot using robot_update. (Support Case: 01185299)
  • Fixed an issue in which users installed robot on Windows Server 2012 R2 and applied MCS profiles for CPU, Memory, and Disk profile. They were getting some disk and CPU metrics, but no memory metrics. (Support Case: 01249736)
  • Fixed an issue in which snmpcollector was not getting launched from Admin Console. This issue was happening because controller was not reachable sometimes. (Support Case: 01307099)
  • Fixed an issue in which users were not able to install robot through rpm because it was using the default value (that is, /opt/nimsoft). The command was installing the robot in the correct location /opt/CA/nimsoft; however, it was not updating this file with the correct file path /usr/lib/systemd/system/nimbus. The robot would not start until the path in this file was updated to /opt/CA/nimsoft. The file had /opt/nimsoft. (Support Case: 01347207)
  • Fixed an issue in which after upgrading robots, the spooler probe was failing to send the messages after the hub restart. (Support Case: 01306288)
  • Fixed an issue in which when users were trying to install robot/hub on CentOS 6.8 using nimldr (from CA UIM 9.0.2) installation, the installation was failing ends with an error message. (Support Case: 01332537)
CA UIM 9.2.0 has adopted OpenJDK 8u212 instead of Oracle JDK. Because of this change, CA UIM 9 SP1 (9.1.0) that was using Oracle JDK (JRE) 8u212 is no longer available and has been removed from the Support site. All the functionality that was included in 9.1.0 is now released as part of CA UIM 9.2.0. Consequently, all references to the 9.1.0 release and the probe version 9.10 (released with it) have also been removed from this probe documentation. We recommend that you move to this version 9.20 of this probe, as the previous version 9.10 is no longer available now. For more information about the OpenJDK usage in CA UIM, see Adopting OpenJDK.
August 2019
  • Updated to support the Microsoft Visual C++ Redistributable for Visual Studio 2017 package version 1.01 (vs2017_vcredist_x86 1.01 and vs2017_vcredist_x64 1.01). This support helps ensure that the minimum version of the VS 2017 package is equal to or greater than 1.01. With this dependency on the version 1.01, the computer is no longer getting restarted automatically when installing the VS 2017 package. That is, with v1.01, no auto-restart of the computer happens.
  • Better handling of the controller plug-in. For example, when controller 7.96 (compiled with vs2017_vcredist_x86 1.0 or vs2017_vcredist_x64 1.0) tries to load attr_publisher (compiled with Microsoft Visual C++ Redistributable for Visual Studio 2008), the controller stops responding. This happens because of the compiler incompatibility. Now, with this release of the probe, which is dependent on vs2017_vcredist_x86 1.01 or vs2017_vcredist_x64 1.01, controller no longer loads the plugin (attr_publisher) if it is not compatible.
  • Updated to provide support for Amazon Linux 2.
December 2018
Included in CA UIM 9.0.2
What's New:
  • Added support for monitoring Ubuntu 18.04. Apply robot 7.93HF10 for this support.
    Support Case: 01184423
  • Changed the default reuse_async_session setting in the controller section of robot.cfg to 1 = ON.
  • Added support for PowerPC 64 Little-endian (ppc64le).
  • Removed support for the following platforms:
    • HP-UX OS 11.2 (IA64) and 11.2 (PA-RISC)
    • Linux CentOS 5 (32 bit and 64 bit), Debian 5 and 6
  • (February 2019) Added support for monitoring Windows 2019.
October 2018
What's New:
  • (7.92HF5) If you create a new Solaris zone, a robot installed in the global zone is not automatically deployed to the new zone. To install a robot in a new, non-global zone, install the robot into the non-global zone using the same steps that you use to install the robot in the global zone. (Support Case 746015)
  • (7.92) In addition to the operating systems listed below, support for Suse 11 or later secondary hubs and robots is added:
    • If you are installing your hub or robot on one of the following operating systems:
      • CentOS 7 or later
      • Red Hat 7 or later
      • Suse 11 or later
      • openSUSE 13 or later
      • Debian 8 or later
    • You must enable the nimbus service after your nimldr installation is complete. To enable the nimbus service, execute:
    • systemctl enable nimbus.service
  • (7.92HF3) Fixed a problem where VMware templates were not properly created in Windows when
    was set. (Support Case 00425378)
  • (7.92HF3) Fixed a problem where sections of a probe configuration file could be lost during editing when
    is enabled, causing the probe to crash.
  • (7.92HF3) Fixed a problem where timed probes showed as inactive when they are active. (Support Case 00633989)
  • (7.92HF3) Fixed a problem where multi-threaded probes could lock the config file on Windows unnecessarily.
  • (7.92HF10) Controller performance improvements.
  • (7.92HF11) The snmpcollector probe can now be successfully deployed through Infrastructure Manager. The controller now distributes the snmpcollector probe vendor certification files.(Support Case 00819546, 00824491, 00683844, 00825054, 00835227, 00818146, 00821694)
October 2017
What's New:
  • Ubuntu 16 x64 robot is now supported.
    • Perform a native installation as described in Deploy Robots in Bulk with a Third Party Tool and Native Installers.
      Note: Deployment with automated_deployment_engine is not supported for Ubuntu 16.
      • When installation completes, execute
        /opt/nimsoft/install/ enable
        to enable the robot services on Ubuntu 16. This step is not required for Ubuntu 14.
      • Start the robot with
        /opt/nimsoft/bin/niminit start
    • To completely uninstall the robot on Ubuntu 16, uninstall the service by executing the command
      systemctl disable nimbus.service,
      and delete the file
  • Microsoft Cluster is now supported.
  • Windows Server 2016 robot is now supported.
  • Support for Debian 6 robot is discontinued.
  • The probe utility (pu) is distributed as a separate package. Use the pu package to upgrade the probe utility to v7.90.
  • Robot automatic IPv4 address determination is improved. Robotip does not have to be manually set in
    in order for a robot to start.
  • Robot failover detection prevents unnecessary robot failovers when the hub misses a single response to a robot request (_status, alive, robotup, or probelist). The robot is more tolerant of incomplete _status requests. Two new properties can be specified in
    • robot_status_check_interval
      controls how frequently the robot polls the hub with a _status
      request. Previously, this was not configurable, and the polling occurred at a medium timeout, approximately every 11 seconds. Use this property to approximately specify the new polling interval. The interval is approximate because the status check occurs in the medium timeout that exceeds the requested interval. For example, if the
      is set to 30 seconds, polling will occur every 33 seconds (3 x 11 second medium timeout). The default value is 60 seconds, which equates to a status check every 66 seconds.
    • robot_failover_count
      improves the resiliency of the robot.  In the past, the robot failover mechanism was invoked when one _status request to the hub failed. Use this property to specify the number of consecutive _status failures that must occur before initiating robot failover to a secondary hub. Default, 2.
Known Issues:
  • Install the v7.90 robot_update package before upgrading the hub probe to v7.90. When the hub package is installed first, the hub appears to go offline in Admin Console and Infrastructure Manager. A communication error is reported, but the hub upgrade is successful even when the error occurs.
  • Update robotip manually on Debian platform
    • By default, Debian uses as the name resolution address. When a robot is deployed to a Debian system with automated_deployment_engine and the system is restarted, the robot attempts to bind to To avoid contention for on Debian systems, take the following actions:
      • After installing the robot manually or with automated_deployment_engine, add or update the following key in the robot.cfg file to ensure that the robot binds to the correct IP address:
        • robotip =
      • When preparing an XML file for bulk deployment to Debian systems, explicitly set the robotip in the XML file as follows:
        • <robotip>
      • Where,
        is the IP address that the robot should bind to on the target system.
Fixed Defects:
  • Packages fail to deploy from distsrv on the primary hub.
  • Robot crashes when audit is on in conjunction with MCS. (Support Case 00425278)
  • Incorrect logging when request.cfg is not available, which caused users to believe there was a problem has been fixed.
  • Install with Nimldr fails with a segmentation fault on systems with more than 10 IP addresses.
  • Probe utility (pu) crashes on Windows when calling automated_deployment_engine probe get_status callback. Error: PDS type unknown. Handling of unknown PDS types is improved. (Support Case 70004053)
  • The discovery server fails to detect robot origin changes on a controller soft restart.
  • Pre-install command on Linux platform prevents downgrade or reinstall of v7.80
    • Before the fix, a downgrade from a higher version, or a reinstall of the v7.80 robot_update caused a robot installation failure.
  • Long webservicemon soap requests fail to return data. (Support Case 70000840)
    • The 5000 character buffer size limit for a key value has been removed. Before the fix, data was truncated at 5000 characters.
  • Spooler error:
    buffer too small
    when starting a robot with more than 200 virtual IPs. (Support Case 00170426)
  • PIDs are not validated before issuing a process kill command on controller restart. (Support Case 246869)
    • By default, existing probe processes that have the same name as a probe to be started are stopped.
    • By default, when a probe is stopped for any reason, the controller attempts to stop the probe with the _stop callback. If the _stop callback is not honored, the controller kills the probe process.
  • ADE probe not adding Origin correctly in HP-UX. (Support Case 00289464)
  • A race condition causes the hub to crash.
  • Alarms sent by the spooler do not have a corresponding CLEAR to remove them from the active alarm list.
  • Probe Utility ServerErrorException occurs when running list_subscribers callback on a non-English Windows O/S.
  • File descriptors and sockets cached for too long in the controller, cause the controller to hang. (Support Case 379016)
  • Deploying a robot to Windows causes Windows to automatically reboot. The problem is most often seen when you use Windows Native Installer or ADE.
  • probe_config_get callback fails every other time. To implement the fix, add the new key reuse_async_session = 1 to the
    section of robot.cfg. The default is 0, off. (Support Case 521488)
Apr 2017
What's New
  • Support for OpenSSL TLS cipher suites
    • When using TLS 1.1 or 1.2 cipher suites, include an alternative fallback to SSLv3. Fallback for backwards compatibility between older robots and new hubs, or probes connected to a robot using SSL. Example: AES128-SHA256:RC4-SHA, where AES128-SHA256 is TLS v1.2 and RC4-SHA is SSLv3.0
  • OpenSSL 1.0.1m implemented
  • Windows IA64 is no longer supported
Fixed Defects
  • The spooler probe restarts
    • When a controller probe configured in proxy mode is restarted, the spooler probe also restarts.
  • The controller SID is automatically renewed after the hub login expiration time has passed
    • The controller SID from the hub expired when the
      Login Expiration Time
      elapsed. Expiration prevented the controller from acquiring a new license for a probe from a
      on a remote hub. A new license is needed when a probe with an expired license is restarted. Now, the remote controller is automatically logged in to the hub and acquires a new SID when the SID expires.
  • The controller starts java probes on AIX.
    • On AIX systems, the controller failed to start java probes. The AIX system call to start java probes now allows them to start. The process name now appears on AIX systems as
      instead of
  • The controller preinstall exit code is correctly interpreted.
    • Preinstall exit codes are:
      • 0 - okay
      • 1 - warn but continue
      • 2 - warn and abort this section
      • 3 - warn and abort the rest of the installation
  • The controller handles a probe restart without crashing.
    • The robot v7.70 crashed when all the following conditions were true:
      • A probe was running.
      • The robot had
        probes that were not installed.
      • The controller restarted its probes due to an origin or
        settings change.
June 2015
SSL communication mode options are more meaningful with the release of controller v7.70. The controller creates the
certificate file during startup. The file enables encrypted communication over the OpenSSL transport layer. The treatment of the
certificate file has changed. Changes in treatment impact communication for:
  • Hubs set to mode 0 (unencrypted)
  • Hubs set to mode 2 (SSL only)
  • Hub managed components
What's New:
  • User tags are propagated by the hub and the controller.
    Hub and controller alarms and messages now contain user tags. Previously, the hub and controller read user tags
    from the file
    . Now, the hub reads user tags from the file
    . The
    General Configuration
    section in the Admin Console hub configuration UI allows users to specify
    . On a hub system, the hub spooler for the hub probe adds user tags to probe alarms and messages. On a robot system, the robot spooler adds the user tags.
option, which enabled the hub to read user tags from
, was removed from the hub v7.70. Hubs and robots at v7.70 do not read user tags from
. If the hub robot had defined user tags, they will remain in
after upgrade, but they are ignored. To add user tags to hub probe alarms and messages, specify the user tags in
  • Package included in CA UIM 8.2 distribution
Fixed defects:
  • Existing memory leaks were addressed
  • Attempts to save changes to the robot configuration when the file system is full retain the original configuration.
  • The controller does not assign probes to ports used by hub tunnels. Ports are assigned to the correct interfaces based on strict binding mode.
  • Robot correctly installs package files on zLinux.
  • Robot stops all child processes when shutting down.
  • Robots that are configured for
    return to their designated parent hub after failover.
  • If an available port could not be found, the robot could consume 100 percent of CPU.
  • The hdb probe could crash on Windows due to issues with logmon configuration.
  • Issues when the robot mode was changed from passive to active.
March 2015
  • OpenSSL 1.0.0m
  • Removed a potential crash condition during a shutdown
  • Improvements to port free checks under various circumstances
  • Package included in CA UIM 8.1 distribution
December 2014
  • The
    callback includes MAC address information for AIX, Solaris, and HP-UX (in addition to Linux and Windows).
  • Resolved core dump issue on a controller shutdown
  • Fixed a defect that caused the robot to unregister from the hub on shutdown.
  • Resolved a socket leak in the
    callback on Linux
  • Package included in CA UIM 8.0 distribution
November 2014
  • New native robot installers and
    support for AIX and zLinux
  • Robot 7.60 for zLinux
  • Robot first probe port defaults to 48000
  • Package included in NMS 7.60 distribution
June 2014
  • Package included in NMS 7.50 distribution
March 2014
  • Added support for Microsoft Windows 2012 Server and Microsoft Windows 8.
  • Removed dependency on .NET framework 2.0
  • Integrated installation of Visual C++ 2008
  • Package included in NMS 7.00 and 7.10 distributions
December 2013
  • When a robot is upgraded, it is recommended to upgrade the controller plug-ins like attr_publisher as well. It is mandatory in the case of a robot upgrade from an older version to 7.97. Otherwise, attr_publisher does not work.
Valid Values for the audit Key in robot.cfg
When you enable the audit functionality in the controller, a configuration key called audit is added to the robot.cfg file. This key has several valid values, which are constructed by adding the "base" values together.
  • "6" - Enable auditing and send the messages to the message bus with subject AUDIT
  • "5" - Enable auditing but save the messages to a file called "audit.txt" in the Nimsoft\Robot directory.
  • "7" - Enable auditing and send the messages to the message bus and save them to the file.
  • "8" - Enable auditing only if this robot's hub has "audit=robot" in its hub.cfg.
These values (other than 8) are arrived at by adding certain "base values" together. These can be thought of as "switches" that enable certain functionality.
The base values are:
  • 1 - Audit to a file only. This causes the robot to save audit activity to a file called audit.txt in the Nimsoft\Robot directory.
  • 2 - Audit messages should be sent to the message bus with the subject AUDIT
  • 4 - Enable auditing.
So, for example, a value of "6" therefore means "4+2" are both enabled (since 4+2=6).
Note that if you set the value of audit to 1, 2, or 4, this will have no effect. The first two values (file and message bus auditing) must be "combined" with the "enable auditing" flag.
A value of "8" is a special value that tells the robot to defer to the hub setting for audit.