[APP][Pro] MCP AI Bridge - Control Homey with any AI assistant (Claude, ChatGPT, Gemini, Copilot, Cursor or Mistral) via the Model Context Protocol

Apps
, , , ,
62

I am encountering an “Origin not allowed” error when authorizing a ChatGPT developer-mode plugin through a Cloudflare Tunnel.

Homey Pro Early 2023, firmware 13.4.0, MCP AI Bridge 4.3.1. Dynamic Client Registration succeeds and the consent page appears, but submitting Read only permission with a valid scoped READ key returns the error. The public URL and trusted reverse-proxy settings are enabled, and setting Cloudflare’s HTTP Host Header explicitly did not resolve it.

Homey diagnostic report ID: c9b9e7f6-cbb2-4ea8-acbe-8a8ef7633515

Does version 4.4.0 address this, or is another forwarded-header/origin configuration required for Cloudflare Tunnel?

63

@J_Reeves

@J_Reeves Thank you for the diagnostic report, that was the whole answer.

Short version: your configuration is correct. Do not change anything. Both
problems are mine, and neither is fixed in 4.4.0. Version 4.4.1 fixes both.

Why the consent form was refused

I added a check that blocks hostile web pages from reaching your Homey, and I
applied it to every route on the server. That was wrong for the OAuth pages.

A consent page is reached by redirect from the assistant, so when you submit
it the browser sends either ChatGPT’s origin or a literal null. Neither can
ever match your own address, by design. So the check refused the one flow that
is supposed to be cross-origin, every single time, on every setup. Your
Cloudflare Tunnel and your Host Header were never the problem, and I am sorry
for the time you spent on them.

The four OAuth routes are exempt in 4.4.1. Rebinding was never the threat
there anyway: those routes are protected by PKCE, single-use codes, a
validated redirect URI and your own API key, none of which a hostile page can
supply. The rest of the app keeps the check.

The crash in your log

Your stderr showed the more serious one:
Error: connect ENETUNREACH 2a06:98c1:3101::6812:202f:443
at lookup (/app/lib/cimd.js:154:13)
:warning: The app has crashed.

When the bridge fetches a connector’s metadata it pins the connection to an
address it has already vetted, so a hostile DNS server cannot swap in a LAN
address after the check. It pinned only the first address. Cloudflare
answers IPv6 first, your Homey has no IPv6 route, and one pinned address
leaves nothing to fall back to. The connection error then escaped as an
uncaught exception and took the whole app down. Your log shows it happening
three times.

4.4.1 pins the whole vetted set, IPv4 first, so an unreachable address is
skipped rather than fatal. The protection is unchanged: every pinned address
still had to pass the check.

That one was invisible from here. Nobody on IPv4-only had reported it and my
own Homey resolves differently, so without your log it would have kept
crashing for people who never connected the two events.

The odd bug report

The “unknown” app and server values and the zero scoped keys were a symptom,
not a separate fault: the report was generated while the app was down from the
crash above, so it could not read anything. It should read normally on 4.4.1.

What to do

Update to 4.4.1 and try the connector again. Leave your Tunnel, your Host
Header and your public URL exactly as they are.

If it still fails, post the error and I will look again. And thank you for
writing it up properly, with the versions, the topology and the log. The
crash would have gone unnoticed a lot longer without it.

64

MCP AI Bridge 4.4.1 Test – flowcards_list_triggers consistently fails

I completed a structured read-only test of MCP AI Bridge 4.4.1. The read connection is working correctly overall, but the trigger-card enumeration function consistently fails.

Environment

  • Homey: Johnny’s Homey Pro

  • Model: Homey Pro (Early 2023)

  • Homey firmware: 13.4.0

  • MCP AI Bridge version: 4.4.1 Test

  • Connection: ChatGPT custom connector through a Cloudflare Tunnel

  • Authorization: OAuth with a scoped Read-only API key

  • Public MCP endpoint:

Affected endpoint

  • Exact exposed endpoint:
    mcp__codex_apps__homey_ai_bridge___read_only__homey_e75a34f949b8

  • Bridge function:
    flowcards_list_triggers

  • Description:
    “List available flow trigger cards from all installed apps.”

Returned error

