Feature Requests

Today Anvil is focused on the development loop: you see your own driver running on your own controller with full detail. Production monitoring would extend Anvil to cover the other side of the driver lifecycle — once your driver is in customers' homes, running on dealers' controllers, with no direct visibility on your end. The goal is to let you find out about a regression because Anvil surfaces it, not because a dealer calls you. In production mode the shape of the data changes. Instead of every event with full payload in real time, you get aggregated views: crash-free rates, version distribution, top errors with occurrence and install counts, error timelines. Errors are grouped by fingerprint across thousands of installs, so one underlying bug shows up as one entry rather than thousands. Logs are sampled instead of streamed in full, with the option to capture full logs for a specific install if you're helping a dealer chase something down. A Releases view shows how each version of your driver is performing in the field, including rollout progress as newer versions replace older ones. Because production data comes from controllers in customer homes, the model is privacy-first by design. Install IDs are hashed and not traceable to specific customers, controller IDs and customer information aren't collected at all, and dealers can disable telemetry per install if their customer requires it. A Development/Production toggle at the top of the project makes the mode you're in obvious, and the two modes have different navigation so the aggregate-focused production UI doesn't clutter your day-to-day debugging work. What we're thinking: Development/Production mode toggle per project, with clear visual distinction Production overview dashboard: active installs, error rate, crash-free rate, version distribution, top errors Aggregated error view with fingerprint grouping across thousands of installs Sampled production logs with configurable sampling rate (1%, 10%, 100%) and per-install full capture Release tracking: rollout progress, error rate per version, crash-free rate per version Privacy-first telemetry: hashed install IDs, no PII, per-install opt-out Alerting on error spikes, new errors in a release, regressions Help us shape this: How do you find out about problems in your driver today once it's deployed — dealer reports, customer complaints, nothing until something breaks badly? What would be more useful earlier: aggregated error reports from all installs, or a way to pull detailed data from a specific install when a dealer contacts you? What's your comfort level with telemetry from customer controllers — do dealers or end customers push back on it, and what would they need to see to be comfortable with it?

Driver development today is a round trip. Change code, build a .c4z, import it into Composer, deploy it to the controller, trigger the event you want to test, dig through logs, repeat. Each cycle is minutes of waiting for feedback before you find out whether your change worked — and most changes are small. Live debugging collapses that loop to seconds. Your driver code runs on your own machine, a real Control4 controller drives it with real events and real API calls, and your usual Lua debugger attaches to the running code the same way it would to any other Lua process. Breakpoints hit inside your callbacks. Variables inspect. Step over, step into, step out — all of it — inside the handlers the controller is actually calling into. The way it works is that your real driver isn't on the controller at all during a debug session. When you run anvil debug , Anvil temporarily swaps your driver for a small shim driver that ships with the CLI. The shim contains no business logic — it exists to be a bridge. The controller itself doesn't know anything has changed: it still calls OnDriverInit , ReceivedFromProxy , OnPropertyChanged and every other callback exactly as it always does. The shim intercepts each call, captures the arguments, and forwards it over a messaging channel to your machine, where your actual driver code is running in a local Lua process. Your code executes, hits any breakpoints you've set, and returns a response. The shim passes that response back to the controller as if nothing unusual happened. The messaging goes both directions, which is what makes it feel like you're actually on the controller. Callbacks come down from the controller to your machine as above. API calls go up from your machine to the controller: when your code calls C4:SendToDevice or C4:GetDeviceVariable or any other C4: function, the call doesn't execute locally — it's sent across the same channel to the shim, which runs it on the real controller (against real devices, real properties, real state) and returns the result back to your code. So C4:SendToDevice actually sends. C4:GetDeviceVariable actually reads the current value. Your code behaves the same way it would if it were running on the controller itself, because as far as the controller is concerned, it is. Because your code lives on your machine for the whole session, there's nothing to push up when you make a change. Save a file and the next callback the controller fires runs the new version — no rebuild, no repackaging, no redeploy, no hot-reload protocol to think about. The local Lua process just picks up what's on disk. That means the inner loop of driver development — tweak, trigger, observe, repeat — takes as long as it takes the controller to fire the event again, which is usually a fraction of a second. Both the shim and the CLI connect outbound to Anvil's messaging broker, so a direct network path between your laptop and the controller isn't needed. This works when the controller is behind a customer's firewall, on a VLAN you can't reach, or otherwise isolated from where you're sitting. When you're done, Ctrl+C ends the session and anvil deploy puts your real driver back on the controller exactly as it was before. What we're thinking anvil debug to start a session, anvil deploy to end it and restore your real driver The shim driver is part of the CLI — no manual stub deployment, no code changes to your driver Your usual Lua debugger (VS Code, ZeroBrane, etc.) attaches to the local process Bidirectional messaging: controller callbacks come down to your machine, C4 API calls go back up to the controller Real API calls execute on the real controller against real devices and real state Save a file to update — no rebuild, no redeploy, no hot-reload protocol Both sides connect outbound to Anvil's broker — works across VLANs and firewalls Logs and events from the session still flow to Anvil UI as normal Help us shape this: Which IDE or debugger do you use for Lua today — VS Code, ZeroBrane, something else? Of the three things this unlocks — breakpoints and variable inspection, save-to-update with no rebuilds, and remote reachability across VLANs/firewalls — which would change your workflow most? Any controller setups where network access between your machine and the controller is blocked today, making the outbound-only design important for you?