DEV Community: Arjun Krishna

Build an ESP32 energy meter with a live dashboard

Arjun Krishna — Sat, 18 Jul 2026 09:07:23 +0000

Most ESP32 energy-meter tutorials you'll find are built on platforms that have since changed out from under them — deprecated app flows, retired tokens, code that no longer compiles as written. This build has no such dependency. A PZEM-004T does the metering, the ESP32 reports over plain HTTPS/WebSocket, and the dashboard, history, and alerts run in nodrix on your own Cloudflare account — nothing in the path can be discontinued on you.

What you get: live volts, amps, watts, and a lifetime kWh counter on a dashboard you can open from anywhere, a 24-hour load curve, and a Telegram message when something draws more than it should.

Safety first

This project meters mains electricity. The ESP32 side is all low-voltage, but the PZEM's input terminals connect to live line and neutral:

De-energize the circuit before touching any mains wiring, every time.
Enclose everything. No exposed screw terminal when powered — a cheap junction box is fine.
Fuse the voltage tap with a small inline fuse (0.5A is plenty; it only feeds the meter).
The CT clamp is non-invasive — it clips around one insulated conductor (line or neutral, never both) and touches no copper.

If any of that reads as unfamiliar rather than routine, build the firmware against a bench supply and have an electrician land the mains side.

What you'll need

An ESP32 dev board (any common DevKit variant).
A PZEM-004T v3.0 with its split-core CT coil — the version with the Modbus serial interface.
A 5V supply for the ESP32, an enclosure, and a fused tap off the circuit you're metering.
The Arduino IDE with the ESP32 board package, the Nodrix library, and the PZEM004Tv30 library, both from the Library Manager.
A nodrix instance with a project and a project token.

Why use dedicated metering hardware

The classic DIY route — an SCT-013 current clamp into the ESP32's ADC with EmonLib — measures only current and assumes a mains voltage to estimate watts. Real mains sags and swells a few percent all day, the ESP32's ADC is famously nonlinear, and reactive loads (fridges, motors, anything with a power supply) make apparent and real power diverge.

The PZEM-004T v3.0 samples voltage and current together in purpose-built metering silicon and hands the ESP32 six finished numbers over serial: volts, amps, watts, kWh, hertz, and power factor. It measures 80–260V, up to 100A with the external CT, and keeps its energy count through power cuts. The ESP32's job collapses to what it's good at: asking for numbers and shipping them to the cloud.

Wiring

Two sides, kept physically apart. The mains side: line and neutral into the PZEM's voltage terminals (through the fuse), and the CT clipped around the line conductor. The low-voltage side is four wires:

From	To	Wire
PZEM 5V	ESP32 3V3	Power
PZEM GND	ESP32 GND	Ground
PZEM TX	ESP32 GPIO16 (RX2)	Serial
PZEM RX	ESP32 GPIO17 (TX2)	Serial

Power the PZEM's interface side from the ESP32's 3.3V pin, not 5V. The comms side is optically isolated from the mains-side metering chip and runs happily at 3.3V — and it keeps the PZEM's TX at levels the ESP32's RX pin (which is not 5V-tolerant) is built for. If your particular module only talks when powered at 5V, keep the 5V supply but put a two-resistor divider on the PZEM-TX line.

The firmware

One socket carries everything: readings go up, and the connection stays open for anything you add later (a relay, a counter reset). The nodrix Arduino library owns the socket and the reconnects; the sketch is just a read-and-send loop.

#include <Nodrix.h>
#include <PZEM004Tv30.h>

const char* WIFI_SSID = "your-ssid";
const char* WIFI_PASS = "your-password";
const char* HOST      = "nodrix.you.workers.dev";
const char* TOKEN     = "tok_your_project_token";

PZEM004Tv30 pzem(Serial2, 16, 17);

void setup() {
  Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN);
}

