# nodrix — full reference > nodrix is an open-source, single-tenant IoT cloud that deploys to your own Cloudflare account. Hardware speaks plain HTTPS or WebSocket, telemetry streams to realtime drag-and-drop dashboards, automations run at the edge, and a clean read API exposes the data — with no broker, no servers, and your data never leaving your account. Status: stable (v1.0). License: MIT. Home: https://nodrix.live/ Docs: https://nodrix.live/docs Widgets: https://nodrix.live/widgets Source: https://github.com/decoded-cipher/nodrix ## What nodrix is - An open-source IoT backend that deploys straight into the user's own Cloudflare account. - Single-tenant: every deployment is isolated in the owner's account, on their own D1, R2, and Durable Objects. - One-click "Deploy to Cloudflare" provisions Workers, Durable Objects, D1, R2, and KV. - Runs entirely on Cloudflare primitives — nothing to host, nothing to maintain. ## Features 1. Telemetry over HTTPS or WebSocket — Hardware POSTs JSON to the project, or opens a WebSocket (/v1/control/ws). Variables create themselves on first sight: no schema to declare, no MQTT broker to run, and no SDK required. Anything that can make an HTTPS request can talk to nodrix; on ESP32/ESP8266 an optional Arduino library wraps the whole protocol. 2. Realtime dashboards, two-way — Drop widgets onto a grid, bind them to variables, watch values stream live over hibernating WebSockets that cost nothing while idle. Toggles, sliders, and buttons write back to hardware on the same channel; devices ack when applied. 3. Automations without a server — A visual flow builder. Each automation is a graph: one or more triggers (variable threshold, a clock, sunrise/sunset, custom event, or manual run) flow through optional conditions (if-variable comparison that branches yes/no, time window) into actions (set a variable, call an integration, emit an event). Integrations cover HTTP service (with optional HMAC request signing), email, and chat (Slack, Telegram, Discord). All evaluated at the edge. 4. A clean read API — Edge-cached latest state, recent time-series, and variable listings behind one bearer token. Plug in Grafana, a React app, or a Raspberry Pi screen. 5. Single-tenant by design — Every deploy lands in the user's own account. Email + password out of the box, with optional Google or GitHub sign-in. 6. MCP server for AI clients — Optional, off by default, owner-gated. Two transports on the same worker: bearer-token at /v1/mcp (for CLI/IDE clients like Claude Code) and OAuth 2.1 at /v1/mcp/oauth (for browser-based clients like claude.ai connectors). Read tools (list/get projects, variables, dashboards, automations, integrations, state, series) are exposed when the server is on; management tools (create/update of projects, variables, dashboards, automations, integrations; run automations; set variable values) require an additional deployment-wide writes toggle AND an explicit mcp:manage scope at the consent step. No delete operations are ever exposed. Every write is recorded in the audit log when enabled, tagged with source=mcp so AI-initiated changes are distinguishable from web/API ones. ## How it works (four steps) 1. Deploy in one click — Hit "Deploy to Cloudflare". It provisions D1, R2, KV, and the Worker straight into the account. 2. Claim the instance — Open the worker URL and create the first account; it becomes the owner. Spin up the first project in a couple of clicks. 3. Connect hardware — Mint a project token and point the device at /v1/telemetry. Variables show up the moment data starts flowing. 4. Build & automate — Compose a dashboard, bind widgets to variables, and wire automations to act on the data — or hand it off through the read API. ## Device protocol (overview) - Send telemetry: POST /v1/telemetry with header "Authorization: Bearer " and a JSON body like { "metrics": { "temperature": 23.4, "humidity": 61 } }. Responds 204 No Content; variables are auto-created. - Read state: GET /v1/projects/:proj/state returns the latest value per variable, edge-cached. - Arduino/ESP library: an optional library for ESP32/ESP8266 wraps the protocol — handle control writes with NODRIX_WRITE("var"){…} and push telemetry with Nodrix.send(). Repo: https://github.com/decoded-cipher/nodrix-sdk ## Widgets (framework-agnostic Web Components) Display: - iot-value — The latest reading of a single variable, large and legible. Attributes: data-title, data-unit. - iot-gauge — An arc gauge for a numeric variable with configurable min/max bounds. Attributes: data-title, data-min, data-max, data-unit. - iot-percent — A circular percentage ring that maps a value to 0–100%, with optional color thresholds that recolor the ring by value. Attributes: data-title, data-min, data-max, data-unit. - iot-chart — A multi-series time-series chart (ApexCharts): line, area, bar, or stepline, with optional drag-to-zoom. Attributes: data-title, data-chart-type, data-zoom. - iot-map — Geographic markers from static coordinates or live lat/lng variables, on a configurable basemap. Attributes: data-title, data-basemap, data-zoom. Control: - iot-toggle — On/off switch that writes a value to a variable and reflects last reported state. Attributes: data-title, data-variable, data-on-value, data-off-value. - iot-slider — Horizontal slider for a numeric write; commits on release. Attributes: data-title, data-variable, data-min, data-max, data-step. - iot-push — Momentary push button for one-shot commands (restart a node, fire a routine, kick off a script). Attributes: data-title, data-variable, data-value, data-label. - iot-color — Color wheel for writing a color to a variable; drag for hue/saturation, set brightness, or tap a preset. Commits on release with hex/hsv/rgb output. Attributes: data-title, data-variable, data-format, data-brightness, data-hex-input, data-presets. ## Tech stack Cloudflare Workers, Durable Objects, D1, R2, and KV. ## Source & license - Repository: https://github.com/decoded-cipher/nodrix - Arduino/ESP library: https://github.com/decoded-cipher/nodrix-sdk - License: MIT # Guides (full text) The following are nodrix's hands-on guides in full — hardware builds, platform comparisons, and concept explainers, each with its FAQ. All builds report to a nodrix instance on the reader's own Cloudflare account. ## Guide: Control your ESP32 with Claude: an MCP server for your own hardware URL: https://nodrix.live/guides/control-esp32-with-claude-mcp Category: project · Board: ESP32 Point Claude at your own IoT backend and let it read your sensors and flip your relays in plain language — no cloud middleman, no vendor skill. nodrix ships a native MCP server, owner-gated and off by default, that turns your ESP32 fleet into tools an AI agent can call. 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](https://modelcontextprotocol.io) 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: 1. **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. 2. **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. 3. **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: 1. **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. 2. **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. 3. **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**. 4. **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. 5. **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 ` header carrying a token from your instance. If a menu has moved, Anthropic's [custom-connectors guide](https://support.anthropic.com/en/articles/11175166-getting-started-with-custom-connectors-using-remote-mcp) 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 **Q: 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. **Q: 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. **Q: 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. **Q: 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. **Q: 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. --- ## Guide: Build an ESP32 air quality monitor with a live CO2 dashboard URL: https://nodrix.live/guides/esp32-air-quality-monitor Category: project · Board: ESP32 A complete ESP32 CO2 and air-quality build on the Sensirion SCD41: true NDIR-grade CO2, temperature and humidity over one sensor, streamed to a live dashboard with colour-banded alerts — no MQTT broker, no Home Assistant server, on your own Cloudflare account. 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](https://github.com/Sensirion/arduino-i2c-scd4x), 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](https://github.com/decoded-cipher/nodrix-sdk) owns the socket and reconnects. ```cpp #include #include #include 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](https://nodrix.live/guides/esp32-deep-sleep-battery), 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](https://nodrix.live/guides/esp32-smart-home-automation). ## 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 **Q: 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. **Q: 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. **Q: 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. **Q: 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. **Q: 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. --- ## Guide: ESP32 project ideas that connect to the cloud: 10 real builds, ranked URL: https://nodrix.live/guides/esp32-project-ideas Category: project · Board: ESP32 Ten ESP32 IoT project ideas worth actually building — ranked by usefulness, each with the sensor, the difficulty, and a real build guide, not a one-line summary. From a first temperature monitor to a Claude-controlled greenhouse, every one reports to a dashboard you own. Most "ESP32 project ideas" lists are written to be skimmed, not built — fifty one-line summaries from a parts vendor, each ending where the actual work begins. This one is the opposite: ten projects worth genuinely building, ranked by how useful the result is, each with the sensor it needs, its real difficulty, and a full build guide behind it rather than a sentence. Two things they share. Every one reports to a dashboard you **own** — deployed to your own Cloudflare account, no per-device fee and no freemium cap to hit halfway through a semester. And every one is a variation on the same skeleton: read a sensor, send it over HTTPS, see it live, act on it. Build the first and the rest are remixes. ## How these are ranked By usefulness of the finished thing — would you keep it running after it works — with difficulty noted so you can start where you're comfortable. If you're new, start at the top and work down; the skeleton never changes, only the sensor and the logic. ## 1. Temperature & humidity monitor — the one to start with **Sensor:** BME280 · **Difficulty:** beginner · **Build:** the loop every other project reuses. Four wires, a dozen lines, and the whole IoT loop in miniature: sensor to Wi-Fi to live dashboard to phone alert. It's the "hello world" of connected hardware, and worth building even if you don't need it, because it's the foundation the other nine stand on. Add barometric pressure and it graduates into a [weather station](https://nodrix.live/guides/esp32-weather-station). ## 2. Weather station — your microclimate, charted **Sensor:** BME280 · **Difficulty:** beginner · **Build:** [ESP32 weather station](https://nodrix.live/guides/esp32-weather-station). Temperature, humidity, and the barometric pressure that warns of an incoming storm before the clouds arrive — measuring your actual balcony, not a regional forecast. Runs for months outdoors on a battery, and the falling-pressure alert is the kind of thing you'll actually trust. ## 3. Air quality / CO2 monitor — the one that changes your behaviour **Sensor:** Sensirion SCD41 · **Difficulty:** beginner · **Build:** [ESP32 air quality monitor](https://nodrix.live/guides/esp32-air-quality-monitor). Watch CO2 climb through a closed room and you will open a window before anyone gets a headache. A real photoacoustic sensor (not a drifting MQ-135), colour-banded thresholds, and an alert when the air goes stale. The rare monitor whose readings you act on daily. ## 4. Plant watering system — closed-loop and hands-off **Sensor:** capacitive soil moisture + pump · **Difficulty:** beginner · **Build:** [ESP32 plant watering](https://nodrix.live/guides/esp32-automatic-plant-watering). The first project that does something back: reads soil moisture, and when it dries out, runs a pump — with the watering logic in the cloud so you retune it without reflashing. Your introduction to two-way control and safe relay switching. ## 5. Energy meter — the standout capstone **Sensor:** PZEM-004T · **Difficulty:** intermediate · **Build:** [ESP32 energy meter](https://nodrix.live/guides/esp32-energy-meter). Real volts, amps, watts, and a lifetime kWh counter on a live dashboard, with a load-spike alert. It's the project that pays for itself — you'll find the always-on device quietly dominating your bill — and it demonstrates everything an examiner wants to see: real measurement, history, alerting, data you own. The strongest single choice for a final-year project. ## 6. GPS tracker — a live map you control **Sensor:** NEO-6M GPS · **Difficulty:** beginner · **Build:** [ESP32 GPS tracker](https://nodrix.live/guides/esp32-gps-tracker). A marker that follows your vehicle or asset across a map dashboard, with a speed alert — and no proprietary tracking cloud in the loop, unlike every incumbent tutorial. Honest about where Wi-Fi tracking works and where it needs cellular, which is more than most guides manage. ## 7. Smart home controller — switch the house from anywhere **Sensor:** relays + your appliances · **Difficulty:** intermediate · **Build:** [ESP32 smart home](https://nodrix.live/guides/esp32-smart-home-automation). Lights and appliances switched from one private dashboard, with scenes, schedules, and a sunset trigger running the house — no commercial hub, no vendor cloud. The project that turns "I read a sensor" into "I control my home." ## 8. Multi-channel notifier — alerts done right **Sensor:** any + the alert logic · **Difficulty:** beginner · **Build:** [ESP32 notifications](https://nodrix.live/guides/esp32-notifications). Less a single build than a technique every project above reuses: send alerts to Telegram, Discord, Slack, or SMS with zero secrets in your firmware, the threshold and channel editable without reflashing. Build it as a freezer monitor; apply it everywhere. ## 9. Battery sensor node — months on one cell **Sensor:** any + deep sleep · **Difficulty:** intermediate · **Build:** [ESP32 battery life](https://nodrix.live/guides/esp32-deep-sleep-battery). The skill that makes half this list deployable where there's no USB power: deep sleep, RTC-memory Wi-Fi caching, and a real power budget that takes a sensor to months on a single charge. Learn it once, apply it to the weather station, the air monitor, the tracker. ## 10. Claude-controlled hardware — the frontier **Sensor:** any + the MCP server · **Difficulty:** intermediate · **Build:** [Control your ESP32 with Claude](https://nodrix.live/guides/control-esp32-with-claude-mcp). Point an AI assistant at your own instance and let it read your sensors and — if you allow it — flip your relays in plain language. "Is the greenhouse too warm? Turn on the fan." No ESP32 project list anywhere else has this yet, because it needs a platform with a native MCP server. It's the most future-facing thing you can build on an ESP32 right now, and it's genuinely a few clicks away once a sensor is reporting. ## Picking yours - **First ever project?** Start at #1, then #2 or #3 — same skeleton, more interesting output. - **Final-year / capstone?** #5 (energy) or #7 (smart home) for depth, or #10 (Claude) to stand out. Examiners reward closed loops and data ownership; all three have them. - **Something genuinely useful around the house?** #3 (air quality) and #5 (energy) are the two you'll still be running a year later. Every one of these starts the same way — [get an ESP32 reporting over HTTPS](https://nodrix.live/guides/esp32-https-cloud) to [an instance on your own Cloudflare account](https://nodrix.live/guides/deploy-nodrix-cloudflare) — and branches from there. Build the skeleton once, and this whole list becomes an afternoon each. ### FAQ **Q: What's a good first ESP32 IoT project for a beginner?** A temperature-and-humidity monitor on a BME280, reporting to a cloud dashboard. It's four wires, a dozen lines of firmware, and it teaches the whole loop — sensor to Wi-Fi to dashboard to alert — without any risky wiring or moving parts. Once that works, every other project on this list is a variation on the same skeleton, which is exactly why it's the one to start with. **Q: What makes a good final-year or capstone IoT project?** One that closes the loop and owns its data. Anyone can read a sensor and print it; the projects that stand out add real logic (thresholds, automations), two-way control (the dashboard flips a relay), and data ownership (it runs on infrastructure you control, not a freemium cloud that caps you). The energy monitor, the smart-home controller, and the Claude-controlled build on this list all demonstrate those, which is what turns a demo into a project worth presenting. **Q: Do these ESP32 projects need paid cloud services?** No. Every build here reports to a nodrix instance you deploy to your own Cloudflare account, which for student-scale telemetry sits inside Cloudflare's free plan — no per-device fees, no message caps, no data-retention limit counting down. That matters for a project you'll run for months or demo repeatedly: the free tiers of hosted IoT platforms are sized to run out exactly when your project starts working. **Q: Can I do these ESP32 projects on an ESP8266 or Pico W instead?** Most of them, yes. The simpler sensor projects run fine on an ESP8266 (mind its tighter RAM) or a Pico W in MicroPython. The heavier builds — always-on WebSocket control, several sensors at once — are more comfortable on an ESP32. Each guide notes where the board choice matters; the cloud side is identical whichever you pick. **Q: How long does a typical ESP32 IoT project take to build?** A first sensor-to-dashboard project is an afternoon. The mid-list builds — energy meter, air-quality monitor, GPS tracker — are a weekend once you're comfortable with the loop. The complexity is almost never the firmware, which the device library keeps short; it's the physical build (wiring a relay safely, calibrating a sensor, mounting the enclosure), which is the part worth taking your time on. --- ## Guide: Build an ESP32 weather station with a live cloud dashboard URL: https://nodrix.live/guides/esp32-weather-station Category: project · Board: ESP32 A complete ESP32 weather station on the BME280: temperature, humidity, and barometric pressure streamed to a live dashboard you open from anywhere — with a falling-pressure storm alert — no MQTT broker, no legacy IoT cloud, on your own Cloudflare account. A weather station is the project that makes a maker check a dashboard every morning. This one measures the weather where you actually are — temperature, humidity, and the barometric pressure that warns of an incoming storm — with a single BME280, and streams it to a live dashboard you open from your phone anywhere. No regional-forecast API guessing at your microclimate; the pressure on your own balcony, charted. Most ESP32 weather-station tutorials stop one step short: they read the sensor and print it to the Serial Monitor or a tiny OLED, then wave at "connect it to the cloud" as a next step. This one is the cloud step, done properly — over plain HTTPS to your own Cloudflare account, no MQTT broker and no legacy freemium platform holding your history. ## Why the BME280 The default two-in-one sensor, the DHT22, measures temperature and humidity and nothing else. The BME280 measures those plus **barometric pressure**, from the same small I2C part — and pressure is what earns the name "weather station." A steadily falling barometer is the oldest reliable storm signal there is, hours ahead of the clouds. The BME280 is also more accurate than a DHT22 and speaks clean I2C instead of the DHT's slow, occasionally-flaky one-wire timing. For a few cents more, it's the sensor every serious build uses. (One caution when buying: the BMP280 is the cheaper sibling with no humidity. For a weather station you want the BME — the E has humidity.) ## What you'll need - An **ESP32** dev board (any common DevKit variant). - A **BME280** breakout (I2C version — most are). - Four jumper wires. - The **Arduino IDE** with the ESP32 board package, the **Nodrix** library, and Adafruit's [**BME280** library](https://github.com/adafruit/Adafruit_BME280_Library) (it pulls in the Adafruit Unified Sensor library), from the Library Manager. - A **nodrix instance** with a project and a project token. ## Wiring I2C, four wires, no analog: | From | To | Wire | |------|----|------| | BME280 VCC | ESP32 3V3 | Power | | BME280 GND | ESP32 GND | Ground | | BME280 SDA | ESP32 GPIO21 | I2C data | | BME280 SCL | ESP32 GPIO22 | I2C clock | Mount the BME280 away from the ESP32 on a short lead. The board's own heat will bias the temperature reading if the sensor sits right against it — a couple of centimetres and some airflow fixes it. ## The firmware Read three values, send three variables, on a gentle cadence — weather moves slowly. The [nodrix Arduino library](https://github.com/decoded-cipher/nodrix-sdk) handles the connection. ```cpp #include #include 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"; Adafruit_BME280 bme; void setup() { bme.begin(0x76); // some breakouts are at 0x77 Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); } void loop() { Nodrix.run(); static unsigned long lastReading = 0; if (millis() - lastReading >= 60000) { lastReading = millis(); Nodrix.send("temperature", bme.readTemperature()); Nodrix.send("humidity", bme.readHumidity()); Nodrix.send("pressure", bme.readPressure() / 100.0F); // Pa → hPa } } ``` Worth understanding rather than copying: - **Pressure in hPa.** The BME280 reports pascals; dividing by 100 gives hectopascals (millibars), the unit weather reports use — sea-level pressure sits around 1013 hPa, so your readings should land near there once you account for altitude. - **A minute between readings is generous.** Weather doesn't change in seconds. On mains power a minute is fine; on a battery you'd stretch it to 5–15 minutes and deep-sleep between. - **Check the I2C address.** BME280 breakouts are at 0x76 or 0x77 depending on the board — if `begin()` fails, try the other. - **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 | Widget | Bind to | Shows | |---|---|---| | Value | `temperature` | current temperature | | Value | `humidity` | relative humidity | | Gauge | `pressure` | barometric pressure, ~980–1040 hPa | | Chart | `pressure` | the pressure trend — the storm-teller | | Chart | `temperature` | the day's temperature curve | The pressure chart is the one to watch. Absolute pressure matters less than its slope: a slow rise means settling, fair weather; a steady fall over a few hours is the classic sign of an approaching low and likely rain. Once you've watched it for a week against what the sky actually did, you'll read an incoming front off that line before any app tells you. ## Add the storm alert Weather stations reward one good automation. A rapid pressure drop is the signal worth a notification: trigger on a new `pressure` reading, and alert when it falls meaningfully below where it sat a few hours ago (a threshold around 1000 hPa is a reasonable absolute floor for "weather coming" in many regions; tune it to yours). Action: Telegram — "Pressure dropping, {{value}} hPa — weather likely turning." Swap the channel for Discord or SMS without touching the logic, per [ESP32 notifications](https://nodrix.live/guides/esp32-notifications). ## Going further - **Take it outside on a battery.** Deep sleep makes an outdoor node last months; house it in a vented radiation shield to keep sun and rain off the sensor — see [ESP32 battery life](https://nodrix.live/guides/esp32-deep-sleep-battery). - **Add rain and wind.** A tipping-bucket gauge (a counted reed switch), an anemometer, and a wind vane each add a variable and a widget without changing the loop's shape. - **Compare to the forecast.** Pull your own history through the read API and chart it against a weather service's numbers — your microclimate almost never matches the regional forecast exactly, and the gap is the interesting part. - **Run several stations.** Sun and shade, indoors and out, ground and roof — each node reports its own variables to one dashboard. ## Notes - **Your microclimate, not a regional guess.** The sensor measures your location; the API can't. - **No broker, no legacy cloud.** HTTPS to your own Cloudflare account — no MQTT, no ThingSpeak or Blynk caps, history that stays yours behind the read API. - **Battery-friendly by design.** Slow weather plus deep sleep equals months on a cell. ### FAQ **Q: Why a BME280 and not a DHT22?** The DHT22 gives temperature and humidity and stops there. The BME280 adds barometric pressure over the same tiny I2C part — and pressure is what makes it a weather station rather than a thermometer, because a falling barometer is the classic leading indicator of an incoming storm. The BME280 is also more accurate and doesn't have the DHT22's slow, occasionally-flaky one-wire protocol. For a few cents more it's the obvious pick. **Q: Do I need an internet weather API for this?** No — this measures your actual location, which is the point. An API tells you the regional forecast; your BME280 tells you the pressure on your balcony, the humidity in your greenhouse, the temperature in the shade of your garden. The two are complementary, but the sensor is the one that knows your microclimate, and it keeps working when the API rate-limits you. **Q: How do I measure rain and wind too?** Add them as more variables. A tipping-bucket rain gauge is a reed switch you count with an interrupt; anemometer and wind vane kits output pulses and a voltage you read the same way. Each becomes another Nodrix.send call and another widget — the reporting loop and dashboard don't change shape, they just gain series. This guide covers the temperature/humidity/pressure core that every station shares. **Q: Why does my BME280 read a few degrees high?** Self-heating. The ESP32 and the sensor's own draw warm the board, and a BME280 mounted right against it reads the board's heat, not the air's. Mount the sensor away from the ESP32 on a short lead, give it airflow, keep it out of direct sun, and if you deep-sleep the board between readings the self-heating largely disappears — another reason a battery weather station reads more accurately than a always-on one. **Q: Can this run outdoors on a battery?** Yes, and it's the natural form. Deep sleep between readings takes an ESP32 weather node to months on a single cell, and weather changes slowly enough that a reading every 5-15 minutes is plenty. Put the electronics in a vented enclosure (a Stevenson-screen-style shield keeps sun and rain off the sensor), and report on each wake over HTTP — the pattern is in the battery guide linked below. --- ## Guide: Raspberry Pi Pico 2 W vs ESP32: which for a cloud IoT project? URL: https://nodrix.live/guides/raspberry-pi-pico-2-w-vs-esp32 Category: comparison · Board: Raspberry Pi Pico 2 W An honest Pico 2 W vs ESP32 comparison for connected projects — where the Pico 2 W's newer silicon and clean MicroPython win, where the ESP32's wireless maturity and huge ecosystem win, and which to pick when the project reports to a cloud dashboard. The Raspberry Pi Pico 2 W put real pressure on the ESP32's default-board status: newer silicon, the Raspberry Pi name and documentation, and a genuinely lovely MicroPython experience, all around seven dollars. So "Pico 2 W or ESP32" is now a fair fight — and most of the comparisons answering it either predate the Pico 2 W entirely or lean on secondhand benchmark claims with no code to back them. Here's the honest version, aimed at the question makers actually have: which board for a project that connects to a cloud dashboard. ## The short version - **Value newer silicon, clean MicroPython, and the Raspberry Pi ecosystem?** Pico 2 W. - **Value wireless maturity, the deepest library/example ecosystem, and proven cloud-IoT patterns?** ESP32. - **It's not about price** — they're within a few dollars. It's about which ecosystem fits how you like to work. ## What the Pico 2 W brings The Pico 2 W is built on the RP2350, and it's a genuinely modern part: - **Dual-architecture silicon.** The RP2350 carries both Arm Cortex-M33 and RISC-V cores — you pick which to run — which is a first at this price and a sign of how current the design is. - **Excellent MicroPython.** The Pico's flagship path is MicroPython, and it's among the most pleasant on any microcontroller: clean, well-documented, fast to iterate. - **The Raspberry Pi pedigree.** Documentation, longevity, and a foundation behind the board — the same reasons people trust the bigger Pis. - **Programmable I/O (PIO).** A standout hardware feature: state machines that generate or capture precise digital signals, which makes bit-banging odd protocols genuinely easy. ## What the ESP32 brings The ESP32's advantages are the kind that only accrue with time in the field: - **Mature wireless.** Wi-Fi is the ESP32's original purpose, and a decade of IoT projects have hardened the networking stack, the reconnect handling, and the TLS code. - **The deepest ecosystem.** More libraries, more examples, more Stack Overflow answers, more cloud-connection tutorials than any comparable board — when you hit a problem, someone has already solved it publicly. - **A family of variants.** Need Bluetooth, more compute, or Thread/Zigbee? There's an ESP32 variant for it — the C3, S3, C6 — where the Pico line is essentially one wireless board. - **Two strong frameworks.** Happy in the Arduino framework or ESP-IDF, with a device library that can hide the Wi-Fi, TLS, and reconnect work entirely. ## Head to head | | Raspberry Pi Pico 2 W | ESP32 (classic / variants) | |---|---|---| | Silicon | RP2350, Arm + RISC-V | Xtensa or RISC-V, by variant | | Flagship language | MicroPython | Arduino C++ or ESP-IDF | | Wireless maturity | Good, newer | Deep, battle-tested | | Ecosystem size | Growing | The largest in the class | | Standout feature | PIO (programmable I/O) | Variant choice, BLE, mature TLS | | Bluetooth | Yes | Yes (classic + BLE) | | Price (2026) | ~$7 | ~$4–10 | Two honest notes the freshest incumbents still get wrong: the boards are at price parity, so cost isn't the tiebreaker; and performance claims you'll see quoted (interrupt speed, current draw) are often secondhand and untested — measure them yourself for your workload rather than trusting a number copied between articles. ## For a cloud dashboard project specifically This is where the abstract comparison gets concrete. Both boards speak plain HTTPS, so both reach a cloud dashboard without a broker. The difference is how much the ecosystem does for you: - **On the ESP32**, a device library can own the Wi-Fi, the TLS handshake, the reconnect logic, and the control channel — your sketch is just `Nodrix.send` and a handler. The maturity shows up as less code you write and fewer edge cases you hit. Built end to end in [Connect an ESP32 over HTTPS](https://nodrix.live/guides/esp32-https-cloud). - **On the Pico 2 W**, MicroPython with `urequests` posts readings cleanly, and the code reads beautifully — you're just a bit closer to the metal on reconnects and TLS. Built end to end in [Pico W to the cloud with MicroPython](https://nodrix.live/guides/raspberry-pi-pico-w-iot-dashboard). Crucially, the dashboard doesn't care. Point either board at your own instance and the readings land in the same widgets, the same automations fire, the same alerts go out. You can even run both — a Pico 2 W in one room and an ESP32 in another — reporting to one dashboard, which is a good way to decide with your own hands which you'd rather build on. ## The bottom line Pick the **Pico 2 W** if you love MicroPython and want current silicon with the Raspberry Pi foundation behind it. Pick the **ESP32** if you want the deepest ecosystem and the most mature wireless — which, for a first cloud-connected project, is usually the safer default simply because every problem you'll hit already has a published answer. They're close enough in 2026 that you won't regret either, and since [your own instance](https://nodrix.live/guides/deploy-nodrix-cloudflare) runs both identically, you can change your mind later without changing your cloud. ### FAQ **Q: Is the Raspberry Pi Pico 2 W better than an ESP32?** Neither is strictly better — they optimise for different things. The Pico 2 W has newer silicon (a dual-architecture RP2350: Arm plus RISC-V cores), excellent MicroPython support, and the Raspberry Pi documentation pedigree. The ESP32 has more mature Wi-Fi, a vastly larger library and example ecosystem, and years of proven cloud-IoT deployments. For a first wireless project the ESP32's ecosystem depth usually wins; for a project that values clean MicroPython and current silicon, the Pico 2 W is compelling. **Q: Which is cheaper, Pico 2 W or ESP32?** They're at rough price parity in 2026 — a Pico 2 W is around $7, ESP32 dev boards run roughly $4–10 depending on variant. Price isn't the deciding factor between them the way it is between an ESP8266 and an ESP32. Choose on ecosystem and use-case fit, not on saving a dollar. (Worth noting: Raspberry Pi's larger boards saw price rises in 2026 on memory costs, but the microcontroller Picos stayed low.) **Q: Which has better Wi-Fi for IoT?** The ESP32's wireless is more mature — Wi-Fi and networking are its original reason for existing, and a decade of IoT projects have hardened the stack and the libraries. The Pico 2 W's wireless works well and MicroPython makes it pleasant, but the ecosystem of cloud-connection examples, reconnect handling, and battle-tested TLS code is deeper on the ESP32 side. For a connect-to-the-cloud project specifically, that maturity is a real advantage. **Q: Can I use the Pico 2 W with the Arduino IDE like an ESP32?** You can, via the Arduino-Pico core, but the Pico's most natural and best-supported path is MicroPython — that's where its documentation and community are strongest. The ESP32 is happiest in either the Arduino framework or ESP-IDF. If you strongly prefer Arduino C++, the ESP32's support for it is more established; if you like MicroPython, the Pico 2 W is a joy. **Q: Which should I pick for a cloud dashboard project?** Both speak plain HTTPS, so both reach a cloud dashboard — the choice is ecosystem fit. The ESP32 has more ready-made cloud examples and a device library that hides the Wi-Fi, TLS, and reconnect work; the Pico 2 W does it cleanly in MicroPython with urequests. Point either at your own instance and the dashboard doesn't care which board sent the reading — nodrix has walkthroughs for both. --- ## Guide: The best free IoT platforms for makers in 2026, ranked URL: https://nodrix.live/guides/best-free-iot-platforms Category: comparison Every 'free' IoT platform caps something — devices, messages, retention, or all three. Here's an honest ranking of the free tiers makers actually use in 2026, what each one caps, and the one option where the free tier is Cloudflare's, not a vendor's. Every "free" IoT platform is free until your project works. Then the caps arrive: a device limit you hit by adding a second sensor node, a message quota that continuous monitoring empties in a week, a retention window that quietly deletes the data you meant to keep. None of that is a scam — hosted platforms have real costs — but it means "which free tier" is a real engineering decision, not a signup form. This is a ranked list of the free options makers actually weigh in 2026, judged on what the free tier honestly sustains. One disclosure up front: nodrix is our platform. It's also ranked first for a structural reason you can verify yourself — it's the one option on this list whose free tier belongs to Cloudflare, not to an IoT vendor with an upgrade funnel. ## The short version | Platform | Model | The free tier's real limit | First paid step | |---|---|---|---| | nodrix | Open source, your Cloudflare account | Cloudflare free-plan quotas (generous) | Cloudflare usage pricing | | Blynk | Hosted SaaS | Few devices, monthly message quota, short history | Steep — Pro is ~$99/month | | ThingSpeak | Hosted (MathWorks) | Update-rate floor, annual message cap | Annual license tiers | | Adafruit IO | Hosted SaaS | Data-rate cap, 30-day retention | IO+ subscription | | Arduino Cloud | Hosted SaaS | Tight thing/device limits, ecosystem pull | Monthly plans | | Datacake | Hosted SaaS | Per-device model from the start | Per-device pricing | | TagoIO | Hosted SaaS | Handful of devices, data-ops metering | Usage-based paid plans | | ThingsBoard | Open source + hosted cloud | Cloud has no free tier; self-host is heavy | ~$10/month cloud, or your server | ## 1. nodrix — free the way infrastructure is free nodrix is open source (MIT). There is no hosted nodrix service and no vendor free tier: you one-click **deploy it to your own Cloudflare account**, and the only quotas that exist are Cloudflare's — which, on the free plan, comfortably absorb hobby and small-fleet telemetry at rates that would blow through any hosted cap on this list. Devices speak plain HTTPS/WebSocket through an open Arduino library (ESP32/ESP8266) or raw HTTP from anything else; dashboards, automations, and a read API are in the box; every reading stays in your tenancy. The honest trade: you're operating your own instance — one click to deploy, but yours. There's no vendor support desk, and a native mobile app is still on the roadmap (dashboards are responsive web). If a managed service is what you want, one of the hosted options below fits better. **The free tier sustains:** continuous multi-device monitoring, indefinitely — the workload the hosted tiers below are specifically sized to exclude. ## 2. Blynk — the polished app, until the cliff Blynk's mobile app is still the best in class, and for point-a-phone-at-a-microcontroller projects the experience is hard to beat. The free tier is a genuine trial: a few devices, a monthly message quota, days-not-months of history. The structural problem is the cliff after it — the Pro plan runs about $99/month, with little between hobby and professional. Great for evaluating; expensive the moment a real project outgrows the cap. The full comparison is in [our Blynk alternative guide](https://nodrix.live/guides/blynk-alternative). ## 3. ThingSpeak — the academic workhorse Backed by MathWorks, stable for over a decade, and still the default in university coursework thanks to MATLAB analytics. The free tier's shape is distinctive: an annual message allowance and a minimum interval between updates, which suits slow environmental logging and rules out anything chatty. If your project reports every few seconds, the update-rate floor is the wall you'll hit first — the details are in [our ThingSpeak alternative guide](https://nodrix.live/guides/thingspeak-alternative). ## 4. Adafruit IO — friendly, capped by design The most beginner-friendly onboarding in the hosted group, excellent docs, and honest pricing. The free tier caps the data rate and retains data for 30 days — fine for a first project, limiting for anything that needs a year of history. IO+ is reasonably priced as hosted plans go. Where it sits against self-hosting is in [our Adafruit IO alternative guide](https://nodrix.live/guides/adafruit-io-alternative). ## 5. Arduino Cloud — smooth inside the fence If you're all-in on Arduino hardware and the Arduino IDE, the integration is genuinely smooth — sketch sync, device provisioning, dashboards in one place. The free plan's thing limits are tight, and the deeper cost is architectural: the workflow pulls you toward the Arduino ecosystem end to end. For any-board projects, [the comparison](https://nodrix.live/guides/arduino-cloud-alternative) covers where it pinches. ## 6. Datacake — per-device from day one A clean low-code dashboard builder with strong LoRaWAN support. The free tier is a couple of devices, and the paid model is per-device — predictable for a fixed fleet, punishing for the add-a-sensor-every-month style of maker growth. Compared in [our Datacake alternative guide](https://nodrix.live/guides/datacake-alternative). ## 7. TagoIO — capable, metered A capable platform with real analytics, and a free tier of a handful of devices metered by data operations. It shows up in expert maker roundups for good reason, but the metering model means you budget "operations" the way you'd budget an API bill — workable, just never free-feeling. ## 8. ThingsBoard — free software, not a free service ThingsBoard Community Edition is genuinely capable open source — the catch is that, as of mid-2026, the hosted cloud publishes no free tier (maker plans start around $10/month), so "free ThingsBoard" means self-hosting a Java application with PostgreSQL and a message broker on a server you run and patch. If you have the box and the appetite, it's the most featureful self-host in the list; the operational weight is the trade, and it's exactly the weight [a serverless deploy avoids](https://nodrix.live/guides/thingsboard-alternative). ## How to actually choose - **A weekend demo** → any hosted free tier works; pick the onboarding you like. Adafruit IO and Blynk are the smoothest. - **A project that runs for years** → count messages per month before you build. Continuous monitoring at even one reading per 10 seconds is ~260k messages a month per variable — check that number against any hosted cap on this list, then check what the paid step costs. - **A classroom or club** → per-account device caps multiply badly. One self-deployed instance for the whole cohort sidesteps the accounting. - **Data you intend to keep** → retention windows and export paths matter more than dashboards. Prefer platforms where history sits behind an API you control. The pattern behind the ranking: hosted free tiers are sized to end. That's their job. The only free tier that doesn't expire with your project's success is one attached to general-purpose infrastructure — which is the argument for [deploying your own](https://nodrix.live/guides/deploy-nodrix-cloudflare) and letting Cloudflare's free plan be the cap. ### FAQ **Q: Is there a completely free IoT platform?** Truly free means no device caps, no message quotas, and no retention limits — and no hosted platform offers that, because your data costs them money. The closest thing is running open-source software on infrastructure with a generous free tier: nodrix on Cloudflare's free plan is free in that sense, and self-hosted ThingsBoard is free if you already own a server and the time to run it. **Q: What's the catch with hosted free tiers?** They're sized for a demo, not a deployment. A couple of devices, a message quota that continuous monitoring burns through in days, and short data retention. That's fair — they're funnels to paid plans — but it means the free tier decision is really a pricing decision: check what the first paid step costs before you build on the free one. **Q: Which free tier is best for a classroom or student projects?** For a room full of students, per-account device caps bite immediately. ThingSpeak remains a common classroom pick because MATLAB-adjacent coursework tolerates its update-rate floor. A single nodrix deploy on one Cloudflare account can host every student's project with no per-device accounting, which is why it works well for cohorts. **Q: Do any of these lock me in?** Watch two things: whether the device protocol is open (can you point firmware elsewhere without a rewrite?) and whether your historical data can leave (is there a bulk export or API?). Vendor SDKs and proprietary protocols are the usual lock; platforms speaking plain HTTP/MQTT/WebSocket with a real read API are the easy ones to walk away from — which, paradoxically, is a good reason to trust them. --- ## Guide: ESP32-C3 vs ESP8266: the upgrade question, answered honestly URL: https://nodrix.live/guides/esp32-c3-vs-esp8266 Category: hardware · Board: ESP32-C3 ESP32 vs ESP8266 in 2026, at the budget end: the ESP32-C3 is the 8266's designated successor at nearly the same price, with the RAM headroom that makes TLS comfortable instead of a squeeze. When to switch, when the old board is still the right call, where the wider ESP32 family fits, and what changes in firmware. The ESP8266 is the board that made Wi-Fi microcontrollers a hobby: a decade of tutorials, a sub-two-dollar price, and millions of deployed nodes still dutifully reporting. It's also a 2014 design whose RAM budget makes modern TLS feel like packing a suitcase by sitting on it. The ESP32-C3 is Espressif's designed successor — near-8266 pricing with the constraints removed — and "should I switch" has become the default question at the budget end of the family. The honest answer has three parts: for new designs, yes; for working deployments, no; and the details are worth two minutes because the 8266's remaining advantages are real. ## What the C3 fixes The upgrades that actually change a maker's day, in order: - **RAM headroom.** The C3 has several times the usable memory of the 8266, whose ~40–50 KB of practical heap made every TLS handshake a negotiation. On the C3, HTTPS with full certificate validation is a non-event — the difference between pinning a fingerprint and hoping and pinning a CA properly. - **Bluetooth LE 5.** Provisioning without hardcoded credentials, beacons, phone-adjacent tricks — a whole category the 8266 simply doesn't have. - **Hardware crypto.** TLS handshakes lean on acceleration instead of grinding the core. - **Saner pins.** More usable GPIO without the 8266's minefield of boot-strapping pins that reset the board if a sensor holds them low at the wrong moment — and deep-sleep wake without the famous GPIO16-to-RST bodge wire. - **A current toolchain.** RISC-V core, first-class attention in today's SDK and Arduino core, and the same platform generation as the C6 above it. ## What the ESP8266 still has - **Price and ubiquity.** Under $2 in bulk, in every parts drawer, on every tutorial site — the cheapest ticket to Wi-Fi there has ever been. - **A decade of documented behavior.** Every quirk has a forum thread; the platform holds no surprises, which is its own kind of reliability. - **Continued life.** Espressif's 15-year production commitment carries the series toward the end of the decade, and the software ecosystem still sees genuine investment — this is a supported legacy, not abandonware. - **It already works.** A deployed 8266 that reports on schedule owes you nothing. Boards in service are not an upgrade queue. ## ESP32 vs ESP8266 is no longer two chips The reason this page is about the C3 specifically, rather than "ESP32 vs ESP8266" as a binary, is that the ESP32 stopped being one chip years ago. It's a family now, and which variant you pick usually matters more than the family name: - **ESP32-C3** — this page: near-8266 price, modern RAM, BLE, the natural successor for a cheap Wi-Fi node that has outgrown the 8266. - **Classic ESP32** — dual-core and ubiquitous, the default when you want the deepest ecosystem and the most examples to copy from. - **ESP32-S3** — more compute and vector instructions for camera work or light on-device ML. - **ESP32-C6** — Wi-Fi 6 plus the 802.15.4 radio for Thread and Zigbee, the family's route into Matter; the detail is in [ESP32-C6 for makers](https://nodrix.live/guides/esp32-c6-for-makers). So the old question — "should I use an ESP32 or an ESP8266?" — almost always resolves to "move to a modern ESP32 variant," and then to "which one." At the budget end where the 8266 lived, that's the C3; step up only when a project needs an S3's compute or a C6's radios. The two-chip duel has quietly become a shortlist, and the 8266's price is the one thing that still keeps it on the list at all. ## The firmware reality With the [nodrix Arduino library](https://github.com/decoded-cipher/nodrix-sdk), both chips run the same sketch — same `Nodrix.begin`, same `Nodrix.send`, same `NODRIX_WRITE` handlers. The one line that differs is how you pin TLS, and it's the whole story of the two chips in miniature: ```cpp #include void setup() { #if defined(ESP8266) Nodrix.setFingerprint(HOST_FP); // chain validation is heavy for 40 KB of heap #else Nodrix.setCACert(ROOT_CA_PEM); // C3: validate the chain properly, RAM is a non-issue #endif Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); } void loop() { Nodrix.run(); } ``` The 8266 route works — [the full walkthrough](https://nodrix.live/guides/esp8266-iot-dashboard) squeezes BearSSL into that budget deliberately, and a fingerprint pin is honest security. But a fingerprint pins one certificate rather than a chain, so certificate rotation upstream means re-pinning; a CA pin on the C3 shrugs rotation off. That maintenance difference compounds over a fleet's lifetime. Everything else in a migration is pin numbers and the pleasant deletion of workarounds: the ADC that's no longer a single overloaded pin, the wake wire that's no longer soldered, the payload size you stop budgeting. ## Choosing, compressed | Situation | Pick | |---|---| | New design, any TLS ambition, BLE, or growth plans | ESP32-C3 | | Absolute-minimum-cost fixed sensor, modest reporting | ESP8266, still | | Deployed 8266 fleet, working fine | Leave it be | | Buying for the drawer in 2026 | C3 — or [a C6](https://nodrix.live/guides/esp32-c6-for-makers) for the radio options | | Deep-sleep battery sensor | Either — [the pattern](https://nodrix.live/guides/esp32-deep-sleep-battery) fits both; the C3 skips the wake-wire bodge | ## The bottom line The ESP8266 earned its retirement-age respect, and nothing about 2026 forces it out of service. But the design conversation is over: the C3 costs pennies more and deletes the exact constraints — RAM, TLS comfort, pin quirks, no BLE — that every 8266 project spends its first evening working around. Point either one at [your own instance](https://nodrix.live/guides/deploy-nodrix-cloudflare) and the cloud can't tell them apart — the difference is the workarounds you no longer write. ### FAQ **Q: Is the ESP8266 obsolete in 2026?** No — dated, not dead. Espressif's longevity commitment keeps the ESP8266 series in production toward the end of the decade, the ecosystem still receives real investment, and boards cost under two dollars in bulk. For a Wi-Fi-only sensor with modest TLS needs it remains perfectly serviceable. Obsolete is the wrong frame; 'no longer what you'd design in' is the right one. **Q: What does the ESP32-C3 actually improve over the ESP8266?** The ones that change your day: several times the usable RAM, which turns TLS from a heap-anxiety exercise into a non-event; Bluetooth LE 5 for provisioning or beacons; hardware crypto acceleration; more usable GPIO with saner boot-strapping quirks; and a current toolchain that gets first-class attention. The CPU jump (a 160 MHz RISC-V core vs the 8266's aging Tensilica) matters less than the memory for typical projects. **Q: Do I have to change my code to move from ESP8266 to ESP32-C3?** Less than you'd fear. Arduino-side, most sketches move with pin-number edits — and with the nodrix library the cloud calls are literally identical. The one visible difference is TLS pinning: on the 8266 you pin a certificate fingerprint (setFingerprint) because full chain validation is heavy for its RAM; on the C3 you pin the CA properly (setCACert) and stop thinking about the heap during handshakes. **Q: Should I buy ESP8266 boards for a new project just because they're cheaper?** Only if the project is genuinely at the two-dollar end: a fixed sensor, one HTTPS report every few minutes, no BLE, no growth ambitions — the 8266 still does that with dignity. The moment the plan includes always-on TLS connections, bigger payloads, OTA headroom, or Bluetooth anything, the one-dollar saving buys you the exact constraints the C3 was designed to remove. --- ## Guide: ESP32-C6 for makers: what the new radios change, and what they don't URL: https://nodrix.live/guides/esp32-c6-for-makers Category: hardware · Board: ESP32-C6 The ESP32-C6 packs Wi-Fi 6, BLE, and an 802.15.4 radio for Thread and Zigbee into a $5 board — the ESP32 line's ticket into Matter. Here's what that actually means for a maker project today, the radio fine print nobody leads with, and why your cloud firmware doesn't change at all. The ESP32-C6 is the chip that made the smart-home crowd take notice: Wi-Fi 6, Bluetooth LE, and an IEEE 802.15.4 radio — the physical layer under Thread and Zigbee — on one die, on dev boards that cost about five dollars. It's become one of the most popular chips in the ESPHome and Home Assistant world on the strength of that radio list, and it's Espressif's ticket into the Matter era. This page is the maker's-eye view: what those radios actually buy you today, the fine print the spec sheet doesn't lead with, and the part that matters if your project talks to a cloud dashboard — which is that nothing changes at all. ## What the C6 actually is A single RISC-V core at 160 MHz with the modern peripheral set, plus the most interesting radio package Espressif has shipped at this price: - **Wi-Fi 6 (802.11ax) on 2.4 GHz** — current-generation Wi-Fi, including Target Wake Time. - **Bluetooth LE 5** — the usual provisioning and beacon duties. - **802.15.4** — the mesh radio protocol under **Thread** and **Zigbee**, which is what makes the C6 **Matter-capable** both over Wi-Fi and over Thread. Worth saying plainly: it's a single-core chip. The classic dual-core ESP32 still wins raw compute, and the C6 isn't a straight upgrade — it's a current-generation radio platform. For read-a-sensor, run-a-relay, talk-to-the-cloud projects, one core is plenty. ## The radio fine print The three protocols share **one 2.4 GHz radio**. Coexistence is real and SDK-supported, but it's time-slicing, and the practical shape in today's firmware stacks is choosing a primary personality per build: this board is a Wi-Fi device, or it's a Zigbee sensor, or it's a Thread node. Toolchains reinforce it — Zigbee and Thread live in specific SDK configurations, and the mainstream Arduino path is Wi-Fi-first. A C6 gives you the option of any of them on the same hardware; it doesn't give you all of them at full strength at once. Wi-Fi 6 comes with its own asterisk: its dense-network efficiency and Target Wake Time need an 802.11ax access point on the other side, and TWT support across routers and firmware is still uneven. A battery project shouldn't be planned around TWT yet — a deep-sleeping board already schedules its own radio, on any access point ever made. ## What this means for a cloud project: nothing, pleasantly Here's the part that keeps the C6 boring in the best way. A dashboard you can open from anywhere, telemetry history, alerts to your phone — that's cloud-backend work, and it rides ordinary Wi-Fi and HTTPS, which the C6 speaks at least as well as every ESP32 before it. The [nodrix Arduino library](https://github.com/decoded-cipher/nodrix-sdk) targets the esp32 core, and the C6 is just another entry in the boards menu: ```cpp #include NODRIX_WRITE("relay") { digitalWrite(10, value.asBool()); } void setup() { pinMode(10, OUTPUT); Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); } void loop() { Nodrix.run(); } ``` Same `Nodrix.send`, same `NODRIX_WRITE`, same one socket. One devkit footnote: the official C6-DevKitC's onboard "LED" is an addressable RGB on GPIO8 that wants `neopixelWrite()`, not `digitalWrite()` — which is why the example above drives a plain GPIO instead. Every guide on this site — the [HTTPS walkthrough](https://nodrix.live/guides/esp32-https-cloud), the [deep-sleep battery patterns](https://nodrix.live/guides/esp32-deep-sleep-battery), the project builds — runs on a C6 without a changed line beyond pin numbers. ## When do the extra radios earn their keep? - **You want the same hardware to serve two futures.** Today it's a Wi-Fi sensor on your dashboard; next year maybe it reflashes as a Thread device in a Matter fabric. One $5 board covers both bets. - **You're building for a smart-home ecosystem on purpose** — a device that Apple Home or Google Home should discover natively. That's Matter's job, the C6 is the budget entry point, and it's a local-interoperability goal, distinct from (and combinable with) your own cloud dashboard — [the Home Assistant comparison](https://nodrix.live/guides/home-assistant-vs-nodrix) draws that boundary. - **Zigbee sensors without a commercial hub** — the C6 as a DIY Zigbee endpoint is an active, fast-moving corner of the ESPHome world, tooling caveats included. If none of those describe your project, buy the C6 anyway when it's convenient — it's cheap, current, and fine — but know you're buying optionality, not capability your dashboard will notice. ## The bottom line The ESP32-C6 is the right default board to reach for in 2026: current silicon, every relevant radio, five dollars. Just read its promise correctly — it's one radio wearing three hats, the smart-home protocols are a per-build choice, and the cloud side of your project is gloriously indifferent to all of it. Point it at [your own instance](https://nodrix.live/guides/deploy-nodrix-cloudflare) and the newest chip in the family behaves exactly like the family: a few lines of firmware, a live dashboard, nothing else to run. ### FAQ **Q: Should I buy an ESP32-C6 instead of a regular ESP32 for a new project?** If you're buying new anyway and the board fits your form factor, the C6 is a sensible default: current-generation silicon at effectively the same price, with radio options you may grow into. But it's a single RISC-V core where classic ESP32s are dual-core — for most sensor-and-dashboard projects that difference is irrelevant, and nothing about a Wi-Fi cloud project requires a C6. Don't replace working boards for it. **Q: Can the ESP32-C6 run Wi-Fi and Zigbee at the same time?** They share one 2.4 GHz radio, so it's time-slicing, not two radios. Coexistence support exists in the SDK, but the practical reality in common firmware stacks is that you build for a primary role — a Wi-Fi device, or a Zigbee/Thread device — rather than a router doing both heavily at once. Treat 'all the protocols' as a menu, not a buffet plate. **Q: Does Wi-Fi 6 make my IoT project faster or longer-lived on battery?** Only with a Wi-Fi 6 router on the other end, and mostly in dense environments. The headline battery feature, Target Wake Time, lets a device negotiate scheduled wake-ups with the access point — genuinely promising for battery sensors, but it needs router support and firmware maturity, and a deep-sleeping board already controls its own schedule. Buy the C6 for the option, not the promise. **Q: Does the nodrix Arduino library work on the ESP32-C6?** Yes — the library targets the esp32 Arduino core, and current core releases cover the C6. The same sketch that runs on a classic ESP32 runs unmodified: Nodrix.begin, Nodrix.send, NODRIX_WRITE. Wi-Fi plus HTTPS/WebSocket is deliberately the most portable path across the whole ESP32 family. **Q: Do I need Matter or Thread for a cloud dashboard project?** No — they solve a different problem. Matter and Thread are about making devices interoperable with smart-home ecosystems (Apple Home, Google Home, Alexa) on the local network. A dashboard you open from anywhere, history, and alerts are a cloud-backend problem, which runs over ordinary Wi-Fi and HTTPS. Plenty of projects will eventually do both; they don't compete. --- ## Guide: Build an ESP32 energy meter with a live dashboard URL: https://nodrix.live/guides/esp32-energy-meter Category: project · Board: ESP32 A complete ESP32 energy monitor: read real volts, amps, watts, and kWh with a PZEM-004T, push them to a live dashboard over one WebSocket, and get a Telegram alert when the load spikes — no broker, no vendor app, on your own Cloudflare account. 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**](https://github.com/mandulaj/PZEM-004T-v30) 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](https://github.com/decoded-cipher/nodrix-sdk) owns the socket and the reconnects; the sketch is just a read-and-send loop. ```cpp #include #include 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](https://nodrix.live/guides/esp32-https-cloud). ## 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](https://nodrix.live/guides/esp32-receive-commands). - **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 **Q: 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. **Q: 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. **Q: 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. **Q: 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. **Q: 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. **Q: 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. --- ## Guide: Build an ESP32 GPS tracker with a live map — no proprietary cloud URL: https://nodrix.live/guides/esp32-gps-tracker Category: project · Board: ESP32 A complete ESP32 GPS tracker: read a NEO-6M over serial, stream position over one WebSocket, and watch the marker move on a map dashboard you own — no vendor tracking cloud, no per-device fee, on your own Cloudflare account. Most ESP32 GPS tracker tutorials end the same way: your coordinates flow into somebody else's tracking portal, on their account system, at their pleasure. This build keeps the whole path yours. A NEO-6M reads position, the ESP32 streams it over one WebSocket, and the marker moves across a map dashboard served from **your own Cloudflare account** — open source end to end, no tracking vendor, no per-device fee, and a read API if you ever want the raw trail. It's also honest about the one thing GPS tutorials tend to gloss over: GPS tells the board where it is anywhere; reporting it needs an uplink. With Wi-Fi that means a phone hotspot in the vehicle, depot or campus networks for fleet-yard visibility, or your home network for arrive/leave tracking. ## What you'll build - A **live map** with a marker that follows the tracker, updating in place over a WebSocket. - A **speed readout** on the marker and a 24-hour **speed chart**. - A **Telegram alert** when the tracker moves faster than it should. ## What you'll need - An **ESP32** dev board (any common DevKit variant). - A **NEO-6M GPS module** with its ceramic antenna — the ubiquitous blue breakout. - A **power source** where the tracker lives: vehicle USB, a power bank, or a 5V supply. - The **Arduino IDE** with the ESP32 board package, the **Nodrix** library, and the [**TinyGPSPlus**](https://github.com/mikalhart/TinyGPSPlus) library, both from the Library Manager. - A **nodrix instance** with a project and a project token. ## How the GPS side works The NEO-6M speaks NMEA sentences over plain serial at 9600 baud — a stream of text lines carrying position, speed, altitude, and satellite health. TinyGPS++ parses the stream; your sketch just feeds it bytes and asks for numbers. Two field realities to plan around: - **Cold starts are slow.** First fix after power-up takes one to five minutes under open sky while the module downloads orbit data; indoors it may never lock. Once it has run, a warm module re-fixes in seconds. The onboard LED blinks when locked. - **The antenna wants sky.** On a dashboard shelf or rear window, fine; sealed in a metal box, never. Position the ceramic antenna face-up with a view of the sky. ## Wiring Four wires. The NEO-6M runs on 3.3V logic, so it connects to the ESP32 directly: | From | To | Wire | |------|----|------| | NEO-6M VCC | ESP32 3V3 | Power | | NEO-6M GND | ESP32 GND | Ground | | NEO-6M TX | ESP32 GPIO16 (RX2) | Serial | | NEO-6M RX | ESP32 GPIO17 (TX2) | Serial | Some NEO-6M breakouts prefer 5V on VCC (they regulate down); check yours. The TX/RX logic level is 3.3V either way. ## The firmware The sketch has one job per direction: feed NMEA bytes to the parser, and send a position whenever the tracker has actually moved. The [nodrix Arduino library](https://github.com/decoded-cipher/nodrix-sdk) owns the socket and the reconnects. ```cpp #include #include const char* WIFI_SSID = "your-ssid"; // or the phone hotspot in the vehicle const char* WIFI_PASS = "your-password"; const char* HOST = "nodrix.you.workers.dev"; const char* TOKEN = "tok_your_project_token"; TinyGPSPlus gps; double lastLat = 0, lastLng = 0; void setup() { Serial2.begin(9600, SERIAL_8N1, 16, 17); Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); } void loop() { Nodrix.run(); while (Serial2.available()) gps.encode(Serial2.read()); if (!gps.location.isValid()) return; static unsigned long lastSend = 0; bool moved = TinyGPSPlus::distanceBetween( gps.location.lat(), gps.location.lng(), lastLat, lastLng) > 15; unsigned long interval = moved ? 5000 : 60000; if (millis() - lastSend >= interval) { lastSend = millis(); lastLat = gps.location.lat(); lastLng = gps.location.lng(); Nodrix.send("lat", gps.location.lat()); Nodrix.send("lng", gps.location.lng()); Nodrix.send("speed_kmh", gps.speed.kmph()); } } ``` Worth understanding rather than copying: - **The send rate follows movement.** Moving, it reports every 5 seconds; parked, once a minute as a heartbeat. The 15-meter threshold is roughly GPS jitter — without it, a parked tracker "drifts" a random walk around the true spot and floods the chart with noise. - **Coordinates stay double-precision.** TinyGPS++ returns doubles and `Nodrix.send` takes them as-is. A 32-bit float holds only about seven significant digits — meters of error at longitude scale — so the sketch never casts. - **No fix, no send.** Until `gps.location.isValid()`, nothing is reported. A map with an honest gap beats a marker confidently parked at 0°N 0°E off the coast of Africa. - **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 Add a **Map** widget. In its marker settings, add one marker with **source: Lat/Lng variables**, bind `lat` and `lng`, and set the optional value variable to `speed_kmh` so a tap on the marker shows how fast the tracker is moving. Pick a color, choose a basemap, and the marker starts following the board — updates arrive live over the same hibernating WebSocket the dashboards always use. Two more widgets round it out: | Widget | Bind to | Shows | |---|---|---| | Value | `speed_kmh` | current speed | | Chart | `speed_kmh` | the day's movement pattern | The speed chart doubles as a trip log — flat at zero is parked, and each lobe is a drive, wired to nothing but data you already send. ## Add the alert One automation: trigger on a new `speed_kmh` reading, condition **above 90** (pick your number), action: Telegram — "Tracker doing {{value}} km/h." Whether that's a teen driver, a delivery van, or an e-bike that shouldn't be on a highway, the alert channel and threshold are edited in the dashboard, never in firmware. Swap Telegram for Slack, Discord, or SMS without touching the condition. ## Where this design honestly lands - **In-vehicle with a phone hotspot** — full live tracking while you drive. This is the everyday mode, and a hotspot the phone already provides beats a SIM subscription for a personal vehicle. - **Depot, campus, worksite** — assets report whenever they're on site Wi-Fi: live position in the yard, last-known-position the moment they leave. For "which corner of the site is the trailer in," that's the whole job. - **Arrive/leave at home** — on home Wi-Fi the tracker reports approach and departure; the gap in between is the trip. - **Continuous anywhere-tracking** — that's a cellular modem and a monthly SIM, in any product. If the project outgrows Wi-Fi, the dashboard side here doesn't change; only the uplink does. ## Going further - **Battery asset tag.** Swap the always-open socket for wake-fix-report-sleep over HTTP (`Nodrix.beginHTTP()` + `Nodrix.poll()`) and a small cell runs for weeks — the pattern is in [ESP32 battery life](https://nodrix.live/guides/esp32-deep-sleep-battery). Budget for the GPS fix time: keeping the NEO-6M's backup power pin alive makes each wake a hot start. - **A remote "locate now" button.** Add a `NODRIX_WRITE("locate")` handler that forces an immediate send — a dashboard push button gives you on-demand position while parked. - **More trackers, one map.** Each device sends `lat_2`/`lng_2` (or its own token and variables) and gets its own marker on the same map — fleet view is just more markers. - **Pull the trail.** The full position history sits behind the read API — one token gets you the series for any mapping, geofencing, or trip-report post-processing you want to build. ## Notes - **No tracking vendor in the loop.** Position data goes from your board to your Cloudflare account; the map is served from your instance and the history is queryable through your API. - **The moving parts are all replaceable.** NMEA serial in, HTTPS/WebSocket out — swap the GPS module, the board, or even the firmware framework and the dashboard neither knows nor cares. - **Costs track usage.** A tracker at 5-second cadence is well within normal Workers usage on your own account — there's no per-device fee to multiply across a fleet. ### FAQ **Q: Does this track a car anywhere, like a commercial tracker?** Only where it has an uplink. GPS gives the board its position anywhere on earth; getting that position off the board needs Wi-Fi, so live tracking works wherever the tracker can reach a network — a phone hotspot in the vehicle, campus or depot Wi-Fi, or your home network for arrive/leave visibility. Commercial trackers solve this with a cellular modem and a SIM subscription; that's the honest difference, not the GPS part. **Q: Why does my NEO-6M take so long to get a fix?** A cold start legitimately takes one to five minutes with a clear sky view — the module is downloading satellite orbit data. Indoors it may never lock. Give the antenna sky view, keep the module powered so it can hot-start in seconds next time, and watch the module's fix LED: blinking means locked. **Q: Why send latitude and longitude as two variables instead of one?** Because that's what the map widget binds to: a marker follows a lat variable and a lng variable as a pair. Two plain numeric variables also stay useful individually — both are charted, queryable through the read API, and usable in automations without unpacking anything. **Q: Is float precision enough for GPS coordinates?** The firmware sends doubles, so this isn't a worry here — TinyGPS++ hands out double-precision coordinates and Nodrix.send has a double overload. Truncating to 32-bit floats would cost you real accuracy (a float only holds about seven significant digits, which is meters at longitude scale), which is why the sketch never casts. **Q: What happens to the track while the tracker is out of coverage?** The library keeps reconnecting, and positions sent while offline are skipped rather than queued, so the map shows an honest gap and then the marker jumps to the current fix on reconnect. Backfilling the gap would need timestamps attached to old fixes, which telemetry sends don't carry — buffered breadcrumb history is on the roadmap; today the tracker is live-position-first. --- ## Guide: ESP32 notifications: Telegram, Discord, Slack, or SMS from one sketch URL: https://nodrix.live/guides/esp32-notifications Category: project · Board: ESP32 Send alerts from an ESP32 to Telegram, Discord, Slack, SMS, or WhatsApp — without baking bot tokens and webhooks into firmware. The board sends one line of telemetry; the alert logic, credentials, and channel live in the cloud, swappable without reflashing. Search for "ESP32 Telegram notification" and every tutorial hands the board a bot token and an HTTPS client and wishes it luck. It works — until you want the same alert on Discord, or the token leaks with a firmware dump, or you're reflashing a deployed board because the wording changed. This guide inverts it. The ESP32 sends **one line of telemetry** and holds **zero secrets**. The threshold, the message, the credentials, and the channel — Telegram, Discord, Slack, SMS, WhatsApp, email, or PagerDuty — live in an automation on **your own Cloudflare account**, where changing any of them is an edit, not a reflash. One sketch, any channel, swappable forever. The worked example is a freezer monitor — the project where notifications aren't a novelty but the entire point. ## Why the board shouldn't send the alert Sending from firmware means, for every channel: its TLS endpoint compiled in, its credential stored in flash (readable by anyone with the board and five minutes), its message format hard-coded, and its failure modes handled at 3 a.m. by a microcontroller. Multiply by every channel you add. Sending from the cloud means the board's contract is just `temperature` every minute. Then: - **Secrets stay out of flash.** The bot token and webhook URLs live in your nodrix instance, not in something you might one day post to GitHub. - **The channel is a dropdown.** Telegram today, Discord for the household tomorrow, SMS for the cabin with no one watching chat — same firmware, forever. - **The logic is editable.** Threshold, wording, hysteresis, recipients: dashboard edits, applied on the next reading. - **Deep sleep stays deep.** A battery board reports and sleeps; the alerting happens after it's already unconscious. ## What you'll need - An **ESP32** dev board and a temperature sensor — a DS18B20 on a long lead is the classic freezer choice. - The **Arduino IDE** with the ESP32 board package, the **Nodrix** library, and the **DallasTemperature** library, from the Library Manager. - A **nodrix instance** with a project and a project token. - An account on whichever channel should wake you: Telegram, Discord, Slack, or Twilio for SMS and WhatsApp. ## The firmware All of it. Note what's absent: no bot token, no webhook URL, no threshold, no message text. ```cpp #include #include #include 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"; OneWire oneWire(4); DallasTemperature sensors(&oneWire); void setup() { sensors.begin(); Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); } void loop() { Nodrix.run(); static unsigned long lastReading = 0; if (millis() - lastReading >= 60000) { lastReading = millis(); sensors.requestTemperatures(); float t = sensors.getTempCByIndex(0); if (t > -100) Nodrix.send("temperature", t); // -127 = sensor disconnected } } ``` The library keeps the socket alive and reconnects on its own; for a battery build, swap `Nodrix.begin` for `Nodrix.beginHTTP` and report once per wake — the alert side of this guide doesn't change at all. ## Wire up a channel Each channel is added once, under your project's integrations, and then reused by any automation. **Telegram** — the best free option for personal alerts: instant, free, works everywhere. Message `@BotFather`, create a bot, paste the **bot token** into the integration; message your bot once, pull your **chat ID** from the `getUpdates` URL, done. Group alerts: add the bot to a group and use the group's chat ID. **Discord** — the right answer when a household or team already lives there. In your server: channel settings → Integrations → Webhooks → copy the **webhook URL**. That URL is the entire credential. The integration can send a plain message or a titled embed — embeds read better for alerts with a value in them. **Slack** — same shape as Discord for workplaces: create an Incoming Webhook in your Slack app settings, paste the URL. If the freezer is in an office, the alert belongs in the channel people actually have open. **SMS and WhatsApp via Twilio** — for alerts that must land when nobody's watching a chat app. Paste your **Account SID**, **auth token**, and sending number. SMS costs real (small) money per message, which the hysteresis below keeps honest; a trial account works for testing but only texts verified numbers. Email and PagerDuty follow the same pattern — a webhook-shaped credential pasted once — and everything below applies to them identically. ## Build the alert One automation: trigger on a new `temperature` reading, condition **above -10**, action: send — "Freezer at {{value}}°C — check the door." The `{{value}}` fills in from the reading that tripped it. That's a working alert. Now make it a good alert: - **Add hysteresis.** A freezer cycling around the line would ping you on every crossing. Alarm above **-10**, and only rearm after the reading recovers below **-15** — the automation's set-a-flag pattern: on alarm, also set an `alerted` variable; condition the alert on `alerted` being off; clear it on recovery. Three conditions in the editor, zero firmware. - **Alert on silence, too.** A dead sensor sends nothing — which no threshold ever catches. Add a schedule trigger (say, every morning) with an `if-variable` check that the last `temperature` is fresh; stale means power, Wi-Fi, or the board itself. A monitor that fails silently is worse than none. - **Escalate by severity.** Above -10: Telegram. Above -5: Telegram and SMS. Two automations, same variable, different thresholds and channels — the melted-food tier earns the message that costs money. ## One sketch, any alert Nothing in this pattern is about freezers. The same firmware shape — read, `Nodrix.send`, repeat — with a different sensor and threshold is a leak detector under the washing machine, a mailbox switch, a greenhouse heat alarm, or the [plant-watering monitor](https://nodrix.live/guides/esp32-automatic-plant-watering) that messages you when the reservoir runs dry. The channel decision stays where it belongs: in a dropdown, six months from now, when you've moved from Telegram to Discord and the board neither knows nor cares. ## Notes - **Credentials live in one place.** Rotating a leaked webhook is one edit in your instance — not a reflash of every deployed board. - **The alert path is yours.** Board → your Cloudflare account → channel API. No third-party automation service in the middle, no monthly task quota. - **Every alert has a paper trail.** The readings that tripped it are in your dashboard's chart and behind the read API — the alert tells you now, the chart tells you why. ### FAQ **Q: Can an ESP32 send a Discord or Slack message directly?** Yes — both are one HTTPS POST to a webhook URL, and plenty of sketches do it. The cost is where the credentials end up: the webhook URL is a secret, and anything baked into firmware can be read back out of flash. It also welds the channel to the board — changing where alerts go, their wording, or their threshold means reflashing. Keeping the send in the cloud fixes all three. **Q: How do I get a Telegram bot token and chat ID?** Message @BotFather on Telegram, send /newbot, and it hands you the bot token. Then message your new bot once (it can't message you first), and fetch https://api.telegram.org/bot/getUpdates in a browser — your chat ID is in the reply. Those two values go into the nodrix Telegram integration, not into the sketch. **Q: Does the SMS route cost money?** Yes — SMS is the one channel here with real per-message cost, via a Twilio account (a trial account works for testing but adds a prefix and only texts verified numbers). That's also why the cloud-side design matters: with thresholds and hysteresis keeping the alert count honest, an SMS bill for a freezer monitor is cents per month, not per day. **Q: Why did I get twenty alerts for one event?** A reading that jitters around the threshold retriggers on every crossing — 29.9, 30.1, 29.8 is three alerts for zero information. Use two levels: alert when the value crosses the alarm line, and only rearm once it recovers past a second line. The dead band between them is hysteresis, it's the same trick a thermostat uses, and it's a condition edit in the automation, not firmware. **Q: Does this work while the ESP32 deep-sleeps?** Yes, and better than on-device sending would. The board wakes, reports one reading over HTTP, and sleeps; the automation evaluates and does any messaging while the board is already unconscious. A battery sensor doesn't stay awake for a TLS handshake with Telegram — it doesn't even know the alert happened. --- ## Guide: MQTT vs HTTP for IoT: an honest comparison for makers URL: https://nodrix.live/guides/mqtt-vs-http-iot Category: concept Most MQTT-vs-HTTP comparisons are written by broker vendors, and it shows. Here's the maker's version: where MQTT genuinely wins, where the famous overhead numbers mislead, why WebSocket is the missing third option, and how to actually choose for an ESP32-class project. Search "MQTT vs HTTP" and nearly everything you'll read was published by a company that sells MQTT brokers. The conclusions follow the incentive: HTTP gets framed as a legacy protocol tolerated only for devices that can't do better, backed by overhead numbers measured under assumptions that flatter the product. MQTT is genuinely excellent at what it was built for — this page gives it full credit — but a maker choosing a protocol for an ESP32 deserves the version without the sales motion. Three claims up front, argued below: the famous efficiency numbers compare an unfairly configured HTTP; the decision for most maker projects is really about whether you want to operate a broker; and the strongest architecture for boards-to-cloud is the one both camps skip — HTTPS up, WebSocket down. ## What each protocol actually is [**MQTT**](https://mqtt.org) is publish/subscribe through a broker. Every device holds a persistent TCP connection to a central broker process; publishers push to topics, subscribers receive from them, and the broker routes. The protocol carries real machinery for unreliable links: three QoS levels, retained messages, and a last-will message the broker emits when a client vanishes. It was designed in 1999 to move pipeline telemetry over satellite links — scarce, expensive bytes — and that heritage is exactly why its framing is so lean. **HTTP** is request/response with no middleman. A device POSTs a reading to an endpoint and gets an acknowledgment in the reply; TLS, load balancing, auth tokens, and debugging tooling come from the web's thirty years of infrastructure. What plain request/response lacks is push: the server can't initiate, so commands wait for the device to ask. **WebSocket** is the third option most comparisons omit: a connection that starts as HTTPS on port 443 and upgrades to a persistent, bidirectional channel. Server push without a broker, firewall-friendly because it is web traffic, one socket carrying telemetry up and commands down. ## The overhead numbers, audited The stock argument says MQTT's per-message overhead is a 2-byte header against HTTP's hundreds of bytes of headers, quoting benchmark figures of roughly 8x the bytes and multiples of the latency. Two things about those numbers: - **They compare a held socket against connection-per-request.** MQTT gets a persistent session; HTTP is made to re-handshake for every message. Real HTTP clients reuse connections — and over a WebSocket, the per-message framing is bytes, not headers. Configured comparably, the protocols converge for the payload sizes makers ship. - **Their provenance is stale.** The most-cited latency figures trace to tests against Google Cloud IoT Core — a service retired in 2023. Numbers that outlive the platform they were measured on are marketing, not engineering. The honest version: on a continuously chatty, always-connected link, MQTT's framing really is leaner, and at fleet scale that compounds. At one reading every ten seconds from a handful of devices, the difference is invisible next to Wi-Fi beacons and TLS record overhead. ## The battery argument, audited "MQTT saves battery" assumes a device that stays connected. Battery devices don't — they sleep. The wake-report-sleep cycle pays for boot, Wi-Fi association, DHCP, and a TLS handshake before the first application byte, whichever protocol follows; then it ships a few hundred bytes and loses power on purpose. A session the device isn't holding can't save it anything. The protocol choice for battery hardware is a rounding error against sleep current and wake frequency — the real levers are in [the deep-sleep guide](https://nodrix.live/guides/esp32-deep-sleep-battery). ## Where MQTT genuinely wins Credit where due — choose MQTT when the shape of your system is its shape: - **Fan-out.** One sensor reading consumed by five services: pub/sub is the right primitive, and a broker does it natively. - **Device-to-device.** Boards talking to boards through topics, no backend in the loop. - **Presence.** Last-will gives you "device went dark" detection at the protocol level. - **Sustained chatter on constrained links.** Always-on cellular devices streaming frequent small messages is the satellite-pipeline problem MQTT was born for. - **Existing broker infrastructure.** A factory with Sparkplug conventions or a team already operating EMQX/Mosquitto — the ecosystem is mature and the marginal cost is paid. ## Where the HTTP family wins - **Nothing to operate.** A broker is a server: something to host, secure, patch, and monitor. Point-to-point HTTPS deletes the component entirely — for a maker, that's usually the whole argument. - **Networks just let it through.** Port 443 web traffic works from campus networks, offices, hotels, and behind corporate proxies where port 1883 is a support ticket. - **The web's toolbox applies.** Bearer tokens, `curl` for debugging, serverless platforms, CDNs, standard load balancing — every piece of web infrastructure is your IoT infrastructure. - **State and history live behind an API,** not in retained topic messages you have to mirror into a database anyway. ## The architecture the comparisons skip The classic knock on HTTP for IoT is the downlink: "how does the server tell the device anything?" Polling is the crude answer; a WebSocket is the good one. The pattern that gets the best of both camps, and the one nodrix is built around: - **Telemetry up** as plain HTTPS or over the socket — stateless, debuggable, serverless-friendly. - **Commands down** the same WebSocket — real push, at-least-once delivery, no broker, no polling. - **Battery devices** drop the socket entirely: wake, POST the reading, collect any pending command in the response, sleep — [the downlink guide](https://nodrix.live/guides/esp32-receive-commands) shows both modes behind one handler. That's not a compromise position between MQTT and HTTP; for boards-talking-to-your-backend, it's simply the fit. The broker earns its keep when messages have many consumers or device peers. When every message has exactly one destination — your platform — the broker is a mandatory middleman for a conversation with two parties. ## Choosing, compressed | Your system looks like | Use | |---|---| | Boards report to your backend; occasional commands back | HTTPS + WebSocket | | Battery sensors that sleep between reports | HTTPS, poll-on-wake | | One stream, many independent consumers | MQTT | | Devices messaging each other directly | MQTT | | Existing broker/Sparkplug infrastructure | MQTT | | Hostile networks (campus, corporate, hotel) | HTTPS + WebSocket | If your project is in the first two rows — and most maker projects are — the practical next step is seeing the broker-free version running: [an ESP32 on HTTPS](https://nodrix.live/guides/esp32-https-cloud) with [commands coming down the socket](https://nodrix.live/guides/esp32-receive-commands), on an instance you [deploy to your own Cloudflare account](https://nodrix.live/guides/deploy-nodrix-cloudflare) in one click. The best protocol argument is a working dashboard with nothing else to run. ### FAQ **Q: Is MQTT faster and lighter than HTTP?** Per message on an open connection, yes — MQTT's fixed header is 2 bytes and HTTP's headers are hundreds. But the comparisons that turn this into 'HTTP is 8x heavier' assume a new HTTP connection per message while MQTT keeps its socket open — an unfair matchup. Give HTTP the same courtesy (keep-alive, or a WebSocket) and the per-message gap shrinks to noise for typical maker payloads. For a duty-cycled sensor, the TLS handshake on wake dominates either protocol equally. **Q: Do I need MQTT for an ESP32 project?** Only if you need what a broker uniquely provides: fan-out of one message to many subscribers, device-to-device messaging, or presence via last-will. A board that reports readings to one backend and receives occasional commands — which is most maker projects — is a point-to-point conversation that HTTPS up and a WebSocket down handles with one less system to run. **Q: Does HTTP drain more battery than MQTT?** Not in the sleep-most-of-the-time pattern that battery projects actually use. A sensor that wakes every 15 minutes pays for boot, Wi-Fi association, and a TLS handshake before either protocol says a word — that's the budget, and it's identical. MQTT's efficiency accrues to devices that stay awake and chat continuously; a device that sleeps can't benefit from a session it isn't holding. **Q: Why do most IoT platforms push MQTT?** Partly genuine merit at fleet scale — and partly because many of them are broker companies, so the comparison you're reading is often the sales page. Note what their own numbers lean on: the widely-quoted latency and overhead benchmarks trace back to tests against a cloud IoT service that was retired in 2023, under connection-per-request assumptions. Read protocol advice the way you'd read a benchmark from anyone selling one side of it. **Q: What about CoAP, AMQP, or LoRaWAN?** Different problems. CoAP targets networks too constrained for TCP (it runs over UDP); AMQP is enterprise message-queue territory; LoRaWAN is a radio network whose gateways typically hand data to a backend over IP anyway. For Wi-Fi-class maker hardware — ESP32, ESP8266, Pico W — the real decision is the one on this page. --- ## Guide: nodrix vs Grafana + InfluxDB: the DIY IoT stack, weighed honestly URL: https://nodrix.live/guides/nodrix-vs-grafana-influxdb Category: comparison Grafana with InfluxDB is the forum-default answer for IoT dashboards — and it's half an answer. Here's the honest comparison: what the DIY stack does better, what it quietly doesn't do at all, and what four self-hosted services really cost against one serverless deploy. Ask a forum how to dashboard your ESP32's data and the reflex answer is Grafana with InfluxDB. It's a good reflex — both are excellent, open-source, battle-hardened tools. It's also half an answer: neither speaks to a device, and the missing half is where the real work and the real maintenance live. This page weighs the whole thing honestly — including the cases where the DIY stack is exactly what you should build. nodrix's position in the comparison: the four capabilities the stack assembles — ingest, storage, display, alerts — plus the one it can't (device control), in a single open-source deploy on **your own Cloudflare account**, with nothing to operate. ## What "Grafana + InfluxDB" actually means Grafana charts what lands in a database. InfluxDB is the database. Neither includes a path from a microcontroller, so the real deployment is a stack: 1. **An MQTT broker** (usually Mosquitto) for the boards to publish to, 2. **A collector** (Telegraf, Node-RED, or a hand-written bridge) moving broker → database, 3. **InfluxDB** storing the series, 4. **Grafana** on top — plus a host for all four, TLS in front of them, updates, and backups. Each piece is great. The sum is a distributed system you now administer, and its integration points — topic naming, retention policies, datasource auth — are yours to design and to debug at each version bump. ## Stack vs nodrix, honestly | | Grafana + InfluxDB (+ broker + collector) | nodrix | |---|---|---| | Visualization depth | Exceptional — plugins, multi-source, transformations | Purpose-built IoT widgets | | Query power | Flux/InfluxQL/SQL, full analytics | Read API: state + time-series | | Device ingest | You assemble (broker + bridge) | Built in: HTTPS/WebSocket + Arduino library | | Device control (downlink) | Not offered — build your own | Built in: toggle/slider widgets → `NODRIX_WRITE` | | Alerting | Grafana Alerting (strong, data-side) | Trigger → condition → action, device-aware | | Services to operate | Four, plus host, TLS, backups | Zero — serverless on your Cloudflare account | | Cost shape | VPS or home server + your hours | Cloudflare usage; hobby scale typically free | | Open source | Yes (per component) | Yes (MIT, one stack) | ## When the DIY stack is the right call - **The data already lives in databases.** Grafana across your Postgres, Prometheus, and Influx instances is its home game; no IoT platform touches it there. - **You need real query power** — window functions, joins across sources, transformations. If your project is analysis, Flux and SQL beat any widget config. - **You already run the infrastructure.** A homelab with Mosquitto and Influx humming has paid the ops cost; adding one more dashboard is nearly free. - **Visualization is the product.** For wall-mounted, deeply customized displays, Grafana's plugin ecosystem is unmatched. ## When nodrix fits better - **Devices are the point.** Boards connect with a few lines — `Nodrix.send` up, `NODRIX_WRITE` down — with no broker, no topic scheme, no bridge to write. - **You want control, not just charts.** A toggle on the dashboard flips the relay. In the DIY stack that feature simply does not exist until you build it. - **Zero ops is the feature.** One click deploys to your Cloudflare account; there is no VM to patch, no broker to restart, no backup cron. The stack's four services are four things that can page you. - **Alerts should know about devices.** "When `temperature` crosses 30, Telegram me" is one automation — not a query, a rule, a contact point, and a notification policy. ## The cost accounting people skip The DIY stack's software is free; the system costs a server (a VPS bill or a home machine's power and presence) and, more honestly, your hours: version bumps across four components, certificate renewals, the broker that stopped after a power cut, the disk Influx filled. None of it is hard; all of it recurs, whether or not the project still excites you. The serverless trade is exactly that line item deleted: nodrix runs on Cloudflare's infrastructure under your account, sized so hobby telemetry sits in the free plan. The trade-back is flexibility — you can't ssh into it, tune retention policies, or bolt arbitrary plugins onto it. That's the honest shape of the choice: **their power, your hours** versus **fewer knobs, zero hours**. ## Split it: devices here, analysis there The two aren't exclusive. A clean architecture for heavy-analysis projects: nodrix owns the device layer — ingest, live dashboard, control, alerts — and everything it stores stays reachable through the read API (one token, plain JSON: current state and time-series). Grafana, a notebook, or a script pulls from that API when you want the deep dive. You run zero device infrastructure and still get the query power on demand. ## The bottom line If your project is fundamentally about querying and visualizing data you already have, build the Grafana stack — it's the best there is at that. If your project is about *hardware you want to see and control from anywhere*, the DIY stack hands you a systems-administration hobby on top of your electronics hobby. [Deploy nodrix](https://nodrix.live/guides/deploy-nodrix-cloudflare), point [one board at it](https://nodrix.live/guides/esp32-https-cloud), and keep the soldering iron as the only thing you maintain. ### FAQ **Q: Can Grafana show live IoT sensor data?** Yes — once the data is in a database it can query. That 'once' is the whole comparison: Grafana has no device-facing ingest and no device protocol, so an IoT setup needs something between the board and the database, usually an MQTT broker plus Telegraf or a custom bridge. Grafana is the display layer of a stack, not the stack. **Q: Can I control a device from a Grafana dashboard?** Not in any built-in way — Grafana is read-only by design. It visualizes and alerts on data; it has no concept of writing state back to a device. The day your project wants a toggle that flips a relay, you're building an ingest-plus-command service yourself. Downlink is the sharpest single difference in this comparison: in nodrix a toggle widget writes a variable and the board's handler fires. **Q: Isn't the DIY stack more powerful than nodrix?** At visualization and querying — genuinely yes. Grafana's plugin ecosystem, multi-source dashboards, and query languages are in a different league than any IoT platform's built-in charts, nodrix included. The question is whether your project needs that power, and needs it enough to operate a broker, a database, a collector, and Grafana itself. Most maker telemetry is a dozen series and a threshold alert — the power goes unused while the maintenance doesn't. **Q: Can I use Grafana with nodrix instead of choosing?** Yes, and it's a sensible split for heavy analysis: nodrix handles devices, live dashboards, control, and alerts, while every reading stays queryable behind the read API — one token, JSON out. Point any external tool at it, Grafana included via a JSON API datasource. You keep the zero-ops device layer and borrow Grafana's query power when you actually need it. --- ## Guide: Open-source IoT dashboards in 2026: what actually works for makers URL: https://nodrix.live/guides/open-source-iot-dashboard Category: concept Most 'best open-source IoT platform' lists are written for factories, not makers. Here's the maker's-eye view: what an IoT dashboard actually needs to do, which open-source options genuinely deliver it, what each one costs to operate, and when a serverless deploy beats them all. Search for "open-source IoT dashboard" and the results are written for someone else. The typical list compares industrial middleware — rule engines, OPC-UA gateways, Kubernetes charts — and never mentions a microcontroller. Some still recommend tools that have been dormant for years. If what you actually have is an ESP32 and a sensor, you're left translating factory-floor comparisons into maker terms. This page is that translation. It lays out what an IoT dashboard genuinely has to do, then walks through the open-source options a maker would actually shortlist — including where each one is the wrong answer. ## What an IoT dashboard actually has to do "Dashboard" undersells the job. Four capabilities separate a real IoT platform from a chart on a web page: - **Ingest** — an open protocol a $5 board can speak directly (HTTP, WebSocket, or MQTT), with authentication that isn't a cloud SDK. - **Live display** — gauges, charts, maps that update as data arrives, not on refresh. - **Downlink** — a way to send state back: a toggle on the dashboard that flips a relay. This is the one most "dashboard" tools silently lack. - **Logic** — thresholds, schedules, alerts routed to where you actually look (Telegram, Slack, Discord, email), editable without redeploying anything. Hold every candidate against those four and the crowded field thins fast. ## The DIY stack: Grafana + InfluxDB (+ broker + glue) The forum-default answer. Grafana is a world-class visualization layer and InfluxDB a fine time-series store — and together they cover exactly half the job. There's no device protocol (you'll add an MQTT broker and a bridge, or write an ingest service), and no downlink at all: Grafana is read-only by design, so the day you want a toggle, you're building a control plane from scratch. Even Grafana's own ecosystem concedes the setup-and-maintenance burden is the tax. **Right when:** visualization is the entire requirement, data already lands in a database, and you enjoy running the stack. **Wrong when:** you want to control anything, or when four services to patch is four more than the project deserves. This stack gets [its own full weighing](https://nodrix.live/guides/nodrix-vs-grafana-influxdb). ## The self-host heavyweight: ThingsBoard CE The most complete open-source IoT platform, full stop — device management, a rule engine, dashboards, multi-tenancy. The cost is operational: it's a Java application with PostgreSQL and a message broker underneath, which means a real server, real RAM, and someone (you) patching it. Note that its hosted cloud has no free tier, so "free ThingsBoard" specifically means self-hosting. **Right when:** you have a home server and industrial-grade requirements. **Wrong when:** the platform would be the heaviest thing in the project — [the full comparison](https://nodrix.live/guides/thingsboard-alternative) is the honest version of this trade. ## The flow-wiring toolkit: Node-RED Node-RED is a joy for wiring logic — but it's a component, not a platform. Out of the box there's no data store, no device registry, and the dashboard is an add-on; the usual deployment pairs it with a broker, a database, and Grafana, at which point you're operating the DIY stack with a nicer editor. It shines as glue around a platform rather than as the platform. ## The different animal: Home Assistant Home Assistant is magnificent — at its actual job, which is being a local hub for off-the-shelf smart-home gear. It's not built to be a cloud telemetry backend for custom hardware: remote access means a subscription or reverse-proxy work, and its data model orbits home automation, not fleets of sensors. [Home Assistant vs nodrix](https://nodrix.live/guides/home-assistant-vs-nodrix) draws the line properly — plenty of people correctly run both. ## The zombie recommendations A surprising share of "best open-source dashboard" content still lists projects that stopped moving years ago — Freeboard is the recurring example: dormant repo, hosted service gone, still ranked in roundups. The tell for this whole category: check the commit history and the issue tracker before you check the feature list. An unmaintained dashboard is a security liability with widgets. ## The serverless option: nodrix nodrix is our entry in this field, and its position is specific: all four capabilities in one deploy, with **no server to operate**. It's open source (MIT) and deploys in one click to your own Cloudflare account — Workers, Durable Objects, D1 — so there's no VPS, no Docker Compose, no patching schedule. Devices speak plain HTTPS/WebSocket (an Arduino library covers ESP32/ESP8266; anything else can use raw HTTP), dashboards are drag-and-drop with live widgets including toggles and sliders that write back to the board, and automations route alerts to Telegram, Slack, Discord, email, SMS, or any webhook. Data stays in your tenancy behind a read API. The honest trade: it's serverless-shaped. If you need MQTT specifically, an on-LAN-only system, or industrial protocol gateways, the heavyweights above earn their weight. For the actual maker case — custom boards, live dashboards, control, alerts, zero ops — the serverless shape is the point. ## The decision, compressed | You want | Pick | |---|---| | Charts over an existing database, read-only | Grafana (+ InfluxDB) | | Industrial feature set, own server, ops appetite | ThingsBoard CE | | Visual glue logic around another platform | Node-RED | | A local hub for store-bought smart-home devices | Home Assistant | | Device-to-dashboard-to-device, zero servers | [nodrix](https://nodrix.live/guides/deploy-nodrix-cloudflare) | One rule outranks the table: prefer the tool whose whole stack you're willing to operate. Every open-source IoT dashboard is free software; the difference between them is how much infrastructure each one quietly asks you to own. Picking the platform is really picking your ops burden — choose the one whose answer is a number you'll still accept in a year. ### FAQ **Q: What's the best open-source IoT dashboard for an ESP32 project?** For a maker project, the shortlist is honest: nodrix if you want dashboards, device protocol, and automations in one deploy with nothing to operate; ThingsBoard CE if you have a server and want the industrial feature set; Grafana with InfluxDB if visualization is the whole requirement and you don't need to control devices. The rest of the tools on typical 'best of' lists are either industrial middleware or business-metrics dashboards that never met a microcontroller. **Q: Is Grafana an IoT dashboard?** Grafana is a superb visualization layer, but it only displays: it charts what lands in a database, and it has no device protocol, no way to send a command back to a board, and no concept of a device at all. An IoT dashboard needs an ingest path and a downlink. Grafana can be the display half of a DIY stack — it just can't be the whole thing. **Q: Can I self-host an IoT platform for free?** The software is free; the operating isn't. A self-hosted stack costs a VPS or home server, plus the recurring patching, backups, and TLS renewals that keep it healthy. The serverless variant moves that cost to effectively zero for hobby scale: deploy once to your own Cloudflare account and there's no machine to maintain. **Q: Whatever happened to Freeboard?** Freeboard still gets recommended by older 'open-source dashboard' roundups, but the project has been effectively unmaintained for years — the repo is dormant and the hosted service is gone. It's the clearest sign a list you're reading wasn't written by anyone who tried the tools: check the commit history before adopting anything in this space. --- ## Guide: A Particle alternative you own — open-source, on your Cloudflare account URL: https://nodrix.live/guides/particle-alternative Category: comparison Particle was acquired by Digi International in January 2026 and is being folded into an OEM business. For Wi-Fi makers weighing their options, nodrix is an open-source alternative you deploy to your own Cloudflare account — no subscription, no vendor cloud, plain HTTPS/WebSocket. In January 2026, Digi International acquired Particle for $50 million and began folding it into its OEM Solutions business. The platform keeps running, but the direction is now set by enterprise device programs, not the community Particle itself puts at a quarter-million developers — the people who grew up on Spark Cores, Photons, and Argons. If you're one of them and reassessing, the honest first question isn't "what replaces Particle" — it's which Particle you were using. nodrix replaces one of them well: the Wi-Fi one. It's open source (MIT), you **deploy it to your own Cloudflare account** in one click, and devices talk plain HTTPS/WebSocket — telemetry up, control writes down, dashboards, automations, and a read API, all in your tenancy with no vendor cloud to be acquired out from under you. ## The two Particles Particle is really two products under one SDK: - **A managed cellular fleet platform** — SIMs and carrier relationships across hundreds of networks, Device OS, OTA updates, fleet health. This is what Digi bought, it's genuinely good, and there is no drop-in open-source substitute. If your devices live on cellular in the field, nodrix is not your answer, and this page won't pretend otherwise. - **A friendly Wi-Fi prototyping cloud** — `Particle.publish` from a Photon or Argon on your bench, a console to watch events, functions you call remotely, webhooks into the rest of the internet. This is how most makers actually used Particle, and it's the part that maps cleanly onto nodrix. ## Particle vs nodrix, honestly | | Particle | nodrix | |---|---|---| | Model | Commercial platform, subscription | Open-source (MIT); you deploy it to your own Cloudflare | | Owned by | Digi International (since Jan 2026) | You — it runs in your account | | Where data lives | Particle's cloud | Your Cloudflare account (single-tenant) | | Connectivity | Cellular (managed SIMs) + Wi-Fi | Any board that speaks HTTPS/WebSocket | | Hardware | Particle boards + Device OS | Bring your own — ESP32, ESP8266, Pico W, anything | | Uplink | `Particle.publish` events | `Nodrix.send` telemetry (auto-creates variables) | | Downlink | `Particle.function`, variables | `NODRIX_WRITE` handlers over WebSocket or polling | | OTA updates | First-class, fleet-wide | On the roadmap; cloud-side logic changes need no reflash | | Dashboards | Console; build your own UI | Drag-and-drop web dashboards, embeddable widgets | | Automations | Webhooks, integrations | Visual trigger → condition → action, run at the edge | | Pricing | Subscription tiers | No license; Cloudflare usage (hobby scale: free plan) | ## When Particle is still the better choice - Your devices are on **cellular**. Managed SIMs, carrier fallback, and fleet connectivity are the hard part of that world, and Particle does it properly. - You depend on **fleet OTA** — staged firmware rollouts across hundreds of field units. - You're an **OEM building a product line** and the Digi direction is a feature for you, not a concern: enterprise support contracts and a hardware-to-cloud vendor relationship. ## When nodrix fits better - Your boards are on **Wi-Fi** — the bench, the house, the workshop, the campus — and the cellular machinery was never the part you used. - You want **out of the acquisition business entirely**: the stack is MIT-licensed and runs in your own Cloudflare account, so there is no platform owner whose strategy can change your project. - You want **costs that track usage, not seats or devices** — no subscription, no per-device fee. - You'd rather have **dashboards and automations included** than build a UI against a console. ## Moving a project across The firmware shape survives the move — Particle's model of events up, functions down maps directly: ```cpp #include NODRIX_WRITE("led") { // was: Particle.function("led", ...) digitalWrite(LED_PIN, value.asBool()); } void setup() { pinMode(LED_PIN, OUTPUT); Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); } void loop() { Nodrix.run(); static unsigned long last = 0; if (millis() - last >= 30000) { last = millis(); Nodrix.send("temperature", readTemp()); // was: Particle.publish("temperature", ...) } } ``` The hardware usually moves too: Particle boards are built around Device OS and the Particle cloud, so the pragmatic path is a standard ESP32-class board — a few dollars, the same Arduino toolchain, and no platform assumptions baked into the silicon. The full firmware walkthrough, TLS pinning included, is in [Connect an ESP32 over HTTPS](https://nodrix.live/guides/esp32-https-cloud). Webhook-style glue — "when this event, call that service" — recreates as trigger-condition-action automations with Slack, Discord, Telegram, email, or plain HTTP actions. ## The bottom line If Particle's cellular fleet machinery is your product's backbone, stay and watch how the Digi integration lands. If Particle was your friendly Wi-Fi cloud, the acquisition is a good moment to own the stack instead: deploy nodrix to your Cloudflare account, point one ESP32 at it, and the part of Particle you actually used is yours now, in your own account. ### FAQ **Q: What happened to Particle?** Digi International acquired Particle in January 2026 for $50 million and is integrating it into its OEM Solutions business. Particle's platform continues to operate — this is a change of ownership and direction, not a shutdown — but the center of gravity is now enterprise and OEM device programs rather than the maker community Particle grew up with. **Q: Is there an open-source alternative to Particle?** For the Wi-Fi side of what Particle does — telemetry, remote control, dashboards, webhooks-style automations — yes: nodrix is open source (MIT) and deploys to your own Cloudflare account, so there's no vendor cloud in the loop at all. There is no like-for-like open-source replacement for Particle's managed cellular connectivity; that part of Particle is genuinely hard to substitute. **Q: Can I keep using my Particle hardware with nodrix?** Particle boards are engineered around Device OS and the Particle cloud, and that pairing is most of their value. The practical migration is to move the project, not the board: standard ESP32-class hardware costs a few dollars, and the firmware shape carries over — Particle.publish becomes Nodrix.send, and a Particle.function becomes a NODRIX_WRITE handler. **Q: Does nodrix do over-the-air firmware updates like Particle?** Not today — OTA updates are on the roadmap. Particle's OTA and fleet tooling are first class, and if you're updating firmware across a deployed fleet regularly, that's a real reason to stay. nodrix's design reduces the pressure somewhat: dashboards, automations, thresholds, and alert channels all live in the cloud and change without reflashing, so the firmware itself can stay a thin, stable contract. **Q: What does nodrix cost compared to a Particle plan?** nodrix has no license or subscription — you deploy it to your own Cloudflare account and pay Cloudflare for usage, which for hobby and small-fleet Wi-Fi workloads typically sits within the free plan. Particle is a commercial subscription platform; you're paying for managed connectivity, OTA, and fleet tooling. Which is 'cheaper' depends entirely on whether you need those managed services. --- ## Guide: How to update a nodrix instance: one rebuild, nothing to migrate URL: https://nodrix.live/guides/update-nodrix Category: concept Updating a self-hosted nodrix deployment is one button, not a migration project: the app tells you when a release is out, one rebuild pulls it in, and schema changes apply themselves. Here's exactly how the update path works, how to check your version, and how to roll back. The quiet fear of self-hosting is the second year: the update you postpone because it might mean migrations, config drift, or an evening of reading upgrade notes. nodrix's update path is built to delete that fear. Your instance tells you when a release is out, one rebuild brings it in, schema changes apply themselves, and your data never enters the blast radius. This guide covers the whole loop: how your deployment relates to the upstream project, how to know an update exists, how to apply it, and what to do in the rare case one misbehaves. ## How your deployment actually relates to upstream When you used the Deploy to Cloudflare button, it didn't fork the nodrix codebase into your GitHub account. It created a small **deploy carrier** — a repo holding little more than your `wrangler.toml`, the file with your D1, R2, KV, and Durable Object resource IDs. The code isn't in there at all. Instead, every time Cloudflare's Workers Builds runs a build for your instance, the build step pulls the **latest published nodrix release** from the upstream repository, lays it over the carrier, preserves your `wrangler.toml`, and builds that. Your clone is configuration; the code is always a released version of upstream. Two properties fall out of this design, and they're the whole update story: - **Updating is just rebuilding.** There is no fork to sync, no upstream remote to merge, no conflict to resolve. Any new build of your Worker is, by construction, the newest release. - **Nothing updates without you.** A release on our side changes nothing in your account. Your instance runs exactly what it ran until you trigger a build — the update is always your action, on your schedule. ## Knowing an update exists You have three signals, in decreasing order of convenience: - **The app tells you.** Open **Settings** in your instance: the **Version & updates** panel shows the running version, the commit and build time behind it, and checks upstream for the latest published release. If there's something newer, it says **Update available** and shows you what it is. The check is polite by design — results are cached in your instance's KV for a few minutes and revalidated conditionally, so it stays well inside GitHub's rate limits without any token. - **Watch the repository.** On GitHub, watch the nodrix repo with **Watch → Custom → Releases** and you'll get a notification (or an entry in the releases Atom feed, if you're an RSS person) the moment a version is published — no code noise, releases only. - **Check the changelog.** [The changelog](https://nodrix.live/changelog) lists every release with what changed. Worth a skim before updating anyway: it's how you find out an update includes something you've been waiting for. Releases are versioned semantically — features bump the minor version, fixes bump the patch — so the version string itself tells you roughly how much changed. ## Applying the update From the **Version & updates** panel, the update button takes you straight to your Worker's **Builds** page in the Cloudflare dashboard — sign in, hit **Retry build** on the latest build, and Cloudflare rebuilds your instance. The rebuild pulls the newest release, and a few minutes later the deploy goes live. Back in Settings, your instance rechecks itself and the panel flips from **Update available** to **Up to date** on its own — if it's still showing stale after the build finishes, that's your cue to look at the build log. That's the entire procedure for a button-deployed instance: no terminal, no git, no downtime beyond the atomic swap of Worker versions. If you deployed manually from a full clone instead — some people prefer owning the whole pipeline — updating is the git-native version of the same thing: ```bash git pull # bring your clone up to the release you want bun install bun run deploy:platform # build + deploy the worker with your wrangler.toml ``` Same result, different trigger. Everything else in this guide — migrations, data safety, rollback — applies identically. ## What happens during an update Knowing the anatomy makes the button easier to trust: - **Your configuration survives.** The build preserves your `wrangler.toml` — the resource IDs written on day one — before overlaying the new source, and restores it after. Your bindings never drift. - **Schema changes apply themselves.** Database migrations ship bundled inside the Worker, and an auto-migrator applies any pending ones at runtime. There's no `wrangler d1 migrations` step, no ordering to think about, and migrations are additive — they extend the schema rather than destroying data. - **Your data isn't part of the build.** Telemetry, dashboards, users, tokens, automations — all of it lives in D1, R2, and Durable Object storage in your account. A build produces a new Worker and web bundle; it doesn't read or write any of that. - **The swap is atomic.** Cloudflare cuts traffic over to the new Worker version when the deploy completes. Devices reconnect their WebSockets automatically — the same reconnect logic they use for any network blip — and HTTP-polling devices never notice at all. ## If an update misbehaves The honest section, because "rarely" isn't "never": - **Roll back from Cloudflare.** Your Worker's deployment history lives in the dashboard; rolling back to the previous deployment restores the prior version in one action. Because migrations are additive, the older Worker runs fine against the newer schema. - **Read the build log.** A failed build never replaces your running instance — the old version keeps serving. The log on the Builds page says what went wrong, and retrying after a transient failure (a network hiccup during the upstream fetch, say) usually resolves it. - **Check the release notes.** If a release ever needs something from you — which the design works hard to avoid — its notes on the releases page and [the changelog](https://nodrix.live/changelog) are where that would be said plainly. ## The cadence worth adopting There's no forced pace — an instance that runs untouched for six months keeps working, and the update prompt just waits. But the design rewards a simple habit: when Settings says **Update available**, take the two minutes. Small, frequent updates mean each one carries little change, release notes stay skimmable, and a rollback — should you ever need one — steps back over one release instead of ten. The update path was built to be boring; using it often keeps it that way. ### FAQ **Q: Will updating nodrix wipe my dashboards or telemetry?** No. An update replaces only the code — the Worker and the web app. Your data lives in your account's D1 database, R2 bucket, and Durable Objects, none of which a rebuild touches, and your wrangler.toml with its resource IDs is preserved across every build by design. Schema changes ship inside the new Worker and apply themselves without dropping data. **Q: How do I check which version my instance is running?** Open Settings inside your instance — the Version & updates panel shows the running version, the commit it was built from, when it was built, and whether the upstream project has published something newer. It's the same check the update prompt uses, so what you see there is the answer. **Q: Do I need to run database migrations when I update?** No. Migrations are bundled into the Worker at build time and a runtime auto-migrator applies any pending ones — there's no wrangler command to run and no step to forget. This is deliberate: an update path with a manual migration step is an update path people skip. **Q: Why is my instance still on the old version right after a release?** Because deployments pull the latest release at build time, not continuously — a new release doesn't push itself into your account. Your instance keeps running exactly what it has until you trigger a rebuild, which then picks up the newest published release. That's a feature: nothing about your deployment changes without you pressing the button. **Q: Can I roll back if an update misbehaves?** Yes, from Cloudflare's side: the Worker keeps its deployment history in the dashboard, and you can roll back to the previous deployment there. Schema migrations are additive, so a rolled-back Worker runs happily against the newer schema. If you ever hit a release that needs more than that, its release notes will say so. --- ## Guide: Build a DIY smart home with an ESP32 and your own cloud URL: https://nodrix.live/guides/esp32-smart-home-automation Category: project · Board: ESP32 A complete ESP32 smart-home build: switch lights and appliances through relays, control them from anywhere on one private dashboard, and let scenes, schedules, and a sunset trigger run the house — no hub, no broker, on your own Cloudflare account. A smart home is really two things: switches you can throw from anywhere, and rules that throw them for you. The usual DIY route bolts those onto a hub you keep alive in a closet and a broker you have to secure. This build skips both. An ESP32 switches the lights and appliances through relays, and every decision — the dashboard, the scenes, the schedules, the sunset trigger — lives in nodrix on **your own Cloudflare account**. The board's whole job is to flip relays when it's told to and report what state they're in. Nothing about the house is compiled into it, so you add a room, retime the porch light, or build a "Goodnight" scene from the dashboard, and the firmware you flashed once never changes. ## The idea: your house, your cloud, no hub Put the automation logic on the ESP32 and every change means reflashing, every rule is invisible, and the board can't tell you a relay stuck on. Split it the other way: - **The device switches and reports** — it listens for `light_living`, `light_bedroom`, `light_porch`, and `fan`, and echoes each relay's real state back. That contract almost never changes. - **The cloud holds the logic** — scenes, schedules, the sunset trigger, and any condition are edited in nodrix and take effect immediately, no reflash. - **The cloud holds the controls** — one dashboard drives every relay from any phone or laptop, on the home network or off it. ## What you'll build - A **dashboard** with a toggle per light and appliance, reachable from anywhere. - A **porch light that follows the sun** — on at dusk, off in the morning, no timer to reset. - A **Goodnight scene** that turns the house off in one tap, and again on a schedule. - **State that stays honest** — each toggle reflects the relay's actual position, even after a reboot or a reconnect. ## What you'll need - An **ESP32** dev board (any common DevKit variant). - A **relay module** — a 4- or 8-channel, **opto-isolated** board. Match the channel count to how many circuits you're switching. - The loads: **light fixtures, LED strips, a fan, or smart plugs**. Prefer low-voltage loads while you're learning; leave mains wiring to a qualified electrician. - Jumper wires, and a **5V supply** for the relay board if it draws more than the ESP32 can source. - The **Arduino IDE** with the ESP32 board package and the **Nodrix** library from the Library Manager (it pulls in ArduinoJson and WebSockets). - A **nodrix instance** with a project and a project token. ## Wiring the relays Each relay is switched by one GPIO. Wire four control lines from the ESP32 to the relay board's inputs, power the board, and share a ground: | From | To | Wire | |------|----|------| | ESP32 GPIO16 | Relay IN1 | Signal (living) | | ESP32 GPIO17 | Relay IN2 | Signal (bedroom) | | ESP32 GPIO18 | Relay IN3 | Signal (porch) | | ESP32 GPIO19 | Relay IN4 | Signal (fan) | | ESP32 5V (VIN) | Relay VCC | Power | | ESP32 GND | Relay GND | Ground | Each relay's **COM** and **NO** terminals go in series with the load's supply — the relay is just a switch in that circuit. GPIO16–19 are safe general-purpose outputs; avoid the strapping pins (GPIO0, 2, 12, 15) for relay control so a relay's power-on state can't hold the ESP32 in boot mode. **Mains voltage is dangerous.** Anything switching household AC must use a properly rated, opto-isolated relay with the mains side fully enclosed and isolated from the ESP32's low-voltage wiring — and in many places that wiring must be done by a licensed electrician. If any of that is uncertain, switch **low-voltage LED strips or a smart plug** instead. The firmware doesn't care what the relay switches. ## The firmware One socket carries the whole house: toggle states come down it the instant you tap the dashboard or a scene fires, and each relay's real state goes back up so the controls never lie. The [nodrix Arduino library](https://github.com/decoded-cipher/nodrix-sdk) holds that socket, acks each command, and reconnects on its own, so the sketch is just four relays and their handlers — the complete version is the [HomeLights example](https://github.com/decoded-cipher/nodrix-sdk/tree/master/examples/HomeLights). ```cpp #include #define WIFI_SSID "your-wifi" #define WIFI_PASS "your-password" #define HOST "nodrix.you.workers.dev" #define TOKEN "tok_your_project_token" const int LIGHT_LIVING = 16; const int LIGHT_BEDROOM = 17; const int LIGHT_PORCH = 18; const int FAN = 19; const int RELAY_ON = LOW; // most relay boards are active-LOW — swap if yours isn't const int RELAY_OFF = HIGH; void setRelay(int pin, const char* var, bool on) { digitalWrite(pin, on ? RELAY_ON : RELAY_OFF); Nodrix.send(var, on); // echo the real state so the dashboard stays honest } NODRIX_WRITE("light_living") { setRelay(LIGHT_LIVING, "light_living", value.asBool()); } NODRIX_WRITE("light_bedroom") { setRelay(LIGHT_BEDROOM, "light_bedroom", value.asBool()); } NODRIX_WRITE("light_porch") { setRelay(LIGHT_PORCH, "light_porch", value.asBool()); } NODRIX_WRITE("fan") { setRelay(FAN, "fan", value.asBool()); } void setup() { int pins[] = { LIGHT_LIVING, LIGHT_BEDROOM, LIGHT_PORCH, FAN }; for (int p : pins) { pinMode(p, OUTPUT); digitalWrite(p, RELAY_OFF); } Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); } void loop() { Nodrix.run(); } ``` Worth understanding rather than copying: - **The echo keeps controls honest.** Reporting state back inside each handler means a toggle shows the relay's true position — a scene, a schedule, or a manual tap can't leave the dashboard out of sync with the wall. Because a handler just sets a pin, a duplicate delivery across a reconnect is harmless, and the library re-applies the last known states so the house comes back the way you left it after a power blip. - **The rest is the library's job.** At-least-once delivery, acking, reconnects, and — for production — `Nodrix.setCACert()` TLS pinning all sit below your handlers; the [downlink](https://nodrix.live/guides/esp32-receive-commands) and [HTTPS firmware](https://nodrix.live/guides/esp32-https-cloud) guides cover them in full. ## Build the dashboard Add the controls in the dashboard editor, each bound to a variable: | Widget | Bind to | Does | |---|---|---| | Toggle | `light_living` | switch the living-room light | | Toggle | `light_bedroom` | switch the bedroom light | | Toggle | `light_porch` | switch the porch light | | Toggle | `fan` | switch the fan | | Value | `light_porch` | show whether the porch light is on | Each toggle writes its variable, the library delivers it to the board, and the relay's echoed state settles the toggle — so the dashboard mirrors the house whether the change came from your thumb, a schedule, or a scene. Controls update live over a hibernating WebSocket, so nothing polls and an idle house costs almost nothing to keep connected. ## Automations that run without you The point of a smart home is the rules you don't touch. In nodrix these are **trigger → condition → action** flows evaluated at the edge — no code on the board. Build them in the automation editor. **Porch light at dusk.** A **sunset trigger** fires at your location's sunset and sets `light_porch` to `on`. A **schedule trigger** at, say, 6:30 in the morning sets it back to `off`. The porch now tracks the seasons on its own — no timer to reset when the days get shorter. **Fan on a schedule.** A schedule trigger can turn the `fan` on before you get home and off overnight. Add a condition later — only if a temperature variable is above a threshold — without rewiring anything; that's the [plant-watering pattern](https://nodrix.live/guides/esp32-automatic-plant-watering) of a sensor reading gating an action. **Goodnight, in one tap.** A **scene** is a saved set of variable states you apply together — `light_living`, `light_bedroom`, and `fan` off, `light_porch` on. Put a scene control on the dashboard to run it when you head to bed, and add a schedule trigger that applies the same scene at 11:30pm as a backstop. Because the board echoes state, every toggle settles to match the scene the moment it runs. Swap a channel — send to Slack or Telegram instead of switching a relay, or add an "only on weekdays" condition — and none of it touches the firmware. ## Control it from anywhere, privately The ESP32 opens the connection **outward** to nodrix, so there's nothing to expose — no port forwarding, no dynamic DNS, no VPN — and it works behind the strictest home router or cellular NAT. Port 443 is open everywhere, so the dashboard runs the house from the next room or another country. It's also yours: nodrix is single-tenant on **your own Cloudflare account**, so the device history, scenes, and schedules stay in your tenancy, not a shared vendor cloud. One project token authorizes the whole project — treat it as a secret and load it from config for anything permanent. ## When the internet drops A smart home has to fail gracefully: - **Wall switches never stop working.** The relays sit alongside the existing switches, so the house is always operable by hand. - **Cloud control pauses, then catches up.** While the link is down the board holds its last state; a command you send meanwhile is queued and delivered at-least-once the moment it reconnects, and automations resume on their own. - **Critical rules belong on the board.** If one routine must run during an outage — a safety cutoff, say — keep that single rule in the firmware and leave the convenience logic in the cloud. ## Going further - **Add a room by repeating.** Flash a second ESP32 with its own token and namespaced variables (`light_kitchen`, `light_garage`); one dashboard shows every board, no firmware change. - **Make it sense the house.** Feed a temperature, motion, or door sensor as telemetry and gate actions on it — fan on when it's warm, porch light on motion after dark. - **Dim instead of switch.** Drive a PWM channel or a dimmer module and bind a **slider** widget to a `brightness` variable for smooth control rather than on/off. - **Voice and presence.** Trigger scenes from an event the firmware emits, or from a phone-presence webhook, so "arriving home" sets the lights without a tap. ## Notes - **No hub, no broker.** The device speaks plain HTTPS and WebSocket; the house logic runs on your Cloudflare account, with nothing to keep alive at home. - **Configurable without reflashing.** Scenes, schedules, the sunset trigger, and every condition are edited in the dashboard — the firmware is flashed once. - **Single-tenant data.** Every state change stays in your own account, queryable through the read API. - **Scales by repeating, not rewriting.** The same sketch runs one room or the whole house; you add boards and variables, never new firmware. ### FAQ **Q: Can I control my ESP32 smart home from anywhere, not just on home Wi-Fi?** Yes. The board holds an outbound connection to nodrix in the cloud, so a toggle on the dashboard reaches it wherever it is — you're not on the same network, and you never open a port or set up a VPN. The device makes the connection outward over HTTPS, which every home router already allows, so it works behind NAT and captive portals. **Q: Do I need a hub or an MQTT broker for a DIY smart home?** No. There's no hub to keep powered and no broker to run or secure. The ESP32 talks straight to nodrix over a WebSocket, and the dashboard, automations, and scenes live in the cloud. The only always-on thing is Cloudflare, which you don't operate. **Q: How many lights or appliances can one ESP32 control?** As many as it has free GPIO pins — a common 4- or 8-channel relay board covers a room or two. Beyond that, flash a second ESP32 with its own token and namespace its variables (light_kitchen, light_garage). One dashboard shows every board at once; the firmware never changes. **Q: Is it safe to switch mains-voltage lights with an ESP32 relay?** Mains wiring is dangerous and, in many places, must be done by a licensed electrician. Use a properly rated, opto-isolated relay module, keep mains conductors enclosed and away from the ESP32's low-voltage side, and if you're unsure, switch low-voltage LED strips or smart plugs instead. The firmware is identical either way. **Q: Will my smart home keep working if the internet goes down?** Your physical wall switches always work — the relays don't remove them. Cloud control and automations pause while the connection is down and resume when it returns, and any command you send meanwhile is delivered once the board reconnects. If a routine must survive an outage, keep that one rule on the board itself. **Q: Does my smart-home data stay private?** It stays in your own Cloudflare account. nodrix is single-tenant and open-source — there's no shared vendor cloud holding your device history, and nothing leaves your tenancy. You hold the one token that authorizes the whole project. --- ## Guide: How to deploy nodrix to Cloudflare: a free-tier setup guide URL: https://nodrix.live/guides/deploy-nodrix-cloudflare Category: concept Deploy nodrix into your own Cloudflare account in a few minutes. Create a free account, run the one-click deploy, and understand the one step that trips people up — why Cloudflare asks for a card even though nodrix runs entirely on the free plan. nodrix deploys with **one click into your own Cloudflare account** — Workers, Durable Objects, D1, R2, and KV, provisioned and built for you, with no server to host. Most people are up and running in a few minutes. Two things trip up first-timers, though, and both are easy to clear up: you need a Cloudflare account, and partway through the deploy **Cloudflare asks for a credit card**. Neither one costs you anything for a normal setup. This guide walks the whole thing start to finish and explains exactly why that card prompt appears — because it's the step that gets people worried they're signing up for a bill, and they're not. ## What you're actually deploying The deploy drops a real, self-contained nodrix instance into **your** Cloudflare tenancy. It's single-tenant: the resources, the data, and the billing are all yours. The project never touches your account. Here's what gets created: | Cloudflare service | What nodrix uses it for | |---|---| | Workers | The app itself — API, dashboard, and static assets | | Durable Objects | Live variable state, dashboard sockets, the scheduler | | D1 | Metadata — users, projects, dashboards, tokens (never telemetry) | | R2 | Telemetry history (the cold store) | | KV | Read cache and JWKS | | Workflows | One-time provisioning on first boot | Every one of these runs on Cloudflare's **free plan**. Keep that in mind when the card prompt shows up — none of this requires a paid plan to work. ## Step 1 — Create a free Cloudflare account If you already have one, skip ahead. If not: 1. Go to [dash.cloudflare.com/sign-up](https://dash.cloudflare.com/sign-up). 2. Enter an email and a password. 3. Confirm the verification email Cloudflare sends. That's it — about two minutes, and **no card is requested at signup**. You now have a Cloudflare account on the free plan, which is all nodrix needs. ## Step 2 — Run the one-click deploy Hit **[Deploy to Cloudflare](https://nodrix.live/go/deploy)**. Cloudflare takes over from there and walks you through a short flow: 1. **Connect a Git account** (GitHub or GitLab). Cloudflare creates a small repository in your account to hold the deployment config — this is how you'll get updates later. 2. **Provision the resources.** Cloudflare creates the D1 database, the R2 bucket, the KV namespace, and the Durable Objects automatically. You don't fill anything in. 3. **Build and deploy.** The build pulls the latest nodrix release and ships it to your Worker. When it finishes, you get a `*.workers.dev` URL — that's your live nodrix instance. ## Step 3 — Why it asks for a card (and why it's not a bill) This is the screen that worries people. Somewhere in the flow, Cloudflare asks you to **add a payment method**, and it can look like you're being pushed onto a paid plan. You're not. The reason is **R2**, Cloudflare's object storage, where nodrix keeps your telemetry history. R2 is the one Cloudflare product that wants a payment method **on file before it will switch on** — even though its free tier covers far more than a maker deployment will ever use. Adding the card is **account verification**, not a charge: - It is **not** a plan upgrade. Your account stays on the free plan. - It is **not** a charge. Nothing is billed for staying inside the free allowance. - It **is** required — R2 won't activate without it, and nodrix needs R2 to store history. Add the card (or PayPal), continue, and the deploy completes. You won't see a charge appear. ## What runs on the free plan, and how much room you get Every service nodrix touches has a free tier, and they're generous. Approximate free-plan limits at the time of writing — see [Cloudflare's pricing](https://developers.cloudflare.com/workers/platform/pricing/) for the current numbers: | Service | Free allowance (roughly) | |---|---| | Workers | 100,000 requests/day | | D1 | 5 GB storage; millions of row reads/day | | KV | 1 GB storage; 100,000 reads/day | | Durable Objects | Included on the free plan; free-plan accounts aren't charged for SQLite storage | | Workflows | Included on the free plan | | R2 | 10 GB-month storage; 1M writes + 10M reads/month; **zero egress fees** | For context: a handful of devices each posting a reading every few seconds is a tiny fraction of those limits. The free tiers exist precisely for deployments this size. ## Will I ever be charged? Honestly: for a maker or small-team setup, **no**. The single thing that could eventually cost money is **R2 storage** — if you accumulated a very large volume of telemetry history, you could cross the 10 GB-month free mark. That's a lot of data points, and it's under your control through retention. A couple of reassurances on the things people specifically worry about: - **Durable Objects.** Cloudflare began billing for Durable Object SQLite storage in January 2026, but that applies only to **Workers Paid** accounts. Free-plan accounts are not charged for it. - **Egress.** R2 has **no egress fees**, so reading your own telemetry back out never costs bandwidth the way S3 would. If you want a hard guarantee, Cloudflare lets you set a [billing notification](https://developers.cloudflare.com/notifications/) so you're alerted long before anything approaches a charge. ## Step 4 — First boot With the deployment live, open your `*.workers.dev` URL: 1. The first visit shows a **Create owner account** page. The first signup becomes the `owner`; after that, registration is closed and the owner invites everyone else. 2. Create a **project** and mint a **project token** from the dashboard. 3. Point a device at it — variables auto-create the moment data arrives: ```bash curl -X POST https://.workers.dev/v1/telemetry \ -H "Authorization: Bearer $NODRIX_TOKEN" \ -H "Content-Type: application/json" \ -d '{"metrics":{"temperature":23.4,"humidity":61}}' ``` A reading lands, a widget appears, and you've got a working IoT backend on infrastructure you own. For the device side in full — including getting commands back to the hardware — see [Connect an ESP32 over HTTPS](https://nodrix.live/guides/esp32-https-cloud). ## Staying up to date Because the deploy created a repo in your Git account, updating is a one-click **Retry build** from the Cloudflare dashboard (Workers → your `nodrix` service), which pulls the latest release. nodrix also flags new versions for you under **Settings → Version & updates** and links you straight there. ## The short version - A Cloudflare account is **free** and takes two minutes; no card at signup. - The deploy provisions everything for you and runs on the **free plan**. - The card prompt is **R2 verification, not a bill** — add it and continue. - A normal deployment lives **well inside the free tiers**, and you own all of it. ### FAQ **Q: Do I need a paid Cloudflare account to run nodrix?** No. Everything nodrix provisions — the Worker, Durable Objects, D1, KV, Workflows, and R2 — runs on the Workers Free plan. There is no nodrix license fee either; it's open source. You only ever pay Cloudflare if your own usage grows past the free tiers, which for a maker or small-team deployment it won't. **Q: Why does Cloudflare ask for a credit card during deploy?** Because nodrix stores telemetry history in R2, Cloudflare's object storage, and R2 is the one product that wants a payment method on file before it switches on — even on its free tier. Adding the card is account verification, not a charge and not a plan upgrade. You won't be billed for staying inside the free allowance. **Q: Will I actually be charged anything?** For a typical maker or small-team workload, no. A handful of devices posting readings every few seconds sits comfortably inside Cloudflare's free tiers across every service nodrix uses. You'd only start to pay if you stored a very large volume of telemetry history in R2, and you control that with retention. **Q: I don't have a Cloudflare account — is it hard to set one up?** No. Sign up at dash.cloudflare.com with an email and password, confirm the verification email, and you're in — about two minutes, and no card is asked for at signup. The card prompt only appears later, during the deploy, when R2 is enabled. **Q: Can I deploy nodrix without putting a card on file at all?** Not for the full stack. R2 stores telemetry history and needs a payment method (card or PayPal) on file before it activates, so a working deployment requires one. It stays a verification step, not a bill — nodrix is built to run inside the free tiers. **Q: Is my data or billing shared with the nodrix project?** No. nodrix is single-tenant and deploys into your Cloudflare account. The resources, the data, and the billing relationship are all yours; the project never sees your telemetry or your Cloudflare account. --- ## Guide: The open-source Adafruit IO alternative you host on your own Cloudflare account URL: https://nodrix.live/guides/adafruit-io-alternative Category: comparison Looking for an Adafruit IO alternative without rate caps or data-retention limits? nodrix is open-source IoT you deploy to your own Cloudflare account — plain HTTPS/WebSocket, dashboards, automations, and a read API, with your telemetry in your own tenancy. Most people searching for an **Adafruit IO alternative** have run into one of three walls: the free tier's data-rate limit, the cap on how long history is kept, or simply wanting their feeds on infrastructure they own rather than a hosted cloud. nodrix is built for exactly that. It's open-source (MIT), and instead of signing up for a feed service you **deploy it to your own Cloudflare account** in one click — your feeds, dashboards, automations, and history all live in your tenancy, with no publish-rate ceiling and no per-account retention window. This is an honest comparison, including where Adafruit IO is the better pick. ## What Adafruit IO gets right Adafruit IO is a joy for learning. The tutorials are some of the best on the internet, the CircuitPython and Arduino libraries are tight, and there's a bundled MQTT broker so an always-on board can publish and subscribe with almost no code. If you're already in the Adafruit hardware ecosystem and want a dashboard this afternoon, it's hard to beat the on-ramp. For a classroom or a first IoT project, that polish is a real feature. What sends people looking is the model: it's a **hosted service** with a free tier that limits how often you can publish, how long your data sticks around, and how many feeds and dashboards you get. None of that is wrong for a freemium product — but it's the thing makers react to when a project outgrows the box. ## Adafruit IO vs nodrix, honestly | | Adafruit IO | nodrix | |---|---|---| | Model | Hosted SaaS (feeds + dashboards) | Open-source; you deploy it to your own Cloudflare | | Where data lives | Adafruit's cloud | Your Cloudflare account (single-tenant) | | Pricing | Free tier; IO+ yearly for higher limits | No license cost; you pay Cloudflare for usage | | Publish rate | Rate-limited on the free tier | No platform-imposed publish floor | | History retention | Capped by tier | Your own D1/R2 — you decide | | Device connection | MQTT + REST, Adafruit IO libraries | Plain HTTPS/WebSocket + optional open library | | Open source | Client libraries yes; platform hosted | MIT, full stack | | Automations | Actions / triggers | Visual trigger → condition → action, run at the edge | | Data access | REST API | Read API: latest state + time-series behind one token | | Mobile app | Web (responsive) | Responsive web (native app planned) | ## When Adafruit IO is the better choice - You want the **bundled MQTT broker** and an always-on board doing frequent pub/sub. - You're teaching or learning, and the **tutorial ecosystem** plus CircuitPython integration is the whole point. - You're comfortably inside the free tier or happy to pay for IO+, and you don't need to own the data layer. If that's you, Adafruit IO is a great answer and the ownership trade isn't worth it. ## When nodrix fits better - You've hit the **data-rate or retention limits** and want headroom that's only bounded by your own Cloudflare usage. - You want **open source and ownership** — your telemetry in your account, never on a third-party cloud. - You want a **device library's** convenience without the lock-in — an optional open Arduino library over a protocol any board can speak, not a vendor library or broker. - You want a **clean read API** to pull data into Grafana or your own app, plus **edge automations** you fully control. ## Moving a feed across The device side is tiny. Wherever your firmware publishes to an Adafruit IO feed, send the reading to nodrix instead — the metric key becomes a variable the first time it's seen: ```cpp #include #include DHT dht(4, DHT11); void setup() { dht.begin(); Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); } void loop() { Nodrix.run(); Nodrix.send("temperature", dht.readTemperature()); // was feed("temperature")->save(t) } ``` Commands come back through a `NODRIX_WRITE` handler — the library polls or holds the control socket and acks for you. The full firmware is in [Connect an ESP32 over HTTPS](https://nodrix.live/guides/esp32-https-cloud). From there you rebuild your blocks as nodrix widgets and recreate any IO actions as trigger-condition-action flows. ## The bottom line If you value the Adafruit ecosystem and a hosted MQTT broker, Adafruit IO is a fine home. If you've outgrown the rate and retention caps — or you simply want open source, ownership, and a usage-based cost model — deploy nodrix to a spare Cloudflare account, point one device at it, and star the repo to follow along. ### FAQ **Q: Is there an open-source alternative to Adafruit IO?** Yes. nodrix is an open-source (MIT) IoT backend you deploy to your own Cloudflare account instead of signing up for a hosted feed service. Adafruit's client libraries are open source, but Adafruit IO itself is a hosted cloud — your feeds, dashboards, and history live on Adafruit's servers. With nodrix the whole stack lives in your tenancy. **Q: What are the Adafruit IO free tier limits?** The free tier caps how fast you can publish (a data-rate limit), how long history is retained, and how many feeds, dashboards, and actions you get; IO+ raises those for a yearly fee. People usually look for an alternative when they hit the data-rate or retention ceiling, or want their data off a third-party cloud. **Q: Do I need the Adafruit IO Arduino library to use nodrix?** You don't need Adafruit's library, and you're not locked to a nodrix one either. An optional open Arduino library removes the boilerplate — NODRIX_WRITE for commands, Nodrix.send for readings — and underneath it's plain HTTPS/WebSocket, so any board or language can POST to /v1/telemetry directly. Nothing is tied to a vendor protocol the way an Adafruit-specific library is. **Q: Does nodrix include an MQTT broker like Adafruit IO?** Adafruit IO bundles an MQTT broker, which is genuinely convenient for always-on, sub-second messaging. nodrix is HTTPS-first with a WebSocket path for instant control; for periodic telemetry and dashboards that's simpler, but if you specifically need a hosted MQTT broker, factor that in. **Q: How do I move a feed from Adafruit IO to nodrix?** Wherever your firmware publishes to an Adafruit IO feed (MQTT publish or the REST /data endpoint), send the same value to nodrix's /v1/telemetry instead — the metric key becomes a variable automatically. Then rebuild your blocks as nodrix widgets and recreate any IO actions as trigger-condition-action automations. --- ## Guide: An Arduino Cloud alternative for any board — open-source, on your own Cloudflare URL: https://nodrix.live/guides/arduino-cloud-alternative Category: comparison Arduino Cloud is polished but tied to the Arduino ecosystem and a hosted freemium plan. nodrix is an open-source alternative for any board that speaks HTTPS — deployed to your own Cloudflare account, no per-device limits, no lock-in. People look for an **Arduino Cloud alternative** for two main reasons: they don't want to be tied to the Arduino ecosystem (boards, IDE, plan limits), or they want an open-source stack they own rather than a hosted freemium service. nodrix answers both. It's open-source (MIT), it runs on **your own Cloudflare account**, and it's **board-agnostic** — anything that can make an HTTPS request talks to it, no SDK or particular board family required. Here's the honest comparison, including where Arduino Cloud is the better choice. ## What Arduino Cloud gets right For Arduino users, Arduino Cloud is genuinely slick. It's woven straight into the Arduino IDE: it generates the sync sketch for you, handles **over-the-air updates**, and its variable model keeps device and dashboard in lockstep with very little code. If you use official Arduino boards and live in that toolchain, it's a low-friction, well-supported path, and the integration is the whole point. The flip side is what sends people looking: it's a **hosted freemium** service (free plan caps Things, compile time, and dashboards), it's **centered on the Arduino ecosystem**, and your data lives on Arduino's cloud. ## Arduino Cloud vs nodrix, honestly | | Arduino Cloud | nodrix | |---|---|---| | Model | Hosted freemium SaaS | Open-source; deploy to your own Cloudflare | | Where data lives | Arduino's cloud | Your Cloudflare account (single-tenant) | | Boards | Arduino-centric (best with official boards) | Any board that speaks HTTPS | | Device code | IDE-generated sync sketch | Plain HTTPS/WebSocket (any language) + optional ESP library | | Pricing | Free plan with limits; paid tiers | No license cost; pay Cloudflare for usage | | Open source | No (platform) | MIT, full stack | | OTA updates | Yes | On the roadmap | | Dashboards | Hosted web + mobile | Responsive web, embeddable widgets | | Automations | Triggers / scheduler | Visual trigger → condition → action at the edge | | Maturity | Mature | Stable (v1.0), actively developed | ## When Arduino Cloud is the better choice - You're **in the Arduino ecosystem** — official boards, the Arduino IDE — and want the tight, generated integration. - **Over-the-air updates** are part of your workflow. - You want a polished hosted service and the free plan (or a paid tier) fits your project. ## When nodrix fits better - You use **mixed or non-Arduino hardware** — ESP32/ESP8266, Pico W, Raspberry Pi, custom — and want one backend for all of it. - You want **open source and ownership**: the stack and the data on your own Cloudflare account. - You don't want **per-device or plan limits**, and prefer costs that track real usage. - You want a **few-line device path** — an open Arduino library on ESP32/ESP8266, or plain HTTPS on anything else — instead of an IDE-locked sync sketch. ## Pointing a board at nodrix No IDE lock-in, and no generated sync sketch. On an ESP32 or ESP8266 the optional nodrix library makes it a few lines — `NODRIX_WRITE` for commands, `Nodrix.send()` for readings; the full firmware is in [Connect an ESP32 over HTTPS](https://nodrix.live/guides/esp32-https-cloud). The part Arduino Cloud can't match is everything else. Any board that speaks HTTPS talks to nodrix directly, no library or particular board family required: POST a reading to `/v1/telemetry` with the standard HTTP client, and pull commands back over `GET /v1/control` or the control WebSocket. An Arduino UNO R4 WiFi, a Nano 33 IoT, a Pico W, or a Python script on a Pi all speak the same open protocol — one backend, every board. ## The bottom line nodrix doesn't do OTA today — it's on the roadmap. If the Arduino toolchain integration and over-the-air updates are central to how you work right now, Arduino Cloud earns its place. If you want an open-source, board-agnostic backend you own outright, deploy nodrix to a Cloudflare account, point a board at it, and star the repo to follow along. ### FAQ **Q: Is there an alternative to Arduino Cloud that isn't tied to Arduino boards?** Yes. nodrix is board-agnostic: anything that can make an HTTPS request — ESP32, ESP8266, Raspberry Pi Pico W, a Raspberry Pi, an Arduino, or a Python script — can send telemetry and receive commands. There's no required SDK, IDE, or board family, though an optional open Arduino library gives ESP32/ESP8266 a few-line path if you want it. nodrix is open-source (MIT) and deploys to your own Cloudflare account. **Q: Is Arduino Cloud free?** Arduino Cloud is freemium: the free plan caps things like the number of Things, compile time, and dashboards, and paid plans lift those limits. nodrix has no license cost and no per-device limit; you pay Cloudflare for the usage of your own deployment. **Q: What does Arduino Cloud do better than nodrix?** Integration. If you live in the Arduino IDE and use official boards, Arduino Cloud is tightly woven in — automatic sketch generation, over-the-air updates, and a clean variable-sync model. nodrix doesn't replace that ecosystem; it trades it for being open-source, board-agnostic, and self-owned. **Q: Can I use nodrix with an Arduino board?** Yes — an Arduino with Wi-Fi (e.g. UNO R4 WiFi, Nano 33 IoT, MKR WiFi) talks to nodrix over plain HTTPS using the standard WiFi/HTTPClient libraries, exactly like an ESP32. You just point it at your endpoint instead of Arduino Cloud. **Q: Does nodrix do over-the-air firmware updates like Arduino Cloud?** Over-the-air firmware updates are on the roadmap. nodrix handles telemetry, dashboards, automations, and control writes today, with OTA planned. If OTA is essential to your workflow right now, factor that in; otherwise, stay connected as we add it. --- ## Guide: The open-source Blynk alternative that runs on your own Cloudflare account URL: https://nodrix.live/guides/blynk-alternative Category: comparison Looking for a Blynk alternative? nodrix is open-source IoT you deploy to your own Cloudflare account — no per-device pricing, no hosted cloud holding your data, plain HTTPS/WebSocket with dashboards, automations, and a read API. Most people searching for a **Blynk alternative** want one of three things: out from under per-device limits and template costs, their telemetry on infrastructure they actually control, or a fully open-source stack they can read and own. nodrix is built around exactly that. It's open-source (MIT), and instead of signing up for a hosted service you **deploy it to your own Cloudflare account** in one click. Your devices, dashboards, automations, and data all live in your tenancy — no broker, no per-device pricing, and no third-party cloud holding your readings. This is an honest comparison, including where Blynk is the better pick. ## What Blynk gets right Blynk earned its popularity. The mobile app is genuinely polished, the quick-start is fast, and the community and tutorial base are enormous — if you want to point a phone at a microcontroller this weekend, it just works. Its client libraries are open source and cover a wide range of boards. For a consumer-style project where a clean mobile app is the product, that's a real strength. What changed for a lot of makers is the model: the current platform (Blynk.IoT) is a **hosted commercial service**, the free tier is capped on devices and templates, and your data lives on Blynk's cloud. None of that is wrong — it's a SaaS — but it's the thing people are reacting to when they go looking for an alternative. ## Blynk vs nodrix, honestly | | Blynk | nodrix | |---|---|---| | Model | Hosted SaaS | Open-source; you deploy it to your own Cloudflare | | Where data lives | Blynk's cloud | Your Cloudflare account (single-tenant) | | Pricing | Freemium; paid plans scale by devices/usage | No license cost; you pay Cloudflare for usage | | Open source | Client libraries yes; platform hosted | MIT, full stack | | Device connection | Blynk libraries (vendor protocol) | Open Arduino library + plain HTTPS/WebSocket | | Dashboards | Native mobile app + web | Responsive web, drag-and-drop | | Widgets | App widget set | Framework-agnostic Web Components, embeddable anywhere | | Automations | Automations + events | Visual trigger → condition → action, run at the edge | | Data access | HTTPS API | Read API: latest state + time-series behind one token | | Native mobile app | Yes | Responsive web (native app planned) | | Maturity | Mature, large community | Stable (v1.0), actively developed | ## When Blynk is the better choice - You want a **first-class native mobile app** out of the box, with no front-end work. - You'd rather **not deploy or operate anything** — a hosted service is a feature, not a cost. - You're within the free tier or happy with the per-device pricing, and you don't need to own the data layer. If those are you, Blynk is a fine answer, and the ownership trade isn't worth it for your project. ## When nodrix fits better - You want **open source and ownership** — the stack on your own Cloudflare, your telemetry in your tenancy, your data never leaving your account. - You're allergic to **per-device pricing** and want costs that track actual Cloudflare usage. - You want the few-line convenience of a **device library** — `NODRIX_WRITE`, `Nodrix.send` — but over an **open protocol** you can drop anytime, not a vendor SDK or a broker. - You want a **clean read API** to plug telemetry into Grafana, a React app, or a Raspberry Pi screen, plus **edge automations** you fully control. ## Moving an ESP32 across The device side is small, and the shape is familiar: Blynk's `BLYNK_WRITE` handler becomes `NODRIX_WRITE`, and `Blynk.virtualWrite` becomes `Nodrix.send` — over an open protocol running on your own Cloudflare, not Blynk's cloud. ```cpp #include #include DHT dht(4, DHT11); NODRIX_WRITE("led") { // Blynk's BLYNK_WRITE(V1), minus the vendor cloud digitalWrite(LED_PIN, value.asBool()); } void setup() { dht.begin(); Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); } void loop() { Nodrix.run(); Nodrix.send("temperature", dht.readTemperature()); // was Blynk.virtualWrite(V2, t) } ``` The library holds the control socket (or polls) and acks for you — the full firmware is in [Connect an ESP32 over HTTPS](https://nodrix.live/guides/esp32-https-cloud). From there you rebuild your widgets on a nodrix dashboard and recreate any Blynk automations as trigger-condition-action flows. ## The bottom line nodrix is the right call if you value open source, data ownership, and a usage-based cost model — with your dashboards on responsive web today and a native app on the roadmap. The useful move is to deploy it to a spare Cloudflare account, point one device at it, and star the repo to follow along. ### FAQ **Q: Is there an open-source alternative to Blynk?** Yes. nodrix is an open-source (MIT) IoT backend you deploy to your own Cloudflare account rather than signing up for a hosted service. Devices talk plain HTTPS or WebSocket, and the dashboards, automations, and data all live in your own tenancy. Blynk's client libraries are open source too, but its current platform (Blynk.IoT) is a hosted commercial service, not something you self-host. **Q: Why do people look for a Blynk alternative?** Usually one of three reasons: the free tier's device and template limits, wanting their telemetry on infrastructure they control instead of a third-party cloud, or wanting a fully open-source stack. If a polished mobile app and zero setup matter most, Blynk is hard to beat — the alternatives win on ownership and cost model. **Q: Can I self-host a Blynk alternative?** That's the idea behind nodrix — but rather than running a server, you one-click deploy it onto Cloudflare's serverless platform (Workers, Durable Objects, D1, R2). There's no broker, database, or VM to operate; you pay Cloudflare for what you use, and there's no per-device license. **Q: Does nodrix have a mobile app like Blynk?** A native mobile app is on the roadmap. Today, nodrix dashboards are responsive web and the widgets are framework-agnostic Web Components you can embed anywhere — including in your own app shell. If a first-class native app is essential right now, factor that in; otherwise, stay connected, as it's planned. **Q: How do I move an ESP32 from Blynk to nodrix?** Swap Blynk's virtual-pin writes for Nodrix.send(), and Blynk's BLYNK_WRITE handlers for NODRIX_WRITE — the same few-line shape, but over an open protocol on your own Cloudflare instead of a vendor cloud. The optional nodrix Arduino library handles Wi-Fi, control, and acks; underneath it's plain HTTPS/WebSocket you can use directly. Then rebuild your widgets on a nodrix dashboard and recreate any Blynk automations as trigger-condition-action flows. --- ## Guide: A Datacake alternative without per-device pricing — open-source, on your Cloudflare URL: https://nodrix.live/guides/datacake-alternative Category: comparison Want a Datacake alternative that drops per-device pricing and keeps your data in your own tenancy? nodrix is open-source IoT you deploy to your own Cloudflare account — low-effort dashboards, automations, and a read API, billed as Cloudflare usage. People searching for a **Datacake alternative** are usually weighing one thing against its strengths: **per-device pricing** as a fleet grows. Datacake is a slick low-code platform, but the bill scales with devices and your data lives on its cloud. nodrix is the opposite trade — it's open-source (MIT) and you **deploy it to your own Cloudflare account** in one click, with no per-device license and every reading in your own tenancy. This is an honest comparison, including where Datacake is the better pick. ## What Datacake gets right Datacake nails low-code. The dashboard builder is fast, device templates make onboarding hardware easy, and the **LoRaWAN / The Things Network integration** is genuinely turnkey — for LPWAN sensor fleets that's a big head start. It also offers white-labeling and a rule engine, so for a reseller or a client deployment it's a capable, polished product you don't have to assemble. What sends people looking is the **cost model and ownership**: billing scales by device, and your telemetry sits on Datacake's infrastructure rather than your own. ## Datacake vs nodrix, honestly | | Datacake | nodrix | |---|---|---| | Model | Low-code hosted SaaS | Open-source; you deploy it to your own Cloudflare | | Where data lives | Datacake's cloud | Your Cloudflare account (single-tenant) | | Pricing | Per device | No license cost; you pay Cloudflare for usage | | Open source | No | MIT, full stack | | LoRaWAN / TTN | Turnkey integration | Via gateway/network-server webhook to /v1/telemetry | | Dashboards | Low-code builder | Drag-and-drop, embeddable Web Components | | Rules / automation | Rule engine | Visual trigger → condition → action at the edge | | Device connection | HTTP / MQTT / LoRaWAN | Plain HTTPS/WebSocket + optional open library | | Data access | API | Read API: latest state + time-series behind one token | ## When Datacake is the better choice - Your project is **LoRaWAN-first** and you want turnkey TTN integration and device templates. - You need **white-labeling** and a low-code builder for client or reseller deployments. - Per-device pricing is **fine for your fleet size** and you'd rather not own the stack. If that's you, Datacake is a strong, purpose-built answer. ## When nodrix fits better - You want to **drop per-device pricing** for costs that track actual Cloudflare usage. - You want **open source and ownership** — your telemetry in your account, not a third-party cloud. - Your devices speak **plain HTTPS/WebSocket** (or forward LoRaWAN payloads via webhook), and you want a device library without the lock-in — or none at all. - You want a **read API** for Grafana or your own app, plus **edge automations** you fully control. ## Moving a device across If your hardware already POSTs to Datacake's HTTP endpoint, repoint it at nodrix — each metric becomes a variable automatically: ```cpp // HTTPS POST https://nodrix.you.workers.dev/v1/telemetry // Authorization: Bearer tok_your_project_token // { "metrics": { "temperature": 23.4, "soil": 38 } } -> 204 ``` For LoRaWAN, set your network server's HTTP integration (the webhook that fires on uplink) to send the decoded payload to the same `/v1/telemetry` endpoint. Commands flow back via `GET /v1/control` or the control WebSocket — the full firmware is in [Connect an ESP32 over HTTPS](https://nodrix.live/guides/esp32-https-cloud). ## The bottom line If LoRaWAN and low-code white-labeling are the job, Datacake is a fine tool. But if per-device pricing is the friction — or you want open source, ownership, and a usage-based cost model — deploy nodrix to a Cloudflare account, point a device (or a network-server webhook) at it, and own the stack end to end. ### FAQ **Q: Is there an open-source alternative to Datacake?** Yes. nodrix is open-source (MIT) and you deploy it to your own Cloudflare account instead of paying per device on a hosted plan. Datacake is a low-code SaaS billed by device; nodrix has no per-device license and your data stays in your own tenancy. **Q: Does nodrix support LoRaWAN like Datacake?** Datacake's tight LoRaWAN / The Things Network integration is one of its real strengths. nodrix is HTTPS/WebSocket-first; a LoRaWAN device reaches it through a gateway or network-server webhook that forwards the decoded payload to /v1/telemetry. If turnkey LoRaWAN is central to your project, weigh that. **Q: How do I migrate from Datacake to nodrix?** Point your device's HTTP integration (or your LoRaWAN network-server webhook) at nodrix's /v1/telemetry instead of Datacake's HTTP endpoint — each metric becomes a variable automatically. Then rebuild dashboards and recreate Datacake rules as trigger-condition-action automations. --- ## Guide: Build an ESP32 automatic plant watering system URL: https://nodrix.live/guides/esp32-automatic-plant-watering Category: project · Board: ESP32 A complete ESP32 self-watering build: calibrate a capacitive soil sensor, switch a pump safely through a relay, and let the cloud run the watering logic over a single WebSocket — closed-loop, broker-free, on your own Cloudflare account. A capacitive sensor and a small pump are all a plant needs to water itself. The hard part is deciding when to water without over-watering, doing it reliably when Wi-Fi flakes, and being able to retune later without unplugging anything. This build puts the sensor and pump on an ESP32 and keeps every decision in the cloud, so the firmware you flash once never changes. The board does two things: report a moisture number, and run the pump when told. The rules, dashboard, alerts, and safety checks live in nodrix on **your own Cloudflare account** — no broker to operate, no server to keep alive, no data leaving your tenancy. ## The idea: a dumb device and a smart cloud Bake the watering logic into the ESP32 and every tweak means reflashing — and the board can't tell you it's been watering hourly because the sensor came loose. Split it the other way: - **The device reports and reacts** — it sends `soil_moisture` and watches for a `pump` flag. That contract rarely changes. - **The cloud holds the logic** — thresholds, burst length, and the trigger-condition-action flow are edited in nodrix and apply on the next reading, no reflash. - **The cloud holds the memory** — every reading is stored and charted, so a misbehaving sensor is obvious at a glance. ## What you'll build - A live **soil-moisture gauge** and a rolling **24-hour chart** of the watering rhythm. - **Automatic watering**: the pump runs when the soil dries out and stops once it recovers. - A **pump toggle** for watering on demand, and a **value** readout of the current pump state. - A **Telegram alert** each time the plant is watered, and a scheduled **reservoir check**. ## What you'll need - An **ESP32** dev board (any common DevKit variant). - A **capacitive** soil-moisture sensor — not the resistive forks, which corrode within weeks. - A **5V pump**, a **relay module or logic-level MOSFET**, tubing, and a small reservoir. - A **separate 5V supply** sized for the pump's stall current — don't run the pump off the board. - The **Arduino IDE** with the ESP32 board package and the **Nodrix** library from the Library Manager (it pulls in ArduinoJson and WebSockets). - A **nodrix instance** with a project and a project token. ## Reading the soil A capacitive sensor outputs a voltage that tracks moisture — high in dry air, low when wet. The ESP32 reads it on a 12-bit ADC (0–4095), with two gotchas: - **Use an ADC1 pin.** ADC2 is shared with the Wi-Fi radio, so an analog read there returns nonsense once connected. **GPIO34** is on ADC1, input-only, and has no internal pull-up — ideal for a sensor output. - **Average the samples.** Raw readings jitter and are least accurate near the rails; averaging a handful smooths it. Calibration is two numbers: the raw value in open air (`DRY`) and fully submerged (`WET`). Everything between maps to a 0–100% scale. Those anchors shift with soil type and pot size, so calibrate in the setup you'll actually run — "30% moisture" only means anything relative to your `DRY` and `WET`. ## Wiring The sensor's analog output goes to **GPIO34**. The pump draws far more current than a GPIO can supply, so the ESP32 only switches a relay or MOSFET on **GPIO26**, and the pump runs from its own 5V supply — never off a board pin. | From | To | Wire | |------|----|------| | Soil sensor AOUT | ESP32 GPIO34 | Signal | | Soil sensor VCC | ESP32 3V3 | Power | | Soil sensor GND | ESP32 GND | Ground | | ESP32 GPIO26 | Relay IN | Signal | | Relay VCC | ESP32 5V (VIN) | Power | | Relay GND | ESP32 GND | Ground | | 5V supply + | Relay COM | Power (pump) | | Relay NO | Pump + | Power (switched) | | Pump − | 5V supply − | Ground | The sensor and relay share the ESP32's ground; the pump's separate supply feeds only the relay's load side. Tie the grounds together so the control signal has a common reference. ## Switching the pump safely A pump is an inductive, current-hungry load, and treating it like an LED kills boards. Three rules: - **Never drive it from a GPIO.** A pin sources a few milliamps; a pump pulls hundreds, more at stall. Switch it with a relay or logic-level MOSFET on the separate supply. - **Add a flyback diode** across the pump, cathode to **+**, to absorb the reverse spike when the motor switches off. - **Check relay polarity.** Many modules are active-low. The firmware below assumes active-high (`HIGH` = on); invert the two `digitalWrite` calls if yours differs. ## The control loop The loop is deliberately gentle, because soil and water are slow: 1. The ESP32 reports `soil_moisture` every few minutes. 2. Below **30%**, the automation sets `pump` to `on`. 3. The ESP32 runs a **short, capped burst**. 4. Above **60%**, the automation sets `pump` to `off`. The two thresholds give hysteresis: a single setpoint would make the pump chatter on sensor jitter, so turning on at 30% and only off at 60% builds a dead band that lets the soil wet through between decisions. And the burst is capped, not "run until wet" — water takes time to reach the probe, so it pours briefly, waits, and measures again. All of it lives in nodrix, so you retune from the dashboard without reflashing. ## The firmware One socket carries everything: moisture goes up, pump commands come down. The [nodrix Arduino library](https://github.com/decoded-cipher/nodrix-sdk) owns the socket, the acks, and the reconnects, so the sketch is only your logic — read the sensor, run one capped burst per command, and report the pump state back. ```cpp #include 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"; const int SENSOR_PIN = 34; const int PUMP_PIN = 26; const int DRY = 3200; // raw ADC reading in dry air — calibrate const int WET = 1300; // raw ADC reading submerged — calibrate const int BURST_MS = 5000; int readMoisture() { long sum = 0; for (int i = 0; i < 16; i++) { sum += analogRead(SENSOR_PIN); delay(10); } return constrain(map(sum / 16, DRY, WET, 0, 100), 0, 100); } NODRIX_WRITE("pump") { if (!value.asBool()) { digitalWrite(PUMP_PIN, LOW); return; } digitalWrite(PUMP_PIN, HIGH); delay(BURST_MS); digitalWrite(PUMP_PIN, LOW); Nodrix.send("pump", false); Nodrix.event("watered"); } void setup() { pinMode(PUMP_PIN, OUTPUT); digitalWrite(PUMP_PIN, LOW); Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); } void loop() { Nodrix.run(); static unsigned long lastReading = 0; if (millis() - lastReading >= 5UL * 60 * 1000) { lastReading = millis(); Nodrix.send("soil_moisture", readMoisture()); } } ``` Worth understanding rather than copying: - **The burst is self-limiting.** It's a synchronous `digitalWrite` / `delay` / `digitalWrite`, so a pulse always ends even if Wi-Fi drops mid-pour — there's no path that latches the pump on. And because a command is delivered at-least-once, a "water now" sent while the board was offline still arrives on reconnect; a short burst repeating now and then just waters a little more. - **HTTP works too.** For a wake-report-sleep node, `Nodrix.beginHTTP()` with `Nodrix.poll()` reports the reading and collects any pending command per wake — same handler. - **Pin TLS before you ship.** `Nodrix.begin()` connects encrypted but unverified for the first run; add `Nodrix.setCACert()` for production, covered in [Connect an ESP32 over HTTPS](https://nodrix.live/guides/esp32-https-cloud). ## Build the dashboard Add four widgets, each bound to a variable: | Widget | Bind to | Shows | |---|---|---| | Gauge | `soil_moisture` | current moisture, 0–100% | | Chart | `soil_moisture` | the 24-hour watering rhythm | | Toggle | `pump` | manual water-now switch | | Value | `pump` | current pump state | The gauge and chart update live over a hibernating WebSocket. The toggle writes the same `pump` flag the automation uses, so manual and automatic watering share one path, and the device's echoed state keeps the toggle and value honest. The chart is the diagnostic that earns its place. A tuned system settles into a sawtooth — slow dry-down, sharp recovery, repeat. A flattening curve means water isn't reaching the probe (empty reservoir, slipped tubing); a sawtooth that's suddenly twice as fast usually means the sensor has shifted in the pot. ## Add the automation One automation runs the whole thing — two triggers routed by `if-variable` conditions. Build it in the automation editor. **Trigger 1 — a new `soil_moisture` reading:** - **Below 30** → set `pump` to `on`, then send a Telegram message like "Soil at {{value}}% — watering now." - **Above 60** → set `pump` to `off`. - **Between 30 and 60**, nothing happens — that gap is the hysteresis dead band. **Trigger 2 — a schedule (say, twice a day):** - **If `soil_moisture` is still below 30** → send a Telegram warning to check the reservoir. Soil that stays dry after watering usually means an empty tank or slipped tubing. Swap the integration for Slack, Discord, or SMS without touching the conditions. And because the firmware emits a `watered` event on every pour, you can branch off that event later without touching the board. ## Reliability and failure modes A self-watering system fails unattended, so design for two cases: - **The cloud is unreachable.** No command arrives, so the pump stays off — the safe default — and any in-flight burst finishes on its own. If watering must survive an outage, add a local fallback that runs a short burst on a low reading without the cloud. - **The reservoir runs dry.** Pumping air does nothing and can damage some pumps. The scheduled check catches moisture staying low despite watering, and the flat chart confirms it. ## Going further - **Run it on a battery.** Swap the always-open socket for a wake-report-sleep cycle over HTTP and a single cell lasts months — see [ESP32 battery life](https://nodrix.live/guides/esp32-deep-sleep-battery). - **Add plants by repeating.** Send `soil_moisture_2`, `soil_moisture_3`, and so on; each auto-creates its own variable. Add a gauge per plant and duplicate the automation — no firmware change. - **Dose by volume.** Replace the fixed burst with a measured one (flow rate × time, or a flow sensor) so each watering delivers a repeatable amount. - **React to the `watered` event.** Keep a watering log, post a daily summary, or escalate if waterings spike — all as event-triggered automations, none of it on the board. ## Notes - **No broker or server to run.** The device speaks plain HTTPS and WebSocket; nodrix runs on your Cloudflare account. - **Configurable without reflashing.** Thresholds, burst length, messages, and channels are all set in the dashboard — the firmware is flashed once. - **Single-tenant data.** Every reading stays in your own account, queryable through the read API. - **Scales by repeating, not rewriting.** The dumb-device contract is what lets one sketch run a windowsill or a greenhouse. ### FAQ **Q: Why does the watering logic live in the cloud instead of on the ESP32?** So you can change it without reflashing. Thresholds, burst length, alert channels, and the whole trigger-condition-action flow are edited in nodrix and take effect on the next reading. The board keeps one job — report a number, act on a flag — which is the part you don't want to be reprogramming every time you re-pot a plant or swap a sensor. **Q: How do I calibrate the dry and wet readings?** Read the raw analog value with the sensor in open air, then again fully submerged in water (or in soil you've just saturated), and put those two numbers in DRY and WET. They drift with soil type, pot size, and even the sensor batch, so calibrate in the exact setup you'll run. Everything downstream — the 0-100% scale, the 30% and 60% thresholds — is relative to those two anchors. **Q: Can the ESP32 switch the pump directly from a GPIO pin?** No. A GPIO sources a few milliamps; a pump wants hundreds. Drive the pump through a relay or a logic-level MOSFET powered from its own supply, share grounds, and put a flyback diode across the motor. Wiring a pump straight to a pin browns out the board at best and kills it at worst. **Q: Why two thresholds (30% and 60%) instead of one?** Hysteresis. With a single setpoint the pump would chatter on and off every time the reading jittered across the line. Turning on below 30% and only off again above 60% gives the soil room to actually wet through before the system reconsiders — the same reason a thermostat has a dead band. **Q: What happens if Wi-Fi or the cloud is unreachable?** The board reports nothing and receives no pump command, so it does nothing — the safe default. The capped burst is synchronous, so even if Wi-Fi drops mid-pour the pulse still finishes and stops on its own. If watering must survive an outage, add a local fallback that runs a short burst on a low reading without waiting for the cloud. **Q: Why GPIO34 for the sensor specifically?** It's an ADC1 pin, and ADC1 keeps working while Wi-Fi is on. The ESP32's ADC2 pins are borrowed by the radio, so an analog read there returns garbage once you're connected. GPIO34 is also input-only with no internal pull-up, which is exactly what an analog sensor output wants. **Q: Is the project token safe baked into the firmware?** Treat it as a secret. It scopes to this one project and all traffic is HTTPS, but don't commit it to a public repo — load it from NVS or a config file for anything real, and rotate it if it leaks. --- ## Guide: ESP32 battery life: deep sleep + cloud telemetry that lasts months URL: https://nodrix.live/guides/esp32-deep-sleep-battery Category: hardware · Board: ESP32 Make a battery-powered ESP32 sensor run for months while still reporting to the cloud. Deep sleep structure, RTC-memory Wi-Fi caching, a real power budget, and the dev-board traps that quietly kill battery life. A battery-powered ESP32 that reports to the cloud can run for **months** on a single 18650 cell — but only if it sleeps correctly. Battery life on the ESP32 is almost entirely a Wi-Fi problem: the radio dominates the power budget, so the whole game is to stay asleep, wake briefly, connect fast, send, and sleep again. Get the wake short and rare and the idle current low, and the math works out to a season or more between charges. Get any of those wrong and the same hardware dies in days. This guide is about the power side specifically: where the energy goes, the deep-sleep structure that makes it possible, connecting fast enough to matter, a real worked budget, and the dev-board traps that quietly wreck battery life. For the telemetry and control code itself, see [Connect an ESP32 over HTTPS](https://nodrix.live/guides/esp32-https-cloud). ## Where the power goes Three states matter, and they're orders of magnitude apart: | State | Current (typical) | When | |---|---|---| | Deep sleep | ~10 µA (bare module) | between readings — almost all the time | | Active + Wi-Fi | ~120-160 mA | the few seconds it's connecting and sending | | Peak TX burst | up to ~500 mA | brief spikes during transmit | The lesson reads straight off the table: a few seconds at 150 mA costs roughly the same as **hours** of deep sleep. Lifetime is set by how short and how infrequent the active bursts are — not by the sleep time. That's why "connect fast" is the highest-leverage optimization there is, and why a chatty board that stays awake "just in case" is the classic battery killer. ## The deep-sleep shape Deep sleep changes how you write the entire sketch. On wake the ESP32 powers the radio back up, **wipes RAM, and re-runs `setup()` from the top** — `loop()` effectively never runs. Anything that must survive a nap lives in **RTC memory**, declared with `RTC_DATA_ATTR`. So the structure is: everything happens in `setup()`, ending with a call to sleep; `loop()` stays empty. ```cpp void setup() { // wake → connect → read → send → poll → sleep } void loop() {} // intentionally empty for a deep-sleep design ``` ## Connect fast: cache the association The single biggest win is skipping the Wi-Fi channel scan. On the first connect, cache the BSSID and channel in RTC memory; on every wake after, hand them back to `WiFi.begin()` so it reconnects directly. A static IP skips DHCP for another saved second. Both shave seconds off the radio-on time, which — per the table above — is where the battery actually goes. ```cpp RTC_DATA_ATTR bool rtcValid = false; RTC_DATA_ATTR uint8_t rtcBssid[6]; RTC_DATA_ATTR int32_t rtcChannel; void fastConnect() { WiFi.mode(WIFI_STA); // Optional: a static IP skips DHCP entirely. // WiFi.config(ip, gateway, subnet, dns); if (rtcValid) WiFi.begin(WIFI_SSID, WIFI_PASS, rtcChannel, rtcBssid, true); // cached path else WiFi.begin(WIFI_SSID, WIFI_PASS); // first boot uint32_t start = millis(); while (WiFi.status() != WL_CONNECTED && millis() - start < 8000) delay(50); // bounded wait if (WiFi.status() == WL_CONNECTED) { memcpy(rtcBssid, WiFi.BSSID(), 6); rtcChannel = WiFi.channel(); rtcValid = true; } else { rtcValid = false; // bad cache → force a full scan next time } } ``` The bounded wait matters as much as the cache: never block forever on `WiFi.status()`. A bad night where the AP is unreachable should cost one capped attempt, not a flat battery. ## The full sketch Wake, connect, read the sensor, POST one reading, grab any queued command while the radio is up, and sleep on a timer. That's the entire life of a battery node. ```cpp #include #include #include #include #define SLEEP_MINUTES 15 const char* HOST = "nodrix.you.workers.dev"; // bare host, no https:// const char* TOKEN = "tok_your_project_token"; DHT dht(4, DHT11); void setup() { dht.begin(); fastConnect(); // RTC-cached association (above) if (WiFi.status() == WL_CONNECTED) { Nodrix.beginHTTP(HOST, TOKEN); // reuses the live connection Nodrix.send("temperature", dht.readTemperature()); Nodrix.flush(); // POST the reading Nodrix.poll(); // apply queued commands while we're up } esp_sleep_enable_timer_wakeup((uint64_t)SLEEP_MINUTES * 60ULL * 1000000ULL); esp_deep_sleep_start(); // execution ends here; wakes into setup() } void loop() {} ``` `Nodrix.poll()` is the downlink — it fetches queued writes, runs your `NODRIX_WRITE` handlers, and acks. It's worth doing every wake since the radio is already on; see [Receive commands on an ESP32](https://nodrix.live/guides/esp32-receive-commands). A sleepy device can't be pushed to instantly, but commands queued in the cloud land on the next wake. ## Do the math Plug your numbers in; here's a 15-minute cycle on a 2500 mAh cell: - **Per wake:** ~120 mA × 3 s = 0.1 mAh. - **Wakes/day:** 96 (every 15 min) → ~9.6 mAh/day from active time. - **Sleep/day:** a bare module at 10 µA adds ~0.24 mAh/day; a typical dev board at 0.2-0.3 mA adds ~5-7 mAh/day. - **Total:** ~10 mAh/day (bare) to ~16 mAh/day (dev board). - **Lifetime:** 2500 mAh ÷ 10-16 ≈ **160-250 days** — call it 5-8 months. The spread is almost entirely sleep current, which is why the board you choose matters more than shaving another reading. Stretch the interval to 30-60 minutes and you cross a year; drop to one minute and you're back to weeks. ## Squeeze more - **Pick the right board.** The biggest variable is idle current. A board with a USB-serial chip, a power LED, and a thirsty regulator can sit at hundreds of µA in "deep sleep." For real battery builds use a low-sleep board or power the bare module. - **Give the sensor its warm-up.** Many sensors need tens to hundreds of ms after power-up before a valid reading — budget it rather than reading `nan`. - **Buffer offline.** If a send fails, stamp the reading with your own `ts` (NTP-synced) and send it next wake, so a dropped network doesn't lose data. - **Mind the strapping pins.** Avoid GPIO 12 on the classic ESP32 (a strapping pin that can stop the board booting); safe wake/IO pins on the base chip include 4, 13, 14, 25, 26, and 27. - **Wake on more than a timer.** `esp_sleep_enable_ext0/ext1_wakeup` lets a reed switch, PIR, or button wake the board on an event instead of polling on a clock. ## Notes - **It's a Wi-Fi budget, not a sleep budget.** Optimize the radio-on time first; everything else is rounding error. - **HTTPS fits deep sleep perfectly.** There's no session to keep alive — wake, POST, poll, sleep. No broker, no persistent socket. - **Runs on your account.** Readings land in a nodrix instance on your own Cloudflare account, ready to chart, alert on, or read back through the API. ### FAQ **Q: How long can an ESP32 run on a battery while sending data?** With deep sleep between readings, a single 18650 cell can last months. A ~3-second wake every 15 minutes spends almost all its time drawing microamps in sleep, not the ~120-160 mA of an active Wi-Fi radio — so the radio's brief bursts, not the idle time, set the lifetime. **Q: What actually drains the battery?** The Wi-Fi radio, by a wide margin. Associating and transmitting pulls ~120-160 mA (with brief peaks higher); deep sleep is microamps. Battery life is almost entirely about how briefly and how rarely the radio is on, which is why connecting fast matters more than anything else. **Q: Why does my dev board drain fast even in deep sleep?** Usually the board, not the chip. Many dev boards keep a USB-serial chip, an always-on LDO regulator, or a power LED alive in sleep, turning the ESP32's ~10 µA into hundreds of microamps or more. For real battery builds pick a board designed for low sleep current, or power the bare module directly. **Q: Can a sleeping device still receive commands?** Yes, on its schedule. A deep-sleep device can't be pushed to instantly, but it polls the control endpoint right after it sends telemetry each wake and applies anything queued. Commands wait in the cloud and land on the next wake — seconds to minutes later, not never. **Q: Does deep sleep drop the Wi-Fi connection every time?** Yes — deep sleep powers down the radio and wipes RAM, so each wake reconnects from scratch. The fix is to cache the BSSID and channel (and optionally a static IP) in RTC memory so reconnect skips the scan and DHCP, cutting association from 3-4 seconds to under one. --- ## Guide: Connect an ESP32 to the cloud over HTTPS — a complete guide (no MQTT broker) URL: https://nodrix.live/guides/esp32-https-cloud Category: hardware · Board: ESP32 Push ESP32 sensor data to the cloud and receive commands back with the nodrix Arduino library — plain HTTPS underneath, no MQTT broker. Telemetry, control writes, and months of battery life with deep sleep. **Short version:** an ESP32 can push sensor readings to the cloud with nothing more than a Wi-Fi connection — no MQTT broker, no message queue to babysit. The [nodrix Arduino library](https://github.com/decoded-cipher/nodrix-sdk) wraps the whole thing: readings go up with `Nodrix.send()`, commands come down into a `NODRIX_WRITE` handler, and it's plain HTTPS underneath. This guide builds the full loop and a battery build that runs for months. It targets a nodrix instance on your own Cloudflare account, but the underlying technique works against any HTTPS API. Here is the entire uplink: ```cpp #include Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); Nodrix.send("temperature", 23.4); Nodrix.send("humidity", 61); // The variables show up on your dashboard instantly. ``` That is the part most tutorials stop at. The interesting half — getting a command *back* to the board to flip a relay or change a setpoint — is further down, and it's just as short. ## Should you even use HTTPS? (an honest take) MQTT is the default answer for IoT, and for good reason: on a persistent connection it is lighter per message and naturally bidirectional. But it also means running (or renting) a broker, keeping a socket alive, and handling reconnects. For a huge class of projects that is overkill. Use **HTTPS** when: - Readings are periodic — every few seconds to every few hours, not 50 times a second. - You want zero infrastructure to operate: no broker process, no queue. - The device lives behind awkward networks — corporate Wi-Fi, captive portals, cellular. Port 443 is allowed essentially everywhere; MQTT's 1883/8883 often is not. - You sleep the device between readings (battery sensors) — there is no persistent session to maintain anyway. Stick with **MQTT** when you need sub-second, high-frequency, or many-messages-per-second streams, true server-push with minimal latency, or you are fanning out to thousands of devices where the per-message savings dominate. For a temperature logger, a soil sensor, an energy monitor, or a parking-spot counter, HTTPS is not a compromise — it is the simpler correct choice. ## What you'll need - An **ESP32** dev board. This works on the classic ESP32, ESP32-S3, and ESP32-C3 (and on the ESP8266, which the library also supports). - A sensor. The examples use a BME280 (temperature, humidity, pressure) over I2C, but any reading works. - The **Arduino IDE** (or PlatformIO) with the [ESP32 board package](https://github.com/espressif/arduino-esp32) and these libraries from the Library Manager: **Nodrix**, **ArduinoJson**, and — for the BME280 — **Adafruit BME280** plus **Adafruit Unified Sensor**. - A cloud endpoint. We use a nodrix instance: deploy once to your Cloudflare account, create a project, and mint a **project token** — that token is the device's key. ## The mental model: two variables, two directions Forget topics and payload formats for a second. nodrix models a device as a bag of **variables**: - **Telemetry (up):** `Nodrix.send("temperature", 23.4)`. `temperature` becomes a variable, created automatically the first time it is seen. No schema to declare. - **Control (down):** a dashboard toggle, or one of your automations, queues a **control write** — "set `relay` to `on`". Your `NODRIX_WRITE("relay")` handler runs; the library acks it. One token, both directions. That is the whole protocol surface you need. ## Step 1 — Connect and secure the link `Nodrix.begin()` brings up Wi-Fi and opens the connection. TLS is the one decision to make up front: 1. **Default (insecure)** — traffic is *encrypted*, but you are not verifying *who* you are talking to. Fine for a first run on your own network; **never ship it.** 2. **Pin a root CA** — `Nodrix.setCACert(rootCA)` before `begin()`. Secure and maintainable; you update it only when the CA rotates. Pull the root CA like this and paste the last certificate into a `PROGMEM` string: ```bash openssl s_client -showcerts -connect nodrix.you.workers.dev:443 #include const char* HOST = "nodrix.you.workers.dev"; // bare host, no https:// const char* TOKEN = "tok_your_project_token"; Adafruit_BME280 bme; void setup() { Serial.begin(115200); bme.begin(0x76); // 0x76 or 0x77, per your board Nodrix.setCACert(ROOT_CA); // omit for the insecure default Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); } ``` ## Step 2 — Send readings `Nodrix.send()` stages a metric; they coalesce into one request on the next `run()`. Send as many as you like — each key becomes its own variable: ```cpp void loop() { Nodrix.run(); static uint32_t last = 0; if (millis() - last > 10000) { last = millis(); Nodrix.send("temperature", bme.readTemperature()); Nodrix.send("humidity", bme.readHumidity()); } } ``` Open your dashboard and the `temperature` and `humidity` variables are already there. Drop a **value** or **gauge** widget on them and you are watching live data. Want a trend line? The **chart** widget plots a time window; the **map** widget takes lat/lng if you are tracking something that moves. ## Step 3 — Receive commands back (the half everyone skips) This is where "HTTP can't do downlink" turns out to be a myth. Register a handler for the variable; the library delivers each write, applies it through your code, and acks it so it isn't resent: ```cpp NODRIX_WRITE("relay") { digitalWrite(RELAY_PIN, value.asBool()); } ``` With `Nodrix.begin()` (the always-on WebSocket), writes arrive the instant a widget moves. For a sleepy device use `Nodrix.beginHTTP()` and call `Nodrix.poll()` once per wake to drain the queue. Either way the handler is the same — the library handles at-least-once delivery, acking, and reconnects underneath. ## Step 4 — Make it sip power: deep sleep done right A mains-powered board can just report on a timer. A battery board must **deep sleep** — and deep sleep changes how you write the whole sketch, because the ESP32 wipes RAM on wake and re-runs `setup()` from the top. `loop()` effectively never runs. Anything that must survive a nap goes in **RTC memory** with `RTC_DATA_ATTR`. The single biggest power drain is Wi-Fi association. Cache the BSSID and channel on the first connect and reuse them — this skips the channel scan and cuts reconnect from 3 to 4 seconds down to under a second. Bring Wi-Fi up yourself, then hand the live connection to the library: `beginHTTP` sees you're already connected and skips its own connect. ```cpp #include // deep-sleep API RTC_DATA_ATTR bool rtcValid = false; RTC_DATA_ATTR uint8_t rtcBssid[6]; RTC_DATA_ATTR int32_t rtcChannel; #define SLEEP_MINUTES 15 void fastConnect() { WiFi.mode(WIFI_STA); if (rtcValid) WiFi.begin(WIFI_SSID, WIFI_PASS, rtcChannel, rtcBssid, true); // cached path else WiFi.begin(WIFI_SSID, WIFI_PASS); // first boot uint32_t start = millis(); while (WiFi.status() != WL_CONNECTED && millis() - start < 8000) delay(50); if (WiFi.status() == WL_CONNECTED) { memcpy(rtcBssid, WiFi.BSSID(), 6); rtcChannel = WiFi.channel(); rtcValid = true; } else { rtcValid = false; // force a full scan next time } } void setup() { Serial.begin(115200); bme.begin(0x76); fastConnect(); if (WiFi.status() == WL_CONNECTED) { Nodrix.beginHTTP(HOST, TOKEN); // reuses the live connection Nodrix.send("temperature", bme.readTemperature()); Nodrix.send("humidity", bme.readHumidity()); Nodrix.flush(); // POST the batch Nodrix.poll(); // grab any queued commands while we're up } esp_sleep_enable_timer_wakeup((uint64_t)SLEEP_MINUTES * 60ULL * 1000000ULL); esp_deep_sleep_start(); // execution ends here; wakes back into setup() } void loop() {} // intentionally empty for a deep-sleep design ``` With a roughly 3-second wake every 15 minutes, a single 18650 cell can carry a sensor for months. A few extra wins: prefer a board without a power-hungry USB-serial chip on battery, give the sensor its warm-up time before reading, and avoid GPIO 12 on the classic ESP32 (it is a strapping pin that can stop the board booting). Safe wake and IO pins on the base chip include 4, 13, 14, 25, 26, 27. ## Production checklist - **Verify the certificate.** Set a pinned root CA with `Nodrix.setCACert()` before you deploy anything that matters — the default skips verification. - **Retry on a flaky network.** The library reconnects and re-flushes staged telemetry on its own; for deep-sleep devices, just report again on the next wake. - **Keep the token secret.** The project token is a credential. Do not commit it; load it from config or NVS, and rotate it if it leaks. - **Bound your own waits.** The one blocking spot you own is Wi-Fi association in a battery build — cap it (as above) so a bad night does not drain the cell. ## Troubleshooting - **Connection fails on first bring-up:** usually TLS. Drop `setCACert()` to fall back to the insecure default and confirm the rest works, then re-pin; check the host is the bare name with no `https://` and no trailing slash. - **Handshake fails after it worked:** the server's CA rotated and your pinned root is stale — re-pull it with the `openssl` command above. - **Resets or `Brownout detected`:** Wi-Fi transmit current spikes; power the board from a supply that can deliver about 500 mA, not a marginal USB port. - **Reading is `nan`:** the sensor was not given warm-up time after power-up, or the I2C wiring is off. ### FAQ **Q: Can an ESP32 really talk to the cloud without MQTT?** Yes. Underneath it's an HTTPS POST to one endpoint to send a reading and a GET to fetch queued commands — the library just wraps that. No broker is required for periodic telemetry. **Q: How do I get data back to the ESP32 over HTTP?** Register a handler for the variable with NODRIX_WRITE. The library polls a control endpoint (or holds a WebSocket open while awake), applies each write, and acks it for you. **Q: Is HTTPS too heavy for a microcontroller?** The first TLS handshake costs 1 to 3 seconds. After that it is quick, and for periodic telemetry the cost is irrelevant. Pinning a root CA keeps it both secure and maintainable. **Q: Will HTTPS telemetry drain my battery?** Not with deep sleep. Wake, send, poll, sleep. Cache the Wi-Fi BSSID and channel in RTC memory, hand the live connection to the library, and a single 18650 cell can last months. **Q: Does this lock me into one provider?** No. The pattern is plain HTTPS plus JSON. Here it targets a nodrix instance running in your own Cloudflare account, but any HTTPS API works the same way. --- ## Guide: Receive commands on an ESP32 from the cloud (the downlink, in depth) URL: https://nodrix.live/guides/esp32-receive-commands Category: hardware · Board: ESP32 How to get data back to an ESP32: handle control writes with the nodrix Arduino library over an always-on WebSocket, or poll on each wake for battery devices. The downlink most IoT tutorials skip. Sending a reading **up** is the easy half. The half that trips people up is getting a command back **down**: HTTP is request/response, so how does the cloud tell a device behind home Wi-Fi to flip a relay or change a setpoint? It doesn't, directly. The device asks. It fetches any pending **control writes**, applies them, and acknowledges the ones it handled so they aren't sent again — a pull, not a push, with no broker, static IP, or inbound connection. On an ESP32 or ESP8266 the [nodrix Arduino library](https://github.com/decoded-cipher/nodrix-sdk) runs that whole loop for you: fetch, apply, ack, reconnect. You write a handler per variable and the library calls it whenever the cloud writes that variable. This guide shows that, then explains what it does underneath — at-least-once delivery, idempotency, and acking. ## Two modes, matched to how the device lives The library connects one of two ways. Both share the same handlers and the same token, so you can start with one and switch later without touching the cloud side. | | `begin()` — WebSocket | `beginHTTP()` — poll | |---|---|---| | Latency | instant | your poll interval (seconds) | | Connection | one socket held open | none held; one request per check | | Best for | always-on controllers | sleepy / periodic devices | | Battery | poor unless mains-powered | excellent (sleep between polls) | | Cost when idle | ~zero (Cloudflare hibernates it) | one request per interval | ## Handle a control write A "command" is a **control write** — a pending instruction to set a variable: *`relay` to `on`*. Register a handler for the variable and the library runs it on every write, whether it came from a dashboard toggle, an automation, or the API: ```cpp #include NODRIX_WRITE("relay") { digitalWrite(RELAY_PIN, value.asBool()); } void setup() { pinMode(RELAY_PIN, OUTPUT); Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); // always-on WebSocket } void loop() { Nodrix.run(); // control in, telemetry out, acks, reconnect } ``` `value` coerces the wire value for you — `asBool()`, `asInt()`, `asFloat()`, `asString()` — so a toggle that sends `"on"` and a slider that sends `42` both just work. ## Battery / deep sleep: poll on each wake A sleepy device doesn't hold a socket. Switch to HTTP mode and drain the queue once per wake, right after you report — the board is already connected, so the extra request is nearly free: ```cpp #include // deep-sleep API void setup() { Nodrix.beginHTTP(WIFI_SSID, WIFI_PASS, HOST, TOKEN); Nodrix.send("soil", analogRead(34)); Nodrix.flush(); // POST telemetry Nodrix.poll(); // fetch + apply queued writes, then ack esp_sleep_enable_timer_wakeup(15ULL * 60 * 1000000); esp_deep_sleep_start(); } ``` Same handlers, same acks — a command simply applies on the next wake instead of instantly. ## What the library handles for you The downlink has a few sharp edges, and they're the reason to use the library rather than hand-roll it: - **At-least-once delivery.** A control write stays queued until it's acked and re-delivers on the next connect or poll, so nothing is lost across a nap or a Wi-Fi blip. The library acks every write it hands your code. - **Reconnect and catch-up.** On the socket it reconnects on its own and flushes anything queued while you were gone. - **One connection, both directions.** Telemetry, events, and acks share the socket with control — `Nodrix.send()` and `Nodrix.event()` go up the same pipe. ## Still your job - **Keep handlers idempotent.** At-least-once means you can see the same command twice. Setting a pin is naturally safe; for anything that isn't, act on the desired end-state rather than a toggle. - **Cap physical actions.** Prefer a self-limiting action — a timed pulse over a latch — so a missed "off" can't leave a pump or heater running. ## Notes - **No broker, no inbound connection.** The device only makes outbound HTTPS/WSS requests, so it works behind home routers, captive portals, and cellular NAT — port 443 is open everywhere. - **One token, one project.** The same project token authorizes telemetry, control, and the socket; treat it as a secret and load it from config for anything real. - **Install it.** Arduino Library Manager or PlatformIO; source and the [`LedControl` example](https://github.com/decoded-cipher/nodrix-sdk/tree/master/examples/LedControl) at [github.com/decoded-cipher/nodrix-sdk](https://github.com/decoded-cipher/nodrix-sdk). - **It runs on your account.** The control queue and dashboard live in a nodrix instance on your own Cloudflare account — single-tenant, nothing leaving your tenancy. ### FAQ **Q: Can you push data to an ESP32 over plain HTTP?** Not push, exactly — the device pulls. It polls a control endpoint on an interval and applies any queued writes, which gives near-real-time control without a broker. For instant updates while the board is awake, hold a WebSocket open and the cloud pushes down it. The library does either for you. **Q: How responsive is HTTP polling?** As responsive as your interval. Poll every 2-5 seconds and a dashboard toggle reaches the board in seconds; poll once per wake and a sleepy sensor picks up commands when it next reports. The trade is request volume and battery, not capability. **Q: What happens to a command sent while my device is offline or asleep?** It waits. Control writes are queued and delivered at-least-once: the cloud holds a write until the device acknowledges it, and re-delivers anything outstanding the moment the device reconnects or next polls. Nothing is lost across a nap or a Wi-Fi blip. **Q: Why do I have to acknowledge commands?** You don't, by hand — the library acks each write it delivers to your handler. Acking is how the cloud knows a write landed so it can stop re-sending it; without it the same command keeps coming back. Because delivery is at-least-once, every delivery is acked (even a duplicate), so keep your handler idempotent. **Q: Should I poll or use the WebSocket?** Use the always-on WebSocket (Nodrix.begin) for controllers that need zero-latency writes — on Cloudflare the socket hibernates, so an idle connection costs almost nothing. Use HTTP polling (Nodrix.beginHTTP, then poll each wake) for battery devices that wake, report, and sleep — there's no session to keep alive. --- ## Guide: ESP8266 to the cloud over HTTPS — a live dashboard with no broker URL: https://nodrix.live/guides/esp8266-iot-dashboard Category: hardware · Board: ESP8266 Push ESP8266 sensor data to a cloud dashboard with the nodrix Arduino library — BearSSL under the hood on the 8266's tight RAM, no MQTT broker, control writes back to the board, and the deep-sleep wiring that makes a battery sensor last. An **ESP8266** is more than capable of putting live sensor data on a cloud dashboard over HTTPS — no MQTT broker, no message queue to babysit. The [nodrix Arduino library](https://github.com/decoded-cipher/nodrix-sdk) supports the 8266 directly; it uses **BearSSL** (bundled in the [ESP8266 Arduino core](https://github.com/esp8266/Arduino)) under the hood, which matters because the chip's RAM is tight, so keep payloads small. This guide builds the whole loop on a real backend (nodrix, which deploys to your own Cloudflare account): a reading up, a command back down, and a deep-sleep build that lasts. Variables show up on your dashboard the first time they're seen — no schema to declare. ## The mental model Forget topics and payloads for a second. The board is just a bag of **variables**: - **Telemetry (up):** `Nodrix.send("temperature", 23.4)`; each key becomes a variable. - **Control (down):** a dashboard toggle or an automation queues a write — "set `relay` to `on`". Your `NODRIX_WRITE("relay")` handler runs; the library acks it. One token, both directions. That's the whole protocol surface. ## Step 1 — Connect `Nodrix.begin()` brings up Wi-Fi and opens the connection over BearSSL. Start on the default (encrypted but unverified) to get a green light, then pin a fingerprint for production: ```cpp #include #include const char* HOST = "nodrix.you.workers.dev"; // bare host, no https:// const char* TOKEN = "tok_your_project_token"; DHT dht(D2, DHT11); void setup() { Serial.begin(115200); dht.begin(); Nodrix.begin(WIFI_SSID, WIFI_PASS, HOST, TOKEN); } ``` ## Step 2 — Send readings `Nodrix.send()` stages a metric; they coalesce into one small request on the next `run()`. Keep the set of keys per call modest on this chip: ```cpp void loop() { Nodrix.run(); static uint32_t last = 0; if (millis() - last > 10000) { last = millis(); Nodrix.send("temperature", dht.readTemperature()); Nodrix.send("humidity", dht.readHumidity()); } } ``` Open your dashboard and `temperature` and `humidity` are already there. Drop a **value** or **gauge** widget on them and you're watching live data; the **chart** widget plots a time window. ## Step 3 — Receive commands back "HTTP can't do downlink" is a myth. Register a handler for the variable — the library delivers each write, runs your code, and acks it so it isn't resent: ```cpp NODRIX_WRITE("relay") { digitalWrite(RELAY_PIN, value.asBool()); } ``` With `Nodrix.begin()`, writes arrive the moment a widget moves. For a sleepy device, switch to `Nodrix.beginHTTP()` and call `Nodrix.poll()` once per wake. ## Step 4 — Deep sleep, the ESP8266 way A battery ESP8266 must **deep sleep** between readings, and there's one piece of hardware to get right: **wire GPIO16 to RST**. That jumper is how the chip wakes itself from a timed sleep — without it, `ESP.deepSleep()` puts the board to sleep and it never comes back. ```cpp #define SLEEP_MINUTES 15 void setup() { Serial.begin(115200); dht.begin(); Nodrix.beginHTTP(WIFI_SSID, WIFI_PASS, HOST, TOKEN); Nodrix.send("temperature", dht.readTemperature()); Nodrix.send("humidity", dht.readHumidity()); Nodrix.flush(); // POST the batch Nodrix.poll(); // grab queued commands while awake ESP.deepSleep((uint64_t)SLEEP_MINUTES * 60ULL * 1000000ULL); // wakes via GPIO16 -> RST } void loop() {} // intentionally empty for a deep-sleep design ``` Deep sleep wipes RAM and re-runs `setup()` from the top, so the whole sketch lives in `setup()` and `loop()` stays empty. Keep the awake window short — connect, send, poll, sleep. ## Production checklist - **Pin a fingerprint.** Call `Nodrix.setFingerprint(fp)` before `begin()` to verify the server on the 8266 — the default skips verification, and a full CA store is too heavy for this chip. - **Watch the heap.** Print `ESP.getFreeHeap()` during bring-up; TLS plus a large JSON buffer is the usual cause of a failed request. Keep the number of metrics per send modest. - **Keep the token secret.** The project token is a credential; load it from config, don't commit it. With a short wake every 15 minutes, an ESP8266 sensor reporting to a dashboard you own is a tidy, broker-free build — and the read API behind it means you can pull the same data into Grafana or your own app whenever you want. ### FAQ **Q: Can an ESP8266 do HTTPS to the cloud?** Yes — the nodrix library uses BearSSL (built into the ESP8266 Arduino core). The chip has far less RAM than an ESP32, so use the default (insecure) for a first run, then pin a fingerprint for production. A periodic HTTPS POST to one endpoint is well within its budget. **Q: Do I need MQTT for an ESP8266 dashboard?** No. Underneath it's an HTTPS POST to a single endpoint to send a reading and a GET to fetch queued commands — no broker to run. MQTT is worth it only when you need persistent, sub-second, high-frequency messaging. **Q: How is the ESP8266 different from the ESP32 here?** Same library and the same calls, three practical differences: it uses BearSSL under the hood; it has much less heap, so keep payloads small; and deep sleep needs a physical wire from GPIO16 to RST to wake the board. TLS pinning on the 8266 is a fingerprint (setFingerprint) rather than a CA. **Q: Will HTTPS drain an ESP8266 battery?** Not with deep sleep. Wake, send, poll, sleep. The TLS handshake costs a second or two, which is irrelevant against a 15-minute sleep. Wire GPIO16 to RST and a single cell can carry the sensor for a long time. **Q: Why is my ESP8266 connection returning -1?** Almost always TLS or memory. Try the insecure default to isolate certificate problems, and watch the heap — running out of RAM during the handshake also surfaces as a failed connection. Keep JSON payloads small. --- ## Guide: Home Assistant vs nodrix: local smart-home hub or your own cloud IoT backend? URL: https://nodrix.live/guides/home-assistant-vs-nodrix Category: comparison Home Assistant vs nodrix — they solve different problems. HA is a local home-automation hub for off-the-shelf devices; nodrix is an open-source cloud IoT backend you deploy to your own Cloudflare for custom hardware, remote dashboards, and a read API. Here's how to choose, and how they pair. **Home Assistant vs nodrix** isn't really a head-to-head — they're built for different jobs, and the honest answer for a lot of people is "both." Home Assistant is a **local home-automation hub**: you run it on a box at home and it ties together off-the-shelf smart devices with local control and an enormous integration library. nodrix is an **open-source cloud IoT backend**: you deploy it to your own Cloudflare account, and custom hardware POSTs telemetry over HTTPS to dashboards, automations, and a read API you own. This guide is about choosing the right one — and how they pair. ## What Home Assistant is for Home Assistant is the gold standard for the **local smart home**. If you've got Zigbee bulbs, Z-Wave locks, smart plugs, cameras, and Wi-Fi gear, HA speaks to thousands of them, runs automations locally (no cloud round-trip), keeps your data in your house, and has a polished mobile app and a massive community. For tying together *consumer devices* in one home, nothing else comes close. Its center of gravity, though, is **local and home-shaped**: it expects an always-on machine on your LAN, and reaching it from outside usually means a tunnel, a VPN, or the Nabu Casa cloud subscription. That's perfect for a house, and less aimed at custom hardware fleets reporting from the field. ## What nodrix is for nodrix is for **custom hardware and owned cloud telemetry**. An ESP32 soil sensor, a remote energy monitor, a parking-spot counter, a fleet of devices spread across sites — they POST plain JSON to a backend you deployed on Cloudflare, and you get realtime dashboards reachable from anywhere, edge automations, and a **read API** to pull data into Grafana or your own app. There's no home server to keep online or expose, because it runs at the edge. ## Home Assistant vs nodrix, honestly | | Home Assistant | nodrix | |---|---|---| | Category | Local home-automation hub | Cloud IoT backend for custom hardware | | Runs on | A box at home (Pi / NUC / VM), always on | Cloudflare (Workers, Durable Objects, D1, R2) | | Best for | Off-the-shelf smart-home devices | Custom devices, telemetry, fleets, remote dashboards | | Integrations | Thousands of device integrations | Plain HTTPS/WebSocket — any device; optional ESP library | | Remote access | Tunnel / VPN / Nabu Casa cloud | Public by default (it's already in the cloud) | | Data location | Your home machine | Your Cloudflare account (single-tenant) | | Automations | Local, very deep | Visual trigger → condition → action at the edge | | Read API | Via REST/templates | First-class: latest state + time-series, one token | | Open source | Yes | Yes (MIT) | ## When Home Assistant is the better choice - Your project is the **local smart home** — off-the-shelf Zigbee/Z-Wave/Wi-Fi devices. - You want **local control** with no cloud dependency and a huge integration catalog. - You're happy running and maintaining an **always-on home server**. ## When nodrix fits better - Your hardware is **custom** (ESP32/Pico/LoRaWAN) and you want it reporting to a cloud **you own**. - You need **dashboards reachable from anywhere** without exposing a home box. - You want a **clean read API** for telemetry and a stack with **no machine to keep patched at home**. ## Better together You don't have to pick. A common setup: custom field sensors report to **nodrix in the cloud**, and **Home Assistant pulls that data in** via its RESTful sensor integration against the nodrix read API: ```yaml # Home Assistant configuration.yaml — read a nodrix variable as a sensor rest: - resource: "https://nodrix.you.workers.dev/v1/projects//state" headers: Authorization: "Bearer " scan_interval: 60 sensor: - name: "Field soil moisture" value_template: "{{ value_json.state.soil.value }}" ``` HA owns the local smart home; nodrix owns the cloud telemetry for your custom hardware — each doing the half it's best at. ## The bottom line If you're automating a house full of off-the-shelf devices, run Home Assistant. If you're building custom hardware that needs cloud dashboards, automations, and a read API you own — without standing up and exposing a home server — deploy nodrix to your Cloudflare account. And if you're doing both, let them do what each is good at and bridge them through the read API. ### FAQ **Q: Is nodrix a replacement for Home Assistant?** Not really — they solve different problems. Home Assistant is a local hub for off-the-shelf smart-home devices (Zigbee, Z-Wave, Wi-Fi gear) with local control and a huge integration library. nodrix is a cloud backend for custom hardware: your ESP32/Pico sensors POST over HTTPS to a stack you deploy on your own Cloudflare account, and you get remote dashboards and a read API. Many people run both. **Q: Can I use Home Assistant and nodrix together?** Yes, that's a natural setup. Custom field sensors report to nodrix in the cloud (reachable from anywhere without exposing your home box), and you pull that data into Home Assistant via its REST/RESTful sensor integration using nodrix's read API. HA handles the local smart home; nodrix handles owned cloud telemetry. **Q: Does nodrix need an always-on machine at home like Home Assistant?** No. Home Assistant typically runs on a Raspberry Pi, NUC, or VM you keep online. nodrix is serverless — it deploys to Cloudflare (Workers, Durable Objects, D1, R2), so there's no home box to power, patch, or expose to the internet. --- ## Guide: Raspberry Pi Pico W to the cloud with MicroPython — a live dashboard URL: https://nodrix.live/guides/raspberry-pi-pico-w-iot-dashboard Category: hardware · Board: Raspberry Pi Pico W Send Raspberry Pi Pico W sensor data to a cloud dashboard with MicroPython over HTTPS — no broker. Full code for telemetry with urequests, commands back to the board, the onboard temperature sensor, and an honest note on Pico W TLS. A **Raspberry Pi Pico W** can put live sensor data on a cloud dashboard with a few lines of [MicroPython](https://micropython.org) — no MQTT broker, no SDK. You POST JSON to one HTTPS endpoint and poll a second one for commands. This guide builds the whole loop against a real backend (nodrix, which deploys to your own Cloudflare account), using the Pico W's own onboard temperature sensor so you can run it with no wiring at all. Variables appear on your dashboard the first time they're seen. ## The mental model The board is just a bag of **variables**: - **Telemetry (up):** POST `{"metrics": {"temperature": 23.4}}`; each key becomes a variable. - **Control (down):** a dashboard toggle or an automation queues a write — "set `led` to `on`". The board fetches pending writes, applies them, and acks. Two endpoints, one token. ## Step 1 — Connect Wi-Fi ```python import network, time, ujson, urequests from machine import Pin, ADC, deepsleep SSID = "your-ssid" PASS = "your-password" HOST = "https://nodrix.you.workers.dev" TOKEN = "tok_your_project_token" HEADERS = {"Authorization": "Bearer " + TOKEN, "Content-Type": "application/json"} def connect_wifi(): wlan = network.WLAN(network.STA_IF) wlan.active(True) wlan.connect(SSID, PASS) while not wlan.isconnected(): time.sleep(0.25) print("Wi-Fi up:", wlan.ifconfig()[0]) return wlan ``` ## Step 2 — Read a sensor and POST it No external sensor needed to start: the RP2040 has an onboard temperature sensor on ADC channel 4. ```python def read_temp_c(): raw = ADC(4).read_u16() * 3.3 / 65535 return 27 - (raw - 0.706) / 0.001721 # datasheet conversion def send_telemetry(metrics): body = ujson.dumps({"metrics": metrics}) r = urequests.post(HOST + "/v1/telemetry", headers=HEADERS, data=body) print("POST /v1/telemetry ->", r.status_code) # 204 = success r.close() # always close — frees the socket ``` Open your dashboard and the `temperature` variable is already there. Drop a **value** or **gauge** widget on it and you're watching live data; the **chart** widget plots a time window. > Always call `r.close()` after a urequests call. The Pico W has limited sockets, and leaking them > is the most common reason a long-running script stops sending after a while. ## Step 3 — Receive commands back The board asks for pending commands and applies them. The Pico W's onboard LED is a perfect test output — it's addressed as `Pin("LED")`. ```python def poll_control(): r = urequests.get(HOST + "/v1/control", headers=HEADERS) if r.status_code == 200: data = r.json() # { "control": [ { "id": "ctl_x", "variable": "led", "value": "on" } ] } for w in data.get("control", []): if w["variable"] == "led": Pin("LED", Pin.OUT).value(1 if w["value"] == "on" else 0) # POST w["id"] to /v1/control/ack so the platform stops resending it r.close() ``` Toggle the `led` variable from a dashboard control widget and the onboard LED follows. Poll every few seconds for near-real-time control. ## Step 4 — The main loop (and an honest note on sleep) On mains power, a simple loop is fine: ```python connect_wifi() while True: send_telemetry({"temperature": read_temp_c()}) poll_control() time.sleep(15) ``` For battery, you can deep sleep instead — but be realistic about the RP2040. `machine.deepsleep` resets the board and re-runs your script from the top on wake, like an ESP, yet its sleep-current floor is higher than an ESP32's, so the same duty cycle gives shorter battery life: ```python connect_wifi() send_telemetry({"temperature": read_temp_c()}) poll_control() deepsleep(15 * 60 * 1000) # milliseconds; board resets and re-runs on wake ``` If long battery life is the goal, an [ESP32](https://nodrix.live/guides/esp32-https-cloud) or [ESP8266](https://nodrix.live/guides/esp8266-iot-dashboard) with deep sleep will outlast a Pico W. The Pico W is at its best on mains power, short missions, or where you specifically want MicroPython and the RP2040's PIO. ## Production checklist - **Verify TLS for anything sensitive.** urequests encrypts but doesn't authenticate the server by default — pass an `SSLContext` loaded with the server certificate if confidentiality isn't enough. - **Close every response.** `r.close()` after each call; leaking sockets is the classic Pico W bug. - **Wrap network calls in try/except.** Wi-Fi blips happen — catch the exception, back off, and retry rather than crashing the script. - **Keep the token secret.** The project token is a credential; keep it out of shared code. That's a Pico W reporting to a dashboard you own, with commands flowing back — and the read API behind it means you can pull the same telemetry into Grafana or your own app whenever you like. ### FAQ **Q: Can a Raspberry Pi Pico W send data to the cloud?** Yes. In MicroPython, connect with the network module and POST JSON to a single HTTPS endpoint using urequests — each metric becomes a dashboard variable automatically. No MQTT broker and no SDK are required for periodic telemetry. **Q: MicroPython or Arduino for the Pico W?** Both work. MicroPython is the fastest way to get a Pico W onto a dashboard — urequests handles the HTTPS POST in a few lines. If you'd rather write the same C++ you'd use on an ESP32, the arduino-pico core gives you WiFi + HTTPClient and the ESP-style pattern applies unchanged. **Q: Does the Pico W verify the HTTPS certificate?** Be aware: MicroPython's urequests encrypts the connection but does not verify the server certificate by default — there's no CA store loaded, so it's confidential but unauthenticated, similar to setInsecure() on an ESP. For anything sensitive, pass an SSLContext with the server's certificate. The traffic is still TLS-encrypted either way. **Q: How do I get commands back to the Pico W?** Poll the control endpoint on an interval and apply what comes back, then ack it so it isn't resent. A dashboard toggle or an automation queues the write; the board reads it from /v1/control and flips the pin. **Q: Can the Pico W run on battery like an ESP32?** It can deep sleep with machine.deepsleep, but be honest about the RP2040: its sleep floor is higher than an ESP32's, so battery life is shorter for the same duty cycle. For long battery runs, an ESP32/ESP8266 with deep sleep is the better pick; the Pico W shines on mains power or short missions. --- ## Guide: A lightweight ThingsBoard alternative for makers — zero servers to run URL: https://nodrix.live/guides/thingsboard-alternative Category: comparison ThingsBoard is powerful but heavy to self-host. nodrix is an open-source alternative that one-click deploys to your own Cloudflare account — no Java, Postgres, broker, or VM to operate, with dashboards, edge automations, and a read API. People search for a **ThingsBoard alternative** rarely because ThingsBoard lacks features — it has plenty — and almost always because of **weight**. Self-hosting the Community Edition means standing up Java, a database (Postgres or Cassandra), and usually a message queue, then keeping all of it patched and alive. For an enterprise that's justified. For a maker or a small team, it's a lot of machinery to monitor a greenhouse. nodrix takes the opposite stance: it's open-source (MIT) and **one-click deploys to your own Cloudflare account** — Workers, Durable Objects, D1, and R2 — with **no server, broker, or database for you to run**. You still own everything (it's single-tenant, in your tenancy), but there's nothing to operate. This is an honest comparison, including where ThingsBoard remains the right tool. ## What ThingsBoard gets right ThingsBoard is a serious platform: a mature **rule engine** with rule chains, **multi-tenancy**, device provisioning, a broad protocol surface (MQTT, CoAP, HTTP, LwM2M), and a rich dashboard system. If you're building a product with many tenants, thousands of devices, or strict on-prem requirements, that depth is exactly what you want, and it's hard to match. The cost of that power is operational. Either you self-host and own the infrastructure, or you pay for ThingsBoard Cloud / Professional. Both are reasonable — they're just the thing makers are trying to avoid when they look for something lighter. ## ThingsBoard vs nodrix, honestly | | ThingsBoard | nodrix | |---|---|---| | To self-host | Java + Postgres/Cassandra + queue, on a VM/cluster | One-click deploy to Cloudflare; nothing to run | | Ops burden | You operate and scale it | Serverless; Cloudflare handles it | | Pricing | CE free (you host); Cloud/PE paid | MIT; pay Cloudflare for usage | | Protocols | MQTT, CoAP, HTTP, LwM2M, … | HTTPS + WebSocket (no broker) | | Rule engine | Deep rule chains | Visual trigger → condition → action at the edge | | Multi-tenancy | Yes | Single-tenant by design (one deploy = yours) | | Scale target | Enterprise / fleets | Makers and small teams | | Maturity | Mature, production-proven | Stable (v1.0), actively developed | ## When ThingsBoard is the better choice - You need **enterprise scale**, **multi-tenancy**, or a **mature rule engine** with complex chains. - You require **MQTT/CoAP/LwM2M** or other protocols beyond HTTP/WebSocket. - You have **on-prem** or specific data-residency requirements that a managed edge won't meet. For those, ThingsBoard is the grown-up answer and the operational weight is the price of admission. ## When nodrix fits better - You want **zero ops** — no Java, no database, no broker, no VM patching. - You want **open source you own** but deployed serverlessly to **your own Cloudflare account**. - Your devices speak **plain HTTPS/WebSocket** and your automations are maker-scale, not enterprise rule chains. - You'd rather pay **Cloudflare usage** than run (or rent) a cluster. ## The shape of the trade ThingsBoard gives you a powerful platform you must operate. nodrix gives you a narrower platform you don't have to operate at all — the same "your data, your infra" ownership, minus the servers. Pointing hardware at it is a plain HTTPS POST (see [Connect an ESP32 over HTTPS](https://nodrix.live/guides/esp32-https-cloud)); there's no broker to provision. If you need enterprise scale, multi-tenancy, or a deeper rule engine today, ThingsBoard's depth is the right call — and several of those are on the nodrix roadmap. If you're a maker or small team who wants ThingsBoard-style ownership without the ThingsBoard-style operations, deploy nodrix to a Cloudflare account, point a device at it, and star the repo to follow along. ### FAQ **Q: What's a lighter-weight alternative to ThingsBoard?** nodrix. ThingsBoard is a capable, enterprise-grade platform, but self-hosting it means running Java, a database (Postgres or Cassandra), and usually a message queue — real ops. nodrix instead deploys onto Cloudflare's serverless primitives (Workers, Durable Objects, D1, R2) in one click, with no server, broker, or database for you to operate. **Q: Is ThingsBoard free?** ThingsBoard Community Edition is open-source and free to self-host, but you carry the hosting and operations. ThingsBoard Cloud and the Professional Edition are paid. nodrix is open-source (MIT) with no license cost; you pay Cloudflare for the usage of your own deployment. **Q: Do I need MQTT for nodrix like I might with ThingsBoard?** No. ThingsBoard speaks MQTT, CoAP, HTTP, and more. nodrix is intentionally narrower: devices talk plain HTTPS or a WebSocket, with no broker to run. For periodic telemetry and command-and-control that's simpler; if you specifically need MQTT/CoAP/LwM2M at scale, ThingsBoard is the better fit. **Q: Can nodrix do a ThingsBoard-style rule engine?** Yes — nodrix has a visual automation builder (triggers, conditions, actions over HTTP/email/chat) evaluated at the edge, with deeper rule logic on the roadmap. It's single-tenant by design, where ThingsBoard targets enterprise multi-tenancy. **Q: When should I stay on ThingsBoard?** When you need enterprise scale, multi-tenancy, a mature rule engine, many device protocols, or on-prem requirements. ThingsBoard is built for that. nodrix targets makers and small teams who want zero ops and a single-tenant deployment they fully own. --- ## Guide: A ThingSpeak alternative for realtime IoT you own — open-source, on your Cloudflare URL: https://nodrix.live/guides/thingspeak-alternative Category: comparison Need a ThingSpeak alternative without the update-rate floor or annual message cap? nodrix is open-source IoT you deploy to your own Cloudflare account — realtime telemetry and control, dashboards, automations, and a read API, all in your tenancy. People reach for a **ThingSpeak alternative** for a handful of reasons: the fixed update-rate floor on the free tier, the annual message quota, the non-commercial restriction, or wanting realtime control and richer dashboards instead of mostly logging-and-plotting. nodrix covers those. It's open-source (MIT) and you **deploy it to your own Cloudflare account** in one click — your channels become variables in your own tenancy, with no per-account message cap and no minimum interval between readings. This is an honest comparison, including where ThingSpeak is the better tool. ## What ThingSpeak gets right ThingSpeak's superpower is analysis. Because it's a MathWorks product, the **MATLAB integration** is excellent — you can run real analytics and visualizations on your channel data, schedule them, and trigger reactions. For research, coursework, and anything where you want to *crunch* the numbers rather than just watch them, that's a serious advantage, and it's free for non-commercial use. The channel/field model is also dead simple to start logging into. What pushes people to look elsewhere is the shape of the free tier: a **minimum update interval**, a **yearly message limit**, and a **non-commercial** clause — plus dashboards that lean toward static plots rather than live, interactive control. ## ThingSpeak vs nodrix, honestly | | ThingSpeak | nodrix | |---|---|---| | Model | Hosted SaaS (channels + analytics) | Open-source; you deploy it to your own Cloudflare | | Where data lives | MathWorks cloud | Your Cloudflare account (single-tenant) | | Pricing | Free (non-commercial, capped); paid licenses | No license cost; you pay Cloudflare for usage | | Update rate | Minimum interval on free tier | No platform-imposed floor | | Message cap | Annual quota | Bounded only by your Cloudflare usage | | Focus | Data logging + MATLAB analytics | Realtime telemetry **and** control | | Downlink | TalkBack / React | First-class control writes (poll or WebSocket) | | Device connection | REST + MQTT, channel API key | Plain HTTPS/WebSocket + optional open library | | Open source | No (hosted) | MIT, full stack | | Data access | REST channel feed | Read API: latest state + time-series behind one token | ## When ThingSpeak is the better choice - You want **built-in MATLAB analytics** and scheduled analysis on your data. - You're in **academia or research** and the non-commercial free tier and citability fit. - Your project is **periodic logging plus offline analysis**, and live control isn't the point. If that's you, ThingSpeak is a strong, purpose-built answer. ## When nodrix fits better - You need **realtime** readings without a minimum-interval floor, and **control back to the device** as a first-class feature. - You've hit the **message cap** or the non-commercial restriction and want headroom bounded only by your own Cloudflare usage. - You want **open source and ownership** — your data in your account, not a third-party cloud. - You want a **read API** to pull telemetry into MATLAB, Python, or Grafana yourself, plus **edge automations** you control. ## Moving a channel across A ThingSpeak channel's fields map cleanly onto nodrix metrics. Wherever your firmware writes a channel update, POST the same values to nodrix — each key becomes a variable automatically: ```cpp // HTTPS POST https://nodrix.you.workers.dev/v1/telemetry // Authorization: Bearer tok_your_project_token // { "metrics": { "field1": 23.4, "field2": 61 } } -> 204 ``` Use real metric names instead of `field1`/`field2` and your dashboards get a lot more readable. Commands flow the other way via `GET /v1/control` or the control WebSocket — the full firmware is in [Connect an ESP32 over HTTPS](https://nodrix.live/guides/esp32-https-cloud). ## The bottom line If MATLAB analytics is the reason you're on ThingSpeak, stay — nothing here replaces that. But if you're fighting the update-rate floor, the message cap, or the non-commercial clause, or you want realtime control and a stack you own, deploy nodrix to a spare Cloudflare account, point one device at it, and pull the data wherever you want to analyze it. ### FAQ **Q: Is there a free, open-source alternative to ThingSpeak?** Yes. nodrix is open-source (MIT) and you deploy it to your own Cloudflare account, so there's no license cost and no annual message quota — you pay Cloudflare for usage, which for a handful of sensors is effectively free. ThingSpeak is a hosted MathWorks service; the free tier is non-commercial and rate-limited. **Q: Can nodrix send commands back to a device like ThingSpeak's TalkBack?** Yes, and it's first-class. A dashboard control or an automation queues a control write; the device fetches it from /v1/control and acks, or holds the control WebSocket open for instant writes. ThingSpeak can do downlink via TalkBack/React, but nodrix treats control as a core part of the protocol. **Q: Does nodrix do analytics like ThingSpeak's MATLAB integration?** Not built in — ThingSpeak's MATLAB analysis and visualization is genuinely its standout feature. nodrix instead exposes a clean read API (latest state + time-series behind one token) so you can pull data into MATLAB, Python, Grafana, or your own app and analyze it wherever you like. **Q: How do I move a ThingSpeak channel to nodrix?** Replace the channel field write (GET/POST to /update with your API key) with an HTTPS POST to nodrix's /v1/telemetry — each metric key becomes a variable automatically, so a channel's eight fields just become eight named metrics. Then rebuild your plots as nodrix chart widgets. --- ## Guide: A Ubidots alternative that drops per-dot pricing — open-source, on your Cloudflare URL: https://nodrix.live/guides/ubidots-alternative Category: comparison Looking for a Ubidots alternative without per-dot or per-device pricing? nodrix is open-source IoT you deploy to your own Cloudflare account — dashboards, events, automations, and a read API, with costs that track Cloudflare usage instead of data points. Most teams searching for a **Ubidots alternative** are reacting to one thing: **cost at scale**. Ubidots is a genuinely polished platform, but it's billed by data points or devices, and for a maker fleet or a growing project that meter adds up. nodrix takes a different shape. It's open-source (MIT) and you **deploy it to your own Cloudflare account** in one click — there's no per-dot or per-device license, just your Cloudflare usage, and every reading lives in your own tenancy. This is an honest comparison, including where Ubidots is the stronger choice. ## What Ubidots gets right Ubidots is built for businesses and it shows. The dashboards are clean and presentation-ready, the events/alerts engine is mature, it speaks a wide range of protocols (REST, MQTT, TCP/UDP), and the industrial tier brings **white-labeling**, prebuilt connectors, and managed support. If you're shipping a client-facing product and want a vendor to stand behind the platform, that's real value you'd otherwise have to build yourself. What sends people looking is the **pricing model**. Consumption-based billing is fine for a funded product with predictable volume; it's painful for hobby fleets, prototypes that suddenly scale, or anyone who'd rather own the stack than rent it by the data point. ## Ubidots vs nodrix, honestly | | Ubidots | nodrix | |---|---|---| | Model | Hosted commercial SaaS | Open-source; you deploy it to your own Cloudflare | | Where data lives | Ubidots' cloud | Your Cloudflare account (single-tenant) | | Pricing | By data points / devices | No license cost; you pay Cloudflare for usage | | Open source | No | MIT, full stack | | Dashboards | Polished, presentation-ready | Responsive web, drag-and-drop, embeddable | | Events / alerts | Mature events engine | Visual trigger → condition → action at the edge | | White-label / support | Yes (industrial tier) | Self-hosted; community + the repo | | Device connection | REST / MQTT / TCP-UDP | Plain HTTPS/WebSocket + optional open library | | Data access | REST API | Read API: latest state + time-series behind one token | ## When Ubidots is the better choice - You're shipping a **client-facing product** and need **white-labeling** and a vendor to support it. - You want **prebuilt industrial connectors** and a managed events engine out of the box. - Consumption-based pricing is **predictable for your volume** and you'd rather not own the stack. If that's you, Ubidots earns its price and the ownership trade isn't worth it. ## When nodrix fits better - You're **allergic to per-dot / per-device pricing** and want costs that track actual Cloudflare usage. - You want **open source and ownership** — your telemetry in your account, not a third-party cloud. - Your devices speak **plain HTTPS/WebSocket** and you want a device library without the lock-in — or none at all. - You want a **read API** to plug data into Grafana or your own app, plus **edge automations** you fully control. ## Moving a device across Ubidots variables map directly onto nodrix metrics. Swap the Ubidots POST for a nodrix one — each key becomes a variable automatically: ```cpp // HTTPS POST https://nodrix.you.workers.dev/v1/telemetry // Authorization: Bearer tok_your_project_token // { "metrics": { "temperature": 23.4, "battery": 87 } } -> 204 ``` Commands flow back via `GET /v1/control` or the control WebSocket — the full firmware is in [Connect an ESP32 over HTTPS](https://nodrix.live/guides/esp32-https-cloud). Rebuild your widgets on a nodrix dashboard and recreate Ubidots events as trigger-condition-action automations. ## The bottom line If you need white-labeling, industrial connectors, and managed support, Ubidots is a reasonable buy. But if the per-dot meter is the problem — or you want open source, ownership, and a usage-based cost model — deploy nodrix to a Cloudflare account, point a device at it, and watch the bill track usage instead of data points. ### FAQ **Q: Is there an open-source alternative to Ubidots?** Yes. nodrix is open-source (MIT) and you deploy it to your own Cloudflare account rather than paying for a hosted plan. Ubidots is a polished commercial platform billed by data points / devices; nodrix has no license cost and your bill is just your Cloudflare usage. **Q: Does nodrix have events and alerts like Ubidots?** Yes. nodrix automations are visual trigger → condition → action flows that run at the edge — e.g. when a variable crosses a threshold, call a webhook, send an email, or set another variable. It covers the common Ubidots events/alerts use cases without a separate events product. **Q: Is nodrix suitable for commercial or industrial projects like Ubidots?** It runs on Cloudflare's production platform (Workers, Durable Objects, D1, R2), so it's solid for commercial telemetry and dashboards. What Ubidots adds for industry is white-labeling, managed support, and prebuilt industrial connectors — if those are contractual requirements, weigh them; nodrix wins on ownership and cost model. **Q: How do I migrate from Ubidots to nodrix?** Replace the Ubidots variable POST (to /api/v1.6/devices/