Reference · built on requestConnectorSensors, meters & gateways

Losant

Device state, time-series queries, events, data tables, and webhooks from the Losant REST API at api.losant.com.

About

Losant is an application enablement platform for connected products. Each application holds devices with up to 256 typed attributes (Number, String, GPS, Boolean, Blob) that report state over MQTT, REST, or a workflow. The REST API at api.losant.com serves the last state and the composite state per device, time-series and last-value queries across devices by id, tag, or query, events with a level and a state of new, acknowledged, or resolved, and data tables with row queries. Webhooks give an application fixed HTTP endpoints that trigger workflows; state and command streams arrive as Server Sent Events.

An operator on Fibric reads state and events and proposes the device command, the event update, or the table row for your approval.

This is a reference listing. It documents what Fibric would read from Losant and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Last known state per device through GET /applications/{APPLICATION_ID}/devices/{DEVICE_ID}/state, with limit, start, end, and duration
  • The composite last complete state of a device through GET .../devices/{DEVICE_ID}/compositeState, narrowed by attributes
  • Time-series data across devices through POST /applications/{APPLICATION_ID}/data/time-series-query with start, end, resolution, aggregation, and attributes
  • The last value of one attribute across devices through POST .../data/last-value-query, selected by deviceIds, deviceTags, or deviceQuery
  • Events with level, state, subject, message, and deviceId, and the first new event ordered by severity
  • Data table rows through GET .../data-tables/{DATA_TABLE_ID}/rows and POST .../rows/query with $and, $or, and $nor conditions
  • Live state and command streams as Server Sent Events through .../devices/{DEVICE_ID}/stateStream and .../commandStream

Proposed actions

  • Target capability: propose a command through POST /applications/{APPLICATION_ID}/devices/{DEVICE_ID}/command
  • Target capability: propose creating an event, or updating matching events' state with the asynchronous PATCH
  • Target capability: propose adding rows through POST /applications/{APPLICATION_ID}/data-tables/{DATA_TABLE_ID}/rows
  • Target capability: propose a device data export through POST .../devices/{DEVICE_ID}/export with a callbackUrl

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Work the event queue

    Read events in state new, ordered by level. Propose which to acknowledge and which need a person, then the PATCH that updates their state once you approve.

    With Alarm Triage, Anomaly Notice

  • Notice the device that stopped reporting

    Compare each device's last state time with its expected interval, using the last-value query across a device tag. Propose the check with the composite state attached.

    With Sensor Health, Data Freshness

  • Send the command and keep the record

    When a queried attribute crosses your threshold, propose the command payload for that device. You approve; the command goes out once and the outcome is written to a data table row.

    With Cold Room Watch, Setpoint Drift

Requirements

  • A Losant application containing the devices, events, data tables, and webhooks in scope
  • An application API token whose scope covers the endpoints used; all.Application is the default scope
  • Content-Type and Accept headers set to application/json on every request
  • A webhook in the application with basic authentication filled in, if Losant workflows should push into Fibric
Authentication
A Bearer token in the Authorization header: an application API token created through POST /applications/{APPLICATION_ID}/tokens with a name, expirationDate, status, and scope list, shown once at creation.

Limits

  • Device state is accepted at 30 messages per 15 second window per device; each state payload is at most 256KB
  • Event creation is limited to 15 calls per 15 second window per application
  • Webhooks accept 100 calls per 10 second window and 100 concurrent connections per application, with a 256KB payload; a workflow reply must come within 60 seconds
  • Reported state may be dated no more than 30 days in the past or 24 hours in the future

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Losant ↗

Questions and answers

How does Fibric get data out of Losant?
Two documented ways. Poll the state, time-series, last-value, and event endpoints on api.losant.com, or attach to a device's stateStream and commandStream over Server Sent Events. Losant webhooks point the other way: they are endpoints that trigger workflows, which Fibric can call.
What token does Fibric use?
An application API token, created through POST /applications/{APPLICATION_ID}/tokens with a name, expirationDate, status, and a scope list that defaults to all.Application. The token value is returned once at creation. A user token with all.User grants full account access and is broader than needed.
What are the rate limits?
Device state: 30 messages per 15 second window per device, 256KB each. Event creation: 15 calls per 15 second window per application. Webhooks: 100 calls per 10 second window and 100 concurrent connections per application. Multipart file uploads are capped at 10MB.
Ask about Losant

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.