Tesla Powerwall 3 support?

[zcpnate]

Was hoping to test out evcc but it does not appear there is support for Powerwall 3.

This has been accomplished in:
https://github.com/jasonacox/pypowerwall

but it seems the go-powerwall implementation used in evcc is pretty old and lacks Cloud API or Powerwall 3 support.

Any plans for powerwall 3 support?

[GrimmiMeloni]

I can have a look a Jason's changes, but cannot promise anything.
I only have access to my PW2, so it will be impossible to test any changes.
For this to happen we will likely need a contribution by someone with a PW3.

[felberch]

Hi I just got my Tesla Powerwall 3 today.
Unfortunately I can not get it working in my evcc config:

• name: my_battery
  type: template
  template: tesla-powerwall
  usage: battery
  host: 192.168.0.112
  password: XXXXX
  refreshToken: EU_404

Error msg:
main ] INFO 2024/12/17 19:23:57 evcc 0.131.11
[main ] INFO 2024/12/17 19:23:57 using config file: /etc/evcc.yaml
[main ] INFO 2024/12/17 19:23:57 listening at :7070
[powerwall] TRACE 2024/12/17 19:23:57 GET https://192.168.0.112/api/status
[powerwall] TRACE 2024/12/17 19:23:57 404 page not found
[main ] FATAL 2024/12/17 19:23:57 cannot create meter 'my_battery': cannot create meter type 'template': cannot create meter type 'powerwall': API call to https://192.168.0.112/api/status returned unexpected status code 404 ("404 page not found\n")

[zcpnate]

Unfortunately evcc does not work with PW3

[felberch]

I got this. As GrimmiMeloni mentioning it needs contribution by someone with a PW3.
I have a PW3 I can run test and help.

[vtml]

Just putting in my 2 cents with a Powerwall 2 and running on firmware version 24.44.0 510adfd5.
The Tesla Fleet API is now required

[GrimmiMeloni]

This thread is about PW3 support.
FWIW, I cannot confirm your statement. My PW2 / TG2 is on 24.44.0 as well and is still working fine.
Please open a separate discussion if your problem persists and you would like us to further investigate.

[foersst]

This thread is about PW3 support.

FWIW, I cannot confirm your statement. My PW2 / TG2 is on 24.44.0 as well and is still working fine.

Please open a separate discussion if your problem persists and you would like us to further investigate.

Was it Running all the time or did you some changes to make it run again? Thx

[GrimmiMeloni]

No changes. Running like this for roughly 2 years now.

[foersst]

Mine was also Running one year without any issues. Sine three days not working anymore. According to other threads there could be an issue with the availability of API.

[erikgieseler]

You could use a pyPowerwall proxy server as a workaround and run it in TEDAPI MODE.

This also works with the Powerwall 2 without any problems.
Unfortunately, I cannot test the Powerwall 3, but it should also work.

The measured values can then be retrieved via http://localhost:8675/soe and http://localhost:8675/aggregates.
The structure of the JSON corresponds to the previous local Powerwall 2 API.

However, a static route to the IP 192.168.91.1 must be set up, otherwise it will not work.

See: https://github.com/jasonacox/pypowerwall/tree/main/proxy

docker-compose.yml

version: ‘3’

services:
  pypowerwall:
    image: jasonacox/pypowerwall:latest
    container_name: pypowerwall
    hostname: pypowerwall
    ports:
      - 8675:8675
    environment:
      - PW_PORT=8675
      - PW_HOST=192.168.91.1
      - PW_GW_PWD=123abc
      - PW_CACHE_EXPIRE=5
      - PW_TIMEZONE=Europe/Berlin
      - TZ=Europe/Berlin      
      - PW_DEBUG=no
    restart: always

[zcpnate]

This is actually a great idea.. I’ll give it a try and report back

[erikgieseler]

Try a custom meter with the http plugin
https://docs.evcc.io/docs/reference/plugins#http-lesenschreiben

meters:

- name: grid
  type: custom
  power: 
    source: http
    uri: http://IP:8675/aggregates
    jq: .site.instant_power
    timeout: 10s

- name: solar
  type: custom
  power: 
    source: http
    uri: http://IP:8675/aggregates
    jq: .solar.instant_power
    timeout: 10s

- name: battery
  type: custom
  power: 
    source: http
    uri: http://IP:8675/aggregates
    jq: .battery.instant_power
    timeout: 10s
  soc:
    source: http
    uri: http://IP:8675/soe
    jq: .percentage
    timeout: 10s
  capacity: 13.5

[zcpnate]

Reposted from proper GH account -- will try a custom meter

