Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

TOU api

This site may earn commission on affiliate links.
I've captured some requests and responses to Tesla's servers for the ap, for those who already know how to access the servers.

POST /api/1/energy_sites/nnn/time_of_use_settings

where nnn is your site id.

{"tou_settings":{"optimization_strategy":"economics","schedule":[{"target":"peak","week_days":[1,2,3,4,5],"start_seconds":50400,"end_seconds":75600},{"target":"off_peak","week_days":[1,2,3,4,5],"start_seconds":79200,"end_seconds":27000},{"target":"peak","week_days":[0,6],"start_seconds":null,"end_seconds":null},{"target":"off_peak","week_days":[0,6],"start_seconds":79200,"end_seconds":25200}]}}

{"tou_settings":{"optimization_strategy":"balanced","schedule":[{"target":"peak","week_days":[1,2,3,4,5],"start_seconds":50400,"end_seconds":75600,"timestamp":1533354852668,"receipt_timestamp":1533354852668},{"target":"off_peak","week_days":[1,2,3,4,5],"start_seconds":79200,"end_seconds":27000,"timestamp":1533354852668,"receipt_timestamp":1533354852668},{"target":"peak","week_days":[0,6],"start_seconds":null,"end_seconds":null,"timestamp":1533354852668,"receipt_timestamp":1533354852668},{"target":"off_peak","week_days":[0,6],"start_seconds":79200,"end_seconds":25200,"timestamp":1533354852668,"receipt_timestamp":1533354852668}]}}

It appears that it only includes the "timestamp" values when you change between balanced and cost saving, and vice versa.

Changing the backup reserve

POST /api/1/energy_sites/nnnn/backup

{"backup_reserve_percent":67}

Changing modes:

POST /api/1/energy_sites/nnn/operation

{"default_real_mode":"backup"}

{"default_real_mode":"self_consumption"}

{"default_real_mode":"autonomous"}

This latter is for "Advanced mode, or TOU".

In all cases the respone is

{"response":{"Code":201,"Message":"Updated"}}

It may be that the "default_real_mode" is just "default_mode" prior to firmware 1.21.0
 
Thanks. From this it appears that you have a three part tariff, with shoulder on weekdays from 7:30 to 14:00 and again from 21:00 to 22:00, and the message defines peak and off peak, with shoulder "everything else"?

Weekend is shoulder and off peak, and no peak period?

Off Peak end seconds can be "after" start seconds, so it wraps around midnight.
 
Weekend is shoulder and off peak, and no peak period?

That's how mine is set, yes - there's no peak at weekends, so it appears that to represent that it specifies null for the start and end times. As you surmised, shoulder is everything not included in the specified periods.

It looks as if there are a couple of minor things that could be achieved with the api, that the ap won't allow. Once is to change the week/weekend split, perhaps to handle a forthcoming public holiday. The other is to specify boundaries that are not multiples of 30 minutes, though I'd be surprised if there are my tariffs like that.

Still pretty basic stuff, though.
 
I'm now trying to see if the TOU scheduler can take complex scheduling that the UI cannot create. This one has two off-peak periods, and only one shoulder. It also starts on a 45-minute mark:
{"tou_settings":{"optimization_strategy":"economics","schedule":[{"end_seconds":21600,"start_seconds":2700,"target":"off_peak","week_days":[6,0]},{"end_seconds":82800,"start_seconds":72000,"target":"off_peak","week_days":[6,0]},{"end_seconds":2700,"start_seconds":82800,"target":"peak","week_days":[6,0]},{"end_seconds":21600,"start_seconds":2700,"target":"off_peak","week_days":[1,2,3,4,5]},{"end_seconds":82800,"start_seconds":72000,"target":"off_peak","week_days":[1,2,3,4,5]},{"end_seconds":2700,"start_seconds":82800,"target":"peak","week_days":[1,2,3,4,5]}]}}

Then, I'm going to try combining weekend/weekday schedules later as the format supports it, so there's no reason to duplicate it separately.

After, see if it can support multiple peak periods.
 