void loop() {
  Nodrix.run();

  static unsigned long lastReading = 0;
  if (millis() - lastReading >= 10000) {
    lastReading = millis();

    float voltage = pzem.voltage();
    float current = pzem.current();
    float power   = pzem.power();
    float energy  = pzem.energy();

    if (isnan(voltage)) return;   // meter not answering — skip, don't send garbage

    Nodrix.send("voltage", voltage);
    Nodrix.send("current", current);
    Nodrix.send("power", power);
    Nodrix.send("energy_kwh", energy);
  }
}

Worth understanding rather than copying:

The isnan check matters. When the PZEM sees no mains voltage (breaker off, loose tap) it returns NaN for everything. Skipping the send keeps the chart honest — a gap reads as "meter offline", a stream of zeros reads as "house off", and those are different diagnoses.
The kWh counter lives in the meter. pzem.energy() is a lifetime total that survives reboots and outages on both sides. Report it as-is; derive per-day or per-billing-period numbers in the cloud from the stored series.
Ten seconds is a deliberate rate. Fast enough to catch a kettle, slow enough to be free on your own infrastructure — and a rate that monthly-capped hosted tiers can't sustain.
Pin TLS before you ship. Nodrix.begin() connects encrypted but unverified on first run; add Nodrix.setCACert() for production, covered in Connect an ESP32 over HTTPS.

Build the dashboard

Four widgets, each bound to a variable the firmware is already sending:

Widget	Bind to	Shows
Gauge	`power`	live draw in watts
Chart	`power`	the 24-hour load curve
Value	`energy_kwh`	lifetime energy total
Value	`voltage`	mains health at a glance

The chart is where the project pays for itself. A day of household load has a shape — the overnight baseline, the morning spike, the compressor sawtooth of a fridge. Once you know your baseline, two
things become obvious: what's always on (that's the number that dominates the bill), and anything new that shouldn't be. A baseline that steps up 60W and stays there is how you find the amplifier
that never sleeps.

Add the alerts

Two automations cover the useful cases; both are edited in the dashboard, not the firmware.

Load spike. Trigger on a new power reading, condition above 3000 (tune to your circuit), action: Telegram — "Drawing {{value}}W right now." A washing machine tripping this at 2 p.m. is routine; a space heater tripping it at 3 a.m. is worth a message.

Meter offline. A schedule trigger every morning with an if-variable condition on voltage — if the latest reading is stale or missing, something upstream is off: breaker, fuse, or the meter itself. A monitor that fails silently is worse than none.

Swap Telegram for Slack, Discord, or SMS without touching the conditions — the alert channel is a detail of the automation, not the build.

What it costs to run

Four variables at six readings a minute is roughly a million updates a month. On hosted maker platforms that's deep into paid territory — monthly message caps are exactly what continuous monitoring burns through. Here the meter reports to your own Cloudflare account, where that volume sits comfortably inside normal Workers usage; there is no per-device fee and no message quota to manage. The economics are the point: an energy monitor only earns its keep if it runs continuously
for years.

Going further

Switch loads from the same board. A relay on a spare GPIO plus a NODRIX_WRITE handler turns the meter into a metered smart switch — the pattern is in Receive commands on an ESP32.
Meter more circuits. Additional PZEM units share one serial bus with distinct Modbus addresses, so one ESP32 can report power_lights, power_kitchen, power_ac — each auto-creates its own variable and chart series.
Compute the bill. Pull the energy_kwh series from the read API and multiply by your tariff in a spreadsheet or script — the data is yours, behind one token.
Track power factor. The PZEM also reports pf() and frequency(); two more Nodrix.send lines if you want them.

Notes

Nothing here can be deprecated on you. The meter speaks Modbus, the board speaks HTTPS and WebSocket, and the platform is open source (MIT) on your own account.
The data is queryable. Every reading lands in your tenancy and comes back out through the read API — no export button to hunt for.
Configurable without reflashing. Thresholds, alert channels, and message text all live in the automation editor.

FAQ

Why a PZEM-004T instead of an SCT-013 clamp and EmonLib?

