Tesla Powerwall 2 Integration

Hi, I am occuring the famous autentification error on https://IP/api/login/Basic

{"code":401,"error":"bad credentials","message":"Login Error"}

In the Thing setting I put the local id (customer) and local pw correctly
If I invoke the https://api/meters/aggregates I get the data

In the log file after getting the getMeterAggregates I have the following warn

2021-10-17 18:39:39.469 [WARN ] [rwall.internal.TeslaPowerwallHandler] - Unexpected error connecting to Tesla Powerwall
	at org.openhab.binding.teslapowerwall.internal.api.MeterAggregates.parse(MeterAggregates.java:67) ~[?:?]
	at org.openhab.binding.teslapowerwall.internal.TeslaPowerwallWebTargets.getMeterAggregates(TeslaPowerwallWebTargets.java:127) ~[?:?]
	at org.openhab.binding.teslapowerwall.internal.TeslaPowerwallHandler.pollStatus(TeslaPowerwallHandler.java:129) ~[?:?]
	at org.openhab.binding.teslapowerwall.internal.TeslaPowerwallHandler.poll(TeslaPowerwallHandler.java:96) ~[?:?]

any advice to solve the issue? I’am on OH 3.2.0
Thanks
Lorenzo

No real ideas… my installations are still running 3.1.0, I havent tested yet with 3.2.0

Hi, I still have the same problem. I am on OH 3.2.0 and with Powerwall2 firmware 21.20.07
The strange thing is that the binding is connecting with PW2, autenticate correctly, than getOperations than getBatterySOE , getGridStatus and getMeterAggregates and later I got a connection error.
Fews value are parsing correctly while the others are NULL …
Can be a Parsing error? here attach an example of the respose

021-11-01 16:36:15.911 [DEBUG] [rwall.internal.TeslaPowerwallHandler] - Polling for state
2021-11-01 16:36:15.911 [DEBUG] [ll.internal.TeslaPowerwallWebTargets] - logonjson = {"username":"customer","password":"xx","email":"xx@gmail.com","force_sm_off":false}
2021-11-01 16:36:15.912 [DEBUG] [ll.internal.TeslaPowerwallWebTargets] - Calling url: https://192.168.0.xx/api/login/Basic
2021-11-01 16:36:16.513 [DEBUG] [ll.internal.TeslaPowerwallWebTargets] - Token: ankD6i2pVSJbj_onHXfCLsLbKKMAgw8XkDsqr7us1WllYcI2bbQQ79z2nTBQXBTGmJY-x_-l1UBxWw4_xRKmYQ==
2021-11-01 16:36:16.524 [DEBUG] [ll.internal.TeslaPowerwallWebTargets] - getOperations response = {"real_mode":"autonomous","max_pv_export_power_kW":0,"backup_reserve_percent":24}
2021-11-01 16:36:16.536 [DEBUG] [ll.internal.TeslaPowerwallWebTargets] - getBatterySOE response = {"percentage":9.084856107124361}
2021-11-01 16:36:16.548 [DEBUG] [ll.internal.TeslaPowerwallWebTargets] - getGridStatus response = {"grid_status":"SystemGridConnected","grid_services_active":false}
2021-11-01 16:36:16.566 [DEBUG] [ll.internal.TeslaPowerwallWebTargets] - getMeterAggregates response = {"site":{"last_communication_time":"2021-11-01T17:36:16.490359311+02:00","instant_power":997,"instant_reactive_power":-415,"instant_apparent_power":1079.9231454135984,"frequency":0,"energy_exported":49.46347124934255,"energy_imported":375392.9554079209,"instant_average_voltage":392.2748668981993,"instant_total_current":5.045,"i_a_current":0,"i_b_current":0,"i_c_current":0,"last_phase_voltage_communication_time":"0001-01-01T00:00:00Z","last_phase_power_communication_time":"0001-01-01T00:00:00Z","timeout":1500000000,"num_meters_aggregated":1},"battery":{"last_communication_time":"2021-11-01T17:36:16.490589673+02:00","instant_power":-510,"instant_reactive_power":-20,"instant_apparent_power":510.3920062069938,"frequency":49.97,"energy_exported":880,"energy_imported":2020,"instant_average_voltage":226.60000000000002,"instant_total_current":11.200000000000001,"i_a_current":0,"i_b_current":0,"i_c_current":0,"last_phase_voltage_communication_time":"0001-01-01T00:00:00Z","last_phase_power_communication_time":"0001-01-01T00:00:00Z","timeout":1500000000,"num_meters_aggregated":1},"load":{"last_communication_time":"2021-11-01T17:36:16.490359311+02:00","instant_power":494.75,"instant_reactive_power":-418.5,"instant_apparent_power":648.012200888224,"frequency":0,"energy_exported":0,"energy_imported":374203.49193667155,"instant_average_voltage":392.2748668981993,"instant_total_current":1.2612329816388528,"i_a_current":0,"i_b_current":0,"i_c_current":0,"last_phase_voltage_communication_time":"0001-01-01T00:00:00Z","last_phase_power_communication_time":"0001-01-01T00:00:00Z","timeout":1500000000}}
2021-11-01 16:36:16.567 [WARN ] [rwall.internal.TeslaPowerwallHandler] - Unexpected error connecting to Tesla Powerwall

looking in the binding file it seems a RuntimeException Error … what does it means and how to solve?

Waiting some advice to solve the issue…
Regards
Lorenzo

I’m on OH3.1 and Powerwall firmware 21.35.3 runing on to different sites, and both are running fine.

