DEV Community: Synacl Labs

ThingsBoard alternatives in 2026: picking an IoT platform for a small industrial fleet

Synacl Labs — Mon, 26 Oct 2026 05:08:46 +0000

By the Synacl team. Originally published at synacl.com.

ThingsBoard is the platform most people find first when they search for an open-source IoT dashboard, and for good reason: it's mature, self-hostable and can do almost anything. It's also a lot of platform for a plant with forty meters and one electrician. This guide compares the realistic alternatives for a small industrial fleet (tens to a few hundred devices, mostly Modbus, RS485 and simple sensors) on the things that actually decide the outcome: who hosts it, how devices get in, what the pricing model does as you grow, whether commercial use is allowed on the cheap tiers, and how much engineering you need on staff.

Prices below were checked in September 2026 against each vendor's public pricing page, and ThingsBoard's again on 8 October 2026 after its licence change. They change often, so treat them as the shape of the offer, not a quote. Synacl is our product, so the last section is ours to argue; the rest is written to be fair.

What ThingsBoard is good at, and where it gets heavy

ThingsBoard comes in two forms:

Self-managed ThingsBoard. Since version 4.4 (September 2026) the old Community and Professional editions are one product under the Business Source License 1.1. Production use is free for commercial use up to 100 devices on one server (1,000 devices for non-commercial use), as long as the ThingsBoard branding stays visible and you use a free licence key. Beyond that, self-managed subscriptions run from $99 to $499 a month, and a perpetual licence starts at $4,999. Versions before 4.4 stay Apache 2.0, and each new release becomes Apache 2.0 four years after it ships. You get device management, a rule engine, a large widget library and a dashboard builder, and you pay in servers and attention.
ThingsBoard Cloud is the hosted version. It's billed by plan, and each plan caps both devices and data points, where one data point is one telemetry value. The free tier covers 5 devices and 1 million data points a month. Paid tiers are Prototype ($49 a month, 50 devices, 10 million data points), Pilot ($149, 100 devices, 100 million), Startup ($399, 500 devices) and Business ($749, 1,000 devices), with extra devices at about $0.30 each.

There's also ThingsBoard Edge, a local instance that runs on site and syncs with the cloud.

Where ThingsBoard shines: you need a rule engine you can program in depth, you want to own the stack, or you're integrating a dozen protocols through the separate ThingsBoard IoT Gateway, a Python service you install on an edge box.

Where it gets heavy:

The gateway is a second product to deploy and keep alive.
Modbus devices are configured in the gateway's connector config rather than in the platform.
Self-hosting at scale means PostgreSQL or Cassandra plus Kafka.
On Cloud, the data-point caps punish sensors that report often: 50 devices reporting four values every 10 seconds come to about 52 million data points a month, five times the Prototype allowance.

If your team has a developer who enjoys this, ThingsBoard is a fine choice. If your team is an installer with a laptop, it's a project. For the two side by side, feature by feature, see ThingsBoard vs Synacl.

The hosted alternatives, one by one

ThingSpeak

ThingSpeak is MathWorks' IoT analytics service, and it comes up in almost every "ThingsBoard vs ThingSpeak" search. Its strength is MATLAB: you can run MATLAB analysis and visualisations on channel data without leaving the browser. The free tier allows about 3 million messages a year, 4 channels and one update every 15 seconds, and it's for non-commercial use only. Paid licences are sold per unit of messages per year and priced by country rather than published. The device side is your own firmware posting over HTTP or MQTT.

Best for: research, teaching and data analysis projects, especially if you already use MATLAB. It isn't built for fleet operations, alerting or multi-user access.

Blynk

Blynk grew up as the app builder for makers and has moved towards businesses. Its strength is the phone app: drag a few widgets, connect an ESP32 with the Blynk library, and you're done. The free plan covers 5 devices for exploration. Paid plans start at Starter ($29 a month for 10 devices), then Prototype ($99 for 50) and Production tiers from $199 for 100 devices. Modbus and RS485 aren't first-class: you write the firmware that reads the bus and publishes values.

Best for: a product team building a consumer or light-commercial device that ships with its own firmware and needs a branded mobile app.

Datacake