The PZEM-004T measures voltage, current, power, energy, frequency, and power factor in dedicated metering hardware and hands the ESP32 finished numbers over serial. The SCT-013 route reads a raw current waveform on the ADC and estimates power by assuming a fixed mains voltage, so it drifts with every sag and it can't see power factor. The clamp still has one advantage — it's fully non-invasive — but for numbers you'd bill against, the PZEM is the right tool.

Does this work on both 230V and 110V mains?

Yes. The PZEM-004T v3.0 measures 80–260V AC at 45–65Hz, which covers 110V/60Hz and 230V/50Hz systems alike. The firmware doesn't change — the meter reports whatever it sees.

Where is the kWh total stored, and does it reset when the board reboots?

The energy counter accumulates inside the PZEM itself and survives both ESP32 reboots and power cuts. The firmware just reports it. If you want billing-period totals, keep the lifetime counter as-is and compute deltas in the cloud — or call the library's resetEnergy() from a control write when a new period starts.

Is it safe to build this myself?

The low-voltage side — ESP32, serial wiring, USB — is as safe as any breadboard project. The mains side is not: the PZEM's screw terminals connect to live line and neutral. Work with the circuit de-energized, put everything in an enclosure so no live terminal is exposed, fuse the tap, and if you're not comfortable working inside a mains box, stop at a plug-in smart meter or ask an electrician. The CT coil itself clips around one insulated conductor and never touches copper.

Can the same build switch the load on and off?

Yes — add a relay on a spare GPIO and a NODRIX_WRITE handler for a switch variable, the same downlink pattern as the toggle in the smart-home guide. Size the relay for the load and keep it on the mains side of the enclosure. The meter and the switch stay independent: you can monitor without switching, or switch without trusting the meter.

How much data does reporting every 10 seconds generate?

Four variables every 10 seconds is about 34,000 updates a day. That's nothing for a WebSocket on your own Cloudflare account, but it's exactly the kind of rate that burns through hosted-platform free tiers with monthly message caps — one reason energy monitors are usually the first project to outgrow them.

Originally published on nodrix.live. nodrix is an open-source (MIT) IoT platform you deploy to your own Cloudflare account — source on GitHub.

Build an ESP32 air quality monitor with a live CO2 dashboard

Arjun Krishna — Sat, 18 Jul 2026 08:59:10 +0000

A CO2 monitor is the rare sensor project that changes your behaviour: watch the number climb through a closed meeting room and you will open a window before anyone gets a headache. This build measures
CO2 properly with a Sensirion SCD41, reads temperature and humidity from the same part, and streams all three to a live dashboard with colour-banded thresholds — so a glance tells you whether the air
is fine or stale.

What it doesn't need is the thing most SCD41 tutorials quietly assume: a Home Assistant server running the ESPHome add-on on your network. The ESP32 here posts straight to your own cloud dashboard over plain HTTPS. Nothing local to keep alive, and the readings open from anywhere.

Why the SCD41

Air-quality projects live or die on the sensor, and the cheap default is a trap. An MQ-135 costs two dollars and reports something, but not CO2 in real ppm — it's a metal-oxide sensor that drifts, needs constant recalibration, and can't separate CO2 from other gases. The older MH-Z19 is a real NDIR CO2 sensor and a fine choice a few years ago.

The Sensirion SCD41 is the current answer: a photoacoustic CO2 sensor accurate to about ±(40 ppm + 5% of reading), that also hands you temperature and humidity over the same I2C bus — three variables, one part, no analog guesswork. It's low-power enough for battery builds, and its automatic self-calibration keeps it honest over time. It costs more than an MQ-135, and it's worth every cent the first time the number tells you something true.

What you'll need

An ESP32 dev board (any common DevKit variant).
A Sensirion SCD41 breakout (SCD40 works too — slightly lower accuracy, same code).
Four jumper wires; the SCD41 is I2C, so it's just power and two data lines.
The Arduino IDE with the ESP32 board package, the Nodrix library, and Sensirion's I2C SCD4x library, both from the Library Manager.
A nodrix instance with a project and a project token.