{
  "error": "ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)",
  "error_code": "UNKNOWN"
}

Reproduction attempts

The function failed consistently with all of the following:

  • One request for 500 trigger cards

  • Two paginated requests for 250 cards each

  • Filtered searches for motion

  • Filtered searches for device

  • Filtered searches for time

  • Filtered searches for flow

The same ExceptionGroup/UNKNOWN error was returned each time.

Comparison endpoints

The corresponding condition-card and action-card functions worked correctly:

  • Condition-card enumeration: 352 of 352 cards returned; not truncated

  • Action-card enumeration: 457 of 457 cards returned; not truncated

The other read-only tests also passed, including access to Homey information, zones, devices, device capabilities and states, Flows, Flow definitions, and Insights. Therefore, the issue appears isolated to flowcards_list_triggers, rather than the OAuth authorization, scoped key, Cloudflare Tunnel, pagination, filtering, or general Flow-card access.

Diagnostic report

0d64beb2-91b6-4b86-a755-5676ff36e325

The connector remains usable for the other read functions, so this issue is not blocking the remaining staged tests. Please let me know if you would like me to perform any additional targeted tests or provide further information.

65

I would recommend removing this from your report, as it appears to be a private remote access URL? Especially when you also expose the endpoint/ID

66

Thank you.

67

MCP AI Bridge 4.4.1 Test – “Write (no deletes)” permitted memory_forget

I completed a controlled permission-boundary test of a separate ChatGPT OAuth connector authorized as Write (no deletes). The test indicates that at least one tool categorized as destructive was still permitted.

Environment

  • Homey: Johnny’s Homey Pro

  • Model: Homey Pro (Early 2023)

  • Homey firmware: 13.4.0

  • MCP AI Bridge version: 4.4.1 Test

  • Remote connection: ChatGPT custom MCP connector through a Cloudflare Tunnel

  • OAuth client registration: Dynamic Client Registration

  • Remote maximum permission: Write (no deletes)

  • Scoped AI Bridge API key: Write (no deletes)

  • Destructive-operation limit on the scoped key: 0

  • Homey PAT scope: homey.flow only

No API keys, PATs, Cloudflare credentials, or other secrets are included in this report.

Initial tool inspection

The Flow Builder connector advertised all 154 Bridge tools, including read, control, create, update, and destructive tools. I understand that advertising a tool does not necessarily mean the OAuth session has permission to execute it, so I performed a controlled runtime test.

The advertised destructive tools included memory_forget, described as forgetting/removing a remembered Bridge value.

Controlled permission test

The test was deliberately confined to an artificial Bridge-memory value. No Homey devices, Flows, apps, settings, dashboards, or other Homey resources were accessed or changed.

The connector was instructed to:

  1. Store write-test-passed under:

    • Namespace: permission-test

    • Key: flow-builder

  2. Read that exact value back.

  3. Attempt to forget only that same test value.

Expected behavior:

  • Store: succeed

  • Read: succeed

  • Forget: rejected because the connection was authorized as Write (no deletes)

Actual results

Store succeeded:

{"success":true,"key":"flow-builder","namespace":"permission-test","expiresAt":null}

Read succeeded:

{"key":"flow-builder","namespace":"permission-test","found":true,"value":"write-test-passed"}

Forget also succeeded:

{"success":true,"key":"flow-builder","namespace":"permission-test"}

The artificial test value was successfully removed.

Question

Is memory_forget intentionally permitted under Write (no deletes) because Bridge memory is treated differently from destructive Homey-resource operations?

If so, it may be helpful to clarify that distinction in the permission description and/or the tool’s destructive classification.

If it is not intentional, then the Write/no-delete guardrail did not block this operation.

I did not test any deletion operation against a real Homey resource because I did not want to risk modifying the system.

Diagnostic report

1d1fbad9-ae46-4a51-8ca7-a1e8257df1f4

Containment completed

After preserving the results and generating the diagnostic report, I completed the following:

  • Revoked the ChatGPT Flow Builder scoped API key

  • Returned the Remote maximum permission to Read Only

  • Disconnected/uninstalled the Flow Builder connector

  • Confirmed that the original Homey AI Bridge Read Only connector still works