Datacake is a low-code platform with unusually good LoRaWAN support. The first 5 devices are free, and paid plans are bundles priced in euros: Hobby is €25 a month for up to 25 devices, and the next step, Light, is €159 a month for 50. Device data is decoded with JavaScript payload decoders you maintain per device type. Modbus reaches Datacake through third-party RS485-to-LoRaWAN converters.

Best for: LoRaWAN sensor fleets, and anyone whose devices already speak MQTT or HTTP with a payload they can decode in a few lines.

Ubidots

Ubidots offers polished dashboards, an events engine and white-label options on higher tiers. The free STEM plan covers 3 devices for non-commercial use. The Professional plan is $99 a month for 50 devices, plus about $2 per extra device, and the Industrial and Enterprise tiers are priced on request. As with Blynk and Datacake, the device side is your problem: Ubidots ingests MQTT and HTTP, and Modbus comes in through a third-party gateway.

Best for: teams that want a clean, presentable dashboard product on top of devices they already control.

TagoIO

TagoIO is a developer-friendly platform with serverless "analysis" scripts, a dashboard builder and network integrations for LoRaWAN and similar radios. The free tier covers 5 devices. Starter is $49 a month for up to 100 devices with a monthly data allowance, and usage beyond it is pay-as-you-go. A dedicated or on-premise deployment is available at a much higher price. Like most hosted platforms it expects devices, or a third-party gateway, to deliver data over HTTP or MQTT.

Best for: developers who want to script their own processing in JavaScript and don't mind usage-based billing.

Arduino Cloud

If your hardware is Arduino-branded, or ESP32 boards flashed with Arduino sketches, Arduino Cloud is the path of least resistance: the IDE, device provisioning and dashboards are one product. Read the licence terms carefully, though. The free plan and the Maker plan ($72 a year for 25 "Things") are for personal use only. Commercial use starts at the Team plan, $1,000 a year for 100 Things. Industrial protocols, fleet operations and alerting are thin.

Best for: classrooms, prototypes and personal projects.

AWS IoT Core and Azure IoT Hub

These are building blocks, not platforms. You get a secure MQTT broker at any scale and pay per message and per connection minute. Then you assemble storage, dashboards, alerting, device provisioning and OTA from other services. That assembly isn't stable, either. Google shut Cloud IoT Core down in 2023, and AWS has since retired IoT Analytics and IoT Events, so a stack built on those had to be rebuilt. The hyperscalers are superb when you have a cloud team and unusual requirements, and expensive in engineering time when you don't.

Best for: software companies building their own IoT product on top.

Two other names come up in enterprise shortlists. Losant is now part of SUSE and prices by quote. Azure IoT Central is still available, despite a 2024 retirement notice that Microsoft withdrew. Both are aimed at larger deployments than this guide covers.

If you need to self-host

Self-hosting is the main reason people choose ThingsBoard in the first place. If it's a hard requirement (data residency, an air-gapped site, company policy), the realistic options are:

Self-managed ThingsBoard. The most complete self-hostable platform, and the heaviest to run. Since 4.4 it is source-available rather than open source: free for commercial use up to 100 devices on one server.
Thinger.io. Lighter, with open-source (MIT) client libraries and a hosted service priced per instance rather than per device: a free Maker tier with 2 devices, and paid instances from about €29 a month. Private on-premise instances are also offered.
Node-RED + InfluxDB + Grafana + Mosquitto. The DIY stack. It's all free software and endlessly flexible, and Node-RED's Modbus nodes are excellent. The cost is ownership: backups, upgrades, TLS, user management, and the knowledge living in one person's head.

Be honest about whether self-hosting is a requirement or a preference. A preference usually evaporates the first time an upgrade breaks at 2 a.m. and the only person who understands the stack is on holiday.

Comparison at a glance

