If you’ve got a freezer, a refrigerated room, a greenhouse, or a server closet with a temperature sensor, this post is going to save you a $2,400/year subscription to a cold-chain monitoring SaaS.
We’re going to subscribe an MQTT broker to Tablize, let the agent identify your sensor topics, set up a Watch on a temperature threshold, and route alerts to Slack. Total time: about 10 minutes. No Python, no Node-RED, no Grafana setup.
What you need
- An MQTT broker your sensors are publishing to. Mosquitto, HiveMQ, EMQX — any of them. If you don’t have one yet, EMQX has a free cloud broker that takes 2 minutes to spin up.
- At least one sensor publishing temperature data as JSON or plain numeric values. Most consumer-grade ESP32-based sensors do this out of the box.
- A Tablize workspace on Pro tier ($60/month). MQTT is a Pro feature because it needs an always-on compute pod — your agent has to be awake when the sensor data arrives.
- A Slack workspace for delivery. (Email works too — we’ll mention it at the end.)
Step 1: Connect Tablize to your MQTT broker
In the Tablize sidebar, click Spaces (the IoT section). If you’ve never used IoT in Tablize, this is the entry point.
Click Add MQTT broker. You’ll need:
- Broker host (e.g.,
broker.hivemq.comor your EMQX cloud URL) - Port (1883 for plain MQTT, 8883 for TLS — use TLS)
- Username + password (if your broker requires auth)
- Subscription topics (start with
#to receive everything, or scope to e.g.sensors/+/temperature)
Hit “Test connection.” Tablize subscribes, waits for messages, and shows you the first 10 it receives. If you see your sensor data flowing in, you’re connected.
This is also the moment to give Tablize a clue about which sensors are which. If your sensors publish to topics like sensors/freezer-east/temperature and sensors/walkin-cooler-1/temperature, the agent will infer “freezer-east” and “walkin-cooler-1” are two distinct devices. If your topics are opaque (devices/0a3f1b2c/temp), you’ll want to rename them in the Spaces UI after they appear — give each one a human-readable name.
Step 2: Let the agent learn your data
Open a new chat. Type:
"What MQTT data is currently flowing into my workspace?
Show me each topic, how often it's publishing, and the
typical value range for any numeric fields."The agent queries your last 24 hours of MQTT data (which Tablize stores in TimescaleDB automatically — you don’t have to set up any pipeline), and gives you back a table:
- Topic name
- Messages per minute
- Field names extracted from the JSON payload
- Min / max / median value for each numeric field
This is your sensor inventory. It also surfaces problems — if a sensor publishes once and stops, it shows up here as “1 message in last 24h” and you know to go check it.
Step 3: Set up the Watch
Now the part that replaces the $200/month SaaS. Type:
"Watch every freezer sensor (anything with 'freezer' in the topic name).
If the temperature reading goes above -15°C for more than 5 consecutive
minutes between 10 PM and 6 AM, send me a Slack DM with the sensor name,
current temperature, how long it's been above threshold, and a link
to view the live data in Tablize."The agent:
- Parses your rule into the underlying Watch primitives — filter (topic LIKE ‘%freezer%’), trigger (temperature > -15), duration (5 min), schedule (10 PM - 6 AM), action (Slack DM).
- Asks you which Slack workspace + channel/DM to use. If you haven’t connected Slack yet, it walks you through OAuth.
- Shows you the rule in plain language for you to confirm.
- Activates the Watch.
The Watch lives in your Watches sidebar from now on. You can edit it, pause it, or duplicate it. The agent didn’t write any code that you can’t see — every Watch is a structured object with the trigger, condition, and action all visible and editable.
Step 4: Verify it works
This is the step most cold-chain rollouts skip and regret. Tablize makes it easy:
"Simulate a 30-minute window where freezer-east goes above -15°C
from 11 PM to 11:30 PM. Tell me what notifications my Watch
would have sent."The agent runs a dry-run simulation against historical data, applies the rule, and shows you exactly what Slack messages would have fired. If your Watch is wrong (wrong time window, wrong sensor pattern, threshold backwards), you see it now.
You can also force a real trigger by temporarily lowering the threshold (e.g., -100°C — anything above that fires immediately), confirming the Slack DM arrives, then putting the real threshold back. Takes 30 seconds.
What this costs
Compared to typical cold-chain SaaS:
| Tablize Pro | Cold-chain SaaS A | Cold-chain SaaS B | |
|---|---|---|---|
| Monthly cost | $60 (includes everything in Tablize) | $200 per location | $150 per location, plus alerts billed extra |
| Sensors covered | Unlimited per workspace | Usually 10-50 per plan tier | Usually 5-20 per plan tier |
| Other use cases included | All of Tablize | None | None |
| Lock-in to vendor sensors | None | Often yes | Often yes |
The reason the dedicated SaaS exists is that some customers (hospitals, FDA-regulated food storage, vaccine cold-chain) need certified hardware, audit-trail compliance, and 24/7 SLA support. For those, you should pay the $200/month. For everyone else — a restaurant with three freezers, a farm with a greenhouse, an apartment with a wine fridge that broke last year — Tablize is the right shape.
Extending the Watch
Once you have the basic Watch running, the natural next moves:
Add multi-channel alerting. “Also page me via SMS if the alert fires between 11 PM and 5 AM and I haven’t acknowledged it within 10 minutes.” Tablize supports email, Slack, and webhooks out of the box; SMS via Twilio webhook.
Aggregate event reports. “Every Sunday morning, send me a digest of every freezer event from the past week — sensor name, time, peak temperature, duration above threshold.” This is a separate Report on top of your Watch’s event history.
Generate a dashboard. “Build me a dashboard showing live temperature for all freezers, a 24-hour line chart per sensor, and a list of the last 10 alerts.” This is a generated App, shareable via public link if your kitchen manager needs to see it from a phone.
Watch derivative conditions. “Ping me if any sensor stops publishing for more than 15 minutes during business hours” — catches sensor failure, not just temperature drift. Often more useful than temperature alerts.
What about email instead of Slack?
Same flow, swap the action: “send me an email instead of Slack.” The agent reconnects the Watch action to email (uses your account’s verified address by default).
You can also route to a webhook — common pattern for piping into PagerDuty, Opsgenie, or a custom notification stack.
Common gotchas
TLS vs plain MQTT. Use TLS (port 8883) in production. Plain MQTT (port 1883) sends credentials in clear. Tablize supports both but defaults to TLS.
Topic wildcards. MQTT uses + (single level) and # (multi-level). sensors/+/temperature matches sensors/freezer-1/temperature but not sensors/freezer-1/room-a/temperature. Use sensors/# for the latter.
Duplicate messages. Some QoS-0 publishers retry on flaky networks, which can cause duplicate events. Tablize deduplicates on the same (topic, timestamp, payload) triple by default — if your sensors have aggressive retry behavior and Tablize isn’t deduplicating correctly, add a unique event_id to your payload.
Sensor offline. If a sensor goes offline, your temperature Watch will never fire (because there are no readings exceeding the threshold). Always pair a temperature Watch with a “sensor stopped publishing” Watch — that’s what catches the dead sensor.
What’s next
If this is your first IoT integration in Tablize, the natural extensions are: connect a second sensor type (humidity, door-open events, power consumption), generate a Spaces map UI showing all your physical assets, or build a maintenance ticketing app on top of your sensor events. All of these are one-sentence prompts away.
Try Tablize Pro with your MQTT broker →
Related reading: