Skip to content

A hosted WebSocket server for IoT devices

Devices open one WebSocket to Eventeer and send JSON events. You get acknowledgements, online status, last-seen times and a REST call to send commands back, without running a socket tier.

The problem

A fleet of sensors, trackers or controllers needs somewhere to send data that is always reachable. A plain HTTP POST per reading is wasteful on constrained links, and it tells you nothing about whether the device is still there.

A WebSocket fixes both, but it moves a burden to you. You have to hold thousands of long-lived connections, authenticate each device, handle reconnect storms after a deploy, track who is online, route a command to the node that holds the right socket, and store what comes in. That is real infrastructure for what is usually a side concern of the product.

Then there is the quiet failure: a device that stops reporting does not raise an error anywhere. Someone has to notice the silence.

How Eventeer handles it

  • One socket per device

    A device connects to the listener with its device_id and sends event frames. Eventeer upserts the device row and marks it online.

  • Per-device tokens

    Issue a device token bound to one device through the API. Revoke it without touching the rest of the fleet.

  • An ack for every event

    Each event frame carries your ref. The reply is an ack with the stored event id, or an error code such as payload_too_large.

  • Downlink through the API

    POST a message to a device and it is pushed down the open socket from any node. If the device is offline you get a 409 and can decide what to do.

  • Quiet-device alerts

    An absence alert fires when a device or listener sends nothing for N minutes. It resolves itself when events resume.

Connection behavior you can rely on

The server sends a WebSocket ping every 30 seconds by default and closes a socket after two quiet intervals. Close codes are explicit: 4401 unauthorized, 4402 plan required or spend cap reached, 4409 replaced by a newer connection, 4423 listener paused, 4429 rate limited. Devices can add an idempotency_key to an event frame so a resend after a flaky link is not stored twice.

Limits and cost

Concurrent connections are a hard limit by plan, shared with streams and WebSocket sources. Connection minutes are metered while a socket is open and billed as overage past the included amount, bounded by your spend cap. See pricing for exact figures.

What you do with the data

Every reading is a regular event: stored for your retention, filterable by device, streamable to a dashboard and available to metrics. Turn $.temp into an average, graph it, and alert when it crosses a threshold.

What it looks like

The device side is a single WebSocket and two frame types. The backend side is one REST call.

Device uplink and a downlink command
# Device: connect with a per-device token and send a reading
websocat -H "Authorization: Bearer $DEVICE_TOKEN" \
  "wss://app.eventeer.io/in/d/lst_…?device_id=pump-17"
{"type":"event","ref":"r1","data":{"temp":21.4}}
# Eventeer answers: {"type":"ack","ref":"r1","id":"0192f…"}

# Your backend: send the device a command (202, or 409 device_offline)
curl -X POST https://app.eventeer.io/api/v1/devices/$DEVICE_ID/messages \
  -H "Authorization: Bearer $EVENTEER_KEY" -H "Content-Type: application/json" \
  -d '{"data":{"cmd":"reboot"}}'

Questions

What happens when a device loses its connection?
The device is marked offline and its last-seen time is recorded. A sweeper also marks devices offline when their node dies. Reconnect with the same device_id and the older socket, if any, is closed with code 4409.
Do downlink messages queue while a device is offline?
No. A message to an offline device returns 409 device_offline. Downlink messages are best-effort, are not stored as events, and count as delivered events for billing.
How are device connections billed and limited?
Each open device socket meters one connection minute per minute. Plans include 1M, 10M or 100M minutes a month and cap concurrent connections at 50, 500 or 5,000, shared by devices, streams and WebSocket sources.

Connect your first device

Create a device listener, issue a token per device and watch readings arrive in the event explorer.