Last edited:
I'm now trying to see if the TOU scheduler can take complex scheduling that the UI cannot create. This one has two off-peak periods, and only one shoulder. It also starts on a 45-minute mark:
Status so far:
* 45 minute mark: works
* two off-peak periods: only displays the latter one. eg P-O-S-O displays as P-S-O
* shoulder-period between two off-peak periods(P-O-S-O): treats the shoulder as off-peak, but displays as shoulder up to the previous peak period
* peak wrap-around before-after midnight: works
* combining weekend/weekday into one schedule: disables display of weekday schedule
 
I believe that link is actually to the information on how to connect to the local Gateway, not the server. The server API is the same one that's used for cars: Tesla API.

With older versions of the Powerwall firmware, configuration changes were read only once an hour. With newer versions (I have 1.41.2) changes appear to be applied immediately, although it does look like it may take several minutes for the Powerwall to completely switch to the new settings. While switching, the Powerwall goes to standby mode, so it would not be optimal to switch settings during a high demand time if the utility has a demand charge, for example.
 
I believe that link is actually to the information on how to connect to the local Gateway, not the server. The server API is the same one that's used for cars: Tesla API.

With older versions of the Powerwall firmware, configuration changes were read only once an hour. With newer versions (I have 1.41.2) changes appear to be applied immediately, although it does look like it may take several minutes for the Powerwall to completely switch to the new settings. While switching, the Powerwall goes to standby mode, so it would not be optimal to switch settings during a high demand time if the utility has a demand charge, for example.
Thanks for the heads up, looks like I'll be testing this when everyone else is sleeping once mine is fired up.
 
Hi,
Can you confirm the payload still works? I'm trying to setup similar and receive the following response, using your payload example;
```
{
"response": null,
"error": "Must provide valid TOU settings in request for txid `e15efe77cc8428a1457d86ed4c649110`",
"error_description": ""
}
```
TIA, Piers

I'm now trying to see if the TOU scheduler can take complex scheduling that the UI cannot create. This one has two off-peak periods, and only one shoulder. It also starts on a 45-minute mark:
{"tou_settings":{"optimization_strategy":"economics","schedule":[{"end_seconds":21600,"start_seconds":2700,"target":"off_peak","week_days":[6,0]},{"end_seconds":82800,"start_seconds":72000,"target":"off_peak","week_days":[6,0]},{"end_seconds":2700,"start_seconds":82800,"target":"peak","week_days":[6,0]},{"end_seconds":21600,"start_seconds":2700,"target":"off_peak","week_days":[1,2,3,4,5]},{"end_seconds":82800,"start_seconds":72000,"target":"off_peak","week_days":[1,2,3,4,5]},{"end_seconds":2700,"start_seconds":82800,"target":"peak","week_days":[1,2,3,4,5]}]}}

Then, I'm going to try combining weekend/weekday schedules later as the format supports it, so there's no reason to duplicate it separately.

After, see if it can support multiple peak periods.
 
[SOLVED]
The invalid TOU settings seams to be related to specifiying days 0 & 6.

BAD:
week_days":[0,1,2,3,4,5,6]
week_days":[0,6]

OK:
week_days":[1,2,3,4,5]
week_days":[6,0]

```
{
"response": null,
"error": "Couldn't update config syncer for site 1234567-01-G--T17I1234567, return code is 400 for txid `205a806e054447bc38f5eff02f919dd1`",
"error_description": ""
}```

Hi,
Can you confirm the payload still works? I'm trying to setup similar and receive the following response, using your payload example;
```
{
"response": null,
"error": "Must provide valid TOU settings in request for txid `e15efe77cc8428a1457d86ed4c649110`",
"error_description": ""
}
```
TIA, Piers
 
Hi,
When you indicated "two off-peak periods: only displays the latter one",
did you have confirmation via the API
`https://owner-api.teslamotors.com/api/1/energy_sites/nnn/site_info`
or only in APP?

When I set for two off-peak periods, and two peak periods for that matter, the API only appears to register the latter of each when queried with `/api/1/energy_sites/nnn/site_info`

Am running a dual period test this afternoon to see if the actual behaviour:
Off-Peak - 3pm-5:15pm
Peak - 5:15pm-6:45pm
Off-Peak - 6:45pm-8pm
Peak - 8pm-3pm

