Feature Requests

Every event Anvil captures gets richer context: how much memory the driver used before and after, how much CPU time the handler consumed, which controller model and OS version it's running on, and how long the controller has been up. This runs for every event with essentially zero overhead. It's not something you turn on for a debugging session — it's always there. Two concrete outcomes. First, memory leaks become visible: the event timeline picks up a slow, steady climb in memory that wouldn't otherwise be obvious, and flags the individual events allocating disproportionately. Second, when something is slow, you can tell what kind of slow it is — an event that spent 500ms inside your code is a different problem from an event that spent 500ms waiting on a network call. Over time, the same data supports cross-cuts like "this driver behaves differently on an EA-1 vs an CORE 5" or "memory usage jumped after the Director 4.1 update". What we're thinking: Memory usage and CPU time on every event — automatic, no configuration Memory-over-time chart with leak detection Flags on events that allocate much more than the rolling average Controller model, OS version, uptime, and reboot markers visible alongside the event Ability to compare a driver's behaviour across different controller models Help us shape this: How do you diagnose memory or performance problems in your drivers today? Is automated leak detection more useful than manual inspection, or vice versa? How valuable is comparing a driver's behaviour across different controller models or OS versions?

Most observability tools treat environments as something you tag explicitly — local, staging, QA, production. Control4 driver development has a simpler shape: you test on your own controller while building, then the driver goes out to dealers and end-users and stops being something you directly control. Environments in Anvil would reflect that reality with two implicit modes — Development and Production — rather than asking you to label every telemetry payload yourself. Development is everything you already see: full event, log, and error detail from your own controller while you're iterating. Production is the opt-in side, populated only when you enable production monitoring for a release and data starts flowing back from dealer installs. The two streams share the same project but stay clearly separated: a noisy error you intentionally triggered while debugging doesn't show up in your production error counts, and a spike in the field doesn't get buried under your own test traffic. Where development and production data coexist, an environment filter sits at the top of each data view and you can switch between "All", "Development", and "Production" as needed. Production data is visually distinct — a different badge colour, clear labelling in detail views — so you never have to guess which side of the fence you're looking at. For projects that never enable production monitoring, the filter stays hidden and nothing changes from today. Custom environment names beyond development and production are deliberately out of scope for now; most driver workflows don't have intermediate stages that need their own bucket, and we'd rather keep the mental model simple until we hear otherwise. What we're thinking: Two implicit environments: Development (default) and Production (opt-in via production monitoring) Environment filter on data views when production data is present Visual distinction (badge colour, labelling) so the two are easy to tell apart Separate aggregations — dev errors don't pollute prod metrics and vice versa Stricter privacy controls on production data (anonymised install IDs, no PII) Different retention windows if needed (longer for production, for compliance) Custom environment names deferred — intentionally not in v1 Help us shape this: Does your workflow have anything that looks like a staging step — a QA controller, a beta dealer, a test installation — or is it really just "your machine" then "production"? Would you ever need to look at dev and prod data side-by-side in the same view, or are they different enough that you'd always filter to one? If we later added custom environment names, what would you use them for?

The third-party integrations Anvil ships out of the box won't cover everything — internal dashboards, custom issue trackers, data warehouses, CI/CD pipelines, or homegrown alerting tools. Webhooks would give you a generic way to have Anvil notify any HTTPS endpoint when something happens, so you can wire it into the tools your team already runs without waiting for a first-class integration. You'd configure a webhook by giving it a name, a URL, and a list of events to subscribe to — new errors, regressions, resolved errors, error spikes, new releases, published releases. When one of those events fires, Anvil POSTs a JSON payload with consistent structure (organization, project, event type, and event-specific data) and an optional HMAC signature so your receiver can verify the request really came from Anvil. You can add custom headers for authentication, set a shared secret, and test the webhook against your endpoint before saving. Because webhooks can fail for reasons outside Anvil's control, failed deliveries retry with exponential backoff and a delivery log shows recent requests, their status codes, response times, and retry history. If a webhook fails repeatedly it's auto-disabled and admins are notified, so broken integrations don't quietly stop working. The feature is aimed at teams with custom tooling — Anvil's own built-in integrations (Jira, Linear, Slack, etc.) cover the common cases, and webhooks are the escape hatch for everything else. What we're thinking: HTTPS-only webhook endpoints configured per project Subscribable events: new errors, regressions, resolved errors, error spikes, new releases, published releases Consistent JSON payload shape with organisation, project, and event-type data Optional shared-secret HMAC signing so receivers can verify authenticity Custom headers (for auth tokens or routing) Test-webhook button during configuration Retry with exponential backoff on failure, auto-disable after repeated failures Delivery log showing recent requests, response codes, and retry state Help us shape this: What would you connect a webhook to first — a chat channel, an internal ticket system, a data warehouse, something else? Are there events beyond errors and releases that you'd want to subscribe to (comments, assignments, configuration changes)? Would per-environment webhooks matter to you — for example, different endpoints for staging vs. production?

