FR: Expose AEMO P30 predispatch forecasts

[purcell-lab]

AEMO are making their P30 predispatch forecasts available for download.
It would be great to surface those forecasts here.

[purcell-lab]

Oh, I just realized you are already exposing the AEMO forecasts in your other integration.

https://github.com/cabberley/HA_AemoNemData

[cabberley]

Yes I am, but still I could enable this one to do that as well, so you don't need both.
It was just too much work to build out the sensor and data for AEMO this morning while I was fixing the feedin

[ceedeebee907]

bump, currently using one of your other add-ons to get get the 30 min aemo forecasts but would be good to have it all in the one spot. running into api rate limiting using both

[purcell-lab]

Status update — May 2026

Findings

• @cabberley confirmed in the May 2025 comment that this would be feasible (the AEMO predispatch data is already surfaced in HA_AemoNemData), it was just out of scope at the time.
• @ceedeebee907 confirmed the operational pain point in January: running both add-ons hits Amber API rate limits because each integration polls independently.
• For reference, AEMO's Pre-dispatch page confirms the P30 file is a public NEMWeb download (~4MB, 14-day rolling window, half-hourly updates) — no auth required, so the implementation is just an HTTP fetch + parse loop, no credential handling.

Proposed way forward

Two options, depending on @cabberley's preference:

1. Add P30 to amber2mqtt — port the AEMO fetch/parse from HA_AemoNemData into this repo, surface it on a separate MQTT topic prefix (amber2mqtt/aemo/p30/...) so it doesn't collide with Amber's own forecasts. Solves the rate-limit double-poll problem cleanly.
2. Document the separation — keep AEMO data in HA_AemoNemData and add a README note in amber2mqtt pointing users there, plus consider sharing a polling cache between the two integrations (e.g. a shared on-disk JSON file or an internal MQTT topic that one writes and the other reads).

Option 1 is the cleaner UX but doubles the maintenance surface on this repo. Option 2 keeps things modular but doesn't actually fix @ceedeebee907's rate-limit problem unless caching is added.

Happy to help with whichever direction you'd prefer. If option 1, I can put up a PR to port the AEMO predispatch fetch — should be a fairly small lift.