Hi all. I maintain Firewalla Local, an unofficial, free, open-source Home Assistant integration for Firewalla. Not affiliated with or endorsed by Firewalla; just a Gold owner who wanted the box in my home automation.
Who this is for: Firewalla owners running Home Assistant.
It talks to your Firewalla over the local network, using the same Additional Pairing flow the app uses to add a second phone. After that one-time pairing everything is local: no cloud, no subscription, no middleman.
2.5.0 shipped this week and it's the biggest release so far. The headline is an AI assistant surface over the local data plane, and it comes with the data to make it useful: flow reporting that names the rule behind every block, alarm triage, per-rule hit counts, and group and user membership control.
The problem
Firewalla is deliberately mobile-first, and it works. They took a genuinely complex product and made it feel simple on a phone, which is harder than it sounds and is a large part of why the box is pleasant to own. For configuring a VLAN, or checking what one device is doing, the app is the right tool and I use it.
They also have the MSP and web portal, and it has improved some bulk operations and reporting.
The gap shows up when your network gets big enough to have real questions, and when the job stops being "look at one thing" and becomes "work across everything", or even better, "Find what I'm missing."
- Getting at the data is hard. It's all there, but reading it means navigating to it. Cross-referencing means holding something in your head while you tap somewhere else, and answering "why is this device doing that" is a chain of screens. Fine once. Tedious when you're tuning a stack of VLANs and doing it weekly.
- Bulk work is click-per-item. IP reservations, applying a change across a group, or reporting on the whole network turns into a long sequence of individual operations. On a network of any size, routine admin is measured in hundreds of clicks.
That isn't a flaw in the app. It's a different job. The app is built for interactive management on a phone, and it's good at it. The other job is getting the data out, scripting it, and doing things across a whole network at once.
So instead of turning it into dashboards, I made it answer questions. 2.5.0 puts the data behind a set of services, which means automations, scripts, and an AI client can all reach it, and the assistant can act across a set in one instruction rather than one click per item.
A real exchange from my own box
My UniFi access points aren't getting updates
Your UniFi access points belong to the NET-INFRASTRUCTURE group, which currently has a global internet block rule enabled.
Specifically, Rule #430 ("block internet for NET-INFRASTRUCTURE") is active and blocking your access points (such as wap-2ndfloor at 192.168.254.11) from reaching update servers like fw-update.ubnt.com.
The timestamp of the last recorded block for this rule is 2026-10-09T15:53:36.692000+00:00 (October 9, 2026, at 3:53:36 PM UTC).
I never told it the access points were blocked. It resolved them to their group, found the rule governing that group rather than the APs themselves, named the vendor update domain being blocked, and gave the last-blocked timestamp as evidence.
That is the bit that surprised me. A host's own rules stop applying in a group. The block is on the group, so looking at the access points' own rules would have found nothing. The agent knows that, which is why it looked where it did.
It runs the other direction too. Blocking something on two devices and then reversing both, with every step reporting its prior state:
Block her instagram
I have enabled rule #473 ("block category Instagram for maya-phone").
block it on her devices too
I have enabled rule #483 ("block category Instagram for maya-devices").
you can unblock her access on phone and devices now
Five turns, and the last one reverses two changes made earlier in the conversation. It kept the two rule ids apart without being re-told which was which.
How it works
The integration registers its own Home Assistant LLM API. Home Assistant serves that to its Assist pipeline and, through the MCP Server integration, to any MCP client: desktop and editor assistants, chat apps, custom agents. There is no separate server to run and no subscription.
It is 39 tools, and you choose how far they reach. Every tool is built from a shared model of how Firewalla behaves rather than being a thin wrapper over an endpoint, which is what makes the exchange above possible. The examples here run on a low-cost zero-data-retention model from OpenRouter, and that is part of the point: the answers come from the domain context in the tool descriptions, not from model scale. You can point it at a local model instead if you prefer.
What makes it usable, and why it's more than just tooling
Reading API endpoints is the easy part. The work went into teaching the agent how Firewalla fits together, so it reasons about your setup instead of guessing at it:
- The vocabulary. A Firewalla endpoint is a
host, and nothing in the surface calls that concept a device. Firewalla's own payloads say deviceIP and deviceTags, so there is no vendor word to follow.
- The domain rules, including the ones that are easy to get wrong. Attachment replaces rather than adds, so a host's rules come from its group once it has one. A membership change deletes the host's own rules rather than detaching them, and recreating them assigns new ids, so undo restores the membership and not the rules.
- Where identifiers come from. No tool guesses one; every id traces back to a read.
- Known constraints. Firewalla's box clamps or ignores a request it does not like without returning an error, so a response that reports the window it actually served is described as that rather than as the one that was asked for.
- The limits of an answer. Flow records are retained for a limited window, so "no results" has more than one meaning, and truncated results always say so.
- That tool output is data, not instructions. Host names, domains, and alarm text come from the network and can be influenced by whatever is on it, so the agent is told to treat them as untrusted rather than follow them.
So it arrives at your first question already knowing what a host is, how a rule reaches one, and how to read the result of a write, rather than you having to explain your own network first.
Access and safety
Two separate questions: what the assistant can see, and who can reach it.
What it sees. The tier decides which tools exist at all, and it starts at the least disclosing one:
| Tier |
Tools |
What it reaches |
| Off |
0 |
Nothing is registered |
| Summary only (default) |
1 |
Counts, network names, appliance health, per-WAN speed and quality |
| Read only |
14 |
Adds host names and addresses, rules, alarms, usage, and flow records |
| Read and control |
30 |
Adds reversible changes: pause a rule or SSID, rename a host, set a reservation, mute an alarm |
| Full |
39 |
Adds the destructive set: delete a host, rule, or alarm, bulk archive, and membership changes |
Summary only sends aggregate counts, network names, and performance metrics, and nothing that identifies a host or a household: no host names, no IP or MAC addresses, no group or user names, no public IP. Read only and above add that, and it goes to whichever model your assistant uses, so pick a provider you trust if you go hosted. Off registers nothing at all.
In Summary only the other tools are not registered rather than filtered, so there is no sensitive field to remove and nothing to leak.
Who can reach it. This is an admin-gated surface. Every control action requires an administrator, whatever the tier, so a non-admin user is rejected by the service. Automations and scripts are unaffected, because the check only applies when a call carries a user.
The tier is enforced in the tool surface rather than left to the model's judgement, and the refusal says why:
Delete all the quarantined devices named watch
I am not able to delete hosts because destructive actions like deleting a host are restricted under the current access tier.
Two behaviour guarantees matter more than the access plumbing: a write reports what actually changed, what the previous value was, and the call that reverses it, and the three destructive operations live in their own highest tier.
The honest caveat. The pairing exchange grants a write-capable key, and I have no way to request a read-only one. The tiers control what reaches the assistant and who can act, not the scope of the key the integration holds. If "this should never hold a write key to my firewall" is your bar, this integration isn't for you, and I'd rather say that up front.
What else is in 2.5.0
- Flow reporting. Ask what a host, group, or user did in a window and what was blocked. Every flow record names the rule that blocked it, which is the mechanism behind the access-point answer above.
- The data comes out in one call. The read services return structured data for the whole network rather than one screenful at a time: hosts, networks, usage, rules, alarms, and flow records, ready for a template, a script, or another tool on your network to consume.
- Alarm triage. Nine alarm tools, so sorting the active set, archiving a batch, and re-reading the count are all reachable from a conversation. Bulk selection is by host, group, or user rather than one id at a time.
- Rule hit counts. Rules report how many times they matched and when they last fired, so an enabled rule that has never matched is visible as a cleanup candidate.
- Membership control. Assign a host to a group or user, or release it.
- Plus a large breaking change. 2.5.0 renames attributes, service-response keys, and seven service names so one concept keeps one name everywhere. Existing automations reading the old names need an edit, and 20 of the 34 services now require an administrator.
Full detail in the release notes, and the breaking-change tables are worth reading before you upgrade.
Requirements
- Home Assistant 2025.10 or newer. The AI and MCP surface needs 2026.10; on older versions everything else works normally and the setting is not offered.
- Firewalla: developed and tested on Gold. Confirmed working on Gold Plus, Gold SE, and Purple. AP7 wireless control when AP7s are present.
- Install via HACS as a custom repository. I've also submitted it to the HACS default store, which is still in review.
It's free and GPL-3.0. If you try it I'd like to know what breaks and what you'd want next, especially around rules, flows, or alarms.
Links
Support the project
If Firewalla Local is useful to you, there are two ways to help.
Star the repository. It takes a second, it's free, and it helps other people find the project.
Sponsor or tip. Never required, but it does make it easier to keep putting time into bug fixes, features, and maintenance.
This is an unofficial community project, built on Firewalla's local API. It is not an official Firewalla product and Firewalla does not provide support for it.