I’m trying to resync my fork against the latest OH3.2 code and rebuild the binding right now - perhaps that will help?

Edit:
New build https://smedley.id.au/tmp/org.openhab.binding.teslapowerwall-3.2.0-SNAPSHOT.jar

Hi Paul, thanks for your help.
Finally I found out the problem: it was related to hardware:
The Inverter TA inside the gateway was mis-configurated by the installer and therefore the gateway did not measure any solar value … The null value is not allowed in your binding creating the famous error. By re-configure correctly the TA, the binding starts to work.
I apologize if I bore you.
Regards
Lorenzo

2 Likes

Should now be in the Marketplace - Tesla

1 Like

Hey guys, how much interest is there is the ability to change reserve and mode?

I now have a Time of use tariff -whilst I’m currently using Darwins Den on Smartthings to control the reserve, it would be nice to do this via OH.

At the moment - I’m thinking of a minimalist binding that only allows changing settings via the Tesla API. To keep things simple, you’d need to get the API key via an app - and potentially need to refresh it every 45 days.

In Germany this would be a very interesting feature. Since 2017 I ask Tesla to implement such a feature - they just didn’t do it!

Reason: In Germany PV-generated output can only be sold to the local supplier if it is limited to 70 % of the maximum power, e.g… my 6kWp-PV must be throttled to 4.2 kW (+ house use), even if it generates more. Since the powerwall starts charging in the morning it is full by midday, afterwards I have to throttle the PV-generation. The intelligent mode would be to charge between 11 and 14 to avoid this.
Obviously in some regions (California, Australia, Great-Britain ?) Tesla enabels time-based control, but not in Germany :wink:

A feature to control charging time or chargingpower really would be nice!

Hi Christian,

Ok, I’ll have a think about how hard this would be.

Nite that for now I’m thinking it would be a separate binding to avoid complexity.

Would it be possible to use the two bindings parallel?

Yes, one would use the local API, the control one would use the web based api (State And Settings - Tesla API)

Hi Christian,

The options I can give you is:
a) the ability to set the battery reserve setting
b) the ability to set the battery mode to one of:

  1. {“default_real_mode”:“backup”}
  2. {“default_real_mode”:“self_consumption”}
  3. {“default_real_mode”:“autonomous”}

I’m not 100% sure this will do what you need.

For me all I want to do is manipulate the battery reserve setting to take advantage of cheaper off peak power when solar production is expected to be low.

Cheers,

Paul

In Germany only “self_consumption” can be elected in the app.

What does changing the battery reserve setting do?
Can you define treshholds such that the PW

  • is not charging any more if the battery reserve is more than a lower treshhold?
  • is charging unconditionally if the battery reserve is less than an upper treshhold?
  • is charging only if PV energy is available and the battery reserve is less than an upper treshhold?
    With either of the three I could switch charging on or off depending on predicted solar supply and demand.

One could even charge only to 80 % to enlarge the longevity of the PW.

Powerwall Modes of Operation with Solar | Tesla Support Australia explains the operating modes better than I can.

I’m not aware of a way to stop the Powerwall charging if there is excess solar available.

OK; I guess I understand.
Battery reserve setting controls a lower treshhold in backup mode - it reserves x % of the capacity for outage times.
So it seems my idea to charge only in times of high excess solar power could not be accomplished.

Yes - and it can be manipulated to force the battery to grid charge. For example, I get cheap power from 1am - 6am and 10am - 3pm. I force the reserve to 25% at 1am to ensure I have at least 25% charge at 6am - which will get me through until the solar cranks up. When winter arrives - I’ll probably increase this reserve % further due to heating being used in the morning.

I’m certainly not aware how it can be done using the Tesla API.

I’ve done some experiments with curl to help me understand how to use the API, now I just need to sit down and code it. Now I’ve looked - I will probably also support reading the current situation like battery charge, solar power, grid power, etc - as it looks to be a single API call then just decode the information.

OK… I got started - https://github.com/psmedley/openhab-addons/blob/powerwallcontrol will show progress.

Initial state is i’ve setup the ‘things’ in openhab-addons/thing-types.xml at powerwallcontrol · psmedley/openhab-addons · GitHub

If anyone can have a look and suggest anything other information that’s provided in the app that I’ve missed it would be helpful.

Hi Paul, first link returns a 404.

Apologies, correct link is https://github.com/psmedley/openhab-addons/tree/powerwallcontrol

Initial build - supporting read-only so effectively - a duplicate of the previous binding, except that it uses the tesla web api vs the local api.

https://smedley.id.au/tmp/org.openhab.binding.teslapowerwallcontrol-3.3.0-SNAPSHOT.jar

Usage notes:
Needs an Owner API Access Token - such as that provided by https://play.google.com/store/apps/details?id=net.leveugle.teslatokens&hl=en_AU&gl=US

Currently, needs you to know the site_id of your powerwall (despite what the ‘Thing’ options say). The intent for the future is that if this field is left blank, then the first powerwall found using the API call below:
curl -H ‘Authorization: Bearer {tesla token}’ --location --request GET ‘https://owner-api.teslamotors.com/api/1/products

will be used - but I still need to code this.

Note: if trying to replicate this curl command locally - don’t put {} around the tesla token :slight_smile:

Next steps will be to allow the reserve, operating mode and storm mode settings to be changed.

Feedback appreciated :slight_smile:

Cheers,

Paul

I just sent you the error messages I got by mail. What do I have to use as site_id? The ST…-Identifier of my gateway?