Events & Telemetry
Reading device state - over REST, and the /api/v1/ws WebSocket feed.
Telemetry (API-key callable)
Two Device Control-tagged endpoints read a device's reported state:
GET /api/v1/devices/{deviceId}/telemetry- history of readings.GET /api/v1/devices/{deviceId}/telemetry/latest- the quickest "current state" snapshot: one row per metric the device has ever reported, plus itsrelayState. This is what the quickstart polls after sending a command.
Both accept either an API key or a dashboard session - they're read paths with no side effects, so they're deliberately not locked to sessions the way configuration endpoints are.
Audit events (dashboard-only)
Every command sent, grant change, and schedule/rule action is recorded as a
DeviceEvent and readable via GET /api/v1/events (whole account) or
GET /api/v1/devices/{deviceId}/events (single device) - both session-only.
This is also what DeviceGrant rate limiting
counts against: a COMMAND_SENT event tagged with the grant's id in its metadata.
The WebSocket feed
GET /api/v1/ws is a live push feed of device state changes, so your
application doesn't have to poll. It authenticates with a session token
rather than an API key - see the WebSocket reference
for the connection details, the full message catalog, and how to handle the
4001 close code.