When launched, Kit Manager analyzes the kits installed on a device. A progress bar displays in the view during this analysis. Afterwards, the Kit Manager view displays featuring the Kits table and Verifier table, as shown in Figure 9.
The Kits table shows the schema or collection of “kits” used by the application currently running on the device. Each row in the Kits table represents a kit. Also shown for each kit, is the specific version installed on the device, the latest version downloaded to either the Workbench (if managing the device through a Sox session) or to the JACE (if managing the device through the Sedona Device in the Sedona Network), as well as the individual actions available for the kit.
In the Kits table, a kit icon with a padlock () shown to the left of the kit name indicates that the kit is required by the application running on the device and may not
be deleted. An unchecked box to the left of a kit name indicates that the kit is compatible and may be installed. A checked box indicates a kit that is installed, but not used by the current Sedona app. Kits not used by the current app may be uninstalled,
if desired. Kits that are not supported by the device appear dimmed on a gray background. The Action column describes those
kits as “Not supported”.
The Verifier table shows kit dependency errors when they occur. If a selected kit requires the presence of an uninstalled kit in order to run on the device, the missing dependency will be listed in the Verifier table, as shown in Figure 10.
When a kit dependency error occurs, the Kit Manager will NOT automatically select a missing kit (even if it is present in
the Sedona environment and available for installation) since doing so may cause kits to be deployed to the device that the
user did not intend. The missing kit, if not present in the Workbench, must be obtained from the vendor.
Figure 10. Verifier table shows that removing the types kit causes a missing dependency for the hvac kit.
The actions that are available for each installed kit can be viewed in the Figure 11.
drop-down list which you access by clicking a kit’s Action value, as shown inThe
drop-down list options can be one or more of the following:[current version]
[newer version]
[older version]
The newer/older kit version levels shown in the SEDONAHOME
\kits
directory.
If you have older kits in the current app, you may want to upgrade all kits to the newer versions available in your Workbench. You can easily do this by right-clicking within the Kits table to display the drop-down list shown in Figure 12, and then select the option to .
The
drop-down list options function as follows:Kit details
This option opens a pop-up window listing details for the selected kit. The details include kit name, current version with a drop- down list for other versions (if available), kit checksum, as well as listing any kit dependencies.
This option changes the Action value for all installed kits to
(latest version)
This option returns the kits back to the unmodified state.
Located below the two tables in the Kit Manager dialog box, are check boxes for the following options:
Rebuild kits.scode
This option is automatically selected (and dimmed) when you make any kit selection changes. The reason for that is that the kits.scode must be rebuilt whenever a change affects the schema. This ensures such changes are included in the recompiled binary .scode image. The only time you would need to actually select the option is when you want to force the scode to be rebuilt (even if no change was made to kit selections). This is useful in a development environment where the actual code in a kit might change while the kit version and checksum do not. In this case, no change is required in the Kit Manager but the scode must be regenerated in order to deploy the new code on a device.
Copy manifests to device
This optional feature gives the device the capacity to act as a “manifest server.” If not supported by the device, the option will not display in the view. If supported by the device, when you encounter a missing manifest while copying kits, the device can serve up the missing manifest. By contrast, in Sedona 1.1 and earlier, a missing manifest causes an exception.
Functioning as a manifest server is an optional feature that must be supported by the device in order for the option to display
in the view. If you do not see the option, then it is not supported by the device. Also, the device must be running Sedona
Framework TXS 1.2 in order to function as a manifest server.
For more details on using the Kit Manager, refer to Common Tasks.
Copyright © 2000-2014 Tridium Inc. All rights reserved.