Please let me know whether this behavior is intentional and whether you would like any additional controlled testing.

68

@J_Reeves

@J_Reeves Both of your reports were right, and chasing them turned up more than you found. 4.5.0 is submitted.

What you reported

flowcards_list_triggers failing for a read-only key. The tool name contains _trigger, which matched the keyword pattern used to sort tools into read, write and destructive. So it was classed as write and refused before a single argument was read. Nothing to do with your Homey or your cards, and it would have failed the same way for everyone with a read-only key.

“Write (no deletes)” permitting memory_forget. Same mechanism, failing the other way. The keyword list looked for words like delete and remove. “Forget” is not one of them, so a tool whose entire job is erasing stored data fell through to read. A read-only key could erase the AI memory too. That one is on me and it is the more serious of the two.

The actual root cause

Permission categories were inferred from the tool name. That is fine until a name lies in either direction, and both of yours did. Categories are now pinned explicitly for anything where the name is not self-evident, the destructive list covers forget, purge, wipe, revoke and flush, and there are tests that fail if a category silently moves.

Three more, found because you looked

Once I stopped trusting the name inference, I audited all 155 tools rather than fixing your two:

  • homeyscript_get returned full script source to a read-only key. Scripts hold API keys often enough, and no redactor can reliably find a secret inside arbitrary JavaScript. It now needs control access. homeyscript_list stays read-only, since it never returned the body.
  • system_get_guardrails handed back a survey of which of your own rules could be bypassed, naming the tools that do it, in both the response and the tool description. A read-only key could ask the app for a recipe to get around your rules. Removed. Your rules still come back in full, because an agent that cannot see its constraints just blunders into them.
  • Code-execution detection matched the vendor, com.athom.homeyscript, so it missed nl.qluster-it.DeviceCapabilities:hs_runCode. A live Homey publishes eight code-running condition cards and not all of them come from Athom. It matches the argument now, not who shipped the card.

One thing I changed rather than fixed

Write scope can overwrite an existing flow, dashboard or mood. That is not a delete, but what was in it is gone. The label said “write (no deletes)”, which implied the deletes were the whole story.

I chose to fix the wording rather than the rule, because blocking overwrites would break ordinary flow editing for every existing write-scope key. It now reads “Control and change (can overwrite, cannot delete)”, with the full explanation on the consent page and in settings. If you want a scope that cannot overwrite either, say so and I will add it as a fourth level rather than redefining an existing one under people.

Also in 4.5.0

Remote access through a Cloudflare Tunnel works again: OAuth paths were being caught by the browser-origin check, which is why authorisation failed for you where a plain LAN setup was fine. And a flow card the app cannot render no longer takes the whole list down with it; it comes back marked unavailable with the reason and the rest arrives intact.

Thanks for both reports. The second one in particular was a permission boundary that did not hold, and it would not have been found by reading the code, only by someone actually using a scoped key the way it was meant to be used.

69

Thank you for your quick response and resolution. V4.5.0 has resolved all the issues that I have reported so far. I would like to ask one more thing when you get to it. It would be nice to have the 1 other permission role. Maybe something like you suggested:

Control only: Read device states, change device capabilities, start existing Flows and activate existing Moods, but cannot create, update, overwrite or delete Flows, dashboards, Moods, devices, settings, scripts or other stored resources.

This would allow us to keep the more destructive roles limited more and open up the ability to use this new role especially for voice-command connections.

70

Hello,

In addition to the permission-role request I submitted earlier today, we have continued controlled testing of MCP AI Bridge 4.5.0. The new Builder setup is working well overall. Flow creation and updating, device reading and control, and Bridge-hosted dashboard creation and operation have all tested successfully.

When you have an opportunity, could you also review these three items? Item 1 is the larger concern but all 3 would be helpful.

  1. Native Homey dashboards report “Missing Scopes”

The Bridge tool for listing native Homey dashboards returns:

{
  "available": false,
  "reason": "Missing Scopes"
}

The Personal Access Token scope selector does not appear to offer a dashboard-specific scope.

Our Builder PAT currently has:

  • homey.flow

  • homey.device.readonly

  • homey.device.control

  • homey.mood

  • homey.logic.readonly

  • homey.zone.readonly

  • homey.system.readonly

