# Troubleshoot data

> Why values are missing in trends, in the Unified Namespace or in an outbound target, and what to check at each step.

Source: https://proxus.io/docs/troubleshoot/data

The device reads, but the values do not show up where you expect them. Work through the section for the place
where they are missing. First make sure the device itself is reading: its status is **Connected** and its tags have
values (see [Devices](https://proxus.io/docs/troubleshoot/devices)).

## Health Checks findings

[Health checks](https://proxus.io/docs/organize/health-checks) finds most data problems for you. The findings about data:

| Finding | Meaning | What to do |
| --- | --- | --- |
| `Gateway is offline` | The hub has no connection to the gateway. Its devices, rules and functions do not report. | See [Gateways](https://proxus.io/docs/troubleshoot/gateways). |
| `Device stopped sending data` | `Last data <time> ago; expected within <time>.` | Check the device's network and connection settings, or disable the device if it was retired. |
| `Device has never sent data` | No data since the hub started. | Check the device's connection settings and that its gateway can reach it, or disable it until it is installed. |
| `Tags nobody stores or reads` | Tags are read but go nowhere. | Remove them from the profile, or connect them to a target or a pipeline. |
| `Function output goes nowhere` | A function produces values that nothing uses. | |
| `Every source is switched off` | Everything that feeds this object is disabled. | Enable a source, or remove the object. |

## Missing in trends and reports

Trends and reports read the Proxus historian. Values reach it through the **SYSTEM INTERNAL DB** target.

- **The device does not deliver to the historian.** New devices do, but the target can be removed later. Open the
  device's **Delivery** tab; if **SYSTEM INTERNAL DB** is not listed, add it again. Values from the time it was
  missing were not stored.

- **A transport pipeline drops or holds the values.** A **Drop**, **Quarantine** or **Filter** node, or the pipeline's
  **On error** setting, can keep values from being stored. Look at the pipeline's **Trace** tab.
- **The values are older than the retention.** `[ClickHouse] ClickHouseTTLExpression` deletes old values if it is set.
- **The time range is wrong.** Widen it to make sure the values are not just outside it.
- **The historian is not reachable.** **Check** on **SYSTEM INTERNAL DB** shows the last error. The
  [Telemetry API](https://proxus.io/docs/develop/telemetry-api) answers `ClickHouse connection failed: ...` in this case.

## Missing in an outbound target

1. Open the target and select **Check**.
2. Read the parameter check. Errors (`'<key>' is required but missing or empty.`) mean the target cannot work.
   Warnings such as `'<key>' is not set, so the channel falls back to '<value>'.` mean it writes somewhere else than
   you think: to `localhost`, or to the topic `proxus_device_data`.
3. Read the runtime status: **Status**, **Last success**, **Last failure** and **Last error**. `Degraded` means the target
   worked before and fails now; `Error` means it has never worked. While the target is unreachable, the error also
   says how many queued messages are waiting at the gateway. They are written when the target is back, as long as
   they are younger than the gateway's **Buffer Retention (hours)** (48 hours by default).
4. Select **Test Connection**. Run it from the gateway that reads the devices, not from the hub: outbound writers run
   on the gateways, and a target that only the plant network can reach fails from the hub.

| Test result | Meaning |
| --- | --- |
| `Connected: <target> accepted the configured credentials.` | Address and credentials are right. If data is still missing, check write rights on the topic, table or path. |
| `Reachable: a connection to <target> succeeded.` | Something answers, but credentials were not checked. |
| `Failed: the target did not answer within <n> seconds.` | Wrong address or port, or a firewall. |
| `Failed: ...` with the target's own message | For example wrong credentials, a missing bucket or file system. |
| `No connectivity probe is available for <type> in this platform version.` | The type has no test. |
| `Not run: fix the configuration errors above first.` | Fix the errors in the parameter check. |

Other causes:

- **The device does not send to this target.** A device sends only to the targets selected on it (**Where does the
  data go?** in the wizard). **Devices Used** on the target shows how many do.
- **The target's strategy is On Change.** Values that did not change are not sent. **Pipelines Only** sends nothing
  from devices at all.
- **The server certificate is refused.** Every TLS connection verifies the server. A server with a self-signed or
  private-CA certificate needs its CA in the [Certificate Store](https://proxus.io/docs/administer/certificates), chosen as the
  target's trusted server certificate. See
  [TLS parameters](https://proxus.io/docs/reference/outbound-targets#tls-parameters).
- **One record is skipped.** A record the target answers but never accepts (for example a value too long for the
  column) is skipped after a few attempts and named in the status. The data behind it is still written.
- **The type does not work in this release.** Some database types cannot be written to; see
  [Outbound targets](https://proxus.io/docs/reference/outbound-targets#types-that-cannot-be-used-in-this-version).

## Missing in the Unified Namespace

The UNS topics are published by the broker of each gateway. See [MQTT and the UNS topics](https://proxus.io/docs/develop/mqtt).

- **You are connected to the wrong gateway's broker.** Each gateway publishes only its own devices.
- **The client is refused.** It must use the gateway's `MasterToken` as user name.
- **The topic is different from what you expect.** Empty levels of the device's place are left out, and spaces
  become `_`. Subscribe to `v1/#` to see the real topics.
- **Publishing is off.** `[MQTTBroker] Enabled` and `EnableMQTTHooks` must both be `true` on the gateway.
- **A port fallback happened.** If port 1883 was taken when the gateway started, it picked another port and logged
  `Configured port 1883 is already in use. Using fallback port <port>.`
- **Bad values are not published.** Tags that failed to read do not appear on their telemetry topic.

## Values look delayed or thinned out

- `_summary` and `_lastSeen` are sent at most every 5 seconds per device by design (`SummaryIntervalMs`,
  `LastSeenIntervalMs`).
- A target with **On Change** sends only changes.
- After a gateway or a target was offline, buffered values arrive in a burst with their original timestamps.
- Delivery to a target is at least once: rarely, a record whose confirmation was lost is written twice.

## Related

- [Troubleshoot devices](https://proxus.io/docs/troubleshoot/devices)
- [Outbound targets](https://proxus.io/docs/reference/outbound-targets)
- [Health checks](https://proxus.io/docs/organize/health-checks)