A stack trace tells you where an error happened, not how your driver got there. For bugs that depend on sequence or timing — a callback that runs in the wrong order, a proxy command that arrives before the driver is ready, a property that was set to something unexpected just before the failure — the trail of events leading up to the error is usually the thing you most want to see. Anvil would automatically capture a rolling trail of recent activity for every driver instance: C4:* API calls, callback entries, property changes, timers, proxy messages, and outbound network requests, each with a timestamp and the relevant arguments. When your driver throws an error, or you call the Anvil SDK to capture one, the most recent slice of that trail goes along with the report. The stack trace shows the point of failure; the breadcrumb trail shows the run-up. You can also add breadcrumbs of your own wherever something significant happens in your driver — a user action, a state transition, a branch in business logic — so the trail reflects meaningful moments rather than just raw API calls. The trail lives in memory on the controller and is only transmitted when it's attached to an error, so there's no steady stream of data leaving the device in the background. In the UI, breadcrumbs for an error can be filtered, searched, and expanded to show the full arguments for a specific call. What we're thinking: Automatic capture: C4 API calls, callback entries, property changes, timers, network requests, proxy messages A simple SDK call to add your own breadcrumbs with a category, message, level, and arbitrary data Configurable buffer size (default around 100 events) Trail transmitted only when attached to an error — no ambient bandwidth cost Timeline view in the UI with filtering by type and free-text search Automatic redaction of sensitive patterns (tokens, credentials) before transmission Option to disable specific automatic capture types if they're noisy for your driver Help us shape this: Which kinds of automatic breadcrumbs would be most useful to you — C4 API calls, proxy messages, property changes, something else? Would you prefer a longer trail (more history, bigger error payloads) or a shorter one (lighter, less context)? When you've debugged a tricky sequencing bug in the past, what did you wish you could see at the moment of failure?

Every driver you ship is a new release, and when something starts going wrong the first thing you usually want to know is which version is doing it. Anvil already captures the driver version on errors and shows which versions are affected for each error group. Release tracking would extend that coverage to events and logs, and layer a proper notion of a release on top — with release notes, status, adoption metrics, and side-by-side comparison. The Releases page would list every version of a driver with the errors, events, and a quick sense of how each release is performing in the field. When you look at a single release, you'd see the errors that first appeared in that version, a summary of event volume, and an adoption curve showing how many controllers are running it over time. Error detail pages would pick up "Introduced in v1.2.3" and "Fixed in v1.2.4" context so you can tell at a glance which deployment caused or resolved an issue. Releases can be created manually — with notes you write when you cut a version — or drafted automatically when Anvil sees a previously-unknown version appear in telemetry. Comparison between two releases surfaces the differences that matter: errors present in the new release but not the old one, errors the new release resolved, and shifts in error rate or event volume between the two. Coupled with the existing source-map upload flow, this turns version tags into a first-class dimension you can filter, compare, and correlate against. What we're thinking: Driver version captured on events and logs, not just errors (consistent across all three data types) A Releases page per project with version list, status (draft/published/deprecated), and release notes "Introduced in" and "Fixed in" version context on every error Release comparison: new vs resolved errors between two versions Adoption curve showing how many controllers are running each version over time Automatic draft-release creation when a new version first appears in telemetry CLI commands for creating and publishing releases alongside source-map upload Help us shape this: How do you version your drivers today — semver, date-based, build numbers, something else? What format would you want Anvil to display? Is "introduced in version X" context something you'd want computed automatically, or do you prefer to associate errors with releases yourself? Which would be more valuable earlier: release notes and changelog storage, or release-vs-release error comparison?