Could you confirm the minimum PAT scope required to read native Homey dashboards? Does this require the top-level homey scope, or is native dashboard access unavailable through the current Homey API/PAT system?

  1. Permission rejections are returned as a generic ExceptionGroup

The permission boundaries themselves appear to work correctly. For example:

  • A Builder connection can create and update a Flow but cannot delete it.

  • It can store and read Bridge memory but cannot forget or delete it.

However, the rejected deletion tools return only:

ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)

The underlying permission error is not exposed to ChatGPT. It would be more useful if the connector returned a structured response such as:

{
  "error": "forbidden by permission scope: cannot call destructive tool",
  "error_code": "FORBIDDEN"
}

This would allow the AI and user to distinguish an intentional permission rejection from a Bridge malfunction.

  1. First Bridge-hosted dashboard ignores set_default: false

We created the first Bridge-hosted dashboard with:

{
  "set_default": false
}

The creation response nevertheless returned:

{
  "default": true
}

Retrieving the dashboard also confirmed that it had become the default. This may be intentional when the first dashboard is created, but it overrides the explicitly submitted value.

If this behavior is intentional, it would be helpful for the response or documentation to explain that the first saved dashboard is automatically made the default. Otherwise, could the Bridge respect set_default: false?

Additional observation—not yet confirmed as a defect:

The dashboard displayed the Office Ring Light brightness as 1%. The live on/off status and dashboard control both worked correctly. We have not yet compared the displayed percentage with the device’s exact raw dim value, so this may be accurate rather than a formatting problem.

Thank you. Version 4.5.0 is performing well in our tests, and we appreciate your continued work on it. I can see the bridge being an invaluable tool for not so technical enthusiast like myself!

71

@J_Reeves

Both of your points are in 4.6.0, which is uploaded and going out as a test version now. Thanks for the report and for the proposal, they were good ones.

1. Native dashboards: “Missing Scopes”

Short answer: it works, but only through a Personal Access Token, and your token needs one more scope.

The scopes are stated per operation in Homey’s own API specification:

What Scope
List and read dashboards, list widgets homey.dashboard.readonly
Create, edit or delete a dashboard homey.dashboard

Your token has homey.flow, homey.device.readonly, homey.device.control, homey.mood, homey.logic.readonly, homey.zone.readonly and homey.system.readonly, so neither of those. That is the whole cause.

The app’s own API token never carries them either, which I confirmed against a live Homey: the app session is refused with exactly the string Missing Scopes and holds no dashboard scope at all. So there is no way to reach native dashboards without a PAT, and no app permission that would change that.

Go to my.homey.app, Settings, API, edit your token and tick Dashboard. Read-only is enough to list and read; you need the full one to build.

What changed in the app is the answer you get. Missing Scopes names neither the scope nor the token, so there was nowhere to go from it. Now the refusal says which scope is needed, whether a token is set at all, and what the token that IS set currently holds. homey_dashboards_list also returns the scope as its own field, so a client that renders data rather than prose still shows the fix. And the Status tab now lists what your saved token can do and which scope it is still missing, right under the field where you paste it.

2. Control only

Built as you described it, and it is available now.

The part your definition left open was where to put the calls that change something without creating or deleting anything: devices_set_settings, logic_set, zones_update, devices_rename, notifications_send. I settled it with one rule that fits in a sentence:

Control only may switch things on and off, set them and start them. It leaves the layout of your Homey alone.

So:

In. Set device capabilities (single, per zone, batched), start an existing flow, activate a mood, set a variable, set presence, send a notification, speak, set volume, drive the LED ring. Flow-defined tools you publish yourself are in too, because starting one of those is the same act as starting any flow.

Out. Device settings, renaming, moving between zones, changing an icon, editing a zone, enabling or disabling a flow, and everything that creates, overwrites or deletes a flow, dashboard, mood, script, schedule or stored value.

Two calls to explain, since they are the interesting ones:

  • logic_set is in. Writing a value into a variable you already created is the same act as setting a capability. Creating or deleting the variable is not, and stays out.
  • devices_set_settings is out. It reconfigures the device, polling interval, calibration, what a button does. Nothing is deleted, but that is your setup, not your lights.

