Replies: 2 comments 1 reply
-
|
One thing worth checking first: if If none of those explain it, I'd want to know more, because that would be a bug. For the broader "lock it down" problem, I'd push back a little on building a global Read-Only Mode toggle into the integration, because HA already provides that at the platform level. User permissions, Lovelace kiosk mode, and card-level tricks can all restrict who can interact with what on a given dashboard. That's a more appropriate place to solve "family members shouldn't be able to press things" than inside ACP itself. That said, there are a few existing switches that get you most of the way there:
So depending on what you actually need, the tooling is mostly already there. Curious what the underlying goal is, because "family members on a wall tablet" and "debugging automation conflicts" might call for different solutions. For details, see the How-It-Decides wiki page. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed response — that’s really helpful context. Where I think my concern still sits 
to make it clear that this is the disabled |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, the reframing makes sense. My last reply was too narrow on the "who can press buttons" framing. What you're describing is different: the cover entity has no native way to signal "I'm being managed right now," so a slider in a standard Lovelace card just looks interactive, even when ACP is actively holding position. The closest existing answer is the Proxy Cover Entity. When you point your dashboard at For seeing which handler is actually in control, the companion Lovelace card ( If you want to visually grey out controls when automatic_control is on, conditional cards are the per-dashboard approach: hide the position slider when I'm not going to pretend that's a complete answer to what you're describing. The integration doesn't expose a machine-readable "ACP is actively controlling this cover" signal that cards could respond to natively, and that's a genuine gap. I'll keep this open as a feature request because the core idea is worth tracking properly. For details, see the Proxy Cover Entity wiki page. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everyone,
I’ve been using Adaptive Cover Pro for a while now, and it’s honestly one of the most powerful integrations for controlling blinds automatically based on sun position, climate, and priorities. Huge thanks to the developer for the work here 🙌
I wanted to bring up a usability topic and see how others are handling it.
💡 The situation
Even when everything is fully automated (solar tracking, climate mode, etc.), the UI still allows:
So in practice:
😕 Problems this causes
In real-world setups, this leads to:
Even though the integration has a strong internal priority system, UI interaction is still unrestricted.
✅ What I’d like to see
A read-only / interaction lock mode, for example:
Option 1 — Global “Read Only Mode”
A simple toggle:
Read Only Mode: ON/OFFWhen ON:
Option 2 — Smart auto-lock
Automatically disable manual interaction when:
Allow interaction only when:
🧠 Why this would be valuable
Adaptive Cover Pro is effectively a full automation engine, not just a helper.
Adding a “read-only / locked” mode would:
❓ Curious how others handle this
Thanks again for the awesome integration — this is just something that would make it even more solid in multi-user setups.
Beta Was this translation helpful? Give feedback.
All reactions