> For the complete documentation index, see [llms.txt](https://help.tillit.cloud/tillit/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.tillit.cloud/tillit/tools/ignition-module/troubleshooting/tags-and-data-issues.md). # Tags and Data Issues ## Tags and Data Issues If the module is connected (see [Verifying the installation](/tillit/tools/ignition-module/troubleshooting/verifying-the-installation.md)) but tags are missing, stale, or data is not flowing, work through the sections below. ### The TilliT Tag Provider does not appear **Symptom**: the **TilliT** entry is missing from the Tag Browser provider drop-down in the Designer. | Likely cause | Fix | | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The module never reached **Module ready = true** | Check the **System Status** folder of the provider, or the gateway logs for `TilliT` at startup. Resolve any errors before continuing - see [Connectivity Issues](/tillit/tools/ignition-module/troubleshooting/connectivity-issues.md) | | The Designer was open before the provider existed | Close and reopen the project, or refresh the Designer's tag browser | | A previous installation left a stale tag provider behind | In **Config → Tags → Realtime**, delete any TilliT-named provider that is not active, then restart the TilliT module from **Config → Modules** | ### The asset hierarchy is empty or stale **Symptom**: the tenant folder is present, but the asset hierarchy is empty, missing levels, or out of date relative to the structure shown in TilliT. The module builds the hierarchy by calling the TilliT REST API at startup or whenever the **Refresh** tag is set to `true`.

The Refresh tag at the root of the TilliT tag provider. Setting it to true triggers a full re-fetch of the asset hierarchy and event types.

| Likely cause | Fix | | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Hierarchy was changed in TilliT after the module last fetched it | Set the **Refresh** tag at the root of the TilliT provider to `true`. The hierarchy will be re-fetched and the tag will return to `false` automatically | | The TilliT user does not have access to all assets | Confirm in TilliT that the user assigned in the gateway settings has access to every asset that should appear | | REST calls are failing | If `Module ready` is `true` but assets are missing, run `system.tillit.getApi("/api/asset")` in the Designer Script Console to check the call works. If it fails, see [Connectivity Issues](/tillit/tools/ignition-module/troubleshooting/connectivity-issues.md#rest-api-calls-fail-with-401-or-403) | | New event types are not appearing on assets | Setting **Refresh** to `true` also re-pulls event types - this is the same fix | ### Production counts are not flowing **Symptom**: the asset's `CountTotal` tag in Ignition is updating, but counts are not appearing against the active order in TilliT. The module only publishes counts for assets that are actively monitored. Active monitoring requires both an **Active** flag set to `true` and a current work order on the asset. | Likely cause | Fix | | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | The asset's `Active` tag in the **Write** folder is `false` | Set `Active` to `true`. None of the count or status logic runs for an asset until this flag is enabled - see [Data From Ignition To TilliT](/tillit/tools/ignition-module/tillit-tag-provider/data-from-ignition-to-tillit.md) | | There is no running order on the asset in TilliT | Counts are recorded against an order. With no order, the module discards the increments. Start a work order against the asset in TilliT | | `CountTotal` was reset mid-order | The module computes the **delta** between successive readings. Resetting mid-order produces a large negative delta, which is ignored, causing missing counts. Either never reset the counter, or only reset during order transitions - see [Data From Ignition To TilliT](/tillit/tools/ignition-module/tillit-tag-provider/data-from-ignition-to-tillit.md) | | The reference tag is pointing at the wrong path | Confirm the source-tag-path of your reference tag points at `[TilliT]/.../Write/CountTotal` for the correct asset | | Counts were sent before the asset hierarchy finished building | Wait for `Module ready = true` before allowing counts to flow. On a slow API, hierarchy build can take several seconds at startup | The same logic applies to `RejectCount` - replace `CountTotal` with `RejectCount` in the table above. ### Asset Status changes are not reflected in OEE **Symptom**: the `AssetStatus` tag in the **Write** folder is being written from Ignition, but the OEE in TilliT does not reflect the running/stopped time. | Likely cause | Fix | | ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The asset's `Active` tag is `false` | Set `Active` to `true` - same constraint as for counts | | The status value is not one of the recognised states | Status must be exactly one of `RUNNING`, `STOPPED`, `READY`, `SUSPENDED`, `ABORTED`, `BLOCKED`, `FAULTED`, `STARVED` (case sensitive). Any other value is still written to the tag but sets no equipment-status flag, so it silently has no effect on OEE | | A reference tag is writing the same status repeatedly | The module only acts on **changes** in status. Repeating the same value has no effect - this is correct behaviour | ### Process Variables / Edge Data tags are not appearing **Symptom**: a Write folder shows the asset structure but no tag exists for the analog value you want to send (temperature, pressure, etc.). Process variables are not created automatically. They must first be defined in TilliT as **Edge Data Tags** on the asset. | Likely cause | Fix | | -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The Edge Data Tag has not been created in TilliT | Create one in TilliT - see [Edge Data Tag](/tillit/knowledge-base/setting-up-tillit/asset-hierarchy/assets/edge-data-tags.md). Then set the **Refresh** tag at the root of the TilliT provider to `true` | | The Edge Data Tag was created on a different asset | Confirm the tag was created on the same asset whose Write folder you are inspecting | ### Events are not raised in TilliT **Symptom**: writing `true` to an event trigger tag in the **Write** folder does not produce an event in TilliT. | Likely cause | Fix | | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Asset `Active` is `false` | Set `Active` to `true` | | The event trigger tag was not toggled | Events fire on the rising edge (`false` → `true`). Setting an already-`true` tag to `true` again does nothing. Use a one-shot pattern: write `true`, wait for the acknowledgment, then write `false` | | The event type was added in TilliT after the hierarchy was built | Set the **Refresh** tag to `true` to re-load event types onto each asset | | Calling via script with the wrong IDs | `system.tillit.raiseEvent(eventTypeId, assetId)` requires the **TilliT IDs**, not the Ignition tag paths. Use the IDs visible in the TilliT web UI | ### RunningOrder folder is empty **Symptom**: the `Read/RunningOrder` folder for an asset has tags, but they are all empty/null. The RunningOrder folder is only populated while an order is **started** against the asset. | Likely cause | Fix | | ------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | There is no started order on the asset | Start a work order on the asset in TilliT. The RunningOrder folder will populate within a few seconds | | The order was completed | On `COMPLETE`, the RunningOrder folder is intentionally cleared. This is correct behaviour - confirm the order is genuinely active in TilliT | | The order was started just before the module connected and the start event was missed | Suspend and re-start the order in TilliT to re-publish the order context to the module | ### Event folder under Read is empty **Symptom**: the `Read/Event` folder exists but does not populate when events are raised in TilliT. The Events folder requires the **MQTT Integration** to be configured for the events you want to subscribe to. See [MQTT Integration](/tillit/knowledge-base/setting-up-tillit/integrations/mqtt-integration.md). Without an MQTT integration that publishes the event, the module has no way to receive it. ### Best practice: use reference tags Across all of the scenarios above, we recommend mapping TilliT provider tags to **reference tags** in your default tag provider rather than reading the TilliT provider directly. This isolates your project from changes to the TilliT hierarchy and makes it easier to drive UDTs with parameters such as asset name and line name. See the **Best Practice** hint in [Data From TilliT to Ignition](/tillit/tools/ignition-module/tillit-tag-provider/data-from-tillit-to-ignition.md).