What are your thoughts on allowing multiple instances, each with its own OAuth endpoint and its own scope, the same pattern Maker API uses?
One issue is that the current access-control axes don't line up. selectedDevices (plus the bypass toggle) scopes device operations only, and diagnostics, logs, File Manager, backups, hub_get_source etc. ride on the Read/Write masters alone. So "write access to these three devices" isn't really expressible today. Any token that can write to three devices can also read the Groovy source of every app on the hub, read the File Manager, and reach the backup tools.
Are you talking about multiple instances for a single hub? I'm not sure if that'd be a great idea if you're using one AI client. If you're using multiple AI clients you could just set individual permissions like per client, depending on how the client works.
Advanced settings already let you disable individual tools or entire gateways, including source access, File Manager, diagnostics, and backups, while retaining selected-device commands. Those restrictions are enforced when tools are called.
Going more granular than that might be possible but sounds like it might be complicated to implement. If you can give more specific examples of what exactly you're looking for I could look deeper into it and see if it's possible to implement
You're right about the single-client case. What I want is one scope per consumer, in separate clients.
You're right that I should have led with the need, not the solution. Examples, in the order they matter to me:
A CI/test client with write access to a handful of virtual devices and nothing else. I already do this with a dedicated Maker API instance per app under test.
A household-facing client: lights, scenes, thermostats. No locks, no File Manager, no source.
A dev client: source, logs, rule health, no device writes at all.
Sounds like it might be possible to do. It'd be easier if you filed an issue on GitHub so I don't forget about this. Per codex , apparently toggling "singleInstance: true" in the code will be enough, but I'll dig a bit deeper when I get the chance.
I am not convinced it would be that simple, but, sure, I'll put something in GitHub. Thanks for considering the ask.
Thought about it some more and my request is not specific to your app. Simply, your app offers by far the largest and potentially most damaging surface to an AI agent. It is common knowledge by now that if there is something an AI agent can do, it will eventually do it, therefore the conservative approach is required IMO.
Agreed. I have set up backups too, but this has also seen some pain in the butt instances by making multiple backups in a short period of changes, especially when the change failed, a retry attempt takes ANOTHER backup before trying again. And 15MB backups are NOT fast even on a C8P. Annoying, but a necessary backstop.
That sounds almost like a bug, I thought I had it set to backup rules as it worked in realtime but to only require full hub backups every 24 hours or something like that.
This is getting scary good, skip the RM rules, thats tables steaks and slow I might add. Claude can create Groovy apps & devices faster. Now we can actually easily share. Ask Claude or your favorite Ai to document your app and create a shareable prompt . This is like when they created cordless remote controls and microwaves.
My Example Aggregation App (5 minutes)
Click to Expand
The problem: My Recreation Room has 5 separate motion/temperature sensors scattered around it (it's a big room). To my smart home software, that looked like 5 tiny rooms instead of one big one, which confused automations — especially my thermostat "follow-me" logic that's supposed to track occupancy and temperature per room.
The fix: I had Claude write a custom app for my Hubitat home automation hub that merges all 5 sensors into one virtual "room" sensor:
Motion: counts as "someone's in the room" the instant any of the 5 sensors detects movement, and only clears after all five have been quiet for a set number of minutes — so it doesn't flicker on/off as someone walks between sensor zones.
Temperature/humidity/light level: averages the readings across whichever sensors report each one.
Claude actually queried my live hub first to see exactly what each of my 5 sensors reports, caught that one sensor doesn't report humidity, tested the virtual device driver's exact capabilities before writing the code (so it wouldn't guess wrong), and flagged one limitation (no voltage tracking) rather than silently dropping it.
End result: one virtual sensor that acts like a single well-behaved "room" for all my other automations to read from.
So is this basically the built-in Zone Motion Controller plus the Average Temperature Sensors app - which allows for adjusting weighting and offsets for each sensor - in a single device?
I noticed claude code checking last backup and skipping if within x hours. But there was a claude desktop tasking I was doing last week or two and it just annoyed me.
I'll report if I see it happen again. I'm of the type who likes making minor changes myself anyway, so I know what's going on in the 200+ rules I've written manually over the years.
I'm not sure what you mean by that, if you're connecting locally it is just http, if you're connecting over cloud it's https. What version of Claude are you using, code, desktop, or Claude.ai?
Yes. In Claude Desktop, the connector requires https, and so it doesn't accept the http url. If you're using Claude Code, it will accept the local IP url with http.
. This is like when they created cordless remote controls and microwaves.