Reference · built on requestConnectorEnergy, EV & distributed resources

Tuya IoT Development Platform

Device status, commands, and event messages for Tuya-linked plugs and meters through the Tuya OpenAPI and Message Service.

Request accessPricing ↗

About

Tuya IoT Development Platform is the cloud side of devices built on Tuya modules and paired through the SmartLife app or an app of your own. A cloud project on the Tuya Developer Platform holds the Access ID and Access Secret, the devices you link to it, and the API products you subscribe to, IoT Core among them. The OpenAPI reports a device as a set of function codes and accepts commands against them. The Message Service, built on Pulsar, pushes device reports and online, offline, rename, and delete events to a consumer you run.

Through Fibric, an operator reads plug and meter status, follows the message stream, and proposes a command such as switch off for your approval. The command goes out once and a receipt records what changed, why, and how to undo it.

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

  • Latest device status by device ID through GET /v1.0/iot-03/devices/{device_id}/status
  • Device details through GET /v1.0/iot-03/devices/{device_id} and its instruction set through GET /v1.0/iot-03/devices/{device_id}/functions
  • Instruction and status sets for a device through GET /v1.0/devices/{device_id}/specifications
  • Device data reports as devicePropertyMessage and deviceEventMessage (protocol 1000), or statusReport (protocol 4), from the Message Service
  • deviceOnline and deviceOffline (protocol 1001), or online and offline (protocol 20), as devices drop and return
  • deviceNameUpdate, deviceBindSpace, deviceUnbindSpace, nameUpdate, bindUser, and delete messages when devices are renamed, moved, or removed

Proposed actions

  • Target capability: propose a control command through POST /v1.0/iot-03/devices/{device_id}/commands, sent as a commands array of code and value pairs
  • Target capability: propose the same command for devices in a Smart Home project through POST /v1.0/devices/{device_id}/commands

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

What you can build

  • Turn off what was left on

    Device status after hours shows plugs still switched on. The operator proposes an off command for each one, with the device name and the time it was last seen on.

    With Schedule Leak

  • Trim plug loads at the peak

    When site demand nears the threshold you set, the operator proposes off commands for the plugs you marked sheddable, and the matching on commands once the window has passed.

    With Peak Demand

  • Know when a device drops offline

    deviceOffline and offline messages from the Message Service mark the moment a plug or meter went silent. The operator proposes a check on the device, with the last status it reported.

    With Sensor Health

  • Run loads inside the tariff window

    With your tariff schedule beside the device list, the operator proposes on commands at the start of the cheap window and off commands at its end.

    With Tariff Window

Requirements

  • A cloud project on the Tuya Developer Platform with its Access ID and Access Secret
  • Devices linked to the project, for example by scanning the project's QR code with the SmartLife app
  • An IoT Core subscription; the Trial Edition is for individual developers and debugging and prohibits commercial use
  • The endpoint for the project's data center, for example https://openapi.tuyaus.com for Western America
  • A Pulsar consumer on the region's mqe host at port 7285 if you want events pushed rather than polled
Authentication
Access ID and Access Secret from the cloud project's Authorization Key section; each request carries client_id, t, sign_method HMAC-SHA256, and sign, plus an access_token from GET /v1.0/token?grant_type=1.

Limits

  • Device control is rate-limited per cloud project: 4 command sends per second and 50 property queries per second
  • The Trial Edition caps a project at 50 devices, 10 of them controllable, and one data center
  • Each app or app account can be linked with two projects at most
  • Events arrive through a Pulsar consumer you run against the region's mqe host, not through webhooks

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 Tuya IoT Development Platform ↗

Questions and answers

Which endpoint do I call for my data center?
China: https://openapi.tuyacn.com. Western America: https://openapi.tuyaus.com. Eastern America: https://openapi-ueaz.tuyaus.com. Central Europe: https://openapi.tuyaeu.com. Western Europe: https://openapi-weaz.tuyaeu.com. India: https://openapi.tuyain.com. Your project and the app account you link must sit in the same data center.
How do I get device events without polling?
Subscribe to the Message Service, which Tuya built on Pulsar. Connect a consumer to the region's host, for example pulsar+ssl://mqe.tuyaus.com:7285/, with the project's Access ID and Access Secret. Messages carry protocol, pv, t, data, and sign fields; the data field decrypts to a JSON string.
What are the request limits?
Limits apply per cloud project. Device control allows 4 sends of actions or properties per second and 50 property queries per second; device detail queries allow 10 per second. Beyond a limit the request is restricted. Tuya asks you to submit a ticket for more.
Ask about Tuya IoT 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 Tuya IoT 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