Finding faults on a connection
Always start at Settings → Connections. That page carries the state of every connection, since when it has held it, and how many tags depend on it.
The state in the list
Section titled “The state in the list”| State | Most likely cause | Next step |
|---|---|---|
| connecting … and staying there | wrong network address or port, route blocked | check reachability from the server |
| offline | the peer stopped answering | check the machine, the broker, the network; TrakState keeps retrying by itself |
| error | the message stands beside it, credentials stripped | read the message; often a login or a certificate |
| not running | no runtime for this protocol | is the plugin switched on, is its backend up? |
| switched off | somebody deactivated the connection | switch it on again |
What you see on the tag
Section titled “What you see on the tag”- bad — the connection is gone, or a message arrived from which no value could be read (a missing JSON path, for instance). The last value is deliberately not left standing.
- uncertain — the tag exists but has not been given a connector or a connection yet.
- denied — access was refused; the connection is not the problem.
Only the tags of that one connection are ever affected.
A write fails
Section titled “A write fails”| Message, in substance | Cause |
|---|---|
| “the connection is offline, the value was NOT sent” | no live wire — nothing is put in a queue |
| no acknowledgement within five seconds | the far end did not confirm |
| writing to an inbound tag | set the tag’s direction to Writes to the machine or Both |
| topic with a wildcard | an outbound topic has to be exact |
| no connector of this type running | this protocol has no runtime on this installation |
Credentials and the key
Section titled “Credentials and the key”Passwords sit encrypted in the database; the key sits in a file beside it. Two situations follow from that, and both really happen:
- No key at all. The form says so and stores no password. Connections without one keep working.
- Database restored, key file not. A new key file is created at start-up and the old credentials can no longer be opened. The affected connections are logged by name and stay down. The way out is the old key file from the backup — or entering the passwords again.
Remember: a backup is the database and the key file.
Two traps that look like network problems
Section titled “Two traps that look like network problems”- A shared client id on MQTT. Two connections using the same id keep throwing each other off the broker. It looks like a flaky line. Leave the field empty, or give each connection its own id.
- TCP with no delimiter. A silence fallback set too low cuts telegrams in half wherever the sender pauses; a telegram that exceeds the message limit without a delimiter has its buffer dropped. Both show up as patchy data, not as an error.
When a plugin connector does nothing at all
Section titled “When a plugin connector does nothing at all”Check in this order:
- Is the plugin installed and switched on under Settings → Plugins?
- Is its backend running? A plugin backend does not start when its signature no longer verifies against this installation’s trust anchor — then only a re-signed package helps. The plugin page shows the trust state.
- Does the manifest carry
net:socket? Without that permission the connector gets no runtime. - Is the protocol in the form at all? If not, the type was refused; the reason is in the installation’s log.