This is showing promise. pyPowerwall does proxy the config and api as expected. However, some TLS issues to start. Going direct to pypowerwall is a dead end as :8675 is http only and evcc tries to connect to https:// and fails with

[main  ] FATAL 2025/01/11 18:52:33 cannot create meter 'grid1': cannot create meter type 'template': cannot create meter type 'powerwall': Get "https://10.16.10.100:8675/api/status": tls: first record does not look like a TLS handshake

not sure if there are any hidden settings to modify this behavior

putting pypowerwall behind a proxy with proper tls should work and does not complain in curl and wget even from within the container but evcc still fails with

[main  ] FATAL 2025/01/11 19:19:18 cannot create meter 'grid1': cannot create meter type 'template': cannot create meter type 'powerwall': Get "https://exampledomain.com/api/status": remote error: tls: unrecognized name

❯ curl https://exampledomain.com/api/status
{"din": "XXXXX-00-J--XXXXX", "start_time": "2024-05-09T14:30:13-04:00", "up_time_seconds": null, "is_new": false, "version": "24.36.11 c365326b", "git_hash": null, "commission_count": 0, "device_type": null, "teg_type": "unknown", "sync_type": "unknown", "cellular_disabled": false, "can_reboot": true}

thoughts?

[zcpnate]

Making progress. Past the powerwall startup errors. Now getting

[ocpp  ] INFO 2025/01/11 14:45:20 charge point connected, registering: d0b465

[ocpp  ] DEBUG 2025/01/11 14:45:47 charge point disconnected: d0b465

[ocpp-1] DEBUG 2025/01/11 14:45:47 failed configuring availability: timeout

[main  ] FATAL 2025/01/11 14:45:47 cannot create charger 'charger': cannot create charger type 'template': cannot create charger type 'ocpp': cannot send request 562748696, no client d0b465 exists

[main  ] FATAL 2025/01/11 14:45:47 will attempt restart in: 15m0s

[ocpp  ] DEBUG 2025/01/11 14:45:48 charge point connected: d0b465

meters:
  - name: grid
    type: custom
    power:
      source: http
      uri: http://10.16.10.100:8675/aggregates
      jq: .site.instant_power
      timeout: 10s

  - name: solar
    type: custom
    power:
      source: http
      uri: http://10.16.10.100:8675/aggregates
      jq: .solar.instant_power
      timeout: 10s


loadpoints:
  - title: Garage # display name for UI
    charger: charger # charger reference

chargers:
  - name: charger # reference name
    type: template
    template: pulsarplus

site:
  title: Home
  meters:
    grid: grid
    solar: solar

thoughts?

[zcpnate]

This seemed to fix itself. also solar isnt a valid meters key under site, that caused some problems too. Making progress -- this might actually be working!

[erikgieseler]

site:
  title: Home
  meters:
    grid: grid
    pv: solar
    battery: battery

[zcpnate]

Getting there!

meters:
  - name: grid
    type: custom
    power:
      source: http
      uri: http://10.16.10.100:8675/aggregates
      jq: .site.instant_power
      timeout: 10s

  - name: solar
    type: custom
    power:
      source: http
      uri: http://10.16.10.100:8675/aggregates
      jq: .solar.instant_power
      timeout: 10s

  - name: battery
    type: custom
    power:
      source: http
      uri: http://10.16.10.100:8675/aggregates
      jq: .battery.instant_power
      timeout: 10s
    soc:
      source: http
      uri: http://10.16.10.100:8675/soe
      jq: .percentage
      timeout 10s

[zcpnate]

Thanks for your help, I think we're there! Just some final tuning.

For those that may be interested, I also got Rivian working with MQTT from HA with the built in rivian add on and a publishing automation.

Final Config for those interested in getting PW3 working:

mqtt:
  broker: 10.16.10.101:1883
  user: evcc
  password: evcc123

vehicles:
  - name: R1Mango
    type: custom
    title: R1Mango # display name for UI
    capacity: 131 # battery capacity (kWh)
    soc: # battery soc (%)
      source: mqtt
      topic: "/rivian/sensor/battery_soc"
      timeout: 30s
    range: # optional electric range (km)
      source: mqtt
      topic: "/rivian/sensor/range"
      timeout: 30s
    odometer: # optional odometer (km)
      source: mqtt
      topic: "/rivian/sensor/odometer"
      timeout: 30s
    limitsoc: # optional in-vehicle limit soc, read-only (%)
      source: mqtt
      topic: "/rivian/sensor/charge_limit"
      timeout: 30s

