Reference · for Engineers, Administrators, Operators

Troubleshoot data

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

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).

Health Checks findings

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.
`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 answers ClickHouse connection failed: ... in this case.

Missing in an outbound target

Open the target and select Check.
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.
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).
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, chosen as the target's trusted server certificate. See 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.

Missing in the Unified Namespace

The UNS topics are published by the broker of each gateway. See MQTT and the UNS topics.

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.

Was this page helpful?

← Previous

Gateways

Automation

Evaluating Proxus? See it on your own machines in a 30-minute technical session.