Platform	Hosting	Free tier	Commercial use on the cheapest paid plan	Pricing model	Modbus / RS485 path
ThingsBoard (self-managed)	Self-hosted	100 devices on one server (1,000 non-commercial)	Yes, within the free licence	Free to 100 devices, then subscriptions from $99/month	Separate IoT Gateway service
ThingsBoard Cloud	Hosted	5 devices, 1M data points/month	Yes	Plan caps devices + data points	Same gateway, hosted platform
ThingSpeak	Hosted	3M messages/year, non-commercial	Yes, on a Standard licence	Per unit of messages/year, priced by country	Your firmware
Blynk	Hosted	5 devices, exploration	Yes	Per plan by device count	Your firmware
Datacake	Hosted	5 devices	Yes	Device bundles, in EUR	Third-party LoRaWAN converters
Ubidots	Hosted	3 devices, non-commercial	Yes	Plan + per extra device	Third-party gateway
TagoIO	Hosted	5 devices	Yes	Plan + pay-as-you-go data	Third-party gateway
Arduino Cloud	Hosted	2 Things, personal	No, only from the Team plan	Per plan	Your sketch
Thinger.io	Hosted or private	2 devices	Yes	Per instance size	Plugins / third-party gateway
Node-RED + Influx + Grafana	Self-hosted	Free software	Yes	Your time	Node-RED Modbus nodes
AWS IoT / Azure IoT Hub	Cloud building blocks	Small credits	Yes	Per message and connection minute	Build it
Synacl	Hosted	5 devices	Yes	Per plan by device count	Built-in ESP32 gateway, browser-flashed

How to choose in ten minutes

Answer five questions and most of the table disappears.

Do your devices already speak MQTT or HTTP with firmware you control? If they do, every hosted platform works and you're choosing on dashboards and price. If they're Modbus meters, RS485 probes or 4–20 mA transmitters on a PLC, you need a gateway, and the question becomes who provides and maintains it.
Is self-hosting a requirement or a preference? A requirement points at the self-hosting section above. A preference usually doesn't survive contact with the upgrade schedule.
How often do sensors report? Data-point and message caps are fine at one reading a minute and painful at one a second. Per-device pricing doesn't care.
Is this commercial? Several free and entry tiers (ThingSpeak, Ubidots STEM, Arduino Cloud up to Team) rule out commercial use. Check before you build a customer's install on one.
Who will run it day to day? If the answer is an electrician, an installer or a plant manager, the platform has to handle provisioning, firmware updates and diagnostics from a browser. Otherwise the work lands back on whoever set it up.

Moving off ThingsBoard

If you already run ThingsBoard and it's become more platform than you need, migration is less work than it looks, because the part worth keeping is small:

Devices and register maps. Export them from the IoT Gateway's Modbus connector config: slave IDs, register addresses, function codes, scaling. This is the knowledge that took time to collect, and it transfers to any platform as-is.
Rules. Most small-fleet rule chains are thresholds and offline alerts. Write them down as plain sentences ("alert if tank level < 20% for 5 minutes") and rebuild them, rather than trying to translate rule-chain JSON.
Dashboards. These don't move between platforms. Rebuild the few that people actually open, and skip the rest.
History. Export telemetry you need for compliance or reports to CSV before you switch off. Few platforms import another's time-series history, so plan on keeping the export as an archive.

Run the two systems side by side for a week on a handful of devices before you move the rest. Double-reading is harmless if both platforms read the bus, but not if one of them writes.

Where Synacl fits, and where it doesn't

Synacl was built for the case the table leaves half-served: industrial-ish hardware, a small fleet, and no software team.

The gateway is part of the platform, not a separate product. It's an ESP32 you flash from the browser, provision over USB, and update over the air with its settings kept. Modbus RTU and RS485 devices are configured in the platform, register by register, with scaling and units on each tag. Common meters and sensors start from a device catalog with the register map already filled in, and on paid plans a fleet of identical meters can be added in one go with auto-numbered names and Modbus IDs. GPIO, I²C, 1-Wire, SPI, UART and CAN devices hang off the same gateway, and devices that already speak MQTT or HTTPS connect directly without one.

On top of the devices you get:

live dashboards with SCADA-style widgets and P&ID mimics
threshold and event rules with email, webhook and MQTT actions
gateway-local macros that keep running when the internet doesn't
uptime history with probe and heartbeat monitors
a white-label portal for installers who run fleets for several customers
an MCP connection, so an AI assistant can set up devices and dashboards on your behalf

The free browser tools (a Modbus RTU tester, a CRC calculator, a register decoder, a slave simulator and a serial monitor) need no account at all.

Pricing is per plan by device count, with no per-message or per-data-point billing. The first five devices are free, commercial use included, and the paid tiers are on the pricing page. It's a hosted service, billed in USD.

Where Synacl isn't the right pick:

you must self-host
you need a general-purpose workflow engine to build custom applications
you're past several thousand devices and need an enterprise SLA

For those, self-managed ThingsBoard, the DIY stack or the cloud building blocks will serve you better. We'd rather you pick the right tool than pick ours.

Frequently asked questions

Is there a free alternative to ThingsBoard? Several. Self-managed ThingsBoard is itself free for commercial use up to 100 devices on one server. Among hosted platforms, ThingsBoard Cloud, Blynk, Datacake, TagoIO and Synacl all have free tiers of about five devices. ThingSpeak, Ubidots STEM and Arduino Cloud have free tiers too, but those are for non-commercial or personal use.

What is the best open-source ThingsBoard alternative? For a full platform, Thinger.io, whose client libraries are open source and which offers private on-premise instances. For maximum flexibility, Node-RED with InfluxDB and Grafana. Neither has ThingsBoard's depth of rule engine, and both need someone to run them.

ThingsBoard vs ThingSpeak — which should I use? They solve different problems. ThingSpeak is a data-logging and MATLAB-analysis service for research and teaching, and its free tier is non-commercial. ThingsBoard is a device-management and dashboard platform for running a fleet. For monitoring equipment you're responsible for, pick a fleet platform.

Which platform reads Modbus without writing firmware? ThingsBoard, through its IoT Gateway (configured by file or UI). Node-RED, through its Modbus nodes. Synacl, through its browser-flashed ESP32 gateway configured in the web app. The other hosted platforms expect you to bring a gateway or firmware that already publishes the values.

If you want to see the gateway path end to end, the ESP32 Modbus RTU to a cloud dashboard guide walks through a real RS485 sensor from wiring to alert in about fifteen minutes. If you're weighing the wiring first, Modbus RTU vs Modbus TCP covers that decision.

Most of the AI traffic in our logs was fake. So we had to build a system to tell it apart

Synacl Labs — Fri, 23 Oct 2026 17:41:02 +0000

Every Monday we asked three things about one small site: who read it last week, was that good, and what should we write next. Then we added the question everyone with a content site is asking now: are AI assistants reading us?

Counting user-agents said yes, plenty. Then we checked who was behind them.

Scanners wear AI user-agents. In 30 days of our nginx log, 217 of the 221 ChatGPT-User requests from outside OpenAI's published IP list came from addresses that also probed for scanner paths like /.env and wp-login.php. Every request claiming to be DeepSeekBot, CCBot, Grok, Perplexity-User or Claude-SearchBot was fake.

OpenAI, Anthropic, Perplexity, Apple, Google and Bing all publish the IP ranges their crawlers use. A request that claims to be one of their agents from outside that list is not theirs:

$ npx siteread check 203.0.113.9 "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot"
spoofed   203.0.113.9 claims chatgpt-user (chatgpt, answer) but is not in openai.com/chatgpt-user.json (234 prefixes)

The rule of thumb that called a real ClaudeBot fake. Before using the lists, our test was "an IP that ever hit a scanner path is a scanner." Then ClaudeBot followed a GitHub README's relative links onto our domain, asked for a path that does not exist, drew one 444, and all 50 of its reads that day were counted as spoofed. Every real ClaudeBot IP was in Anthropic's published list. So siteread has one rule: where a vendor list exists, the list decides.

Two more from the log: Claude Code's WebFetch sends Claude-User (claude-code/…) from the user's own machine, so no list can cover it; and Google-Extended is a robots.txt token, never a real user-agent.

From a checker to a weekly read. siteread digest turns a Search Console export and your access logs into one JSON document: Search Console weeks with impression-weighted position, people by where their first visit came from, every crawler verified against its vendor's list, and goals you name. The seo-read skill for Claude Code writes that up as a dated weekly memo with two to four things to do next.

It runs on your machine, Node 20+, zero dependencies. No hostnames, URLs or visitor IPs leave it. The optional siteread share sends one week of totals to a public benchmark, prints every byte first, and sends nothing without a yes.

Try it:

npx siteread check <ip> "<user-agent>"
npx siteread digest --gsc export.zip --log access.log --out .siteread/digests

The full story, the benchmark and the docs: https://siteread.dev/blog/introducing-siteread

MIT licensed, source at https://github.com/synacl-iot/siteread. A log line it gets wrong is the most useful issue you can send.