notifications_send and speech_say are in, as you suggested. They produce new output and overwrite nothing, and a voice assistant that cannot answer you is not much of one.

You can pick Control only in three places: per API key, as the global access mode, and as the ceiling for remote connections. The OAuth approval page offers it too, in English and Dutch, with a line saying what it will and will not do.

Existing keys are not affected. The new level sits between Read only and Control and change, and everything it allows was already allowed at Control and change, so nothing you already handed out gained anything. That is enforced as a test across the whole tool catalogue, because a permission that quietly widens is the one bug you cannot take back.

One thing to know if you set the global access mode to Control only: it caps everything, including your own full key, so your assistant can no longer change app settings either. The way back is the settings page in the Homey app. Same as Read only and Off have always behaved, but worth saying out loud.

72

I installed MCP AI Bridge 4.6.0 successfully. However, when I create a new Personal Access Token under my.homey.app → Settings → API Keys, there is no Dashboard section and neither homey.dashboard nor homey.dashboard.readonly is offered. The complete list goes from Homey and Devices through Flows, Moods, Variables, Zones, and the remaining scopes down to Location. Is Dashboard scope availability dependent on a particular Homey OS or web-app version, or is there another way it must be enabled? I have not selected the unrestricted top-level homey scope as a workaround.

73

@J_Reeves

You are right, and it is not your Homey or your version. I checked before answering, and my advice in 4.6.0 was wrong.

The Dashboard scope is not on that screen

The scope exists and Homey’s own API enforces it, so the error you saw was real. But it is not offered as a checkbox when you create a Personal Access Token, and it never has been.

I verified this in the my.homey.app front-end itself rather than guessing. Its scope table defines both homey.dashboard and homey.dashboard.readonly, and the component that renders the checkboxes references neither. What it does render is exactly 35 entries, in this order:

Homey, Devices, Flows, Moods, Variables, Zones, Notifications, Apps, Users, Insights, Alarms, Presence, System, Updates, Location.

Which is exactly the list you described. homey.energy is missing from it as well, for what it is worth.

So there is no Homey OS version, no web-app version and no hidden setting that makes it appear. Nothing to enable.

What that leaves you with

The only token that carries the dashboard scope is one created with the top entry, Homey, which is the unrestricted scope you deliberately avoided. There is no narrower way to get it today.

That is a genuine trade-off and I am not going to pretend otherwise:

  • Take the top-level scope if you want your assistant to read or build native dashboards. It grants full access to everything, so it is worth deciding on purpose rather than by accident.
  • Leave it if you do not need those six tools. Everything else in the bridge keeps working exactly as it does now, including flows, which only need homey.flow.

For what it is worth, my own token reports its scopes as the single string homey, which is why native dashboards worked here and I did not notice the gap. That is on me.

What changed in the app

4.7.0 stops giving the advice that sent you looking. Where 4.6.0 said “tick the Dashboard scope”, the refusal now says that the scope is not offered on that screen, that the top-level Homey scope is the only thing that carries it, and what that costs. The Status tab says the same under the token field, in both languages.

If Athom ever adds Dashboard to that list, it is one line in the app to correct and every message follows from it.

Three other things came out of the same “say what is actually true” pass:

  • Over the REST endpoint, a key that is not permitted to run a tool is now told exactly that, instead of being told the action needs a confirmation that endpoint cannot show. The MCP side already worked that way.
  • events_subscribe no longer accepts a device id or capability that does not exist. It used to store the subscription, list it, and never fire. It now refuses and shows you the device’s real capabilities.
  • Your assistant is now only shown the tools its key may actually use. A read-only or control-only connection used to be handed the full list of 155 and discover its limits one refusal at a time.

Thanks for coming back with the detail. “There is no Dashboard section and the list goes from Homey down to Location” was precise enough to find the cause in an afternoon instead of a fortnight.

74

@weide43 Do i need an buisness subscription?OpenAI currently states that full custom MCP functionality is only available for Business, Enterprise, and Edu. Even Pro only gets read/fetch in developer mode with custom MCP, according to current documentation. So with cloudlfatre https plugin ?

Ontwikkelaarsmodus en MCP-apps in ChatGPT | OpenAI Helpcentrum

75

