DOCSEARCHbyAlgolia
Submit Docs

Connect UI Knowledge Base

website·Indexed 30 days ago

https://docs.trincdn.net

Documentation for the Connect UI, covering device management, SIM records, APN configurations, and reporting. Includes guides on managing device jobs, events, deadlines, and event lenses, as well as instructions for using pipe search, folder organization, and troubleshooting communication states and telemetry.

Tokens
44K
Snippets
118
Records
393
Agent score
50%

What's inside Connect UI

  1. Overview of Zero-Touch Enrollment (ZTE)

    Zero-touch enrollment (ZTE) is the first-connection bootstrap flow for MQTT devices in Connect. It allows a device that already exists in the system (in the CREATED lifecycle state) to retrieve the base information required to establish its initial MQTT identity and complete first registration. ZTE provides the device with its company identity code (cid), a system password (key or SYS_PASSWORD), and initial communication defaults (kai and pdr).

  2. Overview of the Connect Platform for Builders

    Connect provides a suite of APIs, MQTT flows, and platform tooling designed for building applications on top of connected devices and telemetry. Developers use the platform to authenticate integrations, define telemetry contracts, and interact with device and SIM models.

  3. Overview of Connect Auxiliary Properties

    Auxiliary Properties (aux) are company-defined metadata fields for SIM and DEVICE entities. They are used to store stable business context—such as customer references, site codes, asset ownership, billing tags, or workflow routing hints—that remains independent of device firmware or telemetry payloads. Unlike telemetry, these are tenant-scoped fields that model how a customer organizes their estate.

  4. Use Pinboard for quick access to frequent companies

    Pinboard serves as the personal landing space and default page after sign-in. It is designed for quick access to a small, curated set of frequently used companies rather than browsing the entire company directory. Each company entry on the Pinboard includes a pin control to manage its visibility on the page.

  5. Use Transaction Confirmation Topics (TCT) for request-response reconciliation

    Transaction Confirmation Topics (TCT) provide application-level proof-of-delivery confirmation. Use a TCT when a recipient is required to reply so the sender can reconcile the request and response. If no reply arrives, the client is responsible for determining the retry or failure behavior. TCTs should be treated as application ticket IDs; the sender can subscribe to the expected reply and reconcile using the trailing TCT value.

  6. Understand Trinc CDN MQTT protocol assumptions

    The Trinc CDN MQTT implementation is built upon the following technical assumptions:

    • It follows MQTT 5.0 semantics.
    • All names and keys use case-sensitive matching.
    • Payloads must be JSON with constrained message envelopes.
    • Users are expected to have a baseline understanding of MQTT 5.0 concepts, including topics, subscriptions, publishes, retained messages, Last Will and Testament (LWT), and the roles of brokers and clients.

  7. Understand Event Lenses for device event interpretation

    Event Lenses act as a contract between device firmware and external systems. They translate raw numeric event codes emitted by devices (e.g., via MQTT) into meaningful platform events. While a Data Lens interprets telemetry paths and values, an Event Lens interprets event codes to determine their meaning, severity, and whether history should be retained.

  8. Understand Communication Interval Contracts

    Communication Interval Contracts define when Connect expects a device to communicate and determine the device's communication health. Instead of a simple boolean 'offline' status, Connect uses these contracts to track the 'last-seen' time of a device (updated via MQTT traffic) and compare it against defined deadlines to derive communication states and events.

  9. Monitor SIM usage and connectivity

    The SIM Overview page allows developers and administrators to monitor real-time and historical data, including:

    • Month to Date usage and usage charts (daily, monthly, and yearly windows).
    • Data Budget and the next reset date.
    • Latest Session details and the Latest IP Address allocation.
    • Sub-navigation options to dive deeper into Session Record, Map, and SMS logs.

  10. Connect Python SDK capabilities and coverage

    The trinity-connect-client SDK is designed for Python services to manage devices, read company and folder context, issue device commands, and utilize typed response models.

    Currently, the SDK provides primary support for:

    • Devices
    • Companies
    • Folders
    • Response models
    • Service-account token authentication

    Operations not yet covered by the SDK (requiring raw API calls) include SIMs, reports, service-account management, Data Lenses, Event Lenses, auxiliary values, memberships, and historical telemetry.

  11. Understand Device Profiles for multi-step configuration

    Device Profiles are reusable, ordered sets of command invocations applied to a device in sequence. Unlike Stored Commands (which are single invocations), Device Profiles are used when an operation requires multiple steps where the order of execution is critical (e.g., setting reporting intervals before requesting a data publish).

    Sequential Execution Logic: Commands are executed one by one: the system sends a command, waits for acknowledgment, and then proceeds to the next command in the sequence. They are not parallel launch bundles.

  12. Understand the MQTT payload model and time semantics

    All payloads must use JSON and are designed to be stream-friendly to avoid look-ahead parsing. Timestamps are represented as signed integers with the following semantics:

    • Positive value: POSIX time (seconds since epoch).
    • Negative value: Relative time offset from the receiver's current time.
    • 0: No RTC context; use receiver time.
    1408715873 // Absolute POSIX time
-600       // 600 seconds before receiver time