Program an ESP32 without writing code or installing any tools: a browser flash, Claude, and a macro that runs on the board

Synacl Labs — Mon, 21 Sep 2026 12:30:21 +0000

By the Synacl team. Originally published at synacl.com, where the walkthrough is interactive.

You can get an ESP32 reading a light sensor and pulsing a relay without opening an IDE, writing a sketch, or compiling anything. The board is flashed from a browser tab, it joins your Wi-Fi over the same USB cable, and the automation is written by Claude from a sentence you type — as a macro that runs on the ESP32 itself. You read what it wrote and decide whether it may run. This guide walks the whole path on a bare dev board, using the board's own LED as the "relay" so there is nothing to wire up before you try it.

1. Flash the gateway firmware from the browser

synacl.com/flash — pick “Synacl gateway firmware”, click Connect, choose the USB port, Flash. About 25 seconds at 460800 baud; no toolchain, no account yet.

2. Register the gateway and send it Wi-Fi over the same cable

Gateways → Add gateway. Skip the flash step, give the gateway a name, then type your Wi-Fi network and password: the app sends them over USB, no captive portal.

3. The board comes online

Within about 90 seconds the gateway shows online with its firmware version. Nothing is wired to it yet.

4. Add Synacl to Claude as a connector

In claude.ai, add a custom connector with the URL https://api.synacl.com/mcp. That is the whole setup on the Claude side.

5. Approve what Claude may do — note what is not pre-ticked

Synacl's consent screen lists every permission. “Run macros” arrives unticked and says “Off by default — can move equipment”; everything else is pre-selected, and you can grant less than asked. Tick it for this walkthrough — step 8 shows it is not enough on its own.

6. Describe the automation in one sentence

“This gateway has a relay on GPIO 2. Set it up as a device, then write a macro called Blink that switches it on and off five times, half a second each.” Claude creates the device and the macro, compiles and pushes it, and tells you the config resend that puts them on the board is your click.

7. The macro Claude wrote, in your app

Macros shows Blink on your gateway with its five steps: a repeat of five around relay on, wait half a second, relay off, wait again — and Claude's own one-line description. Read it before anything runs.

8. Ask Claude to run it — and it is refused

Asked to run Blink, Claude reads the macro first: “agentRunnable: false on Blink. My connection holds macro:run, but that permission only applies to macros a person has explicitly marked agent-runnable in the web app. That flag is deliberately not something I can set myself.” It holds the Run macros permission and still cannot start it — two keys, and software only ever holds one.

9. You read it, you allow it

Edit the macro and tick “Let an AI agent run this macro”. It is off on every macro by default, and no assistant can set it, not even on macros it wrote.

10. Now it runs — on the board, acknowledged by the board

Ask again. The gateway confirms the run started, the status goes requested → started → done, and the output pin toggles five times. Claude reports what the gateway acknowledged, not what it sent.

What you need

An ESP32 dev board and a USB data cable. Any classic ESP32 works with the Synacl firmware; the board in the pictures is a plain ESP32-WROOM module with the usual blue LED on GPIO 2.
Chrome or Edge on a desktop. Browser flashing and USB provisioning use the Web Serial API, which Firefox and Safari do not have.
A free Synacl account — the first five devices cost nothing. Create it after the flash; the flasher works without one.
Claude, with a plan that supports custom connectors. The connection is a standard remote MCP server, so any assistant that speaks MCP works the same way; the screens here are claude.ai.
For the last section: a BH1750 light sensor — the common GY-302 breakout — on the I²C pins: 3.3 V, GND, SDA to GPIO 21, SCL to GPIO 22, ADDR left low for address 0x23. Any I²C sensor with a datasheet works the same way. A relay module is only needed if you want to switch something real instead of watching the LED.

The whole thing takes about fifteen minutes, most of it waiting for the board to reboot.

Step 1 — Flash the gateway firmware from the browser

Open synacl.com/flash, plug the board in, and choose Synacl gateway firmware. The page fetches the current stable build and shows its version. Click Connect, pick the board's serial port in the browser's chooser, then Flash. At the default 460800 baud the four images take about 25 seconds; the log ends with "Flash complete" and the board restarts on its own. Leave Erase entire flash off — you do not need it on a fresh board, and on a board that was already a Synacl gateway it would wipe the saved Wi-Fi and account settings.