meters:
  - name: grid
    type: custom
    power:
      source: http
      uri: http://10.16.10.100:8675/aggregates
      jq: .site.instant_power
      timeout: 10s

  - name: solar
    type: custom
    power:
      source: http
      uri: http://10.16.10.100:8675/aggregates
      jq: .solar.instant_power
      timeout: 10s

  - name: battery
    type: custom
    capacity: 27
    power:
      source: http
      uri: http://10.16.10.100:8675/aggregates
      jq: .battery.instant_power
      timeout: 10s
    soc:
      source: http
      uri: http://10.16.10.100:8675/soe
      jq: .percentage
      timeout: 10s


loadpoints:
  - title: Garage # display name for UI
    charger: charger # charger reference
    vehicle: R1Mango
    mode: pv

chargers:
  - name: charger # reference name
    type: template
    template: pulsarplus
    remotestart: true

site:
  title: Home
  meters:
    grid: grid
    pv: solar
    battery: battery

And for the record the mqtt.publish automation on HA side. Seems like evcc wants KM

alias: Rivian2MQTT
description: ""
triggers:
  - minutes: /1
    seconds: 0
    trigger: time_pattern
actions:
  - data:
      topic: /rivian/sensor/battery_soc
      payload: "{{states('sensor.r1mango_battery_state_of_charge', rounded=True, with_unit=False)}}"
    action: mqtt.publish
  - data:
      topic: /rivian/sensor/range
      payload: "{{states('sensor.r1mango_estimated_vehicle_range', rounded=True, with_unit=False) | float * 1.60934 | round(2)}}"
    action: mqtt.publish
  - data:
      topic: /rivian/sensor/odometer
      payload: "{{states('sensor.r1mango_odometer', rounded=True, with_unit=False) | float * 1.60934 | round(2)}}"
    action: mqtt.publish
  - data:
      topic: /rivian/sensor/charge_limit
      payload: "{{states('sensor.r1mango_soc_limit', rounded=True, with_unit=False)}}"
    action: mqtt.publish

[Boilermaker86]

I could not find any new updates regarding the Powerwall 3 implementation into EVCC besides the one mentioned in this discussion.
My Powerwall 2 setup is still working without any issues with the current/old configuration but I could not get it running on a new Powerwall 3 installation.
Is there an official update planed in evcc (Tesla Fleet API) like for the car implementation?
Thanks

[symmaxx-sys]

ich besitze ebenfalls eine Powerwall 3 und würde mich um eine Aktualisierung der Integration sehr freuen. Hier kommt nur 404 page not found

[blampe]

@GrimmiMeloni I have a branch here where I've started adding PW3 support. Still very early. It uses the same Fleet API client used for vehicles but with support for the live status endpoint (evcc-io/tesla-proxy-client#1). Tesla no longer returns total capacity (probably because it makes warranty claims too easy) so I'm hard-coding 13.5kWh for now.

[GrimmiMeloni]

Regarding the hardcoded capacity: Are you aware of the PW3 support in https://github.com/jasonacox/Powerwall-Dashboard ? If not, you may want to have a closer look. There's apparently different ways to access (and even via a local interface) for PW3. Maybe the current capacity is available via one of these ways. The required network plumbing might not be worth the effort though.

If you are just interested in the nominal capacity, you can still get this from the SiteInfo endpoint.

[blampe]

Regarding the hardcoded capacity: Are you aware of the PW3 support in https://github.com/jasonacox/Powerwall-Dashboard ? If not, you may want to have a closer look. There's apparently different ways to access (and even via a local interface) for PW3. Maybe the current capacity is available via one of these ways. The required network plumbing might not be worth the effort though.

Yes, I saw that but I worry it will only become more locked down. I'm also primarily interested in something that "just works" because my tinkering time is limited these days :)

If you are just interested in the nominal capacity, you can still get this from the SiteInfo endpoint.

That's a good idea. I could have sworn it was also missing from that payload but I might be misremembering. I should have more time to test this weekend.

I'm completely new to EVCC and could use a small clarification -- since the PW3 can monitor grid + solar + battery, is it expected that the user would configure grid + solar + battery meters three times using the same PW3 credentials? The API does have some moderate rate limits, and as I've implemented things currently it seems to initialize 3 API instances so I worry about that a bit. Might be easier to discuss on the PR.

For what it's worth I'm also testing out support for ChargePoint Home Flex.

[GrimmiMeloni]

since the PW3 can monitor grid + solar + battery, is it expected that the user would configure grid + solar + battery meters three times using the same PW3 credentials? The API does have some moderate rate limits, and as I've implemented things currently it seems to initialize 3 API instances so I worry about that a bit.

At least for PW2 this is the case, yes. But there we have a local interface so it does not matter.

[mfuchs1984]

Caching should be an option. I think this is used in other interfaces already.