Local control of a Tesla Powerwall from Home Assistant

 A few months ago, I realised that almost everything my Tesla Powerwall does in Home Assistant depended on Tesla's cloud. Readings came from the cloud, and every setting change went through the cloud. If the internet was down, or Tesla's API was having an outage, my automations were blind. So I started building a Home Assistant integration that talks to the Powerwall locally. In this post, I am going to explain what it does, what it does not do, and how it compares with the other options available today.

What is Powerwall TEDAPI?

Powerwall TEDAPI is a free, open-source (MIT) Home Assistant integration, installed through HACS. It connects to the Powerwall gateway on your home network using the gateway's local API, through the excellent pypowerwall library. On a Powerwall 3, that means a signed connection: Home Assistant holds a private key, and the gateway accepts commands signed with it.

Once the key is set up, the day to day work is local:

• Readings: power flows, battery level, grid status, energy counters, temperatures, fans and alerts.
• Settings: operation mode, backup reserve, grid export and grid charging.
• Battery dispatch: charge or discharge at a set power for a set time.
• Max backup: charge to full and hold, the same thing Storm Watch does.
• Go off-grid: disconnect the house from the grid, and reconnect it again.

Why not just use the cloud integrations?

A setting change through the cloud can take a minute to reach the gateway. Also If the cloud is unavailable, it does not reach it at all.

How does the setup work?

The setup wizard registers a key for Home Assistant with the Powerwall. You can do this with a Tesla account sign-in, or through Home Assistant's Tesla Fleet or Teslemetry integration if you already use one of them. After that, you confirm the key at the Powerwall itself by switching it off and on. Tesla requires this, so that nobody can add a key from the cloud alone.

After key is confirmed, everything runs on your local network. Home Assistant does not need to be exposed to the internet at any point.

The cloud is still optional. You can keep a Tesla account or Tesla Fleet as a cloud backup, so that settings still work if the gateway is unreachable. You can even use both, in the order you choose.

What did I actually develop and test?

I initially developed this to avoid Tesla Cloud API outages. Previously, I used a wholesale energy retailer, where I had to control battery grid charging and discharging to align with wholesale energy market prices.

So, I started by using a read only local Wi-Fi connection for a few months and recently expanded it to support local control as well. I thought other Home Assistant community members might face similar issues when the Tesla API is unable to communicate with their home gateway.

So, here's what I've tested on my own Powerwall 3:

Read-only to write access: Tested the read-only local Wi-Fi connection over several months before recently expanding it to support write access.

Settings restore: Tested hourly settings drop and restore operations over several days and across two firmware updates.

Battery dispatch: Tested charging and discharging at 500 W, with each session ending automatically as expected.

Go off-grid: Tested a five-minute off-grid run, with the Powerwall automatically reconnecting at the scheduled end time.

Key registration through Tesla Fleet: Registered a new key and confirmed that Home Assistant switched to it only after the Powerwall accepted it.

Gateway restarts: Confirmed that the integration recovered automatically, without manual intervention, after both a firmware update and a manual Powerwall restart.

Where does Powerwall TEDAPI sit?

In my opinion, it is the most complete free and local-first option I found: readings and all four settings are local, key setup happens inside Home Assistant with other choices(Fleet Integration, Teslemetry, Tesla Custom Integration, PowerSync, etc) and no subscription, and it handles Tesla's quirks such as the hourly setting drop.  

If you have a Powerwall, run Home Assistant, and want local control without a subscription, give it a try. It is especially useful if your automations depend on the export and grid charging settings being correct.

I would love to hear how it behaves on your system. The project is on GitHub: cnapagoda/ha-powerwall-tedapi.

Tesla, Powerwall and Tesla Fleet are trademarks of Tesla, Inc. Home Assistant is a trademark of the Open Home Foundation. Teslemetry, PowerSync, and other product names belong to their respective owners. They are used here only to identify the products being discussed. Powerwall TEDAPI is an independent, community project. It is not affiliated with, endorsed by or supported by Tesla, Inc. I would also like to acknowledge Claude, Anthropic's AI assistant. I developed the recent changes to this integration with Claude Code, which served as my pair programmer.

The integration uses interfaces that Tesla does not document or support, which Tesla may change at any time. It is provided under the MIT License, “as is”, without warranty of any kind. Features such as battery dispatch and go off-grid control real electrical equipment; use them at your own risk.

XSLT Conditional Logic: if, choose, when and otherwise

In XSLT (Extensible Stylesheet Language Transformations), we often need to produce different output based on conditions. XSLT gives us two main instructions for this. The xsl:if instruction and the xsl:choose instruction. In XSLT 2.0 or later, we also have a shorter inline syntax. I thought of writing a blog post so others can easily find examples as well.

xsl:if Instruction

XSLT Sorting with xsl:sort

 Sorting is a very common requirement in XSLT transformations. XSLT gives us the xsl:sort instruction for this. It works inside xsl:for-each and inside xsl:apply-templates. While working on integration scenarios, I have used almost every option of xsl:sort. I thought of writing a blog post so others can easily find examples as well.

Basic Sorting

The xsl:sort instruction must be the first child of xsl:for-each. The select attribute defines the sort key.

<?xml version="1.0" encoding="UTF-8"?>

<employees>

    <employee>

        <name>Nimal</name>

        <salary>85000</salary>

        <department>Finance</department>

    </employee>

    <employee>

        <name>Amara</name>

        <salary>92000</salary>

        <department>Engineering</department>

    </employee>

    <employee>

        <name>Kasun</name>

        <salary>78000</salary>

        <department>Engineering</department>

    </employee>

</employees>

Sort by name:

Why API Gateways Are Not Enough for the AI Era

For many years, whenever we needed to control traffic between applications, we had one clear answer. Put an API gateway in front of it. It worked well. But in 2026, our applications are not the only consumers anymore. AI agents are calling models (GPT, Claude, etc), calling tools, and even calling other agents. Recently, I spent some time looking into how to govern this new kind of traffic. I realised that our traditional API gateways are not ready for it.

In this post, I am going to walk through what AI gateways are, the three types you will see in the market, and why you should not force your existing API gateway into this role. I will also cover a common question at the end. If your API needs are simple, can one AI gateway do both jobs?

What is an AI gateway?

An AI gateway is a middleware layer. It sits between an AI agent and whatever the agent is calling. It enforces identity, policy, cost control, and safety at that boundary. 

The market terminology is confusing. Different vendors use different names for the same thing. The simple way I think about it is to classify each gateway by its target: 

• Model/LLM gateway:  when the target is a model or LLM 
• MCP gateway: when the target is a tool exposed over MCP 
• Agent gateway: when the target is another agent 

"AI gateway" is just a term for all above three. The common idea is this, wherever governance changes are needed, you need a control point.