No port in the chooser usually means a charge-only cable; a failed first handshake means holding BOOT while you click Connect. The flashing article covers the rest.

What you have now is a gateway waiting for two things: a Wi-Fi network and an account to belong to.

Step 2 — Register it and send Wi-Fi over the same cable

Create your account, then open Gateways → Add gateway. The page has three steps and you have already done the first, so skip the flash section, give the gateway a name in step 2 and register it, then in step 3 type your Wi-Fi network and password and press Send Wi-Fi & Connect. The app sends the credentials and the gateway's account key over USB — no captive portal, no hotspot to find (the board does offer a Synacl-Gateway fallback portal for provisioning without a computer).

Back on the Gateways page the new gateway shows online within about ninety seconds, firmware version beside it. Nothing is wired to it yet; the next steps add the devices in software, and a pin does not care what is attached until something runs.

Step 3 — Connect Claude

In claude.ai, add a custom connector and give it the Synacl MCP endpoint:

https://api.synacl.com/mcp

The first time Claude uses it, your browser opens Synacl's authorization screen. Read it: it lists every permission Claude asked for under "It will be able to", and you can untick anything you would rather not hand over. Almost everything is pre-selected — creating devices, editing tags, writing macros — because none of that moves anything. One line is different. Run macros arrives unticked and is labelled "Off by default — can move equipment". Tick it — and keep step 5 in mind, where you will see that this permission on its own is not enough to run anything. Approve, and Claude is connected to your account and only your account. You can revoke the connection at any time from Settings → API & Agents.

Everything Claude does from here goes through that connection, with the permissions you ticked and no others — the AI agent article has the full list.

Step 4 — Say what the board should do

Now the sentence. In a new chat, with the connector enabled:

This gateway has a relay on GPIO 2. Set it up as a device, then write a macro called Blink that switches it on and off five times, half a second each, so I can see it work.

Say where things are wired: Claude will not guess a pin, because this connection cannot delete a device and a free account has five device slots, so a wrong guess would cost you one — it asks instead. Given the pin, it looks up your gateway, creates the device — a GPIO digital output on GPIO 2, active-high, off by default — and writes the macro.

One click stays yours. A new device only reaches the board when the gateway's config is resent, and a resend reboots the gateway, so Claude reports it as pending instead of doing it. Open the gateway from its card (Info) and press Resend config; about thirty seconds later the board is back, now owning the relay pin. A Synacl macro is a short program made of blocks: things like switch this output, wait, repeat, read a tag, if. For Blink, Claude produces a repeat of five with four blocks inside it: output on, wait 500 ms, output off, wait 500 ms. If it gets something wrong the platform tells it exactly which block did not compile, and it fixes it; you see none of that unless you want to.

Open Macros in your app and there it is: Blink · your gateway · 5 steps, with a Run button. Click into it and read the steps — the part most "AI does your hardware" demos skip. An assistant that has never seen your rig gets the shape right and the specifics plausibly wrong — a pin, a duration — and plausible-and-wrong is exactly what you want to catch while the board is doing nothing.

Step 5 — Review it, then let it run

Ask Claude to run Blink. It won't. In our run it read the macro first, saw agentRunnable: false, and said so rather than calling the tool; had it called anyway, the platform's answer is worth quoting, because it is the whole design in five lines:

Macro "Blink" is not marked as agent-runnable, so this connection may not start it. That is a deliberate per-macro setting, separate from the permissions on this token: someone has to read the sequence and allow an agent to run it, in the Synacl app. Ask the user to do that if they want it. Do not look for another way to run it.

Running a macro needs two separate keys, and software can only ever hold one of them. The first is the Run macros permission on Claude's connection — the one that arrived unticked and that you ticked in step 3. Claude holds it, and it is still refused. The second lives on the macro itself: in the editor, below the triggers, a box labelled "Let an AI agent run this macro". It is off on every macro, including the ones an assistant wrote, and no assistant can tick it — the platform drops the field from any request that comes over the agent connection. A permission says which software may act; it cannot tell you whether this sequence is safe. So the platform asks you about the sequence, one at a time.

You have read Blink. Tick the box, save, and ask again.