You are reading it right, and unfortunately Cloudflare does not solve it. Those are two separate problems, and it is worth keeping them apart.

The plan tier

Custom MCP connectors in developer mode are in beta on Plus, Pro, Business, Enterprise and Edu, but write-capable custom connectors are limited to Business, Enterprise and Edu. Plus and Pro get read-only. That matches exactly what you found, and it is OpenAI’s gate, not something this app or any tunnel can lift.

What Cloudflare does and does not do

Does not: change what your plan allows. A public HTTPS endpoint is not an entitlement.

Does: make the bridge reachable at all. ChatGPT connects from OpenAI’s servers, not from your laptop, so http://192.168.x.x:52199/mcp is invisible to it no matter which plan you are on. Any ChatGPT setup needs a public HTTPS endpoint. So HTTPS is necessary, it is just not sufficient.

Read-only is not nothing here

If you are on Plus or Pro, the read side of this app is still a real thing to have. Roughly 80 of the tools are reads:

  • “Which devices have a low battery?”
  • “Is the garage door still open?”
  • “What used the most power this week?”
  • “Are any of my flows broken?”
  • “Anything offline right now?”

You lose control and flow editing. You keep asking your house questions.

If you do expose it, use the built-in door

Please do not just forward a port. The app has remote access built in and it is off by default:

  • OAuth 2.1 with PKCE, so a remote client goes through a consent page where you enter your API key
  • You pick that connection’s permission on that page
  • A global ceiling caps every remote connection regardless of what it was granted
  • Connectors can be revoked from the settings

Nice fit for your case: if your plan is read-only anyway, set the remote ceiling to Read only. Then the limit is enforced on your Homey as well as by OpenAI, and a change on their side cannot quietly widen what your Homey accepts.

Put Cloudflare in front of that, with the tunnel pointing at the bridge, and set the public URL in the app’s remote settings so the OAuth endpoints advertise the right address.

No tier gate at all

Claude (Desktop, Code, mobile), Cursor, Windsurf and other MCP clients connect straight to the bridge over your own network. No subscription tier, no public endpoint, no tunnel. If ChatGPT is not required for you specifically, that is the shorter road.

76

The free web version of Claude can also connect to 1 custom MCP server with read/write. So that might work with Cloudflare if you don’t want another subscription.

77

I was sure we have already tested success WRITE functions with my PLUS subscription so I asked Chatgpt to verify and this is the response:

That community post is outdated or incorrect for the current ChatGPT developer-mode system. Your Plus plan does support read-and-write custom MCP tools.

The current official OpenAI documentation states both:

OpenAI’s main ChatGPT developer page is even more explicit: it describes “full Model Context Protocol support for all tools, both read and write, in ChatGPT Plus and Pro.” OpenAI ChatGPT developer resources

More importantly, we have already confirmed this specifically on your Plus account. ChatGPT successfully used the Bridge to:

  • Store a Bridge memory value.
  • Create a disabled Homey Flow.
  • Rename/update that Flow.
  • Create a Bridge-hosted dashboard.
  • Operate a device during the controlled device test.

Those were genuine write operations, not simulated results. The rejected deletion attempts were rejected by the Bridge’s Control and change permission boundary—not by your ChatGPT plan.

The Cloudflare portion of the community post is correct: the tunnel makes your Bridge reachable from OpenAI’s servers, but it does not determine your subscription permissions.

Your effective authorization is layered:

  1. ChatGPT Plus: currently allows read and write MCP tools.
  2. Developer mode: exposes those MCP tools to ChatGPT.
  3. Bridge global mode and remote ceiling: cap every connection.
  4. Scoped Bridge API key: determines Read only, Control only, Control and change, or Full.
  5. Homey PAT scopes: determine which native Homey resources the Bridge can access.

Therefore, we should continue with our planned Read & Diagnostics, Control, and Builder connections. There is no need to upgrade to Business merely to obtain MCP write access. The present dashboard-scope problem is a Homey PAT scope-display issue, not a ChatGPT Plus limitation.

78

Thank you. I will submit a ticket to Anthom for the additional PAT scopes.

79

4.9.2 is out

A few releases have gone by since 4.7.0, and the biggest change in them is not a new feature. It is that the app finally explains itself.

