Announcing Control D Manager 2.0.0
Version 2.0.0 adds an AI assistant surface and completes the endpoint and client lifecycle. It brings two breaking changes: configuration changes now require an administrator, and two summary sensor attributes were renamed.
An assistant surface for control and diagnosis
Control D Manager registers its own Home Assistant LLM API. Home Assistant serves it to the built-in Assist pipeline and, through the MCP Server integration, to any MCP client: desktop and editor assistants, chat clients, and custom agents. There is no separate server to run.
The surface covers everyday control and diagnosis. Pausing a profile, changing a service mode, or reading back what a profile currently enforces takes a sentence instead of a walk through the dashboard. Diagnosis reaches wider, because a single question can legitimately span profiles, endpoints, clients, and rules, and on a home lab or a segmented network the answer usually needs several of those at once before it makes sense.
That diagnostic reach is why this is a set of tools rather than more entities. Control D’s per-query activity log and ranked breakdowns are high-cardinality telemetry, and exposing them as entities would add thousands of registry rows that go stale almost immediately, so they are fetched on demand instead.
What follows is a real session against a live account, transcribed from Assist and lightly trimmed. Profile names are changed. It runs on a low-cost zero-data-retention model from OpenRouter, which is part of the point: the answers below come from the domain context in the tool descriptions, not from model scale.
tell me about my control d
Your Control D account protects 293 devices across 18 endpoints using 8 profiles. In the recent analytics window, your network handled 348,140 total queries: 153,741 blocked queries, 194,046 bypassed queries, 353 redirected queries. All 8 profiles are currently active and unpaused.
Jane’s phone wasn’t working right this morning
Looking at the activity log for Jane’s Phone today, it has experienced several blocked queries by the x-hagezi-light filter. Some of the domains being blocked include:
app-measurement.comgoogleads.g.doubleclick.netapi-eu.mixpanel.comapp-analytics-services.comincoming.telemetry.mozilla.org
These are standard tracker/analytics blocks, but if an app or service Jane was trying to use relies on one of them, it could cause issues. Would you like me to make an exception or pause protection for Jane’s phone?
Give me some time ranges those blocks happened today
Based on the activity log for Jane’s Phone today, the blocked queries occurred in these time windows (all times in UTC):
- 07:06 to 10:56 UTC: Consistent background telemetry and analytics blocks (such as
api-eu.mixpanel.com, app-measurement.com, and googleads.g.doubleclick.net) occurring roughly every 30 minutes.
- 10:19 to 10:56 UTC: Additional blocks including telemetry domains (
incoming.telemetry.mozilla.org) and app measurement services.
If Jane was using her phone around 7:00 AM to 11:00 AM UTC, those background blocks might have affected her apps.
tell me more about that blocking service
The blocking service causing those blocks on Jane’s phone is Hagezi’s Light blocklist (tracked in Control D as x-hagezi-light).
It is a popular, lightweight third-party community blocklist designed to block common online annoyances without being overly aggressive. Specifically, it targets:
- Ad networks and tracking domains (like Google Ads /
doubleclick.net)
- App analytics and telemetry (like Mixpanel and
app-measurement.com)
- Browser telemetry (like Mozilla’s telemetry)
Because it runs at the DNS level through Control D, it prevents Jane’s phone from even resolving the addresses for these trackers and analytics servers, stopping them in the background.
why is it being applied?
The x-hagezi-light filter is being applied because it is enabled within the configuration of the Jane’s Phone profile (profile ID 733915vbnc48r).
Every profile in Control D can have its own set of built-in and third-party security or blocking filters turned on. In this case, the Hagezi Light blocklist has been activated specifically for Jane’s phone profile, so any DNS requests matching that list get blocked automatically.
What blocks and filters apply to Jane’s chromebook?
Jane’s Chromebook is covered under the Jane’s Devices profile (with the Default Profile applied as a secondary/fallback profile).
The active filters and protection categories enabled on the Jane’s Devices profile include: Adult Content, Clickbait, Dating, Drugs, Gambling, Malware, New Domains, Phishing, Torrents & Piracy, and VPN & DNS.
I want to pause the blocking on Ben’s phone for 5 minutes
I have paused the “Ben’s Phone” profile for 5 minutes.
You can reverse this change at any time by running controld_manager__enable_profile(profile_id='518044mplx72q').
Nothing in that sequence required a dashboard. The assistant resolved a device to the profile that owns it, named the filter responsible, described what that filter does, explained why it was active on that profile, compared the protections on a second device, and then made a timed change that reverses itself while handing back the call to cancel it early.
Other questions the tools answer directly include whether a single domain is blocked on a single endpoint without waiting for real traffic, which profile is blocking a request when an endpoint enforces more than one, and what a profile is currently configured to do, including its catch-all rule.
The surface carries the domain model
A tool that can read Control D data is not much use to an agent that does not know what it is reading. Every tool description is composed from a shared model of how Control D works plus that tool’s own specifics, so the agent knows the following before you ask anything.
The vocabulary is defined. A profile is a policy container, an endpoint is a DNS resolver that enforces a profile, and a client is a device seen under an endpoint. Home Assistant’s own device and entity are named as separate concepts, with an explicit rule against conflating them.
The domain rules are stated. An endpoint always enforces at least one profile, so only its secondary can be removed. A device can legitimately be both a client and its own endpoint, and both listings are correct because they answer different questions. A client row is an observation rather than stored configuration.
Identifiers have provenance. Every id a tool accepts is a Control D id obtained from a read tool, and the one translation that is needed happens in the tool layer rather than in the model’s head.
The agent therefore arrives at your first question already knowing what a profile is, where identifiers come from, and how to read the result of a write.
Tiered, and summary by default
Exposure is set in the integration options and starts at Summary only. The tier decides which tools are registered at all:
| Tier |
Tools |
What it reaches |
| Off |
0 |
Nothing is registered |
| Summary only (default) |
1 |
Account counts and block statistics, plus each profile’s name, protected-device count, paused state, and block counts |
| Read only |
5 |
Adds endpoints, clients, addresses, and query-level analytics |
| Read and control |
21 |
Adds reversible changes: filters, services, options, rules, profile enable and disable, endpoint naming, profiles, descriptions, and client aliases |
| Full |
24 |
Adds the three destructive deletes, as their own tool class |
Summary stays high level. It sends aggregate counts and profile names, and nothing that identifies a device or a website: no client names, no IP addresses, no MAC addresses, no endpoint names, no domains, and no per-query records. Anything that specific arrives only when you raise the tier, and it goes to whichever model your assistant uses.
Reads change nothing. Writes report whether anything actually changed, what the state was before, and the call that reverses them where one exists. The destructive tier describes its blast radius before acting. Every write also requires an administrator, so a non-admin user is rejected by the service whatever tier is configured.
Requires Home Assistant 2026.10 or newer. On older versions every other feature works normally and this setting is not offered.
Breaking changes
Every write service now requires an administrator
The 19 services that change Control D configuration now require an admin user. A non-admin user calling a write is rejected where it previously succeeded.
Automations and scripts are unaffected. The check applies only to calls that carry a user, and a call without one is not blocked. The 5 read services are unchanged and remain available to any user.
If you are the only user, or you are the admin, nothing changes for you.
Two summary sensor attributes were renamed
On the account and per-profile summary sensors, discovered_endpoint_count and router_client_count are now endpoint_count and client_count, and the sensors are labeled “Protected devices” with a devices unit instead of “Endpoint count”. The old names described endpoints as if they were devices, which stopped being true once the counts were separated.
Entity identities are untouched. The internal sensor key is unchanged, so nothing is recreated and no entity_id moves. Only templates, dashboards, or automations that read the old attribute names or the unit need a small edit.
What else landed in 2.0.0
Ten new services, four reads and six writes, bringing the total to 24.
The endpoint and client lifecycle is complete. Create and delete endpoints, assign a primary or secondary profile, set an endpoint’s description, delete a client alias, and remove a service override. Each write carries an undo where one makes sense.
Redirect rules survive a toggle. Changing a rule’s state now writes a status-only update, so a redirect keeps its destination instead of being flattened, and the destination appears as a redirect_target attribute on the rule switch.
Protected-device counting is honest. The summary sensors count what DNS protection covers, endpoints plus the clients behind them, and expose both underlying counts as attributes.
Catalog search. get_catalog accepts a search term, so a named object is reachable in a catalog of over a thousand rows without paging.
The 2.0.0 release notes have the full service list and the reasoning behind each change.
Fixes
Eight fixes, most of them in the service and tool write paths. Writes failed for objects you had not exposed as entities. An undo restored a placeholder instead of the real previous value. Profile identifiers were not translated to the device id Control D expects, and numeric account fields broke setup. The tool result contract’s before and after shapes did not match the documentation, and delete_rule blamed an unreadable state for its missing undo.
The full list is in the release notes.
Upgrading
No configuration changes are required. Existing profiles, entities, and automations keep working. See the breaking changes above for the administrator requirement and the two renamed summary sensor attributes.
The AI/MCP surface needs Home Assistant 2026.10 or newer.
Links
On HACS: I have submitted Control D Manager for inclusion in the default store. Until that review completes, it is still installed as a custom repository, exactly as before, and updates arrive through HACS as usual.
Support the project
If Control D Manager is useful to you, there are two ways to help.
Star the repository. It takes a second, it is free, and it helps other people find the project.
Sponsor or tip. This is never required, but financial support does make it easier to keep putting time into bug fixes, features, and long-term maintenance.
This is an unofficial community project. It is not an official Control D product, and Control D does not provide support for it.
The “Everyday” Use Cases
For the Homelabbers & Power Users
Support the Project
Star this repository! (The Non-Negotiable)
Sponsor or Tip (The Ultimate Motivator)
Smarter Syncing & Zero Entity Bloat
Upgrade Notes
)
Version 1.3.0 — Smarter entities & Easier setup
Version 1.3.1 — No more entity state flickering