IoT, MQTT & cameras

Most data tools stop at your database. Tablize reads the physical world too — because sometimes “why did the order go wrong” lives on a warehouse camera, not in Postgres.

This page is for anyone running sensors, industrial equipment, cameras, or any device that speaks MQTT. If you don’t have hardware feeds, skip this page.

The model: Space → Asset → Point

Tablize doesn’t treat sensors as a flat list. They live in a three-level tree that maps the physical world:

Level	Example	What it contains
Space	Warehouse A, Cold room 2	Assets. Nestable (building → floor → room).
Asset	Freezer 7, Conveyor Belt B, Camera 3	Points. Has a kind (sensor / camera / meter / vehicle / …).
Point	Temperature, Voltage, Door-open	Time-series readings.

This structure is why you can ask “which freezer spiked last night” instead of “what’s the temperature on sensor-0042-port-B” — the Agent knows which assets are freezers, which room they’re in, and what normal looks like.

Connecting via MQTT

Tablize runs an EMQX broker for you. Getting a device online is three steps:

1. Create broker credentials. Workspace → Devices → + New device. You get a client ID, username, and password.
2. Point the device at the broker. Tablize Cloud: mqtts://mqtt.tablize.com:8883. Self-hosted: whatever host you run the broker on, port 1883 plain / 8883 TLS.
3. Publish on a topic. Default topic schema: {space}/{asset}/{point}. Publish JSON: {"value": 42.1, "ts": 1710000000} (ts optional; defaults to server time).

Messages land in TimescaleDB immediately. Within seconds of publishing, the Agent can query the point.

Supported topic patterns

• Tablize convention — {space}/{asset}/{point} — assets and points auto-created on first message.
• Custom topic — paste whatever scheme your devices already use, and provide a one-time mapping: “the second segment is asset_id, the third is point_name”. The Agent writes the mapping rule.
• Raw bytes — for devices that don’t speak JSON, upload a decoder (Python function) and Tablize runs it on each message. Works for CBOR, Protobuf, binary packed formats, even custom industrial protocols wrapped in MQTT.

Retained messages and QoS

• QoS 0 / 1 / 2 all supported. Default is QoS 1 — at-least-once delivery, dedupe on server side via message ID.
• Retained messages are honored. Useful for “last known state” queries after a reconnect.
• Will messages arrive in a separate device_events table — Tablize treats them as lifecycle signals, not data points.

Spatial UI

Workspace → Spaces → pick a space. You see:

• The asset tree on the left.
• A live data card for the currently selected asset (latest value per point, with sparklines).
• A time slider at the bottom — drag it to any moment in the last 30 days (or 1 year on Max) and see what the state looked like.

The time slider is the piece that makes debugging easy. “When exactly did the conveyor stop?” — drag to the minute, see every point’s state, watch the change ripple through.

Cameras

Camera feeds are a special kind of Asset (kind = camera). Two entry points:

• IP cameras (RTSP). Paste the RTSP URL in the Asset config. Tablize pulls a frame every N seconds (configurable) and stores it as Media. Live preview in the Spatial UI.
• Uploaded video or image streams. For devices that push frames via HTTP, use a Webhook (see Webhooks & APIs). Each upload becomes a timestamped frame.

Frames are first-class data. Ask the Agent: “show me the camera at the loading dock at the time the missing order was shipped.” It finds the frame matching the timestamp of the order row in Postgres and shows it to you.

For continuous video, frames are sampled, not stored as full video — storage explodes otherwise. You control the sample rate per camera.

AI on frames

Any frame stored as Media can be passed to the Agent for extraction:

• “List all SKUs visible in this photo” — the Agent uses vision + your product table to identify what’s on the shelf.
• “Is this worker wearing a safety helmet?” — binary yes/no, useful in a Watch.
• “Count the forklifts in each hourly frame” — a Script that produces a time-series table from images.

These calls use more tokens than plain SQL queries. The Agent warns before long batches.

Watches on devices

The most common IoT use case: alert me when a point crosses a threshold.

> Ping me if any freezer goes above -15°C for more than 5 minutes overnight.

The Agent creates a Watch (see Watches) that runs every minute against the right subset of assets. You get notifications only when the rule fires.

Because the Agent knows the Asset graph, it correctly interprets “any freezer” as assets WHERE kind='sensor' AND name ILIKE '%freezer%' in your Space hierarchy. You don’t list device IDs.

Storage and retention

Plan	Device storage	History retention
Plus	—	IoT not available
Pro	50 GB hot, 500 GB cold	1 year
Max	500 GB hot, 5 TB cold	5 years

“Hot” = queryable in under 100ms. “Cold” = a second or two to decompress, transparent to the Agent. Camera frames and raw video are separate — they share your Media storage quota.

Common gotchas

• No messages arriving. Check credentials, TLS, topic format. The Devices page shows last-seen-at for each device; if it’s “never,” the MQTT handshake isn’t completing.
• Messages arriving but not queryable. Usually a JSON parse error. The Devices page’s Recent messages tab shows each payload and whether it parsed. Fix the device’s format or upload a decoder.
• Camera frames lagging. Default RTSP sample is every 5 seconds. Crank it to 1 second if you need it, but your storage will grow fast.
• Watches not firing. Check that the Watch’s scope matches the asset tree. The Agent tells you in chat which assets match its rule — spot-check that list before relying on silence.

Next steps

• Watches — the most common home for device data.
• Dashboards — build a physical-world ops view.