This time the gateway acknowledges the run, and Claude tells you so: not "I sent it" but "the gateway confirmed it started". The card in Macros steps through requested → started → done, and the blue LED on GPIO 2 flashes five times. That was your relay. Swap the pin for the one your relay module is on and the same macro drives the coil.

Two honest notes. Claude waits a few seconds for the gateway's acknowledgement and reports unknown if it never comes — never done. And the run happened on the ESP32: the board timed the half-seconds itself and would have finished them with the Wi-Fi pulled — which is also why Abort is a network message, not an emergency stop.

Step 6 — Make it react to the light

Wire the BH1750 — 3.3 V, GND, SDA to GPIO 21, SCL to GPIO 22, ADDR to GND — then tell Claude about it and change the macro rather than writing a second one:

There is a BH1750 light sensor on I²C — SDA on GPIO 21, SCL on GPIO 22, address 0x23. Add it as a device, then change Blink so it first reads the light level and only pulses the relay for two seconds if it is darker than 20 lux. Rename it to Dark relay.

The sensor becomes an I²C device on those pins with a generic tag at address 0x23 — the BH1750 has no built-in driver, so Claude fills in the datasheet numbers: write 0x10 once to start continuous measurement, read two bytes, most-significant first, divide by 1.2 for lux. The I²C article lists those fields if you want to check them. Resend the config once more, and within a poll or two the lux tag is live; cover the sensor with your hand and watch the number fall. Then Claude rewrites the same macro: a read_tag block that puts the lux reading in a variable, an if on that variable, and the pulse inside it. Read it again — a changed macro is a new sequence, and the agent-runnable tick you gave Blink still stands, so this is your moment to check the threshold and the pin before anything moves. Then cover the sensor and ask Claude to run it: the LED pulses. Uncover it and run again: nothing happens, and the run still finishes cleanly — the macro read the sensor, decided, and stopped.

That last run is the thing a lot of people expect the platform to do differently, and it deliberately does not: a macro runs once per trigger. Dark relay reads the sensor one time, decides, and stops. It does not sit there watching the light. To make it a night-light that switches itself you give it a schedule — in the macro editor, every 30 seconds — or fire it from an alert rule on the lux tag. Either one takes you a minute in the app. Claude cannot do it. An assistant can write and edit macros, but it cannot put one on a schedule, wire it to a device event, or re-enable a disabled one; unattended runs are set up by a person, whatever permissions the assistant holds. A sequence that fires at three in the morning with nobody in the room stays your decision.

Once scheduled, the whole loop — read, compare, switch — runs on the board every thirty seconds whether or not the cloud can reach it, and every run is bounded by the gateway's own ten-minute ceiling.

What Claude cannot do, and why

It is one rule, drawn in one place: an assistant may author, a person must allow. Over this connection an assistant cannot:

Delete anything — devices, gateways, dashboards, rules or macros. It can create a duplicate; it cannot remove your data.
Send a raw command to a pin, coil or register. Anything that moves does so by running a macro you can read.
Arm a macro: no schedules, no device-event triggers, no re-enabling a disabled one.
Mark its own work runnable. The agent-runnable tick is set by a person, in the app, per macro.
Hold more than you ticked. Every refusal names the permission it lacks, so you can decide, not guess.

Your plan's macro allowance and the size of a macro are listed on the plans page; the free tier is enough for everything in this guide.

Said plainly: none of this is a safety function. The bounds are real — one gateway, one run at a time, ten minutes, an abort button — but they bound a mistake; they do not make a machine safe. Abort is a message over the network and cannot reach a gateway that is offline. Synacl is not safety-rated. If the thing on the other side of the relay can hurt someone or wreck something, the protection has to be physical and independent of the platform: a hardwired emergency stop in the power path, not routed through the ESP32; interlocks; a properly rated relay; an actuator whose worst case is survivable. Grant Run macros for the things you would be comfortable letting a colleague start from the next room.

Where to go next

The same three pieces — a browser flash, an assistant over MCP, macros on the board — scale from a blinking LED to a Modbus meter and a pump. For the industrial version of this walk — an RS485 sensor on the same gateway, readings on a dashboard with an alert — read ESP32 Modbus RTU to a cloud dashboard in 15 minutes. The macro recipes show what the blocks can do by hand, and the Macros article has the limits and the safety notes in one place.