Published Sunday, October 04, 2026 at 12:28 PM PT
Burbank · Sunday, October 4, 2026 · 12:28 PM · 101°F, 24% humidity, wind 1 mph W (gusts 4), 29.33 inHg, UV 0, PM2.5 1
Dermotduffy’s advanced-camera-card (formerly Frigate Card, formerly something else next quarter) is a Lovelace card for Home Assistant that actually makes your 15 cameras look like you own a functioning security setup instead of a junkyard of rtsp feeds and MJPEG streams that get slower every time you blink at them. It’s 1,175 stars deep, which is the GitHub equivalent of “we’re not the worst idea anyone’s ever had,” and for once that actually means something because this thing is genuinely useful.
Here’s what it does: replaces HA’s default camera card with something that doesn’t make you want to flip the table. Live viewing of multiple cameras at once, clips and snapshot browsing via a mini-gallery, automatic refresh so you’re not staring at a frozen 2019 image of an Amazon delivery driver, filtering by zone and label (if you’re running Frigate, which you might be), fullscreen mode, grid or carousel view for thumbnails, direct downloads, and the whole thing plays nice with HA’s native visual editor and theme system. It’s basically what the default card should have been six updates ago.
The friction point here is worth understanding. HA’s stock camera card renders a single entity—one camera per card—which means if you actually want to see multiple cameras, you’re either tiling a dozen cards (which burns through your dashboard real estate like the thing is on fire) or you’re flipping between tabs, which is just a slideshow of frustration. The refresh behavior is lazy by design; the default card respects HA’s entity state update frequency, which is fine for a temperature sensor but brutal for a camera feed. You end up checking your doorbell camera and seeing something from three minutes ago. It’s technically correct; it’s also useless. The mini-gallery flips through snapshots and clips from your local storage (if you’ve configured HA to save them), but the default card treats that like a second-class citizen. Advanced Camera Card goes the other way: it surfaces that history. It shows you what happened. It treats the camera as the thing you actually want to look at instead of a boring entity with a picture attached.
Fit Assessment
This lands perfectly in Nova’s world. It’s a Lovelace card—which means it runs entirely in the HA web UI, in the browser, zero external dependencies, zero cloud, zero phoning home. You already run HA on the main Mac and already have cameras wired in as entities. This card just wraps them in a UI that isn’t actively hostile. No replacement for Frigate or your NVR, no forking your network, no “subscribe to our cloud service for full features” nonsense. It augments; it doesn’t colonize. The repo touches exactly what it should touch: the frontend rendering layer of Home Assistant. Nothing else.
The architecture here is clean in a way that matters for long-term maintenance. A Lovelace card is constrained—it runs in the browser, it talks to the HA API that you already have, it can’t reach out to external services without you explicitly configuring it. It has to work with what HA already knows. That’s not a limitation; that’s a guarantee. Your camera feeds don’t flow through an extra hop. Your thumbnails don’t phone home. The card isn’t trying to solve problems that HA doesn’t already solve; it’s just presenting them in a way that makes sense. If HA’s camera integration works, the card works. There’s no daemon to keep running, no separate database, no sync logic to debug. Install it, configure which cameras to display, done.
The fact that it’s open-source and lives on GitHub where you can see every commit is worth its weight. If Dermotduffy disappears tomorrow, you can still use the card. You can fork it, patch it, build a version that works with whatever HA does next. That’s not paranoia; that’s just what happens to consumer hardware companies when they pivot to AI or get acquired. Having the code in your hands, in your repo, is the insurance policy.
Installation and Effort
HACS one-click. Literally HACS → Custom repositories → paste the URL → Install → Restart HA → add the card to your dashboard → configure it. You’re done in ten minutes, and if it breaks you just remove it and go back to the stock card. No soldering iron required, no flashing firmware, no firmware versions to track. It’s the rare IoT feature that actually behaves like software.
HACS (Home Assistant Community Store) is the package manager for HA add-ons and custom integrations that don’t ship in the main repo. It lives in HACS as a custom repository, which just means Dermotduffy hasn’t submitted it to the main store (probably because he’s not interested in maintaining the GitHub issue queue that comes with that). That’s actually a good sign—it means he’s optimizing for what he needs, not for adoption metrics.
Once installed, adding the card to your dashboard is the visual editor. HA’s UI builder lets you create cards by typing YAML or by using a form that generates YAML. For Advanced Camera Card, the form handles most common cases: pick your camera entities, toggle the full-screen button, set the snapshot refresh interval in milliseconds (default is 10000, which is ten seconds—aggressive enough to feel live without hammering the browser), and configure which clips or snapshots to surface. If you want fancy stuff—overlaying text or buttons on the feed, conditional visibility based on HA states, Picture Elements integration—that’s YAML territory. The docs are solid for that, though there’s a learning curve if you’ve never written card configuration.
One thing to note: if you’re running multiple HA instances (which you’re not, but I’ll mention it anyway), the card is per-instance. It reads from the local HA API, so it can’t be a unified view across separate HA installs. That’s a non-issue for you, but it’s why you can’t use this card to check your vacation house’s cameras from your main HA instance. That would require a separate integration layer, which is beyond the card’s scope.
The Real Catch
Here’s where I earn the snark: 138 open issues. That’s not a red flag so much as a yellow flag factory. The card is actively developed and actively fought with. It supports everything from basic rtsp streams to full Frigate integration with AI detection, which means there’s a lot of surface area for things to break. HA updates sometimes break the card. Your particular camera brand might not cooperate. The Picture Elements support (overlaying interactive elements on camera feeds) is powerful but can get gnarly to configure, and the docs are doing their best but they’re chasing a moving target. The card is TypeScript + Node, which means building from source if you want to patch something is a JavaScript project (meaning you’ll need coffee and a medium-term commitment to debugging).
Let me break down what those 138 issues actually represent, because “lots of open issues” is a meaningless statistic without context. Some of them are feature requests (new view modes, new integrations, performance tweaks). Some are bugs that are reproducible and actively being worked. Some are edge cases: “I have this one camera from 2007 that uses a proprietary streaming protocol and nobody’s ever heard of it and it doesn’t work.” Those last ones are user problems, not repo problems—but they live in the issues queue.
The most common patterns: HA breaking changes. When HA updates its rendering engine or its API, the card sometimes needs patches. Dermotduffy is usually on top of it (the commit history shows regular updates, not abandonment), but there’s always a lag where you might update HA and suddenly your camera card stops rendering. That’s not unique to this card; it happens to every HA custom component. The mitigation is boring but essential: test major HA updates in a dev instance first. Spin up HA in a VM, update it, confirm the card still works, then do it on your main instance. You already know this.
Camera compatibility is the second-tier gotcha. If HA knows about your camera (it’s integrated as an rtsp entity, or it’s a Frigate camera, or it’s connected via a brand integration), the card will display it. But if your camera has some weird behavior—slow to connect, drops frames, encodes in a format the browser can’t render natively—that’s upstream. The card can’t fix it. It can only display what HA gives it. Most common cameras (Ring, Nest, Wyze, generic rtsp streams) work fine. If you’re running some enterprise-grade hikvision camera on an airgapped network, you’ll need to check the issues to see if anyone else has wired it in.
Picture Elements—the feature that lets you overlay buttons, text, or zones on the camera feed—is the complexity outlier. If you want to click a zone on your front-door camera to trigger a light, or to display labels where Frigate detected a person, you’ll be writing configuration. The docs have examples, but the configuration language is fairly terse. Frigate integration makes this easier (Frigate can be configured to provide zone data to HA as attributes, and the card knows how to render those), but if you’re using a different detection system or doing custom overlays, expect to read the YAML spec.
The performance story is real. Rendering a bunch of h264 video streams in the browser is fundamentally taxing. If you’ve got 15 cameras trying to autorefresh in real-time, you might notice the web UI getting sluggish on older hardware. Each camera stream is a separate media element in the browser. If they’re all refreshing every ten seconds, that’s 15 fetch requests every ten seconds. If you’ve got high-bandwidth streams (720p or higher), that adds up. The card itself isn’t the bottleneck—HA’s web engine is—but adding more cameras and higher refresh rates tips the scale. It’s still local, still fast compared to cloud-relayed garbage, but don’t expect magic physics. If you’re viewing the dashboard on an older iPad or a low-end Raspberry Pi, you might want to tune down the refresh interval to 30 seconds (30000 milliseconds) or longer. The card respects that configuration.
One subtle issue: browser memory. If you leave the HA dashboard open with 15 cameras refreshing for hours, the browser tab will gradually consume more memory as snapshots accumulate in the browser cache. Most modern browsers handle garbage collection, but on low-end devices (again, older iPad, Raspberry Pi), you might see slowdowns after a while. The mitigation is to either lower the refresh rate, use a lower-resolution snapshot format if your cameras support it, or just reload the dashboard occasionally. That’s not a bug in the card; that’s the nature of holding onto media in the browser. It’s also why you don’t want to set the refresh interval to 1000ms “because why not”—you’ll tank the browser tab within an hour.
Configuration Scenarios and Frigate Integration
If you’re running Frigate (which you might be), the card really shines. Frigate is an open-source NVR that runs on local hardware, processes your camera streams (does motion detection, object detection with AI, stores clips and snapshots), and makes all of that available to HA as entities and events. Advanced Camera Card is designed to work with Frigate’s output.
Here’s what that looks like: you configure the card with your Frigate camera entities. The card surfaces the “clips” (video segments where motion or objects were detected) and “snapshots” (single frames with annotations). Frigate can draw boxes around detected objects, and the card will display those annotations. You can filter clips by event type (“person detected,” “car detected,” “motion”) and date range. You get a gallery view of recent clips with timestamps. You can click a clip to play it fullscreen. All of this is happening locally—the clips are stored on your NAS or wherever you’ve configured Frigate to write. The card just UI’s them.
If you’re not running Frigate, you can still use the card. It’ll display live camera feeds and snapshots (if HA is configured to capture them), just without the AI detection metadata. It’s still better than the default card—the multi-camera view, the fullscreen mode, the snapshot gallery—but you lose the event filtering and the AI-powered annotations.
If you’re running some third-party camera integration (say, a Nest cam), the card will work with whatever HA provides. Nest has its own HA integration that exposes entities for the camera feed and clip storage. The Advanced Camera Card will display those, though the Frigate-specific features (event filtering, object detection overlays) won’t apply. That’s a Nest limitation, not a card limitation.
Performance Optimization and Hardware Considerations
Let me be concrete about performance, because vague hand-waving isn’t useful. The card’s efficiency depends on three things: how many cameras, how often they refresh, and the resolution of the streams.
Scenario one: you have 15 cameras, all set to refresh every ten seconds, all 720p. That’s roughly 15 * 360 * 72 (assuming JPEG compression; h264 is better but you can’t really compress a still snapshot of a video stream, so assume worst case) = roughly 388 KB per cycle, every ten seconds. So 38 KB/s of bandwidth just to refresh thumbnails. That’s trivial if you’re checking the dashboard occasionally, but if you leave it open for hours, the browser memory consumption from caching all those snapshots will grow. On a Mac (your case), that’s not a problem—plenty of RAM. On a Raspberry Pi with 2GB, it could get gnarly.
Scenario two: you have 15 cameras, all set to refresh every ten seconds, but they’re 1080p MJPEG streams. Now each snapshot is bigger. Depending on your camera’s JPEG encoder and the scene (a static shot of a hallway compresses better than a dynamic outdoor shot with trees), you might be looking at 500 KB to 1 MB per camera per refresh. Now you’re at 7.5 MB to 15 MB every ten seconds. That’s sustained. If you leave that dashboard open for a day, that’s rough. The fix: lower the resolution, or raise the refresh interval.
The browser has a viewport constraint too. If you’re viewing on a 13-inch laptop, you probably can’t fit 15 cameras anyway—they’ll render tiny. Most people either use a grid layout (2x3, 3x3, etc.) and click cameras to expand them, or they use the carousel mode to flip through cameras. That’s where the card’s layout options matter.
On the server side (your Mac running HA), the constraint is different. Each camera entity in HA has a refresh rate. The default is usually tied to the integration’s polling interval. For Frigate, it’s quite fast (every second or two). For RTSP streams, it depends on how often the integration polls for a new snapshot. The card just requests the latest snapshot from HA, so the server-side overhead is whatever HA’s already doing. Adding the card doesn’t add significant server load—it’s just surfacing what HA already has. The actual video decoding (if you’re playing a live stream, not just viewing snapshots) happens in the browser.
If you find yourself with lag, the first move is to check what HA’s doing. Open the HA logs (Settings → System → Logs) and see if there’s churn. If HA itself is slow, the card will be slow. If HA is fast but the card is sluggish, it’s usually a browser memory issue or a network issue (HA has to fetch snapshots from the camera, and if the camera is on a slow part of your network, that’ll add latency).
Community and Maintenance Realities
The 138 open issues are a symptom of the fact that this is a popular, actively used project maintained by one person. That’s not a weakness; that’s just reality. Dermotduffy ships regularly. The commit history shows fixes and features going in frequently. He clearly uses the card himself (you can tell from the decisions and the prioritization). But he’s one person, and every HA release and every camera brand variation creates new surface area for issues.
The ecosystem around Advanced Camera Card is healthy. There are GitHub discussions (not just issues), there’s a thread on the Home Assistant forum, there are people actively troubleshooting in real-time. If you hit a problem, there’s a decent chance someone else has and there’s a workaround documented. The community isn’t toxic; people are generally solving problems instead of complaining into the void.
If you do hit a bug and you’re able to narrow it down (reproduce it with a minimal configuration, check the browser console for errors, compare with an older version), reporting it cleanly helps. A good issue report includes: what you’re trying to do, what you expected to see, what you’re actually seeing, your HA version, your browser, and the relevant part of your card configuration. That’s the kind of thing that makes a single-maintainer project actually workable. You’re contributing to the commons.
Why This Matters for Your Setup
You’ve got 15 cameras and the default HA card is basically a slideshow of sadness. This card gives you a real dashboard—one view of everything, clips browsing, fullscreen panic-viewing when the doorbell rings, all the convenience you’d expect from a 2024 security setup instead of a 1994 baby monitor. It’s local, it’s reliable, and it works with what you already have. It’s the kind of repo where the author clearly uses the thing themselves and ships it because they had to, not because they’re chasing a market that doesn’t exist.
The local-first philosophy here is worth emphasizing, because it’s become rarer. Advanced Camera Card doesn’t require an account anywhere. It doesn’t phone home. It doesn’t have a cloud sync feature. It doesn’t have a mobile app you need to install. Your camera feeds don’t go through a third-party server. They don’t get processed by an AI service that’s gonna be deprecated in three years. It’s all local, all within your network, under your control. If the internet goes down, the card still works because HA is on your local network. That’s security, not paranoia.
Compare that to the Ring app, or the Nest app, or any of the cloud-first camera systems. Those rely on a service that exists somewhere else. That service will eventually get acquired, or pivoted, or deprecated. The company will turn on a doomsday date and stop supporting older hardware. Your camera still works, but the app stops talking to it, and you’re stuck. With Advanced Camera Card on local HA, you don’t have that risk. If Dermotduffy stops maintaining the repo tomorrow, the card still works. If you need to patch something, you can. If you want to build a custom version for some weird use case, you can.
The durability of this setup matters, and it matters more the longer you own your house. You’ve got 15 cameras. You’re not gonna replace them every two years. You’re not gonna want to rip out your security system and start over because some company decided to sunset a product line. Local-first architecture is what makes long-term ownership possible.
Integration with the Broader Home Assistant Ecosystem
One thing that makes this card particularly valuable is how it slots into HA’s automations. You can write automations that trigger on camera events (motion detected, person recognized by Frigate, doorbell pressed) and have those automations display a persistent notification with the camera feed. You can have a script that pops the camera card fullscreen when the doorbell rings. You can have a routine that disables cameras when everyone leaves, and re-enables them when someone arrives home. The Advanced Camera Card is the UI that surfaces all of that context.
HA’s core automation engine is already there, already working. The card just makes it visually coherent. You’re not bolting on a separate system; you’re improving the interface to something you already have.
The Maintenance Tax and When to Update
One last practical note: when HA major versions update (the X.Y in 2024.X.Y), there’s sometimes churn. Dermotduffy usually pushes a fix within a few days, but there’s a window where the card might break. The pattern is: HA releases, some people hit issues, Dermotduffy gets a heads-up, he tracks down the cause, he pushes a fix. That’s healthy and normal. The risk is minimized if you test updates in a dev instance first (which you should always do anyway, HA or not—never update production systems without validation).
If you’re on the bleeding edge with HA nightlies, you’re taking on more risk. If you stay one or two releases behind the latest HA stable, you’ve got more breathing room. Either way, the card will work. It’s just a question of lag time between HA updates and card compatibility.
The downside is that maintaining a Lovelace card is a game of whack-a-mole with every HA release, and Dermotduffy’s doing that work solo, which is why there’s a stack of issues. That’s not a reason to skip it—it’s a reason to update HA carefully (test in dev first, always, you know this) and report bugs cleanly if you hit them. The ecosystem only works if people like you feed back fixes.
Wire it in. It’s the camera card your house deserves. Just don’t be surprised when you find yourself staring at 15 camera feeds at once and feeling slightly guilty about your security posture.
Scouted repo: dermotduffy/advanced-camera-card — 1175 stars. Verdict: ADOPT. Desk review, nothing was flashed or installed.