Rate Limits and Retries

WebSocket connections, messages, and device operations may be rate limited. Clients should treat RATE_LIMITED as a recoverable request result, not as a connection failure.

Recommendations

• Send session.ping about every 30 seconds
• Reconnect with exponential backoff and random jitter
• Create a wsTicket only immediately before connecting
• Prefer events for state updates instead of repeatedly requesting real-time state
• Keep at least 3 seconds between explicit refreshes for the same device
• Control multiple relays with one relays array

device.state.get refreshes the whole device, including relays, digital inputs, analog inputs, and sensors. It shares the same per-device refresh budget as HTTP GET /wlte/v1/devices/{deviceId}; do not switch protocols to bypass the limit.

When a Request Is Limited

A rate-limited WebSocket request receives a reply correlated with the original request:

{
  "type": "reply",
  "requestId": "req_001",
  "code": "RATE_LIMITED",
  "message": "Too many requests",
  "data": {
    "retryAfterSeconds": 1
  }
}

Retry after the delay in data.retryAfterSeconds. Do not try to bypass the limit by reconnecting repeatedly, switching to REST, or sending the same operation concurrently.

Device refreshes and device controls are serialized per device. DEVICE_BUSY means that another operation is currently communicating with the device. Wait for it to finish before retrying; this is not a connection error and should not be bypassed by opening another connection.

If POST /wlte/v1/ws/ticket returns HTTP 429, follow the REST API Rate Limits and Retries guidance.