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:
- {“default_real_mode”:“backup”}
- {“default_real_mode”:“self_consumption”}
- {“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 
Next steps will be to allow the reserve, operating mode and storm mode settings to be changed.
Feedback appreciated
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?
The site_id is a numeric number.
If you run the curl command I posted, it will show you the site’s associated with your account.
I’ll try and work on the code today to let you leave site_id blank.
https://smedley.id.au/tmp/org.openhab.binding.teslapowerwallcontrol-3.3.0-SNAPSHOT.jar is refreshed - it should be possible to leave the Site ID blank now - it works for me at least 
Works for me too 
I have to find out why the items in (local) teslapowerwall show power in units of kW and the (cloud based) teslapowerwallcontrol show them in W.
1 Like
Woohoo! I think the difference just comes down to my mood when I coded it. I can made the cloud version do kW too.
I’m nearly there with the ability to change the reserve, for some reason, I’m getting:
2022-02-04 19:12:07.518 [DEBUG] [nternal.TeslaPowerwallControlHandler] - Setting reserve to: 12
2022-02-04 19:12:07.520 [DEBUG] [rnal.TeslaPowerwallControlWebTargets] - payload = {"backup_reserve_percent":'12'}
2022-02-04 19:12:07.521 [DEBUG] [rnal.TeslaPowerwallControlWebTargets] - Calling url: https://owner-api.teslamotors.com/api/1/energy_sites/140608504302/backup
2022-02-04 19:12:07.707 [DEBUG] [rnal.TeslaPowerwallControlWebTargets] - response to reserve change = {"error":"invalid JSON: unexpected character (after backup_reserve_percent) at line 1, column 27 [parse.c:769] in '{\"backup_reserve_percent\":'12'}"}
ie my nicely formatted JSON is getting \ added to it and an extra "} and I have no idea why.
Soooo close!
double post ? double answer:
You get back \ and extra leading and trailing {} to make the server return JSON comatible.
Did you try to replace ’ by " in your server request ‘12’ => “12” ?
The Tesla server doesn’t like double quotes - only single quotes…
Actually, it can handle no quotes as well…
so:
String payload = "{\"backup_reserve_percent\":" + newreserve + "}";
results in:
2022-02-05 07:26:01.342 [DEBUG] [rnal.TeslaPowerwallControlWebTargets] - payload = {"backup_reserve_percent":9}
2022-02-05 07:26:01.343 [DEBUG] [rnal.TeslaPowerwallControlWebTargets] - Calling url: https://owner-api.teslamotors.com/api/1/energy_sites/140608504xxx/backup
2022-02-05 07:26:01.675 [DEBUG] [rnal.TeslaPowerwallControlWebTargets] - response to reserve change = {"response":{"code":201,"message":"Updated"}}
Seems I just needed a night to sleep on it
Apologies for any inconvenience, but I’ve renamed the binding to TeslaPowerwallCloud to make it clearer what the differences are to my TeslaPowerwall binding. I may also consider renaming TeslaPowerwall to TeslaPowerwallLocal in the future.
New download link is https://smedley.id.au/tmp/org.openhab.binding.teslapowerwallcloud-3.3.0-SNAPSHOT.jar
I’ll commit this change to my github shortly, and will aim to support toggling Storm Mode, and changing Operating mode before the end of this weekend.
Update:
I got distracted today, and added several mode channels instead of adding support for toggling operating mode and storm mode.
New channels:
- Site Name
- Firmware version
- Grid Services Status (ie is the PW2 participating in a VPP event)
- Grid Services Power (ie how much power is the PW2 sending/receiving from the VPP event)
- Storm Mode Status (ie has Tesla activated storm mode)
- Island Status (Not 100% sure what this one is :P)
Update 2:
I’ve worked out how to (via curl) change Operating Mode and Storm mode, so this should be trivial to support. Will aim to implement this on Sunday.
Update 3:
Looks like Island mode can be used to go off grid - so I’ll need to change it from read-only and work out how to use it.
New jar is working here, too. Units are still W.
1 Like
…is there any example how to integrate/ startup? Using VSC and avoid the OH frontend