```{
"tou_settings": {
"optimization_strategy": "balanced",
"schedule": [
{
"start_seconds": 54000,
"end_seconds": 62100,
"target": "off_peak",
"week_days": [
6,
0
]
},
{
"start_seconds": 62100,
"end_seconds": 67500,
"target": "peak",
"week_days": [
6,
0
]
},
{
"start_seconds": 67500,
"end_seconds": 72000,
"target": "off_peak",
"week_days": [
6,
0
]
},
{
"start_seconds": 72000,
"end_seconds": 54000,
"target": "peak",
"week_days": [
6,
0
]
}
]
}
}
```

Response from `/api/1/energy_sites/nnn/site_info`
```{
"response": {
"id": "12345-01-G--T17I1234567",
"site_name": "Birdsville",
"backup_reserve_percent": 5,
"default_real_mode": "autonomous",
"installation_date": "2018-03-27T16:50:00+11:00",
"user_settings": {
"storm_mode_enabled": true,
"sync_grid_alert_enabled": true,
"breaker_alert_enabled": false
},
"components": {
"solar": true,
"battery": true,
"grid": true,
"backup": true,
"gateway": "teg",
"load_meter": true,
"tou_capable": true,
"storm_mode_capable": true,
"flex_energy_request_capable": false,
"car_charging_data_supported": false,
"battery_type": "ac_powerwall",
"configurable": true,
"grid_services_enabled": false
},
"version": "1.43.3",
"battery_count": 3,
"tou_settings": {
"optimization_strategy": "balanced",
"schedule": [
{
"target": "off_peak",
"week_days": [
6,
0
],
"start_seconds": 67500,
"end_seconds": 72000
},
{
"target": "peak",
"week_days": [
6,
0
],
"start_seconds": 72000,
"end_seconds": 54000
}
]
},
"nameplate_power": 15000,
"nameplate_energy": 40500,
"installation_time_zone": "Australia/Hobart"
}
}
```


Status so far:
* 45 minute mark: works
* two off-peak periods: only displays the latter one. eg P-O-S-O displays as P-S-O
* shoulder-period between two off-peak periods(P-O-S-O): treats the shoulder as off-peak, but displays as shoulder up to the previous peak period
* peak wrap-around before-after midnight: works
* combining weekend/weekday into one schedule: disables display of weekday schedule
 
I've captured some requests and responses to Tesla's servers for the ap, for those who already know how to access the servers.

Changing the backup reserve

POST /api/1/energy_sites/nnnn/backup

{"backup_reserve_percent":67}

I'm trying to do this with curl, and not having any success. I'm using:
curl -k --header "Authorization: Bearer token_goes_here" -X POST -d {"backup_reserve_percent":15} https://owner-api.teslamotors.com/api/1/energy_sites/nnnnnnn/backup

but in response I get:
{"response":null,"error":"Unable to get backup reserve capacity from payload for txid `83d761de6fa1cd9bea3854fd698a90cd`","error_description":""}

Any suggestions on what I'm doign wrong?
 
I'm trying to do this with curl, and not having any success. I'm using:
curl -k --header "Authorization: Bearer token_goes_here" -X POST -d {"backup_reserve_percent":15} https://owner-api.teslamotors.com/api/1/energy_sites/nnnnnnn/backup

but in response I get:
{"response":null,"error":"Unable to get backup reserve capacity from payload for txid `83d761de6fa1cd9bea3854fd698a90cd`","error_description":""}

Any suggestions on what I'm doign wrong?

Any possibility it is an escaping issue with the curly braces in the command line above? Have you tried quoting the string or escaping them?
 
Good ideas - however it didn't help :( The goal here is to extend the Tesla Vehicle binding for Openhab to support Powerwalls. I was using the command line to make sure I understood the API correctly before I wrote the java. Meanwhile, I think I'll just try and implement the code using the approach that the Tesla vehicle commands use and hope for the best :)
 
FWIW, I have no problems invoking exactly that call using Node.js. I don't use curl a lot, so it's also possible the command line arguments aren't quite right. You could try one of the browser plugins that posts to REST APIs as an alternative (I use the Talend API Tester).