rekuiperProcess Industrial & IoT Device Data Where It Is Produced.

Where it fits ​

You write a rule in SQL. rekuiper executes the rule on every message when the message arrives. You add, change, and remove rules through a REST API while the engine runs.

What changes when you deploy rekuiper on the edge:

• Transmit less data: One summary row per minute replaces sixty raw readings.
• Decide locally: An alert fires on the gateway in sub-milliseconds without cloud latency.
• Survive network disconnects: Results buffer in memory and on disk, then transmit in order when the uplink reconnects.

Try it in 60 seconds ​

This demo requires Docker. A built-in simulator generates sensor readings.

1. Start the engine.

docker run -d --name rekuiper -p 9081:9081 indusstack/rekuiper:1.0.0-rc4

2. Register simulated sensor readings (ten events per second).

curl -X PUT http://localhost:9081/metadata/sources/simulator/confKeys/demo \
  -H "Content-Type: application/json" \
  -d '{
    "data": [
      {"deviceId": "pump-1", "temperature": 21.5},
      {"deviceId": "pump-1", "temperature": 23.0},
      {"deviceId": "pump-1", "temperature": 24.5}
    ],
    "interval": 100,
    "loop": true
  }'

3. Create a stream to ingest the readings.

curl -X POST http://localhost:9081/streams \
  -H "Content-Type: application/json" \
  -d '{"sql": "CREATE STREAM demo () WITH (TYPE=\"simulator\", CONF_KEY=\"demo\")"}'

4. Add a rule to aggregate five seconds of readings into one row.

curl -X POST http://localhost:9081/rules \
  -H "Content-Type: application/json" \
  -d '{
    "id": "five_second_summary",
    "sql": "SELECT count(*) AS readings, avg(temperature) AS avg_temp FROM demo GROUP BY TUMBLINGWINDOW(ss, 5)",
    "actions": [{ "log": {} }]
  }'

5. Verify the output.

docker logs -f rekuiper

[RULE five_second_summary] Matched record: {"readings": Number(49), "avg_temp": Number(23.03)}

Fifty readings enter the pipeline. One row exits. To route this row to MQTT, Kafka, or a database, replace log with another sink.

Continue with the Getting Started Guide.

Common patterns ​

Each pattern requires one or two SQL rules.

Cut the cloud bill ​

Devices publish every second. Cloud analytics require one row per minute. Aggregate on the gateway and send the summary.

SELECT deviceId, avg(temperature) AS avg_temp, max(temperature) AS max_temp
FROM sensors
GROUP BY deviceId, TUMBLINGWINDOW(ss, 60)

Read more: Windows

Alert locally ​

A sensor value crosses a safety threshold. Filter on the gateway and publish an MQTT command or call a webhook immediately. The alert does not wait for cloud round trips.

SELECT deviceId, temperature, meta(topic) AS source_topic
FROM sensors
WHERE temperature > 80

Read more: Rules · REST sink · MQTT sink

Survive a bad link ​

The cellular or WAN uplink drops for minutes or hours. Enable the sink cache. Results buffer on disk, and rekuiper resends them in order when the link reconnects.

{
  "mqtt": {
    "server": "tcp://cloud.example.com:1883",
    "topic": "site1/summary",
    "enableCache": true
  }
}

Read more: Sink cache

One feed, many destinations ​

One data feed routes to storage, to a dashboard, and to an alert topic. Multiple rules subscribe to one stream. Each rule defines its own SQL and destinations.

Read more: Sinks

Enrich before sending ​

Messages carry a device ID. Upstream applications require site and asset names. Join the stream with a lookup table in Redis or a SQL database.

SELECT s.deviceId, s.temperature, a.site, a.asset_name
FROM sensors AS s
INNER JOIN assets AS a ON s.deviceId = a.id

Read more: Lookup tables

Is it a fit? ​

Measured on one CPU core ​

All tests run on dedicated Linux hardware constrained to one physical CPU core and 1 GiB of RAM.

Method and full results: Benchmark Overview · Throughput · Parallel rules

Connectors ​

Details: Sources · Sinks

Where to go next ​