Arduino IoT Cloud
Developer ToolsConnect AI agents to the Arduino IoT Cloud, where connected devices publish and receive properties. Agents read sensor properties, write control values back to devices, list registered things, and pull time series history for analysis.
What This Integration Enables
The Arduino IoT Cloud is a property store, not a device shell, and that constraint is the most useful thing about it for automation. A flow cannot run arbitrary code on a board. It can read and write cloud variables, which the sketch running on the board already knows how to interpret. Every capability here goes through that model: List Things and Get Thing describe the logical device, List Properties and Get Property describe its variables, Set Property Value publishes a value to the board, and Update Property edits a property's configuration rather than its value.
That distinction is the reason this integration is safe enough to give an agent at all. The person who wrote the sketch decided what a property named setpoint or pumpEnable means and which values the board will act on. FlowRunner is not inventing device behaviour, it is participating in a contract someone already defined in firmware. Set Property Value only works on properties carrying READ_WRITE permission, and the value must match the property's declared type, meaning a boolean for a switch with STATUS type, a number for numeric properties, and a string for text or colour properties. A read-only sensor property simply cannot be written, which removes an entire category of mistake before a flow is ever built.
The history side is where agents earn their place. Get Property Time Series returns aggregated historical data with a choice of average, minimum, maximum, sum, count, or the 95th and 99th percentiles, capped at 1000 data points per response. Get Properties Last Values returns the latest stored values for several properties at once, which is how a flow surveys a fleet cheaply rather than walking it device by device. Both only return data for properties that have persistence enabled, so persistence is a design decision made before the flow exists, not a setting a flow can turn on. Get Device Events reports what has happened to the hardware itself, which is a different and often more urgent signal than the readings.
There are no triggers. The Arduino Cloud exposes per-thing webhook fields but no subscription management or event callback API that FlowRunner can register against, so nothing here fires on its own. A flow polls on a schedule, and Arduino rate limits to roughly 10 requests per second per authenticated client, which sets the pace of a fleet sweep. Requests can be scoped to an organisation space rather than a personal one, which matters when the boards belong to a company rather than to whoever set them up.
Without FlowRunner
With FlowRunner
Use Case Scenarios
A cold chain that reports itself, and stops itself
A distributor runs temperature and humidity sensors on Arduino boards across several storage rooms. Every fifteen minutes a flow calls Get Properties Last Values across the whole fleet in one request, which is far cheaper than iterating things. Anything outside its band gets a follow-up call to Get Property Time Series over the previous six hours, aggregated by average and by 95th percentile, because a single spike from a door being opened is not the same event as a compressor slowly losing its grip. Readings and their aggregates are appended to Google Sheets for the quality record, and a genuine excursion posts to the operations channel in Slack with the trend attached rather than a bare number. Nothing is switched anywhere. This half of the workflow is entirely read, and it is where most of the value sits.
Catching the board before it stops reporting
Sensors do not usually fail loudly. They reconnect a little more often, then a little more, then one day the last value stops moving and nobody notices for a shift. A daily flow walks List Devices, calls Get Device Events on each, and counts connection events over the window. Boards showing a rising reconnection count are written into a maintenance queue in Jira with the event history attached, ahead of any reading looking wrong. This is what an agent is genuinely good at and a person is genuinely bad at: noticing a slow change in something nobody was asked to watch.
Building the operations view somewhere other than the dashboard
The Arduino Cloud has dashboards, and they are the right place to look at one thing. They are the wrong place to answer a question that spans the fleet and the business. A weekly flow calls List Dashboards and Get Dashboard to read how the team has chosen to group properties, then uses those groupings to structure a report. Get Property Time Series runs for each property in each widget, aggregated by average and maximum, and the result is written into a reporting sheet alongside production volumes pulled from the ERP. The team keeps their dashboard. The people who never open it get the summary that answers their question.
Human-in-Loop Highlight
Set Property Value is the only action in this connector that changes the physical world, and it deserves a gate that most cloud writes do not, for a reason specific to how this API works. The connector knows a property's name, its type, and whether it is READ_WRITE. It does not know what is wired to it. A boolean property called heaterEnable might drive a small resistive element on a test bench or a three phase contactor in an occupied building, and nothing in the Arduino Cloud API distinguishes those two cases. Worse, there is no acknowledgement path: the write publishes a value to the board, and Get Properties Last Values afterwards reports the stored cloud value, not confirmation that the board received it and acted. If the device is offline the flow can be entirely correct and entirely ineffective, and it will not be told. So an agent should carry the write right up to the edge and stop. It reads the history through Get Property Time Series and confirms with Get Device that the board is currently connected. It checks Get Device Events for recent reconnections that would make the reading suspect. Then it asks the engineer on call: "Room 3 has averaged 6.2 degrees over the last 6 hours against a 4 degree setpoint, 95th percentile 7.1, board online and stable since Tuesday. Set compressorBoost to true?" A person answers, and only then does the value publish. This is human-in-the-loop doing what it is for: the agent brought the evidence, and a person who knows what is on the other end of that property made the call.
Agent Capabilities
14 actionsThings
2- List Things Lists the things registered in the space, meaning the logical devices that own cloud properties. The entry point for any fleet-wide flow.
- Get Thing Retrieves one thing with its configuration and the properties attached to it. Used to resolve what a device actually exposes before reading or writing anything.
Properties
4- List Properties Lists the cloud properties defined on a thing, including their type and their permission. The way a flow finds out which properties it is allowed to write before it tries.
- Get Property Retrieves one property with its current value, type, and permission. Worth calling before any write, because the permission and the type decide whether the write can succeed at all.
- Set Property Value Publishes a value to the board, and the core device-control action in this connector. Only works on properties carrying READ_WRITE permission, and the value must match the property's type: a boolean for a STATUS switch, a number for numeric properties, a string for text or colour properties. This is the action that moves physical hardware.
- Update Property Edits a property's configuration rather than its value. A different and more consequential operation than setting a value, because it changes the definition every future read and write depends on.
Devices
4- List Devices Lists the physical devices registered in the space. Distinct from things: a device is the hardware, a thing is the logical model attached to it.
- Get Device Retrieves one device, including its connection state. The check a flow makes before a write, because a value published to an offline board goes nowhere and reports no error.
- Get Device Properties Returns the properties associated with a device, approached from the hardware side rather than the thing side.
- Get Device Events Returns the device's own event history, including connection events. The signal that catches a board which is degrading rather than one that has already failed.
Dashboards
2- List Dashboards Lists the dashboards defined in the space. Useful because dashboards encode how the team has decided to group properties, which is often the best available map of what matters.
- Get Dashboard Retrieves one dashboard with its widgets and the properties they display.
Time Series
2- Get Property Time Series Returns aggregated historical data for a property, with aggregation by average, minimum, maximum, sum, count, or the 95th and 99th percentiles, capped at 1000 data points per response. Only returns data for properties with persistence enabled. This is how a flow tells a trend from a spike.
- Get Properties Last Values Returns the latest stored values for several properties at once. The efficient way to survey a fleet in a single request rather than iterating things, and also limited to properties with persistence enabled.
Frequently Asked Questions
What can FlowRunner do with Arduino IoT Cloud?
FlowRunner agents can run List Things, Get Thing, and List Properties in Arduino IoT Cloud, plus 11 more actions.
Does connecting Arduino IoT Cloud to FlowRunner require OAuth?
Arduino IoT Cloud uses a custom authentication method to connect to FlowRunner.
Can Arduino IoT Cloud trigger a FlowRunner workflow automatically?
Arduino IoT Cloud doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Arduino IoT Cloud
$100 in credits. No card required. Connect in minutes.