Wiring

Pure I2C — four wires, no analog pins, no level shifting (the SCD41 breakout is 3.3V-friendly):

From	To	Wire
SCD41 VDD	ESP32 3V3	Power
SCD41 GND	ESP32 GND	Ground
SCD41 SDA	ESP32 GPIO21	I2C data
SCD41 SCL	ESP32 GPIO22	I2C clock

GPIO21/22 are the ESP32's default I2C pins. The SCD41 draws a brief high current during each measurement, so power it from a stable 3.3V rail rather than a long, thin lead.

The firmware

The SCD41 measures on its own cadence — one reading every five seconds in periodic mode — so the sketch starts it, then reports whatever it has each cycle. The nodrix Arduino library owns the socket and reconnects.

#include <Nodrix.h>
#include <SensirionI2cScd4x.h>
#include <Wire.h>

const char* WIFI_SSID = "your-ssid";
const char* WIFI_PASS = "your-password";
const char* HOST      = "nodrix.you.workers.dev";
const char* TOKEN     = "tok_your_project_token";

SensirionI2cScd4x scd4x;

void setup() {
  Wire.begin();
  scd4x.begin(Wire, 0x62);
  scd4x.stopPeriodicMeasurement();   // clean state after a reset
  scd4x.startPeriodicMeasurement();
  Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN);
}

void loop() {
  Nodrix.run();

  static unsigned long lastReading = 0;
  if (millis() - lastReading >= 30000) {
    lastReading = millis();

    uint16_t co2 = 0;
    float temperature = 0, humidity = 0;
    if (scd4x.readMeasurement(co2, temperature, humidity) == 0 && co2 > 0) {
      Nodrix.send("co2", (int)co2);
      Nodrix.send("temperature", temperature);
      Nodrix.send("humidity", humidity);
    }
  }
}

Worth understanding rather than copying:

The co2 > 0 guard matters. The SCD41 returns 0 ppm when a measurement isn't ready yet; sending it would draw a false floor on the chart. Skipping keeps the history honest.
Give it warm-up time. The first readings after power-up settle as the sensor references itself — expect a couple of minutes before the number is trustworthy, and leave automatic self-calibration on so it stays that way.
Thirty seconds is plenty. CO2 in a room moves over minutes, not seconds. Reporting twice a minute catches every meaningful change and keeps the traffic trivial.
Pin TLS before you ship. Nodrix.begin() connects encrypted but unverified on first run; add Nodrix.setCACert() for production, covered in [Connect an ESP32 over HTTPS (https://nodrix.live/guides/esp32-https-cloud).

Build the dashboard

Four widgets, each bound to a variable the firmware sends:

Widget	Bind to	Shows
Gauge	`co2`	live CO2 in ppm, with colour bands
Chart	`co2`	the day's air-quality rhythm
Value	`temperature`	room temperature
Value	`humidity`	relative humidity

Set the CO2 gauge's bands to the levels that mean something: green below 800 ppm, amber 800–1200, red above 1200. Now the dashboard reads at a glance — you don't interpret a number, you see a colour. The chart is the quietly useful part: a room's CO2 has a shape, climbing while it's occupied and closed, dropping when it's ventilated or empty. Once you know your baseline, the anomalies —
the meeting that ran long, the bedroom that never airs out — jump out.

Add the alert

One automation: trigger on a new co2 reading, condition above 1200, action: Telegram — "CO2 at {{value}} ppm — open a window." Add hysteresis so a room hovering at the line doesn't ping you repeatedly: alarm above 1200, and only rearm once it drops back below 900. Both are edited in the dashboard, not the firmware, and the channel swaps to Discord, Slack, or SMS without touching the condition — the full pattern is in [ESP32 notifications (https://nodrix.live/guides/esp32-notifications).

Going further

Make it portable. On a battery with deep sleep, it's a monitor you carry room to room — swap the socket for wake-report-sleep over HTTP per ESP32 battery life, and budget for the SCD41's warm-up on each wake or use its single-shot low-power mode.
Add particulates. A PMS5003 alongside the SCD41 adds PM2.5/PM10 — more variables, more widgets, same reporting loop, for a fuller indoor-air picture.
Watch several rooms. One SCD41-on-ESP32 per room, each reporting co2_bedroom, co2_office, and so on; a widget per room and one shared automation.
Automate the fix. If a room has a fan or HRV you can switch, add a relay and a NODRIX_WRITE handler and let high CO2 turn ventilation on — closed-loop, the pattern from the smart-home build.

Notes

No broker, no local server. The board speaks HTTPS; the dashboard is on your Cloudflare account. No Home Assistant, no MQTT, nothing on your LAN to keep alive.
A sensor you can trust. Real photoacoustic CO2 plus temperature and humidity from one part — no MOX drift, no analog calibration ritual.
Scales by repeating. One sketch runs a room or a building; add nodes, not complexity.

FAQ

Why the SCD41 instead of an MQ-135 or MH-Z19?

Because it measures CO2 honestly. The MQ-135 is a cheap MOX gas sensor that doesn't report CO2 in real ppm — it drifts, needs constant recalibration, and conflates gases. The MH-Z19 is a genuine NDIR CO2 sensor and a reasonable older choice, but the Sensirion SCD41 is a current photoacoustic CO2 sensor that also gives you temperature and humidity from one I2C part, with ±(40 ppm + 5%) accuracy. For a monitor you'll trust enough to act on, the SCD41 is the right sensor in 2026.

Do I need Home Assistant or a local server for this?

No — and that's the point. Most ranking SCD41 tutorials assume you already run Home Assistant with the ESPHome add-on, which means a local server humming 24/7 just to see a number. Here the ESP32 posts readings straight to your own cloud dashboard over HTTPS. Nothing local to run, and the dashboard opens from anywhere.

What CO2 levels should I actually worry about?

Outdoor air is around 420 ppm. Below 800 ppm indoors is comfortable and well-ventilated; 800-1200 ppm is where drowsiness and reduced concentration start; above 1200 ppm the room needs air, and sustained levels over 1500-2000 ppm are worth fixing. The guide bands the dashboard on those thresholds so a glance tells you whether to open a window.

Why does the SCD41 need a couple of minutes to read correctly?

It self-calibrates and the photoacoustic measurement settles after power-up — early readings can be off until it warms in. Give it a few minutes on first boot, and leave its automatic self-calibration enabled so it re-references to fresh air over days. If you run it somewhere that never sees outdoor-level CO2, disable ASC and calibrate manually instead.

Can one board watch several rooms?

Not one board, but one dashboard. Put an SCD41 on an ESP32 in each room, have each report co2, temperature, and humidity under its own variable names, and add a widget per room. The automations and alerting are shared — the pattern scales by repeating the node, not by rewiring anything.

Originally published on nodrix.live. nodrix is an open-source (MIT) IoT platform you deploy to your own Cloudflare account — source on GitHub.

Control your ESP32 with Claude: an MCP server for your own hardware

Arjun Krishna — Sat, 18 Jul 2026 08:54:37 +0000

Ask Claude "is the greenhouse too warm?" and have it actually check — not because you pasted a number into the chat, but because it queried the sensor. Then ask it to turn on the fan, and hear the relay click. That's what an MCP server on your IoT backend makes possible, and nodrix ships one natively.

This is a different pitch from the AI features bolted onto consumer smart-home apps. There's no vendor cloud in the middle, no pre-baked "skill," and no assistant that only works with devices someone else manufactured. Your ESP32, your firmware, your Cloudflare account — and an AI agent that can read and command all of it through an open protocol, exactly as far as you allow and no further.

What MCP actually is, in one paragraph

The Model Context Protocol is the open standard AI assistants use to call tools outside their own context. An MCP server publishes a list of tools; the assistant decides when to call them and acts on what comes back. Most MCP servers wrap a SaaS API or a database. When your IoT platform is the
server, the tools are your hardware: list the projects, read a variable's live state, pull a time-series, set a control variable, create an automation. Claude stops being a place you describe your system and becomes something that can inspect and operate it.

The niche this fills

It's worth being precise, because the smart-home-plus-AI space is not empty. Home Assistant has shipped an [official MCP server (https://www.home-assistant.io/integrations/mcp_server/) since early
2025, and there are large, active community MCP projects for it. If your setup is off-the-shelf devices on a local hub, that ecosystem is mature and you should use it.

What has essentially no coverage is the other half of the maker world: custom hardware you built, reporting to a cloud you own. An ESP32 you flashed doesn't live in Home Assistant's device registry, and it doesn't want a local hub to reach it from anywhere. That project — a board on plain HTTPS, a dashboard on your Cloudflare account, and now an AI agent that can drive it — is the gap. nodrix fills it as a first-party feature rather than a bridge you assemble.

What the server exposes

Two tiers of tools, gated separately on purpose.

Read tools (available whenever the server is on):

list_projects, list_variables — discover what exists.
get_state — the current value of a variable, as last reported by the device.
get_series — the time-series history, for "what did CO2 do overnight."
list_dashboards, list_widgets, list_automations, list_integrations — the shape of your setup.

Management tools (behind a second switch):

set_variable — write a control variable. This is the one that flips a relay: set the variable your device's NODRIX_WRITE handler watches, and the board acts.
create_automation, update_automation, run_automation — build and fire the trigger → condition → action logic.
create_dashboard, update_widget, create_variable, create_integration, and the matching update_* tools — construct the rest of the setup in language.

There are deliberately no delete tools. An agent can build, read, and command; it cannot destroy.

Turning it on safely

The safety model is the reason this is a feature rather than a footgun. Everything is off until you decide otherwise:

The server is off by default. Until the owner enables it, the MCP endpoint returns 404 — it doesn't exist as far as the internet is concerned.
Only the owner can enable it. It lives in Settings → More, behind the owner role. No member or admin can expose your hardware to an assistant.
Writes are a separate switch. Turn the server on and it comes up read-only — an assistant can see your data but cannot touch a single variable. The management tools stay dark until you flip the write flag too, so "let Claude look at my sensors" and "let Claude control my house" are two distinct, deliberate decisions.

The practical result: an LLM can never command your hardware by default. You grant reading, then — if and when you want it — writing, as two separate acts.

Connecting Claude

The server speaks standard MCP over two endpoints on your instance: an OAuth endpoint at /v1/mcp/oauth for interactive clients like the Claude apps, and a bearer-token endpoint at
/v1/mcp for token-configured clients like Claude Code and IDE plugins.

For the Claude apps, connect it as a custom connector — the whole path is five steps:

Enable the server in nodrix first. In your instance, go to Settings → More and turn the MCP server on; until you do, the endpoint returns 404 and nothing can connect. Turn on the write flag here too if you want Claude to control hardware and not just read it.
Open Claude's connector settings. In the browser, click your profile icon → Settings; on desktop, press ⌘⇧, (macOS) or Ctrl+,. Then click Connectors in the sidebar.
Add a custom connector. Click Add (top-right) → Add custom connector, paste your instance's OAuth URL — https://your-instance.workers.dev/v1/mcp/oauth — and click Add.
Approve on your own instance. Claude redirects you to your nodrix instance to sign in as the owner and approve the connection. That consent screen is where you see exactly what you're granting before anything is shared.
Use the tools. Back in Claude, your instance appears under the + ("Add files, connectors, and more") menu in the message box. From the connector's settings you can enable or disable individual tools — a second place the read-only boundary is yours to draw.

For Claude Code or an IDE plugin, point it at the bearer endpoint /v1/mcp instead, with an Authorization: Bearer <token> header carrying a token from your instance. If a menu has moved, Anthropic's custom-connectors guide has the canonical version of these steps.

From there it's conversation:

"What's the current soil moisture in the greenhouse project?" → get_state.
"Plot CO2 for the last 24 hours and tell me if it ever crossed 1000 ppm." → get_series, then analysis.
"Turn on the exhaust fan." → set_variable, and the ESP32's handler fires. (Only if you enabled writes.)
"Make an automation that alerts me on Telegram when the freezer goes above -10." → create_automation, wired to the integration you already set up.

The last two are the ones that feel like the future: you described an outcome, and the agent assembled the platform primitives to make it real — no dashboard clicks, no YAML.

Why this beats the bolt-on approach

You could get some of this by giving Claude a generic HTTP tool and your API docs. The native server is better in the ways that matter:

It's typed and discoverable. The assistant sees named tools with schemas, not a REST surface it has to reverse-engineer, so it calls them correctly the first time.
It's scoped. Read-only really means read-only; the boundary is enforced server-side, not requested politely in a prompt.
It's yours. The whole path is your instance on your Cloudflare account. No third-party AI-IoT service is brokering access to your devices, and nothing about it can be discontinued on you.

Where it's going

The interesting frontier isn't voice-controlling one bulb — Home Assistant does that well. It's an agent with read access to a fleet of your own sensors and the judgment to reason across them: correlate the energy monitor's spike with the temperature log, notice the greenhouse trend before it becomes a problem, draft the automation and let you approve it. The tools to do that ship in the box
today; the assistant supplies the reasoning. Turn the server on read-only, connect Claude, and ask it what it notices about your data — it's the fastest way to see why this is more than a novelty.

Notes

Off by default, owner-gated, writes separate. Three deliberate gates before an AI touches hardware; no delete tools ever.
Your own endpoint. MCP served from your Cloudflare account — no AI-IoT vendor in the path.
Open protocol. Standard MCP; Claude is the reference client, but any MCP-capable assistant connects the same way.

FAQ

What is an MCP server, and why would my IoT platform have one?

MCP (Model Context Protocol) is the open standard AI assistants like Claude use to call external tools. An MCP server exposes a set of tools an agent can invoke — and when your IoT backend is the server, those tools are your devices: read this sensor, set that variable, create an automation. It's the difference between pasting sensor readings into a chat and letting the assistant query and control the hardware directly.

Is it safe to let an AI control my hardware?

nodrix is built so the answer stays yes. The MCP server is off by default and only the instance owner can enable it. Even then it comes up read-only: the management tools that can write a variable or create an automation are behind a second switch, so an assistant can look at your data without any ability to command hardware until you explicitly turn writes on. There are no delete tools at all. You're granting capabilities deliberately, one gate at a time.

How is this different from the Home Assistant MCP server?

Home Assistant's MCP server is built for Home Assistant's world — off-the-shelf smart-home devices on your local network, exposed through its Assist API. nodrix's is built for the other world: your own custom hardware — an ESP32 you flashed — reporting to your own cloud over plain HTTPS. If your project is a store-bought bulb, use Home Assistant. If it's a board you wrote the firmware for, this is the path that doesn't require running a local hub.

Which AI assistants can connect?

Anything that speaks MCP. Claude (Desktop, Code, and the web connector) is the reference client, and the server also works with other MCP-capable tools. nodrix exposes both a bearer-token endpoint for programmatic clients and an OAuth endpoint for the ones that authenticate interactively, so you connect whichever way your client expects.

Does Claude need my hardware to be online to answer questions?

For live state, yes — reading a sensor's current value asks your instance, which holds what the device last reported. But the history lives in your instance regardless, so Claude can analyze a week of temperature data whether or not the board is awake right now. A deep-sleeping battery sensor's last reading is always queryable.

Originally published on nodrix.live. nodrix is an open-source (MIT) IoT platform you deploy to your own Cloudflare account — source on GitHub.