TapHome
Utilities & PersonalConnect AI agents to TapHome, a smart home automation system. Agents read device values and send control commands so a flow can act on and change the state of a building.
What This Integration Enables
Most smart home APIs hand you a device list and some verbs, and leave you to guess what a value means or whether you are allowed to set it. TapHome does not, and that is the reason this connector is unusually safe to put an agent behind. Discover Devices returns every device exposed under Exposed devices and TapHome API on the Control unit, and each one carries its numeric deviceId, its hardware type, its zone meaning the room, its category, and the full set of supportedValues. Each supported value reports its valueTypeId and valueTypeName, a readOnly flag, a minimum and maximum, and its enumerated values where it has them. The installation describes itself, including which of its own values it will refuse to let you write. An agent that reads that schema before acting is working from the building's own account of what it is, not from a hardcoded map that went stale the last time an electrician added a circuit.
The read surface is built for the two shapes a flow actually needs. Get Device Value reads one device by deviceId and returns every exposed value unless a valueTypeId narrows it to one. Get Multiple Devices Values takes an array of targets, each a deviceId with an optional valueTypeId, and returns each requested device with its values plus any per-device errorCode and message, which matters because a partial failure across twenty devices should not look like a total one. Get All Devices Values returns the complete current state of every exposed device in a single call, which is the right first move for a flow that wants a snapshot and does not need the schema. Get Location Info returns the Control unit's locationId as a GUID, its locationName, the TapHome API version, and the current server timestamp, which is how a flow confirms it is talking to the installation it thinks it is before it changes anything in it.
Then there is one write. Set Device Value sets one or more values on a single device: switching a light, setting a dimmer level, opening blinds, changing a thermostat setpoint. It takes the numeric deviceId, the primary valueTypeId and its numeric value, and optionally additional valueTypeId and value pairs to apply in the same command. Values are numeric doubles whose meaning depends entirely on the value type, so 1 is on for a switch and full for a dimmer that runs 0 to 1, and nothing in the payload distinguishes an intended 1 from a mis-scaled one. Only value types with readOnly set to false in discovery can be set at all.
Two timing facts belong in every flow built here. Reads faster than every 500 ms may return cached values, so an immediate verification read after a write can hand back the old number and look like a command that failed. And setDeviceValue accepts at most one command per device every 500 ms, so a loop writing several values to one device should use the additional pairs on a single call rather than issuing them in sequence. There are no triggers on this connector. TapHome does not push state changes into a flow, so a flow that reacts to the building polls it, and a flow that changes the building is started by something else entirely: a schedule, a booking, an alarm, or a person.
Without FlowRunner
With FlowRunner
Use Case Scenarios
A building that follows the calendar instead of the clock
Fixed schedules waste energy on the days nothing is booked and leave rooms cold on the days something is. A flow reads tomorrow's bookings from Google Calendar, maps each room to its TapHome zone using the zone field that Discover Devices already reports, and builds the day's plan: heating brought up before the first booking in each occupied zone, setbacks left in place everywhere else, lighting following the same pattern. Ahead of each transition it calls Get Multiple Devices Values for just the devices in that zone to confirm the current state, then Set Device Value with the setpoint. Because the discovery response carries the min and max per value type, the flow can reject a computed setpoint that falls outside what the device accepts rather than sending it and reading an error. The building stops heating empty rooms without anyone maintaining a second schedule by hand.
The state of the site, answered without walking it
Somebody asks whether the west wing is heating, whether the server room cooling is holding, or whether the blinds on the south face went down during the heat warning. Today that is a walk and a panel. A flow calls Get All Devices Values on a schedule and writes the full snapshot to Google Sheets with a timestamp, giving a queryable history of the whole installation without a building management system in front of it. A second pass compares each reading against the expected band for that device and zone, and posts anything outside it to Slack naming the zone and the device rather than the numbers: a room that has not reached setpoint after two hours of demand, a circuit that reads on outside its hours. The reading is cheap. The value is that somebody sees the drift on the day it starts rather than on the utility bill.
Faults that reach the right person with the state attached
An alarm arrives from a monitoring system, or a tenant reports that a room is cold. The flow calls Get Location Info to confirm which installation it is working against, Discover Devices to resolve the affected zone's devices and their supported value types, and Get Multiple Devices Values to capture the current readings across that zone in one request, handling any per-device errorCode individually rather than failing the whole call. It opens an incident in PagerDuty with the zone, the device list, and the readings already in the description, so the engineer who picks it up starts from state rather than from a phone call. Where the fix is a value change the flow could make itself, it proposes it rather than applying it, which is the subject of the next section.
Human-in-Loop Highlight
Set Device Value is the only write on this connector and it does something no other write in a catalog does: it changes a physical space that people are standing in. A dimmer goes dark, blinds close, a thermostat setpoint drops, and the people affected did not ask for it, cannot see the flow that did it, and in most cases have no idea a flow exists. What makes that harder to guard is the payload. Values are bare numeric doubles whose meaning depends on the value type, so nothing in the request distinguishes a dimmer set to 1 meaning full brightness from a switch set to 1 meaning on, or from a value that was computed on a percentage scale and should have been 0.01. The discovery response reports readOnly and min and max, so the connector can tell an agent what it is permitted to set, and it cannot tell it what it ought to. And verification is not available in the moment: reads faster than every 500 ms may return cached values, so the confirming read straight after a write can return the previous number and look exactly like a command that did not land. The consequences are not evenly distributed either. A corridor light set wrong is an annoyance. A server room cooling setpoint raised overnight, a heating circuit dropped in a space with a vulnerable occupant, or blinds closed across an escape route are a different category of mistake and none of them announce themselves. So the agent draws the line at occupancy and at range. It resolves every intended write through Discover Devices into names a person recognizes, checks each target against the min and max the device reports, and where the zone is currently occupied or the value falls outside the band the site normally runs, it stops and asks the facilities owner: "Evening setback for the west wing. 14 devices. 11 are within the normal band and unoccupied. Two exceptions: Meeting Room 3 heating setpoint 21.0 to 16.0, the room is booked until 20:00; Comms Room cooling setpoint 18.0 to 22.0, which is outside the range this device has run in the last 30 days. Apply all, apply the 11, or hold?" Everything unambiguous runs on its own. The human-in-the-loop gate exists for the two writes a person would have questioned, which is exactly the pair a threshold would have waved through.
Agent Capabilities
6 actionsDiscovery
2- Discover Devices Lists every device the TapHome Control unit exposes under Exposed devices and TapHome API. Each device carries its numeric deviceId, hardware type, zone meaning room, category, and the full set of supportedValues with valueTypeId, valueTypeName, a readOnly flag, min and max, and enumerated values. This is where a flow learns both what it can read and what it is permitted to set.
- Get Location Info Returns identification and status for the Control unit the API token belongs to, including its locationId as a GUID, locationName, TapHome API version, and the current server timestamp. Use it to verify connectivity and confirm which installation the token controls before writing to it.
Device Values
3- Get Device Value Reads the current values of a single device by its numeric deviceId, returning every exposed value unless a specific valueTypeId narrows the result to one. Values are numeric doubles, and the API serves cached values for reads faster than every 500 ms.
- Get Multiple Devices Values Reads current values for a specific list of devices in one request. Provide an array of targets, each with a deviceId and an optional valueTypeId, omitting the valueTypeId to return all of that device's values. Returns each requested device with its values plus any per-device errorCode and message, so a partial failure stays visible instead of collapsing the whole call.
- Get All Devices Values Returns the complete current state of every device exposed to the TapHome API in a single call, each device with all of its values. Use it for a full snapshot of the installation without first calling Discover Devices.
Device Control
1- Set Device Value Sets one or more values on a single device to control it, covering switching a light on or off, setting a dimmer level, opening blinds, or changing a thermostat setpoint. Provide the numeric deviceId, the primary valueTypeId and its numeric value, and optionally additional valueTypeId and value pairs to apply in the same command. Only value types with readOnly set to false in discovery can be set, and the API accepts at most one setValue command per device every 500 ms.
Frequently Asked Questions
What can FlowRunner do with TapHome?
FlowRunner agents can run Discover Devices, Get Location Info, and Get Device Value in TapHome, plus 3 more actions.
Does connecting TapHome to FlowRunner require OAuth?
No. TapHome connects to FlowRunner with an API key, no OAuth flow required.
Can TapHome trigger a FlowRunner workflow automatically?
TapHome doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with TapHome
$100 in credits. No card required. Connect in minutes.