An advanced flow is a graph of cards rather than one trigger and a list of actions: branches, parallel paths, joins, delays and error handlers. Give each card your own label and refer to those labels in the output lists; real ids are generated before sending. To use a value another card produced, write [[trigger::<that card's label>::]] or [[action::::]]. The [[owner|token]] form used in standard flows does not name a card and will not work here. The flow is created switched OFF and inside the "AI" folder, then read back and compared with what was sent.

An advanced flow is a graph of cards rather than one trigger and a list of actions: branches, parallel paths, joins, delays and error handlers. Give each card your own label and refer to those labels in the output lists; real ids are generated before sending. To use a value another card produced, write [[trigger::<that card's label>::]] or [[action::::]]. The [[owner|token]] form used in standard flows does not name a card and will not work here. The whole graph is replaced, so every card that should survive has to be sent again: read the current one with homey_flow_get first. A flow this server did not create needs confirm: true. Switching a flow that is off ON needs confirmEnable: true.

Signs this server in to the Homey, or confirms that it already is. Call this when any other tool reports that the server is not signed in. A Homey session lasts 24 hours, so a server that has been running for a day needs this rather than a restart. It does not ask for a password or a token and never handles one: the user signs in with Athom directly, and this picks up the result. If it reports that it could not sign in, read the instructions it returns to the user verbatim. They name the exact commands, and which of the two routes keeps working after 24 hours.

Full detail for a single device: every capability with its live value, whether it can be set, its unit, decimals and allowed range, the energy block, and which Insights logs exist for it. Each of those logs carries a logId that homey_insights_query takes as is, so this is the route from a device to its own history. Accepts a device id or a device name. Read the min and max here before calling homey_device_set_capability: several capabilities are a 0..1 fraction despite reading as a percentage.

Changes one capability of one device, for example onoff, dim or target_temperature. This physically changes something in the house. Beware the percentage trap: dim, light_hue, light_saturation, light_temperature, windowcoverings_set, volume_set and fan_speed report their unit as a percentage but take a fraction between 0 and 1, so 60 percent is 0.6. A value outside the capability range is clamped to it and the clamp is reported. Call homey_device_get first when unsure of a range or of which capabilities can be set.

Finds devices by zone, class, capability or name, and optionally returns their live values. Set includeCapabilitySummaries to answer a question like "what is the state of the living room" in one call. Every filter is combined with AND. Results are projected down to what is useful for reasoning: protocol settings, icons, images and interface layout are never returned. The Homey API cannot paginate, so paging happens here: use offset with limit and check truncated.

Reports what is and is not working between this server and your Homey: which kind of address answered and how it was chosen, which kind of credential source was used (never the credential itself), the hardware model and firmware, which features this Homey generation actually supports and why, whether the official Homey CLI is installed and signed in (which is what decides whether flows can be created), and how much of the home has been read so far. Call this when another Homey tool fails, or before reporting a problem. Every check comes with a concrete next step. Safe to paste into a public issue: no device, zone or household names, no network addresses, no Homey id and no file paths. Run "npx homey-mcp doctor" in a terminal for the version that keeps those.

Reads what the home is drawing right now, in watts, broken down by room and by device, together with the whole-home meter reading and the load Homey cannot attribute to anything. Instantaneous only: for history use homey_insights_query on a meter_power log (a cumulative kWh counter, where consumption is the difference between its endpoints) or a measure_power log (instantaneous watts, where energy is the area under it). Homey Pro (Early 2019) has no historical energy report endpoints at all, so Insights is the only history there.

Asks the Homey what a device-typed or autocomplete-typed argument can be set to, and returns the choices. Store the WHOLE object of the chosen result as the argument value. Cards keep app-specific fields next to the id and the name, for example a Google Cast action stores the host and description alongside them, and rebuilding the object by hand loses those and breaks the card.

Returns everything needed to use one flow card: every argument with its type and allowed values, the values the card emits for later cards to read, whether it accepts a dropped value, and whether it is deprecated. The arguments come back under arguments, the same field homey_flowcards_search reports with only the name and type of each; here every entry additionally carries its title, whether it is required, its allowed values and range, and how to resolve it. The values you then set on the card are sent as args, keyed by those argument names. arguments is the schema, args is what you fill in. Call this for each card before building a flow. Guessing an argument name produces a flow that saves and then does nothing.

Finds the flow cards available on this Homey. Flow cards are the building blocks of a flow: a trigger card starts it, condition cards decide whether it continues, and action cards do something. This Homey exposes hundreds of cards, so at least one filter is required: a search term, a device, an owning app or manager, or an owner uri. An unfiltered call is refused. Results carry only enough to choose a card: the id under cardId, which every other flow tool takes under that same name, and the arguments the card declares under arguments, with the name and type of each. Call homey_flowcard_describe with that cardId for the rest of each argument, which is what you need before using the card in a flow.

Builds a new flow. It is created switched OFF and inside a folder called "AI", so nothing happens in the house until the owner has read it and switched it on. The flow is validated first and refused outright if anything is wrong, then read back from the Homey and compared with what was sent. The result carries a link to it in the Homey app.

Deletes a flow, standard or advanced. The Homey has no undo, so the flow exactly as it was is returned in the result and can be rebuilt from it. A flow this server did not create needs confirm: true.

Creates a folder to organise flows in, optionally inside another one. Returns the id, which is what homey_flow_move takes. Names are not unique on a Homey, so check homey_flow_folders_list first rather than creating a second folder with a name that already exists.

Removes an empty flow folder. The Homey refuses to delete one that still contains flows, so move them out first with homey_flow_move. Deleting a folder never deletes a flow.

Lists every flow folder with how many flows sits in it, as a tree: folders can contain folders. Flows outside every folder are reported separately. Use this before moving anything, because folder names are not unique and only the id addresses one for certain.

Renames a flow folder, moves it inside another one, or both. The flows in it are untouched and keep working. Send parent as null to move a folder back to the top level.

Returns everything one flow contains: its trigger, conditions and actions with their arguments, or for an advanced flow the whole graph of cards. Every card is resolved to its title so the flow can be read as a sentence, and a card that no longer exists is marked.

Moves one or more flows into a folder, or out of every folder when folder is null. Takes flow ids or exact names. This changes where a flow lives and nothing about what it does: it keeps its cards, and a flow that was running stays running. The folder each flow came from is reported, so a move can be undone from the result.

Lists the flows on this Homey, standard and advanced together. Filter by name, folder, kind or state. Use homey_flow_get to see what one flow actually does.

Runs an existing flow immediately, exactly as if its trigger had fired. This is a real execution and not a preview: a flow can unlock a door, open a window covering, turn on the heating or send a message. Read the flow with the flow tools before starting it if you are not certain what it does. Works for both standard and advanced flows.

Lists every token on this Homey with the value it holds right now. A token is anything a flow card can drop into a text argument: a device capability, a logic variable, or a tag published by an app. This is how to read back a tag a script has written, which is otherwise only visible in the Homey app. The "id" it reports is what a reference must name: [[|]] in a card argument. Use it with homey_flow_validate, which checks references against exactly this list.

Replaces the trigger, conditions and actions of an existing standard flow. Anything left out keeps its current value, but an array that IS sent replaces that array wholesale. A flow this server did not create belongs to the owner and needs confirm: true. The flow as it was is read first and returned in the result, so a wrong change can be put back by sending it again. Switching a flow that is off ON is a separate step that needs confirmEnable: true, because a flow that is off has never run in the house.

Checks a flow against this Homey without writing anything and without running anything: every card exists and is the right kind, every argument is named and typed correctly, every device and zone it names is still here, and every [[token]] reference names a value this Homey actually publishes, whether that is a device capability, a logic variable or a tag from an app. Worth calling first, because the Homey itself accepts almost anything. A flow naming a card that does not exist saves and shows as "NO CARD"; a token written with a colon instead of a pipe, or naming a tag that was never published, saves and shows as "Unavailable". Neither reports an error. The one thing it cannot judge is whether the flow does what the owner meant.

Orients you in this Homey in one call: the zone tree with device counts, device counts by class, the most common capabilities, devices that are currently unavailable, installed apps, logic variables, household presence, flow counts, and what this Homey generation can actually do. Call this before any other Homey tool. It returns counts and names rather than full device records, so use homey_devices_search or homey_device_get afterwards for actual device state. Narrow it with include when you only need one part.

Fetches up to five Insights series at one resolution and returns statistics computed over them: min, max, mean, median, first, last and delta, plus the true window and step the hub answered with and the share of it that actually carries samples. Gaps are skipped rather than filled in, so always read the coverage next to an average. Use compareWith to fetch a second window and get the differences, which is what questions like "warmer than last week" need. Energy logs are summarised correctly for their kind: meter_power is a cumulative counter, so consumption is the difference between its endpoints, while measure_power is instantaneous watts, so energy is the area under it. Find log ids with homey_insights_search first.

Finds Insights logs (sensor and meter history) by fuzzy matching over room name, device name, log title, capability id and units. A Homey carries well over a hundred logs, titled in the household's own language, so start here: this is how "the living room temperature sensor" becomes a log id you can query. Returns candidates with their ids and never guesses which one was meant.

Creates a new script and returns the id the Homey assigned to it. Use that id afterwards: the name is not an address, and two scripts may share one. The script runs on the Homey, so it has the Homey API available as Homey, writes output with log(), and can hand a value back to the Flow that started it with return or tag(). Write scripts to be reusable. Take what varies as an argument rather than baking it in: the HomeyScript Flow card passes text into the script as args[0], so one script can serve several Flows and several rooms. Prefer looking a device up by what it IS over what its id is, for example by zone and capability, so the script survives a device being replaced. Prefer returning a value and letting the Flow act on it over acting inside the script. A script that answers "should I open the window" can be reused; one that also opens the window cannot. A hard-coded device id is acceptable when there is genuinely no other way, or when a lookup would be more fragile than the id. It is the exception, and it is worth a comment saying why. This server cannot see log() output: it goes to the HomeyScript app console and no route here reads it. What comes back is the return value, so return whatever needs checking rather than logging it. While a script is being written, return an object with the intermediate values in it; trim it to the real answer once it works. Run it with homey_script_run once created, because a script that has never run is a script nobody has checked.

Removes a script from the Homey. It is gone: there is no undo, and any Flow that started it stops working. The code is returned in the result, so it can be recreated from this answer if that turns out to be a mistake.

Returns one script including its code. Takes the id or the exact name, as reported by homey_scripts_list.

Runs a script on the Homey now and reports what it returned. A script that throws is reported here as a normal answer with the error and the line it happened on, so this is also how a script gets debugged. This server cannot see log() output: it goes to the HomeyScript app console and no route here reads it. What comes back is the return value, so return whatever needs checking rather than logging it. While a script is being written, return an object with the intermediate values in it; trim it to the real answer once it works. It really runs: anything the script does to the house, it does.

Lists every HomeyScript script on this Homey with its id, name, version and when it last ran. Scripts are small pieces of JavaScript that run on the Homey itself and can be started from a Flow, which is how logic that a Flow card cannot express gets done. Returns no code: read one script with homey_script_get.

Replaces the code of a script that already exists, found by id or exact name. The previous code is returned so the change can be undone from the result alone. Write scripts to be reusable. Take what varies as an argument rather than baking it in: the HomeyScript Flow card passes text into the script as args[0], so one script can serve several Flows and several rooms. Prefer looking a device up by what it IS over what its id is, for example by zone and capability, so the script survives a device being replaced. Prefer returning a value and letting the Flow act on it over acting inside the script. A script that answers "should I open the window" can be reused; one that also opens the window cannot. A hard-coded device id is acceptable when there is genuinely no other way, or when a lookup would be more fragile than the id. It is the exception, and it is worth a comment saying why. This server cannot see log() output: it goes to the HomeyScript app console and no route here reads it. What comes back is the return value, so return whatever needs checking rather than logging it. While a script is being written, return an object with the intermediate values in it; trim it to the real answer once it works.

Creates a new logic variable. Use this when an automation needs to remember something between runs, or to hand a value from one flow to another. A logic variable is the better choice over a tag published from a script whenever a person may want to see or change the value: logic variables appear in the Homey app, can be set by hand, and are readable here through homey_home_overview. Exactly three types exist: string, number and boolean. The type is fixed once created and the value must match it. It is created with the value given, so pick a starting value the house can live with: flows may read it immediately. Creating something the owner did not ask for clutters their Homey, so confirm is required.

Writes a new value to an existing Homey logic variable. A variable is one of exactly three types: string, number or boolean, and the new value has to match the type the variable already has. Flows read these variables, so changing one can change what the house does next. This tool never creates a variable; use homey_home_overview to see which ones exist.

Reads the outdoor weather Homey itself uses: temperature, humidity, air pressure, a readable sky description, and the name of the town the reading is for, plus the forecast, in one call. Use it to compare outdoors against indoors (pair it with homey_device_get on a room sensor), to answer whether opening a window would help, or to look ahead to tonight's low. Humidity is returned as a percentage from 0 to 100: Homey's own field is a 0 to 1 fraction and is converted here. Temperature is in whatever unit this Homey is configured for, echoed as temperatureUnits, and pressure is given in bar with the millibar (hectopascal) equivalent beside it. Forecast granularity depends on the hardware and is stated explicitly in every result: a daily forecast is always returned, each day carrying its expected, minimum and maximum temperature, where the minimum is effectively that night's low, while an hourly forecast is included only when this Homey offers one and its absence is reported as a plain statement rather than as an error. What it cannot do: it is one reading for one location, the town it names, taken from Homey's weather provider rather than from any hardware in this house, so it is not a substitute for an outdoor sensor in the garden and says nothing about conditions in any individual room. The sky description arrives in the Homey's own language. For outdoor history rather than the present, look for the logs owned by homey:manager:weather with homey_insights_search and query those.