FR: Amber Advanced Price Forecasts - Netzero integration

[purcell-lab]

Thanks for the work on NetZero being able to inject Amber dynamic pricing into the Powerwall.

This has been working well with the Telsa Time Based Control (TBC), charging the battery during the cheapest times overnight and during the day and then exporting during the peaks in the morning and evenings. If anything TBC seems to cycle the battery a little too much as it tries to extract the maximum value against a dynamic tariff.

One other feature of the Australian spot price forecasts is they continue to update/ change even within the 30 minute timesteps, so you might enter a timesteps with a high forecast, TBC starts discharging, but then the prices collapse. This also tends to have TBC not exporting for a reasonable price as it sometimes waits for a higher price later, that then disappears. A classic bird in the hand vs two in the bush problem. In the screen shot below you can see the AEMO forecast at 20:00 has a peak, which TBC would wait for. Our retailer, Amber, has now produced what are called Advanced Price Forecasts, which are the purple shade and reflective based on experience of what the prices actually are going to look like in the future.

The good news is these Advanced forecasts are now also available via the Amber API, which NetZero is already accessing, and publishing not only spot prices but expected high and low advanced forecasts.

https://github.com/amberelectric/public-api/discussions/214

It would be great if NetZero was adapted to have an option to choose between injecting the standard AEMO forecasts (as it does now) or these high or low forecasts for Powerwall TBC. Consensus seems to be the low forecasts are most useful.

[
    {
        "type": "CurrentInterval",
        "date": "2024-07-05",
        "duration": 30,
        "startTime": "2024-07-05T05:30:01Z",
        "endTime": "2024-07-05T06:00:00Z",
        "nemTime": "2024-07-05T16:00:00+10:00",
        "perKwh": 28.94841,
        "renewables": 31.468,
        "spotPerKwh": 13.94436,
        "channelType": "general",
        "spikeStatus": "none",
        "tariffInformation": {
            "period": "offPeak",
            "season": "default",
            "demandWindow": false
        },
        "descriptor": "veryLow",
        "estimate": true,
        "advancedPrice": {
            "low": 29.38334,
            "high": 36.9962
        }
    },
    {
        "type": "CurrentInterval",
        "date": "2024-07-05",
        "duration": 30,
        "startTime": "2024-07-05T05:30:01Z",
        "endTime": "2024-07-05T06:00:00Z",
        "nemTime": "2024-07-05T16:00:00+10:00",
        "perKwh": -13.58623,
        "renewables": 31.468,
        "spotPerKwh": 13.94436,
        "channelType": "feedIn",
        "spikeStatus": "none",
        "descriptor": "high",
        "estimate": true,
        "advancedPrice": {
            "low": -13.98163,
            "high": -20.90241
        }
    }
]

[rob0101]

It might be worth monitoring the success rate of "low" before deploying.

With my state's prices, "low" was best during the day. Now during peak hours, it's not ideal.

Here' an example. The "low" was a poor prediction until the last 30m started.

[purcell-lab]

It might be worth monitoring the success rate of "low" before deploying.

A couple of different measures of success.

. How close was the forecast as the time interval approaches - your measurement graphic above is excellent . How did the forecast modify the peak windows, my observations is that the APF moves the peak left between 30-60 minutes, which means even if the forecast value isn't close an automation can start discharging or taking other actions on the true peak windows . How did the forecast modify future high/ excessive prices. Often we have seen optimisations wait and miss exports for a good price now because it can see a great price later (2-12 hours), but when later comes it has actually collapsed into a poor price. Again if the actual forecast isn't realised as long as the relative values are correct it will be useful for automation.

How to visualise those other measures of success is a good question.

[rob0101]

At the moment, with a small sample to work with, using the average of "high", "low" and "aemo" gives some consistency of being "least wrong" most of the time.

[rob0101]

average(low, low, high, aemo) is another interesting one. It biasses towards "low" but doesn't ignore the other two alternatives.

[zigam]

Thanks @purcell-lab for the suggestion and @rob0101 for all the analysis! I'm happy to add the new pricing data, although I'd rather not make AEMO/low/high an option the user has to make (it gets pretty technical and I don't think most users will be able to make an informed decision here). Since the API is new, it might make sense to gather a bit more data before deciding on the best price signal?

[rob0101]

I'm seeing all three options alone being less than ideal candidates.
AEMO can have a better success rate but also a worse failure rate. The other two alternate between being best. I'll come back with a suggestion once I've seen more data.

[rob0101]

I've change my comparison metric to average cents 'wrong' per prediction. I think this compares each choice on equal terms, not just wins and last places which ignores coming a close 2nd or close last.

For ~ 100 hours of predictions: Amber low: 7.5c, high: 5.8c, AEMO 5.1c, middle value: 4.3c

The lower number, the better. Choosing the middle value is a clear leader still.

The issue with this method is failed spike predictions, where a single bad prediction could be near 1700c 'wrong'. I might need to put an upper limit on 'wrongness' per prediction, perhaps a 100c cap.

[awulf]

Is the API documented anywhere to pass these dynamic prices to the PowerWall? Then we could experiment ourselves.

[zigam]

The lower number, the better. Choosing the middle value is a clear leader still.

Thanks @rob0101! To confirm, the middle value is avg(low, high, aemo)?

[zigam]

Is the API documented anywhere to pass these dynamic prices to the PowerWall? Then we could experiment ourselves.

https://developer.tesla.com/docs/fleet-api#time_of_use_settings

[rob0101]

The lower number, the better. Choosing the middle value is a clear leader still.

Thanks @rob0101! To confirm, the middle value is avg(low, high, aemo)?

No, I mean the number that sits in the middle. If A > B > C, choose B.

The median of low,high,aemo

[rob0101]

@zigam, please be aware my formula has only been tested against the feed for my state, there are 4 states and one other region, each with their own prices and predictions.

It would be good to see at least one other state's analysis to confirm the pattern.

[rob0101]

10 days of data for SA. Average cents away from the final price: aemo: 3.9c, low: 6.4c, high: 5.8c, median: 3.5c

[rob0101]

Amber are going to add their preferred predicted price to the API in the next few days. Guessing it will appear alongside "low" and "high" in the forecasts.

[zigam]

Thanks for the update. I've added support for optionally using advanced price forecasts. I can turn it on for individual accounts, if you're interested in testing this, just send your Tesla email address to ziga@netzeroapp.io and I'll enable it for your account.

[rob0101]

"advancedPrice" : { "high" : 49.82354, "low" : 35.43986, "predicted" : 38.73557 },

I'd say it's safe to switch to this new value rather than AEMO.

[zigam]

The predicted advanced prices are now live for everyone, let me know how it works for you.

[rob0101]

These are average cents away from the final price.

The Amber "predicted" price is working much better than AEMO in SA at the moment. I found a formula that slightly beats it, but not by enough to bother with.