For teams that manage driver development through a corporate identity provider, Anvil would support signing in with SAML 2.0 or OIDC. Members of an organization would authenticate with their company credentials — Okta, Azure AD, Google Workspace, OneLogin, or any other SAML/OIDC-capable provider — rather than with a separate Anvil password. Existing Anvil identities link to the corporate directory, so your team doesn't maintain two sets of logins. When SSO is required for an organization, joining and leaving follow the normal employee lifecycle. A new hire added to your IdP's Anvil group gets access to the org the first time they sign in. Someone who leaves loses access at the same moment their company account is deactivated, with no separate step to remove them from Anvil. Contractors, consultants, and anyone else who comes and goes is handled by whatever rules already govern access to your other tools. SSO can be set to optional (members can sign in either way) or required (SSO is the only path into the org). Session duration is configurable per organization so policies around re-authentication match the rest of your internal tooling. Users who belong to more than one org — for example, an employee of one Anvil customer who also helps out a partner — keep a single Anvil identity and pass through the right SSO check when they switch between them. What we're thinking: SAML 2.0 and OIDC support Per-organization configuration by an admin, with a test-configuration step before going live Optional or required SSO enforcement Configurable SSO session duration Just-in-time provisioning so new employees don't need to be pre-invited Attribute mapping (name, email, optionally group → role) Audit logging of SSO sign-ins and config changes Help us shape this: Which IdP does your team use, and do you already rely on it for other developer tools? Do you need SSO to be required for your org, or is optional SSO enough? Would you want group-based role assignment (e.g. an "Anvil Admins" group in your IdP mapping to admin access) from day one, or is that a later refinement?

For teams that share responsibility for a driver, every error you see is also something that someone might already be on top of — or might have slipped through the cracks. Anvil would add the things you need to turn a list of errors into a shared backlog: a status for each error, an assignee, a thread of comments, and notifications when something you care about changes. Errors progress through a small set of statuses — New, Ongoing, Resolved, Regressed — so at a glance you can tell what's been looked at and what hasn't. When an error is marked Resolved and then happens again, it's flagged as Regressed, so you find out a fix didn't hold without needing to remember what you shipped last week. Errors can be muted for a chosen period when you know something is noisy and don't want to be pestered until you've landed the fix. Assignment and comments give the team a place to discuss the error next to the error itself, rather than in a separate chat channel or ticket. Assign an error to a teammate, @mention someone to pull them in, leave notes for whoever picks it up next. Watchers get notified when things change — a comment, a status flip, a regression — so the right people hear about it without everyone subscribing to everything. What we're thinking: Error statuses: New, Ongoing, Resolved, Regressed Automatic regression detection when a Resolved error recurs Muting for a fixed period (1 hour, 4 hours, 1 day, 7 days) Assignment to a single teammate per error Markdown comments with @mentions Watch an error to receive notifications on activity Email notifications at launch, in-app notification center next, chat integrations later Bulk actions for resolving or assigning many errors at once Help us shape this: Where does error triage live for your team today — chat channels, tickets, a spreadsheet, nothing formal? What's more useful earlier: assignment and a single clear owner, or comments and group discussion? Which notification channel matters most to you — email, in-app, or a Slack/Teams integration?