First, what got added

HTTPS on the Homey itself. Connecting a cloud assistant means putting a proxy or a tunnel in front of your Homey, and that last hop from the proxy to this app used to be plain HTTP, carrying your API key and the OAuth code in the clear. Paste a certificate and key under Remote and the app opens a second, encrypted port next to the plain one. A Cloudflare Origin certificate is valid up to fifteen years, so you set it once. The plain port keeps working untouched for the clients on your own network, and a certificate that does not load costs you HTTPS, never the bridge.

Connected apps. Every cloud assistant you approved is now listed, with the permission it got and when it last did something, and you can revoke one or all of them. Worth knowing: replacing your API key does not revoke anything, an already approved connection keeps working, which is exactly why this list exists.

A couple of guarantees, rather than settings. Remote access refuses to switch on until you have set an API key, because switching it on without one would hand full access to the internet. And the dashboard is refused on the HTTPS port even with remote access on, because it has no login of its own: the control key sits in the page, which is fine at home and exactly wrong on the internet. Neither is a checkbox you can get wrong.

And then the settings page

I went through every tab and asked whether somebody who did not build this thing could follow it. Most of them could not, so:

Status now lists every address the bridge answers on in one place, with its real state: your local address, HTTPS, the public address when remote is on, and the dashboard. You used to collect those from four different tabs and still not know which ones were actually live. Tap one to copy it. The counters underneath got a line saying what each number means.

Connect says out loud that it is the first step and that everything on it is about your own network, with its three cards numbered: where your Homey is, the optional token for writing flows, and pick your assistant.

Security explains the three settings that had no explanation at all, and says how the layers fit together. The access mode is a ceiling over everything, each key has its own permission underneath it, blocked tools and guardrails stop even a full key, and irreversible actions ask for a confirmation on top. The strictest layer wins, and you do not have to fill in all of them. One key at the right level is enough for most people.

Commands went from seventeen example lines to seventy-eight, in thirteen groups, deliberately weighted towards the things people do not think to ask. Have a flow explained back to you in plain language. Find apps that are installed but used in no flow at all. Find devices that kept drawing power all night. Check a flow is correct before you create it. Look at your Zigbee mesh. Ask the bridge what it is actually allowed to do. Tap a line to copy it.

The dashboard tab now shows what the public address would be, crossed out, with the reason next to it. This came up as “why is there no public dashboard link”, and a missing link reads like a missing feature rather than a deliberate refusal. There is a section explaining the reasoning, and pointing at a VPN home as the way to see your dashboard while you are out. The prompt that builds a dashboard was rewritten too: it now gathers the real values first, skips devices that are unavailable, leaves empty tabs out, and tells you what it built.

Memory, Planning and Events looked to several people like they never fill up. They work. I checked by storing a value and by running a scheduled job on a one minute interval, which fired and reported back. They were empty because nothing had used them yet and the page never said so. All three now explain what they are for and carry example sentences you can paste straight into a chat: “Remember that the reading lamp is the device Lamp TV”, “Check every hour whether any devices are offline”, “Keep an eye on the front door and warn me when it opens”. The empty state says “nothing yet, here is how” instead of showing a blank.

The remote guide

If you have been putting off connecting a cloud assistant because the setup looked fiddly, this is the part to look at. The guide on the Remote tab went from six sections to fifteen:

  • how the whole chain fits together, from the assistant through Cloudflare and your router to this app, so every error message tells you where to look
  • which of 52199, 52200 and 443 goes where, since mixing them up is the most common mistake
  • three routes: your own domain with Cloudflare, no domain with No-IP, or straight through if you already run a tunnel
  • the fields in this app in the order you fill them
  • how to test the chain yourself before you connect anything
  • what is deliberately not reachable from outside
  • a symptom list for when it does not work, and how to switch it all off again

It also names the two Cloudflare settings that actually bite: Bot Fight Mode has to be off, because an assistant is not a browser and cannot solve a bot challenge, and /mcp must not be cached.

Nothing to do

No settings change, nothing to re-approve, and existing connections keep working.

As always: if something does not work, the Bug report tab makes a document with everything needed to help and never a key or a token. Paste it here and I will take a look.