It again looks like a discovery/session/runtime bridge issue, with the following pattern:
Resources are briefly discovered correctly.
A first call succeeds.
After that, other paths that were previously visible and registered fail with Resource not found.
Then discovery disappears completely again.
For a permissions issue, I would expect something more like an auth/OAuth/access-denied error.
For a schema issue, I would expect argument validation errors.
Neither of those happened here.
Having a couple of odd issues using the Homey MCP server with opencode …
The mcp server is defined in ~/.config/opencode/opencode.jsonc
“mcp”: {
// Main Athom-built mcp server - has some limitations
“homeypro”: {
“type”: “remote”,
“url”: “https://mcp.athom.com”,
“enabled”: true
},
:
I auth with opencode mcp auth homeypro which opens a browser to select the Homey Pro and allow access. It create a ~/.local/opencode/mcp-auth.json with
Agents in opencode are able to access it with no problem. Except the token expires quickly, seems like less than an hour. Doing auth with opencode mcp auth homeypro again says it’s expired, it re-auths, but doesn’t actually re-auth. I have to delete the mcp-auth.json first.
The other major problem is rate-limiting. I have a script that pulls the json for each flow, and it can only grab about 12 before it gets hobbled with "Too many requests …
[MCP] Listing available tools …
[INFO] get_advanced_flow not on local MCP — trying homeypro MCP at https://mcp.athom.com …
[MCP] Step 1/3 — Sending initialize …
[MCP] Connected to ‘homey’ v1.0.0 (protocol 2024-11-05)
[MCP] Step 2/3 — Sending notifications/initialized …
[MCP] Handshake complete — session ready.
[INFO] HomeyPro MCP session established.
→ Fetching rich data for ‘4-button control of front door sockets’ (a318c2e5…)
✓ 4-button-control-of-front-door-sockets-a318c2e5-rich.json
→ Fetching rich data for ‘Back counter light’ (1bc5331f…)
✓ back-counter-light-1bc5331f-rich.json
:
→ Fetching rich data for ‘Door Window color status’ (b5434476…)
✗ [ERROR] Skipping ‘Door Window color status’ — Too many requests…
→ Fetching rich data for ‘Door/Window reminder when leaving’ (7675c8dd…)
✗ [ERROR] Skipping ‘Door/Window reminder when leaving’ — Too many requests…
Great start! It’d be awesome if one could also access homeyscripts using that. There’s no list_scripts, get_script, run_script, or update_script endpoint
Been testing Advanced Flows through the Homey MCP with Claude and hit two related walls.
Reading variables: Creating condition cards that read a Logic variable (equal_boolean) fails every time because the MCP schema doesn’t include droptoken or ownerUri — they get stripped before reaching Homey:
Invalid type for arg ‘droptoken’ expected ‘string’ but received ‘undefined’
Writing variables: variable_set_boolean only works if you already know the variable’s internal ID. There’s no list_variables or equivalent in the MCP, so there’s no way to look them up programmatically. You have to find IDs through other means and hardcode them.
The only workaround for reading state is inline HomeyScript via Homey.logic.getVariables(), but that’s a poor substitute — and global.set/global.get doesn’t survive a reboot, so it’s not a viable alternative for persistent state.
The MCP can technically write Logic variables if you already know their IDs, but can’t discover them and can’t build conditions that read them. Both issues need fixing for Logic variables to be usable through the MCP at all.
I’ve been using ChatGPT with the homey App and it’s been extremely useful. I created a project called “Homey” in ChatGPT, added custom instructions, and now I can generate detailed daily reports covering temperature, humidity, energy consumption, network health, and device status. It has become a simple but powerful way to monitor my smart home and spot issues before they become problems.
My only wish is that ChatGPT App could access Homey’s historical sensor data. Being able to automatically compare current readings with data from previous days or weeks would make the analysis and trend reporting even more valuable.
ChatGPT wrote the prompt. My initial request was simply to create a detailed daily Homey report, and from there ChatGPT did the heavy lifting. I merely served as the copy-paste department.
When I ask to build a Advanced flow, GPT reports a problem with list_flow_action_cards:
De Homey-API waarmee ik hier werk geeft op dit moment een fout bij het opvragen van de actiekaarten (list_flow_action_cards), terwijl triggerkaarten wel terugkomen. Daardoor kan ik de flow niet veilig genereren zonder te gokken welke kaart-ID’s jouw apps gebruiken.
I experience this too. But not only with variables.
It is asking a lot for ID’s and names of app functions or states.
Offcourse the names are named different in the API.
To build a fancy flow I often need to set cards in a flow so Claude can read the card and options.
For now it seems like it is much more work to build it with AI then doing it yourself. Beside that your tokens are burned really fast because of the constant rework.
Do Homey devs need to make their app ready for working with AI / MCP-server? It often looks like it has no idea how to use the app’s cards.
Often I see a flow created with cards that are displayed in gray with a ? and something like unavailable or do not exist.
