The short answer
The cooling water is the induction furnace’s lifeline: a blocked hose, a scaling coil or a failing pump shows up first as a rising outlet temperature or a widening inlet–outlet difference, minutes to weeks before the furnace trips or a coil fails. Two clamp-on temperature probes and a flow switch, read by a Shelly Plus 1 with the Plus Add-on (about US$60), publish these over MQTT. InduQT learns the normal temperature rise for each melt and warns when it drifts, while the furnace’s own interlocks stay exactly as they are.
- Inlet and outlet water temperature and the rise across the coil, every few seconds
- Flow lost or restored, with the time it happened
- A warning when the rise creeps up melt after melt (scaling, a partly blocked hose)
- What to buy
- Fit the sensors
- Turn on MQTT
- Set up the MQTT broker (once per plant)
- Check the readings with Claude before you connect anything
- Wire it to InduQT
- What InduQT does with it
What to buy
Wi-Fi and MQTT for the Add-on below. Its relay is not used here. Maker: Shelly. Maker’s page
Reads up to five DS18B20 temperature probes and one digital input (the flow switch). Maker: Shelly. Maker’s page
Strapped to the inlet and outlet pipes under insulation; rated to 125 °C. Maker: Adafruit (or any). Maker’s page
Closed while water flows. Separate from the furnace’s own flow interlock. Maker: any (sized to your pipe).
Code option for a busbar, cable or coil-lead temperature. Maker: Espressif, Adafruit. Maker’s page
Runs the MQTT broker and the InduQT bridge (skip it if you already built the gateway). Maker: Raspberry Pi. Maker’s page
Prices are typical street prices in US dollars when we wrote this, not quotes; buy from the maker or a local distributor. InduQT does not sell sensors and is not paid by any maker named here.
Fit the sensors
- With the furnace off and isolated, strap one DS18B20 probe to the cooling-water inlet pipe and one to the outlet pipe, on bare metal, with thermal paste and pipe insulation over them.
- Fit the flow switch in the return line (or use a spare contact on an existing one, if the furnace maker allows it).
- Plug the Add-on onto the Shelly Plus 1, connect the probes to its DATA/VCC/GND terminals and the flow switch to its digital input.
- Power the Shelly in a small enclosure outside the furnace cabinet. In the Shelly web page → Add-on, add the two DS18B20 probes and the digital input.
Turn on MQTT
- Join the Shelly to the plant Wi-Fi with the Shelly app (or its own hotspot at 192.168.33.1).
- Open http://<device-ip> → Settings → MQTT and turn MQTT on. Server 192.168.1.20:1883, the sensors user and password.
- Client ID and topic prefix: factory/furnace-1.
- Turn on “Generic status update over MQTT”. Save; the device reboots and starts publishing.
The Add-on’s probes appear as temperature:100 and temperature:101, the flow switch as input:100. The Shelly publishes factory/furnace-1/status/temperature:100 with tC (and tF), and status/input:100 with state. The bridge sends them as temperature_100.tC, temperature_101.tC and input_100.state.
ESP32 option: the sketch below reads a K-type thermocouple and the flow switch and publishes outlet_temp_c, flow_ok and thermocouple_fault every 5 s. Written for the esp32 boards package 3.x, PubSubClient 2.8 and the Adafruit MAX31855 library; not yet run on a furnace.
ESP32 sketch: thermocouple + flow switch → factory/furnace-1/cooling
// Cooling-water outlet temperature (thermocouple) and flow switch → MQTT every 5 s
// Board: any ESP32 dev board (e.g. Espressif ESP32-DevKitC). Arduino IDE 2.x with the
// "esp32 by Espressif Systems" boards package.
// Libraries (Library Manager): PubSubClient by Nick O'Leary, Adafruit MAX31855 library
#include <WiFi.h>
#include <PubSubClient.h>
#include <SPI.h>
#include <Adafruit_MAX31855.h>
const char* WIFI_SSID = "factory-wifi";
const char* WIFI_PASSWORD = "wifi-password";
const char* MQTT_HOST = "192.168.1.20"; // the Raspberry Pi running Mosquitto
const int MQTT_PORT = 1883;
const char* MQTT_USER = "sensors";
const char* MQTT_PASSWORD = "sensors-password";
const char* TOPIC = "factory/furnace-1/cooling";
const int FLOW_SWITCH = 27; // dry contact from the flow switch, to GND; closed = flow OK
WiFiClient net;
PubSubClient mqtt(net);
void connectAll() {
while (WiFi.status() != WL_CONNECTED) { delay(500); }
while (!mqtt.connected()) {
if (!mqtt.connect("furnace-1-cooling", MQTT_USER, MQTT_PASSWORD)) delay(2000);
}
}
Adafruit_MAX31855 thermo(18, 5, 19); // CLK, CS, DO
void setup() {
Serial.begin(115200);
pinMode(FLOW_SWITCH, INPUT_PULLUP);
WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
mqtt.setServer(MQTT_HOST, MQTT_PORT);
delay(500);
}
void loop() {
connectAll();
double outlet = thermo.readCelsius();
int flowOk = digitalRead(FLOW_SWITCH) == LOW ? 1 : 0;
char json[120];
if (isnan(outlet)) {
snprintf(json, sizeof json, "{\"flow_ok\":%d,\"thermocouple_fault\":1}", flowOk);
} else {
snprintf(json, sizeof json, "{\"outlet_temp_c\":%.1f,\"flow_ok\":%d,\"thermocouple_fault\":0}", outlet, flowOk);
}
mqtt.publish(TOPIC, json);
mqtt.loop();
delay(5000);
}Set up the MQTT broker (once per plant)
The sensors publish their readings to a broker: a small program that receives MQTT messages and hands them to whoever subscribes. Mosquitto is free and runs on a Raspberry Pi, an old PC or a small industrial box on the plant network. You need one per plant, not one per machine. If you already have a broker (Node-RED, Home Assistant, an IoT gateway), use it and skip this step.
# Raspberry Pi OS, Debian or Ubuntu
sudo apt update
sudo apt install -y mosquitto mosquitto-clients
# One user for the sensors and one read-only user for testing
sudo mosquitto_passwd -c /etc/mosquitto/passwd sensors
sudo mosquitto_passwd /etc/mosquitto/passwd viewer# /etc/mosquitto/conf.d/factory.conf
listener 1883
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl# /etc/mosquitto/acl
user sensors
topic readwrite factory/#
user viewer
topic read factory/## Mosquitto 2 wants these files readable only by its own user
sudo chown mosquitto: /etc/mosquitto/passwd /etc/mosquitto/acl
sudo chmod 0700 /etc/mosquitto/passwd /etc/mosquitto/acl
sudo systemctl restart mosquitto
sudo systemctl enable mosquitto
# Watch everything that arrives (Ctrl+C to stop)
mosquitto_sub -h localhost -u viewer -P 'viewer-password' -t 'factory/#' -vCheck the readings with Claude before you connect anything
Before the data goes anywhere, make sure the sensor is telling the truth. Record two minutes of messages to a file and ask Claude (or ChatGPT) to check them. This catches the usual first-day problems (a clamp on the wrong cable, a probe reading the room instead of the pipe, a sensor that only reports when something changes) while you are still standing at the induction furnace cooling circuit.
# Record 2 minutes of messages to a file you can give Claude or ChatGPT
mosquitto_sub -h 192.168.1.20 -u viewer -P 'viewer-password' \
-t 'factory/#' -v -W 120 | while read -r line; do
echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) $line"
done > sensor-sample.txt# Windows PowerShell, with Mosquitto installed from mosquitto.org
& "C:\Program Files\mosquitto\mosquitto_sub.exe" -h 192.168.1.20 -u viewer -P viewer-password `
-t "factory/#" -v -W 120 | ForEach-Object { "$(Get-Date -Format o) $_" } | Out-File sensor-sample.txtI've attached sensor-sample.txt: two minutes of MQTT messages from a sensor I just fitted to the induction furnace cooling circuit.
Each line is: time, topic, payload.
Please check it for me:
1. List each topic and every numeric field in it, with the min, max and typical value.
2. Tell me whether the values are physically plausible for the induction furnace cooling circuit. Inlet and outlet should be close together (within 1–2 °C) when the furnace is idle, and the outlet should rise during a melt by roughly what the furnace manual gives for full power. input_100.state should stay 1 (flow) throughout. Work out the inlet–outlet difference for me and tell me how it changed during the melt.
3. Point out gaps longer than 30 seconds, repeated identical values, or fields that are always 0.
4. Say which fields are worth sending to InduQT as signals and which I can ignore.
Answer in a short table, then a list of anything I should fix before I wire it up.Claude Code or Claude desktop with a terminal can run the mosquitto_sub command for you: ask it to "subscribe to factory/# on 192.168.1.20 as viewer for two minutes and check the readings". Either way the readings stay on your laptop: nothing is stored in InduQT until you wire it up in the next step.
Using a cloud broker (HiveMQ Cloud, EMQX Serverless or your own server with TLS) instead of one on the plant network? Add the free InduQT connector to Claude (https://claude.ai/directory/connectors/induqt) and Claude can listen to the broker for a few seconds itself:
Use InduQT to preview my MQTT broker before I connect it:
url mqtts://<your-cluster>.hivemq.cloud:8883, topic factory/#,
username viewer, password <viewer password>. Listen for 10 seconds.
Then tell me which topic level names the machine and which fields are numeric.Wire it to InduQT
Once the readings look right, send them to InduQT. The simplest way is a small bridge on the same Raspberry Pi: it listens to your broker and forwards every number to InduQT over HTTPS. It works on every InduQT plan, including the free one (up to 3 machines), and nothing on the plant network has to be opened to the internet.
- In Claude with the InduQT connector, paste the prompt below. Claude creates the site, the machine and a key that can only send readings to that site. (No Claude? Do the same in the InduQT app: Add machine with the same externalId, then Settings → API keys → a key with the ingest scope, limited to the site.)
- Copy the key Claude shows you. It is shown once.
- Start the bridge on the Raspberry Pi with that key.
- Ask Claude for the latest values, and set the normal bands.
Set up InduQT for this sensor:
1. Create a site called "Plant 1" (skip if it already exists).
2. Create a machine named "furnace-1" with externalId "furnace-1" and family "other".
3. Create an ingest key for the site called "Raspberry Pi bridge" and show it to me once.
After I start the bridge, I'll ask you to check the latest values. The signals will be temperature_100.tC (inlet), temperature_101.tC (outlet) and input_100.state (flow).python3 -m venv ~/induqt && source ~/induqt/bin/activate
pip install "paho-mqtt>=2.0" requests
export MQTT_HOST=localhost MQTT_USER=viewer MQTT_PASSWORD='viewer-password'
export MQTT_TOPICS='factory/#'
export INDUQT_API_KEY='iq_live_…' # the site key Claude or the app created for you
python3 induqt_bridge.pyinduqt_bridge.py (the whole bridge, about 120 lines)
#!/usr/bin/env python3
"""
induqt_bridge.py — forward MQTT sensor messages to InduQT.
Subscribes to your local broker, turns each message into numbers, and posts them
to the InduQT ingest API in batches. Works on every InduQT plan, including the free one,
and your broker never has to be reachable from the internet.
factory/<machine>/<anything> -> machine = <machine> (matched to the machine's externalId)
factory/pump-3/vibration {"vib_rms_x_g": 0.12} -> signal vib_rms_x_g
factory/comp-1/status/em:0 {"a_current": 12.4} -> signal em_0.a_current
(two or more levels after the machine: the last level names the group, so
two probes or two channels never overwrite each other)
{"temperature": {"tC": 41.2}} -> signal temperature.tC
factory/furnace-1/temp 21.7 -> signal temp (a bare number takes the last level)
pip install "paho-mqtt>=2.0" requests
"""
import json
import os
import re
import threading
import time
import paho.mqtt.client as mqtt
import requests
MQTT_HOST = os.environ.get("MQTT_HOST", "localhost")
MQTT_PORT = int(os.environ.get("MQTT_PORT", "1883"))
MQTT_USER = os.environ.get("MQTT_USER")
MQTT_PASSWORD = os.environ.get("MQTT_PASSWORD")
TOPICS = [t.strip() for t in os.environ.get("MQTT_TOPICS", "factory/#").split(",") if t.strip()]
MACHINE_LEVEL = int(os.environ.get("MACHINE_LEVEL", "1")) # factory/<machine>/... is level 1
SEND_EVERY = float(os.environ.get("SEND_EVERY", "10")) # seconds between posts
IGNORE = set(os.environ.get("IGNORE_FIELDS", "id,ts,time,timestamp,unixtime,Time").split(","))
INGEST_URL = os.environ.get("INDUQT_URL", "https://api.induqt.ai/v1/ingest")
API_KEY = os.environ["INDUQT_API_KEY"] # a site key from InduQT (Settings -> API keys)
BAD = re.compile(r"[^A-Za-z0-9_.\-]")
buffer, lock = [], threading.Lock()
def key(name):
return BAD.sub("_", name)[:64]
def numbers(prefix, value, out):
"""Collect every number in a JSON value; true/false become 1/0."""
if isinstance(value, bool):
out[key(prefix)] = 1 if value else 0
elif isinstance(value, (int, float)):
out[key(prefix)] = value
elif isinstance(value, str):
text = value.strip().lower()
if text in ("on", "true", "online"):
out[key(prefix)] = 1
elif text in ("off", "false", "offline"):
out[key(prefix)] = 0
else:
try:
out[key(prefix)] = float(text)
except ValueError:
pass
elif isinstance(value, dict):
for k, v in value.items():
if k not in IGNORE:
numbers(f"{prefix}.{k}" if prefix else k, v, out)
def on_connect(client, userdata, flags, reason_code, properties):
print(f"MQTT connected ({reason_code}); subscribing to {TOPICS}")
for t in TOPICS:
client.subscribe(t, qos=1)
def on_message(client, userdata, msg):
levels = msg.topic.split("/")
if len(levels) <= MACHINE_LEVEL:
return
machine = levels[MACHINE_LEVEL]
try:
payload = json.loads(msg.payload.decode("utf-8", "replace"))
except ValueError:
payload = msg.payload.decode("utf-8", "replace")
values = {}
group = levels[-1] if len(levels) - MACHINE_LEVEL > 2 else ""
if isinstance(payload, dict):
numbers(group, payload, values)
else:
numbers(levels[-1], payload, values)
if values:
with lock:
buffer.append({"machine": machine, "ts": int(time.time() * 1000), "values": values})
def sender():
while True:
time.sleep(SEND_EVERY)
with lock:
batch = buffer[:500]
if not batch:
continue
try:
r = requests.post(
INGEST_URL,
headers={"Authorization": f"Bearer {API_KEY}"},
json={"readings": batch, "autoCreate": True},
timeout=15,
)
if r.status_code < 300:
with lock:
del buffer[: len(batch)]
print(f"sent {len(batch)} readings: {r.json()}")
elif r.status_code in (400, 401, 403):
print(f"InduQT refused the batch ({r.status_code}): {r.text}")
with lock:
del buffer[: len(batch)] # fix the key or mapping; retrying will not help
else:
print(f"InduQT returned {r.status_code}; will retry")
except requests.RequestException as e:
print(f"network error, will retry: {e}")
with lock:
del buffer[:-5000] # keep at most ~5,000 readings while offline
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="induqt-bridge")
if MQTT_USER:
client.username_pw_set(MQTT_USER, MQTT_PASSWORD)
client.on_connect = on_connect
client.on_message = on_message
threading.Thread(target=sender, daemon=True).start()
client.connect(MQTT_HOST, MQTT_PORT, keepalive=60)
client.loop_forever()
Keep it running after a reboot (systemd)
# /etc/systemd/system/induqt-bridge.service — keeps the bridge running after a reboot
[Unit]
Description=MQTT to InduQT bridge
After=network-online.target mosquitto.service
[Service]
User=pi
EnvironmentFile=/home/pi/induqt-bridge.env
ExecStart=/home/pi/induqt/bin/python3 /home/pi/induqt_bridge.py
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
# then:
# sudo systemctl daemon-reload && sudo systemctl enable --now induqt-bridge
# journalctl -u induqt-bridge -fThe bridge treats the topic level after factory/ as the machine (it matches the machine's externalId and creates it if needed), turns every number in the message into a signal (nested fields become names like temperature.tC; when the topic has a group after the machine, such as Shelly's status/em:0, the group goes in front, as em_0.a_current, so two channels never overwrite each other; true/false and on/off become 1/0) and sends a batch every 10 seconds. It was run end to end on 2026-10-31 against Mosquitto 2 with Shelly Gen2, Theengs and plain-number messages. Prefer Node-RED? The same bridge as a Node-RED flow is on the gateway guide.
Show me the latest values InduQT has for furnace-1.
Then set these normal bands so InduQT knows what "normal" looks like: temperature_101.tC up to the outlet limit in the furnace manual, and input_100.state normal at 1.On the Plant Monitor plan InduQT can also subscribe to a broker directly. Point your sensors (or a Mosquitto bridge) at a cloud broker with TLS, then ask Claude to "create an MQTT connector for this broker, machine from topic level 1", or add it in the app under the site → Connect data → MQTT broker.
What InduQT does with it
- Learns the normal temperature rise for each stage of a melt and flags the first melt where it is higher for the same power.
- Forecasts when the outlet temperature will reach its limit if the trend continues, so the coil can be descaled on a planned stop.
- Records every loss of flow with the time and what the temperatures did, for the maintenance log.
In InduQT, rename temperature_100.tC to "Inlet water" and temperature_101.tC to "Outlet water" on furnace-1, both in °C. Then tell me how the outlet–inlet difference has changed over the last 30 days.Frequently asked questions
Why not use the furnace’s own sensors?
Where the furnace controller exposes them (Modbus, Profibus, an OPC UA server), use them: see the PLC guide. Many older and smaller furnaces do not, and two clamp-on probes outside the cabinet are the fastest way to get the data without touching the controls.
Will the magnetic field affect Wi-Fi?
It can, close to the coil. Keep the Shelly a few metres away, outside the cabinet, and use the Pro models’ Ethernet if Wi-Fi is unreliable in the melt shop.