Reference · built on requestConnectorSensors, meters & gateways

Milesight Development Platform

Telemetry, TSL models, and history for Milesight LoRaWAN and IP devices, with webhook events and service calls.

Request accessPricing ↗

About

Milesight Development Platform connects Milesight sensors, controllers, and gateways to your applications. LoRaWAN end devices join through a Milesight gateway with its network server enabled; Wi-Fi and cellular devices connect over the Internet. Each Group carries an Application with its own client credentials and server address. Devices expose a Thing Specification Language model of properties, events, and services.

Through Fibric, an operator watches DEVICE_DATA webhooks, reads property history, and proposes a service call, a property update, or a configuration task. You approve. The platform runs it and the receipt keeps the request ID.

This is a reference listing. It documents what Fibric would read from Milesight Development Platform 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

  • DEVICE_DATA webhook events with deviceProfile (deviceId, sn, devEUI, name, model), a type of PROPERTY, EVENT, SERVICE, ONLINE, or OFFLINE, a tslID, and the payload
  • Property history through GET /device/openapi/v1/devices/{deviceId}/properties/history
  • The TSL model of a device through GET /device/openapi/v1/devices/{deviceId}/thing-specification
  • Device search and detail through POST /device/openapi/v1/devices/search and GET /device/openapi/v1/devices/{deviceId}
  • Device configuration through GET /device/openapi/v1/devices/{deviceId}/config
  • TASK_DATA events when a configuration task completes, and SYSTEM_MESSAGES such as SERVICE_NOTICE when the daily webhook quota is reached

Proposed actions

  • Target capability: propose a device service call through POST /device/openapi/v1/devices/{deviceId}/services/call
  • Target capability: propose an incremental property update through PATCH /device/openapi/v1/devices/{deviceId}/properties
  • Target capability: propose a configuration task through POST /device/openapi/v1/tasks
  • Target capability: propose adding a device through POST /device/openapi/v1/devices, or an RPS profile URL for provisioning

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

What you can build

  • Turn a threshold crossing into a work order

    A DEVICE_DATA event of type PROPERTY carries the temperature from a cold room sensor. The operator checks it against your limit and proposes the work order with sn and devEUI attached.

    With Cold Room Watch

  • Spot the sensor that stopped talking

    OFFLINE events and gaps in property history mark devices that went quiet. The operator proposes a gateway check or a battery swap and clears the item on the next ONLINE event.

    With Sensor Health

  • Adjust a controller without logging in

    When CO2 stays high, the operator proposes a service call on the ventilation controller, using the service defined in the device's TSL model. You approve and the platform sends it.

    With Indoor Air

  • Stay inside the daily webhook quota

    SERVICE_NOTICE messages say when the day's webhook pushes are used up. The operator proposes narrowing which events fire, or a plan change, before data goes missing.

    With Integration Health

Requirements

  • A Group on the platform, whose Application supplies the client credentials and the base URL shown under Authentication
  • For LoRaWAN devices, at least one Milesight LoRaWAN gateway online with LNS enabled, OTAA join, and a matching frequency band
  • For webhooks, an HTTPS callback URI with a valid certificate, set in Application Settings
  • A plan with enough device and request headroom: the Free plan allows 10 devices and 1,000 API requests per 24 hours
Authentication
An OAuth 2.0 client credentials grant at POST {base_url}/oauth/token using the Application's client ID and secret; the access token lasts 3599 seconds and the refresh token 2591999 seconds, sent as Authorization: Bearer.

Limits

  • Free plan: 1,000 API requests and 1,000 webhook events per 24 hours per Application, 2 webhook URIs, and only the latest reported data
  • Professional plan history is a 1-day window, so longer records sit in your own store
  • The platform stops sending after repeated webhook failures and reports it as a SYSTEM_ALERT; retry counts are not published
  • Webhook signature and payload checks are not described in the developer documentation

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 Milesight Development Platform ↗

Questions and answers

What does a Device Data webhook contain?
A JSON POST with eventID, eventCreatedTime in seconds, eventVersion, eventType DEVICE_DATA, and data. Inside data sit the deviceProfile (deviceId, sn, devEUI, name, model), a type of PROPERTY, EVENT, SERVICE, ONLINE, or OFFLINE, the tslID, and the payload with the reported values.
How many API calls does the platform allow?
It depends on the plan. Free allows 1,000 API requests per 24 hours and 1,000 webhook events per 24 hours per Application. Professional allows 1,000 plus 100 per device and unlimited webhook events. Private Cloud is unlimited.
Do LoRaWAN sensors connect directly?
No. They need at least one Milesight LoRaWAN gateway online on the platform with LNS enabled. Devices use OTAA and must match the gateway's frequency band. Non-LoRaWAN devices such as Wi-Fi or cellular models connect over the Internet, with Auto Provision optional.
Ask about Milesight Development Platform

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Milesight Development Platform through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy