Technical reference · Build guide

    Build cold-chain telematics on Navixy.

    How TSPs, system integrators, and IoT teams assemble a cold-chain solution on Navixy: capture condition off any sensor or reefer, automate the decision with IoT Logic, and turn it into audit-ready proof with IoT Query — on the hardware your lanes already use.

    2,500+ device protocolsIoT Logic (JEXL)IoT Query analyticsOpen API & webhooks
    IoT Logictemperature-differential.flow
    Data source
    Logic
    Set attribute
    Webhook
    condition · rate of change
    value('temperature', 0, 'valid')
      - value('temperature', 1, 'valid') > 3

    Fires on the jump between readings — before the absolute limit is breached.

    Reference architecture

    Five moves from sensor to proof

    Each layer is buildable independently and composes into one solution — so you start with what a lane needs today and extend without re-platforming.

    1. 01

      Capture

      Read condition off BLE and 1-Wire probes, reefer CAN/J1939, serial/analog, door and fuel — across mixed and contractor fleets. Navixy normalizes 2,500+ device protocols into one model.

    2. 02

      Automate

      Express detection in IoT Logic with JEXL: absolute thresholds, rate-of-change between readings, door-plus-geofence correlation, debounce, and an escalation ladder.

    3. 03

      Store & query

      Persist to the Business Repository and compute with IoT Query — mean kinetic temperature, time-out-of-range, and full condition history on a schedule.

    4. 04

      Integrate

      Push results to your TMS, WMS, or BI over an open REST API and webhooks — or let Navixy be the system of record behind your own app.

    5. 05

      Deliver

      Ship it white-label: your brand, your domain, scheduled reports and proof-of-condition records your customers and auditors trust.

    Capture condition off any device

    Cold chain is a sensor problem before it is a software one. Navixy speaks the interfaces the load actually uses — and keeps logging when the network drops.

    Measure the load, not just the unit

    A reefer reports its own supply and return air — but the cargo sits a few degrees warmer and drifts toward the door. Capture the unit over CAN/J1939 and place BLE or 1-Wire probes in the load (front, middle, rear), and Navixy normalizes every source into one schema your logic and reports read from.

    2–8 °C probe−30 °C frozenhumiditydoor

    BLE & wireless sensors

    Battery wireless temperature, humidity, and door sensors — ideal for trailers, totes, and last-mile boxes without wiring.

    front
    middle
    rear

    1-Wire multi-point probes

    Chain front / middle / rear probes inside the load — because supply air is not product temperature.

    setpoint−18.0 °C
    supply−18.4 °C
    return−16.1 °C
    alarmnone

    Reefer CAN / J1939

    Read set point, supply and return air, alarms, fuel, and run-hours straight off Thermo King and Carrier units.

    store & forward

    Offline buffering

    Devices log to memory and store-and-forward on reconnect, so dead zones and unhooked trailers leave no gaps.

    Platform stack

    One platform, five layers

    The same composable stack that runs fleet and field operations, read here through a cold-chain lens. Build at any layer; the ones below it are already solved.

    • L1 Ingestion — 2,500+ device protocols normalized into one schema
    • L2 IoT Logic — device-agnostic rules in JEXL, no firmware work
    • L3 IoT Query — MKT, time-out-of-range, and custody history on demand
    • L4 / L5 — open API, webhooks, and white-label delivery

    Start from a working IoT Logic flow

    Import a ready-made flow, point it at your device, and tune the thresholds. Three cold-chain starters ship as importable JSON.

    Rate-of-change differential — opened in the editor

    The flagship guard branches on a JEXL rule: log while the load is in range, escalate the moment condition drifts between readings — before an absolute limit is breached. Import it, point the Data Source at your device, and tune the threshold; no firmware work.

    IoT Logic Import flow
    Nodes
    Data source
    Logic
    Action
    Attribute
    Endpoint
    Comment
    Save flow
    Reefer CAN flow — summarydecode PGNs · Δ = supply − setpoint · branchin range → logΔ breach → alertCAN BusData sourceDecode CANLogicIn range?Logic · JEXLLog OKActionAlertAction → webhook
    Inspector valid

    Temperature & humidity threshold

    Classic absolute-limit alerting for a fixed set-point band — the place most deployments start.

    Idling / power detection

    Catch a reefer that stopped running or lost power — a leading indicator of an excursion to come.

    Build your own

    Compose nodes in the IoT Logic editor — data source, logic, attributes, webhooks — with no firmware changes.

    Reason over the record with IoT Query

    IoT Logic decides in the moment; IoT Query is its analytical other half — it computes the compliance math on the stored record, applies ML to clean signals and predict excursions, and answers plain-language questions, so the proof writes itself.

    Ask in plain language — it answers in compliance math

    Type the question a quality manager would ask. IoT Query compiles it to a query over the Business Repository — mean kinetic temperature, time-out-of-range, and excursions per lane — while a model denoises a drifting probe and forecasts the breach, before it becomes a rejected load.

    IoT Query scheduled

    “Which lanes ran above +8 °C for over 30 min last week — and is any probe drifting?”

    SELECT lane, mkt(temp), tor(temp, 8)
    FROM readings WHERE week = -1 GROUP BY lane
    min out-of-range / lane
    30m12345
    MKT5.9 °C
    out-of-range12 min
    excursions2
    ML · probe 3 drifting +0.4 °C/day — readings denoised; lane 3 forecast to breach in ~40 min.
    5.9°MKT
    12mout-of-range

    Compliance math, computed

    Mean kinetic temperature, time-out-of-range, dwell, and excursion counts over any window — the numbers GDP, HACCP, and FSMA actually ask for, produced on a schedule.

    ML for reasoning & signal

    Denoise a drifting probe, tell a sensor fault from a real excursion, and forecast a breach from the rate of change — so alerts fire on product risk, not noise.

    coldest lane yesterday?Lane 7 · MKT −0.4 °C

    Conversational analytics

    Ask “which lanes breached above +8 °C last week?” and get a chart and a number back — no SQL, no BI ticket, no waiting on a report build.

    PDFAPIwebhook✓ load cleared

    Decisions & proof, out

    Auto-clear a clean load or flag a disputed one, then push the record to your TMS, BI, or a one-page PDF — the same evidence that settles a rejected delivery.

    Build FAQ

    What integrators ask before they build

    Probe the load, not just the unit. Reefer CAN/J1939 reports supply and return air; for product temperature you place BLE or 1-Wire probes in the load (front, middle, rear, and at the door). Navixy ingests both and you decide which drives alerts — typically product probes for compliance, reefer data for equipment health.

    A rugged IoT telematics box and a stainless temperature probe mounted on the frosted interior wall of a refrigerated trailer near the return-air grille
    Return-air probe−18.4 °C
    2,500+
    certified device models
    Certified, field-proven hardware

    The logic you author runs on hardware built for the cold

    The rules and reports are device-agnostic — but they run on real, ruggedized trackers, probes, and gateways rated for reefer interiors and trailer power. Navixy certifies 2,500+ models, so you match the sensor to the lane and trust the data it sends back.

    • Reefer-rated trackers, BLE / 1-Wire probes, and solar gateways
    • Capture over reefer CAN / J1939, serial, and analog inputs
    • Store-and-forward through dead zones and unhooked trailers
    Browse certified devices

    Design your cold-chain build with us

    Bring your products, lanes, devices, and compliance requirements. Our solutions engineers will map the sensors, IoT Logic flows, and IoT Query reports — and the certified hardware to run them.