Anvil currently lets you narrow down logs, events, and errors through facet checkboxes — level, controller, driver, status, and so on. Search would add free-text content search on top of that, so you can find events containing a specific word or phrase rather than only the ones matching a known field. The same search bar handles both. Type level:ERROR and it filters by field — the same as clicking the facet, just expressed as text. Type timeout and it looks through the message content for that word. You can mix them: level:ERROR timeout shows ERROR-level logs whose message contains "timeout". Clicking facets updates the query in the bar, and editing the bar updates the facets, so however you prefer to work, the other side stays in sync. Searches live in the URL, so anything you find is shareable — paste the link into chat or into a ticket and whoever opens it lands on the same filtered view. Autocomplete suggests field names and recent values as you type, so the syntax is discoverable without having to memorise it. Searching events or errors follows through into their associated logs, so a query for a word in a log message surfaces the event or error that log belongs to. What we're thinking: One search bar shared across Logs, Events, and Errors pages field:value syntax for structured filtering (free on all plans) Free-text content search (Solo and above) Quoted phrase and negation ( -level:DEBUG ) support Facets and search bar stay bidirectionally in sync Autocomplete for field names, values, and recent searches Shareable URLs that round-trip the full query Events and errors matched via their associated log messages Saved searches and search-based alerts in a later phase Help us shape this: When you're debugging a specific issue, what's the first thing you usually try to find — a word in a log message, a specific controller, an error type? Would saved searches be valuable, or do you usually compose a query from scratch each time? What fields would you most want to search on that we haven't listed — driver name, MAC, version, something else?

If you already use Claude, Cursor, or another AI assistant in your development environment, the Anvil MCP server would turn it into a capable collaborator for driver work. MCP (Model Context Protocol) is the way AI assistants connect to external tools and knowledge bases; connecting an assistant to Anvil's MCP server gives it a working understanding of the Control4 API, the Anvil SDK, and your projects on Anvil. The first benefit is documentation. When you ask your assistant "how do I send a command to another device?", it can look up the actual signature of C4:SendToDevice along with examples, rather than guessing from general programming knowledge. The same applies to Anvil SDK calls, common driver patterns by device type (receivers, TVs, lighting, thermostats, security), and best practices for IP, serial, or IR control. Instead of code that looks right and doesn't compile, your assistant works from real reference material. The second benefit is project setup. Starting from an empty folder, your assistant could create a new project in Anvil, generate driver boilerplate for the device type you're building, configure the Anvil SDK, and wire in an API key — all through MCP tool calls. Later additions would let the assistant read the errors and events from your project in Anvil, so when you ask "why is my driver crashing?" it can look at actual telemetry and propose a fix rather than asking you to paste logs. The MCP server would be available on every plan — its purpose is to make driver development approachable enough that more people ship drivers. What we're thinking: Authenticated MCP connection to your Anvil account (device-authorization flow) Searchable documentation: Control4 API reference, Anvil SDK reference, driver patterns Project tools: create a project, scaffold a driver, generate an API key Device-type templates: receiver, TV, lighting, thermostat, security, generic Protocol templates: IP, serial, IR, Zigbee, Z-Wave Telemetry tools: query recent errors and events for a project directly from your editor Works with any MCP-capable assistant (Claude, Cursor, etc.) — no lock-in Help us shape this: Which AI assistants do you already use for coding? Would you connect them to Anvil's MCP server if it were available? What's the single biggest gap in AI assistance for driver work today — API knowledge, boilerplate, debugging help, or something else? Would access to your project's live errors and events from inside your editor change how you debug?

When a driver throws an error, get an AI-generated explanation of what happened, the likely root cause, and a suggested fix — without leaving the error detail view. Stack traces for Control4 drivers are often cryptic on their own. An AI analysis pulls together the context Anvil already has about the error (the events leading up to it, the logs around the same time, the driver version, the relevant C4 API behaviour) and turns it into a short explanation someone less experienced with Control4 can act on. For experienced developers, this shortens the loop between "something broke" and "I have a working theory". For less experienced developers, it helps build intuition about why an error happened, not just where — so over time, fewer errors need the AI to explain them. What we're thinking: One-click AI analysis from any error Plain-English explanation of what happened, why, and how to fix it Code example for the suggested fix Links to relevant Control4 documentation Rate whether the analysis was useful Help us shape this: What kinds of Control4 errors are hardest for you to debug today? Would you want AI analysis on-demand, or automatically for every new error? How concerned are you about error content being sent to an AI provider?