A Template is a JSON file that captures configuration from a Litmus Edge (LE) system. When you create one, you select which components to include, such as devices, connectors, analytics flows, and Digital Twins models and instances.

A configuration you build and validate on one system has to be repeated at every new site, often by someone who did not build the original. A template turns that work into a file you build once and apply wherever you need it.

Litmus Edge Manager (LEM) also has templates, and they are also JSON files describing Litmus Edge configuration. Although they can include the same components, they are not the same features and are not interchangeable.

Use LEM templates when you are pushing configuration out to a fleet you already manage centrally. Use Litmus Edge Templates when you are building a configuration on one system and moving it to another, or when you need the snapshot and roll back safety net around a change.

Templates make a working configuration reusable. With them, you can:

Templates are useful to solution architects who design a configuration once and roll it out, commissioning engineers who bring new sites online, and operations teams who need to return to a known configuration after a change.

Templates include the following components:

Every template contains metadata, followed by one section per component.

A template has two version numbers, both written as major.minor.revision.

If you edit a template outside LE, update fileVersion yourself.

LE stores template files with a canonical key order applied to every object in the file. Within each object, keys appear in three groups: scalar values first in alphabetical order, then the parameters section, then objects and arrays in alphabetical order. The rule applies recursively to nested objects.

This exists to make templates readable and diff-friendly. Two templates that describe the same configuration produce the same key order, so a comparison shows real differences. LE applies the ordering whenever a template is saved or exported, so you do not have to author files in this order yourself. A file with non-canonical ordering imports without error and is reordered when saved.

A parameter lets one template serve many systems. Instead of writing a site identifier or a polling interval directly into the file, you declare it as a parameter and supply the value when you apply the template.

Parameters are declared in a top-level parameters block, keyed by the component they belong to. Use _global for parameters shared across components.

Wherever the value belongs in the template, a placeholder object stands in its place:

When you apply the template, LE replaces each placeholder with the value you supplied, or with the default if you supplied none, then applies the resulting document. The following data types are supported.

Default and user values are stored as text in the file and converted to the declared type when the template is applied. A value that cannot be converted, such as a decimal supplied for an INTEGER, is a validation error that blocks the apply until corrected. Invalid parameter names and values are displayed.

Parameter names must be unique within their scope, not across the whole file. When the same name exists in both _global and a component scope, the component-scoped parameter takes precedence, in the same way a local variable shadows a global one in a programming language.

When you import a template file, LE checks it before adding it to the listing. The check runs in two layers, and both happen offline against the file itself.

A broken reference fails the import, and the error identifies the reference by its path and value. A file that passes both layers is added to the listing. Import also checks both version tags. A version or fileVersion that is not valid major.minor.revision format fails with a descriptive error, as does a file whose schema version is newer than your LE build supports.

These checks run against the file alone. Nothing is compared against the target system until preflight.

Preflight is a validation step that runs when you start an apply. It checks that the target system has the connectors and drivers the template needs.

If the checks pass, the apply continues. If any check fails, LE blocks the apply and reports what is missing. LE writes nothing and takes no snapshot, so the system stays exactly as it was.

Three modes control how a template is applied. Apply is the default. To use Reset & Apply or Merge & Apply, turn on Advanced Modes in the Apply Templates dialog.

Merge & Apply merges against the system's current configuration, not against the template it was last given. If the system has been modified by hand since, those modifications are part of what gets merged.

Reset & Apply, Merge & Apply, and rollback reset each component before they write the new configuration. Merge & Apply resets to the merged result of the template and the current configuration.

When part of a component can't be applied, the error identifies what failed and why:

A snapshot is the complete running configuration at a moment in time. It covers every component the template system manages.

A snapshot is self-contained, which is what makes rollback dependable. Restoring one writes its values straight to the system, so the rollback works even if the template it came from has since been edited or deleted.

LE captures a snapshot at the start of every Reset & Apply and Merge & Apply, and writes it to history when the operation succeeds. A failed operation leaves no snapshot behind, but it does offer you the option to roll back. Apply does not create a snapshot. You can also capture a snapshot manually and give it a label and notes.

Rollback is itself snapshotted. Rolling back creates a new history entry, so the action is auditable and you can undo it by rolling back to the entry the rollback created.

Before a rollback runs, a preview shows what changes:

The Out of scope section matters most. A rollback returns the components in the snapshot to their captured state and leaves everything else alone, so this is where you confirm that something you care about is not going to be missed.

If the live configuration changes between the moment you view the preview and the moment you confirm, LE rejects the rollback and asks you to run the preview again against current state.

When you create a template, you can choose to encrypt credentials. LE then encrypts the protected fields of each component, such as usernames, passwords, tokens, certificates, and keys, so they are not stored or exported as plain text. Protected fields are encrypted for DeviceHub drivers, Integration connectors, Analytics, and OPC UA.

Applying a template rewrites system configuration, so the ability to do it is restricted. Access to the Template tab is controlled by the config permission.

Applying a template rewrites system configuration, so the ability to do it is restricted.

Each template records who created it and when, who last updated it and when, and keeps a log of significant actions such as edits and deployments. Template application is logged in both directions: a successful apply records a timestamp, and a failure records the error alongside it.

Snapshot history is append-only and is not pruned automatically. Entries are listed newest first and show the label, timestamp, and the template name and version where one applies. Users with Modify permission for config can delete individual entries. The most recent snapshot cannot be deleted, so a system always retains at least one point to return to.

Creating, deleting, and rolling back to a snapshot each record an event: config.snapshot.created, config.snapshot.deleted, and config.snapshot.rolledback. Each event includes the snapshot and the user who started the action.