✨ Homey MCP Server | Megathread

Official Announcements
104

Feature request: resolution parameter missing on Insights getLogEntries via MCP

I’m using the official Homey MCP server (mcp.athom.com) with Claude to compare Insights boolean-log events (e.g. alarm_offline) against an external log.

The MCP tool that wraps ManagerInsights.getLogEntries only accepts logId — it doesn’t expose the resolution query parameter that the underlying Web API supports (last24Hours, last31Days, lastWeek, lastMonth, last2Years, etc. — see ManagerInsights docs).

Without it, repeated calls — even hours/days apart — return an identical, fixed ~50-entry window that never reaches “now”. So I can’t retrieve recent Insights events through the MCP tool at all, only whatever fixed historical slice it happens to return.

Could the MCP server pass through a resolution (or start/end) parameter on the Insights log-entries tool, so agents can request a specific/recent time range?

Happy to share more repro details if useful.

105

Hi,

I’m experiencing a persistent issue with the official Homey integration in ChatGPT when ChatGPT tries to retrieve the Flow Trigger Card catalogue.

The Homey MCP call list_flow_trigger_cards consistently fails with:

INVALID_ARGUMENT: Invalid structured content for tool list_flow_trigger_cards

The relevant validation error is:

Expected string, received null

at paths such as:

cards[1353].args[0].values[0].title

cards[1353].args[0].values[1].title

cards[1384].args[0].values[0].title

There are multiple affected cards/values.

It appears that Homey returns one or more Flow Trigger Cards containing an argument with values[] entries where title is null, while the MCP schema requires:

title: string

Because validation fails on these entries, ChatGPT cannot retrieve any of the Flow Trigger Card catalogue.

Impact

Other Homey MCP functionality continues to work. ChatGPT can:

  • read devices and their capabilities
  • read existing Advanced Flows
  • inspect cards and connections inside an Advanced Flow
  • retrieve current sensor/device values

However, because list_flow_trigger_cards fails, ChatGPT cannot safely create/update Advanced Flows, as retrieving the Flow Card catalogue is required before performing these writes.

Troubleshooting already performed

  • Restarted Homey
  • Disconnected and reconnected the ChatGPT/Homey integration
  • Deleted the Advanced Flow that initially appeared to be involved
  • Confirmed other Advanced Flows work normally in the Homey editor
  • Restarted several Homey apps individually, including:
    • Toros Vision
    • Better Logic Library
    • < group >
    • Smart Gateways
    • Solar Forecast
    • Enphase Controller
    • Tuya Cloud
    • Aqara

The error persists.

Restarting apps sometimes changes the numerical index of the affected cards (for example from ~1620 to ~1460 and later ~1353), presumably because the catalogue is rebuilt, but the same values[].title = null validation error remains.

Possible cause

This looks like a schema/serialization compatibility issue between Homey’s Flow Card data and the MCP response schema rather than an Advanced Flow problem itself.

If null is valid/possible for a Flow Card value title on the Homey side, perhaps the MCP schema should accept:

title: string | null

Alternatively, the MCP server could normalize a null title to a string/fallback value or skip malformed entries instead of failing the complete Flow Trigger Card catalogue.

It would also be very useful if the error exposed the Flow Card ID / app ID, rather than only its numerical position in the returned cards[] array. That would make identifying the originating app/card much easier.

Is this a known issue with the official Homey MCP server / ChatGPT integration?

I’m happy to provide additional diagnostics or test a fix.

106

Im Also getting constant issues with Chat GPT. I have on several occassions reauthorised the connection. Chat GPT says it can read all my flows/devices etc and then starts to do what i ask.

I then get connection times out, FORBIDDEN REQUEST, unable to connect.

Basically its stopped working and i dont know why.

Any suggestions?

Thanks

107

Further up in this thread I already suggested an alternaitve.
See: ✨ Homey MCP Server | Megathread - #98 by 4x4_Pete

I had also been asking Athom multiple times (aalso through a support ticket) to improve things and tried to get some general insights into Athom´s AI strategy from @Doekse … - But never got anywhere.

So my recommendation is: When it comes to AI, forget about Athom. They are either not interested in this topic or have neither plans nor ideas. Find yourself a community alternative like the one suggested above.

108

Can it also create Advanced Flows and move them into subfolders?

The official MCP has low rate limits and unfortunately cannot do so in subfolders.

109

Yes. - And much more.
Check this

And this

110

@4x4_Pete Not working :frowning:. However, the app page stated that Homey Pro 2019 is supported. I asked about it in the app’s thread. Just in case anyone here wanted to give it a try.

image
image761×917 122 KB

111

Hi Dominik, sorry about that, and thanks for the screenshots. The store page was wrong, not your Homey.

The bridge only runs on Homey Pro (Early 2023), Homey Pro (2026), Homey Pro mini and Homey Self-Hosted Server. There is no setting to get around it on the 2019. You can safely uninstall it: it never started, so it left nothing behind.

Why not the 2019? The bridge talks to Homey through the newer local Homey API. A Homey Pro (Early 2019) offers the older version of that API, which is what the “platformVersion 1” in the message means. Devices, flows and settings come back in a different shape there, so every one of the 173 tools would need its own translation layer. The flow tools differ the most, and those are exactly the ones you were after. On top of that I don’t own a 2019, so I couldn’t test any of it properly. I’d rather not ship something I can only guess works.

The “Works on” list showed every model because the app only stated a firmware range, and your 2019 runs the same firmware numbers as the newer models. Version 4.20.3 fixes that: the store now only offers the app to the Homeys that can actually run it, so nobody else on a 2019 or older installs it for nothing.

For what you were after, on a supported Homey: the bridge runs on the Homey itself, so the cloud limits of Athom’s own MCP do not apply, and it can create an Advanced Flow straight into a folder (and create the folder first if needed). Sadly that doesn’t help on the 2019.

112

**Homey MCP Server returns `200` for expired tokens, which breaks OAuth MCP clients**

Hey,

I’m using the official Homey MCP Server (https://mcp.athom.com) from an OAuth-capable MCP client.

After the access token expires (~61 min, the server issues expires_in=3660), every tool call fails with:

The access token provided has expired.

…and the client never recovers on its own, even though the **refresh token is still valid and works**. The refresh endpoint returns a brand new token set when I call it manually, so the only problem is the error signalling.

The server answers an expired/invalid token with **HTTP 200** and a JSON-RPC result containing isError: true, instead of **HTTP 401**:

# expired token -> 200 (should be 401)

200 {"result":{"content":[{"type":"text","text":"The access token provided has expired."}],"isError":true},"jsonrpc":"2.0","id":1}

# no auth header -> 401 (correct)

401 {"error":"Missing Authorization Header"}

Per RFC 6750 §3.1 (and the MCP authorization spec), a protected resource that rejects a token should return 401 Unauthorized with a WWW-Authenticate: Bearer error="invalid_token" header. That is the signal clients use to discard the token and refresh or re-authenticate.

Because that signal is missing, any client that gates its OAuth refresh on a 401 keeps sending the dead token indefinitely – and still reports the server as connected, so the failure is silent to the user. This affects every conformant MCP client, not just one.

**Request:** when the access token is expired or invalid, please respond with 401 + WWW-Authenticate: Bearer error="invalid_token", resource_metadata="``https://mcp.athom.com/.well-known/oauth-protected-resource``" instead of 200 + isError.

This is likely the same root cause behind the ChatGPT connector reports where the connector shows a green checkmark but doesn’t work.

I can provide the full probe output if useful. Thanks!