Add Distro Energy day-ahead submission

[Miggets7]

What

Adds the Distro Energy day-ahead integration. It submits the parent optimisation asset's net power forecast to the Distro Energy trader API, one POST per market day.

EmsDistroEnergyAsset carries the portfolio attribute. EmsOptimisationService deploys a handler per asset at startup and keeps it in sync with create, update and delete persistence events, following the pattern already used for the GOPACS handlers.

How far ahead it submits

Submission starts at tomorrow and runs forward until the first market day with no forecast. A day that is only partly covered is still sent whole, zero-filled to midnight, because the API requires one entry per quarter-hour of the market day.

Nothing in this repository writes predicted powerNet; an external producer does. Sending a fixed window regardless of coverage would post a full day of zeros for days past that producer's horizon, every hour, which is a real net power trading position for a day we know nothing about. A fixed window is also wrong in the other direction, since a longer forecast would be silently truncated.

Each run re-submits and overwrites, so a day is sent by the first run after the horizon reaches it. No catch-up state is needed.

MAX_DAYS_AHEAD is a defensive ceiling rather than a business window. The loop stops at the horizon, so the ceiling only bounds the damage if a stray far-future datapoint makes the horizon look unbounded, and it warns when hit.

This rests on one assumption about the forecast producer: it writes a datapoint for every interval it covers, not only for intervals with non-zero power. Absence of data therefore means "beyond the horizon". If a producer ever writes only non-zero intervals, a genuinely idle day would look uncovered and be skipped.

Quarter-hour counts and DST

The API requires exactly one entry per quarter-hour of the market day: 96 on a normal day, 92 on the spring-forward day, 100 on the fall-back day.

Entries are driven by a grid of real instants stepping across the market day rather than by the number of rows the datapoint query returns. The length then follows the DST transition with no per-transition branching.

Predicted datapoints are stored as JVM-local wall-clock rather than UTC, which is openremote/openremote#3292. Each instant is mapped back into that frame to look up its value. On the fall-back day the repeated hour collapses onto one stored row, because the primary key is (timestamp, entity_id, attribute_name) and the upsert overwrites. Those positions reuse the surviving value and log a warning. Once predicted datapoints move to UTC the same code becomes exact with no change, and the tests cover that by running every case under both storage frames.

The collapse can only duplicate a read, never erase one, so it can never turn a day with a forecast into a skip.

Where the submit-or-skip decision lives

buildSubmissionData decides whether a day has a forecast, returning an empty list when it does not. An empty list is unambiguous because a submitted day is never shorter than 92 entries.

The decision comes from the ISP grid rather than from whatever the query returned. Those two answers agree only because the query window is derived from the same day bounds, and widening that window would let a neighbouring day's value make this day look covered, which is the bug this change removes.

A genuine all-zero forecast is still submitted. A fully curtailed site is a real trading position, and the distinction between a forecast 0.0 and a filled 0.0 only survives inside buildSubmissionData, where the grid lookup is a boxed Double and null means missing. It is erased at the boundary because SubmissionData.volume is a primitive double.

Handler lifecycle

ResteasyClient is stored as a field and closed in undeploy(), which covers both service shutdown and the stop-then-start that every asset update performs. The scheduled future is cancelled with an interrupt first, so an in-flight POST is aborted before the client goes away. This matches GOPACSRedispatchHandler.

Closing is safe with the shared executor: WebTargetBuilder.createClient passes it through ResteasyClientBuilder.executorService(ExecutorService), which sets cleanupExecutor to false, so Container.EXECUTOR is untouched.

The constructor also guards the window between createClient and the proxy. client.target throws IllegalArgumentException on a malformed DISTRO_ENERGY_BASE_URL, and no reference escapes a constructor that threw, so undeploy() could never close that client.

Scheduling moved out of the constructor into deploy(), called after construction the way startRedispatchHandler calls startPolling(). getFirstRequestDelayMillis() clamps the initial delay to zero, so any deploy after the half hour scheduled the task with no delay and it could start on an executor thread while the constructor was still running.

startDistroEnergyHandler now resolves the parent and verifies it is an EmsEnergyOptimisationAsset. Previously only the presence of a parent ID was checked, so an asset under any other parent deployed cleanly and then queried powerNet on an asset with no such attribute.

Fixes in the same path

• Interval query bounds are inclusive at both ends, so querying a full day returned 97 buckets instead of 96. The upper bound is now the start of the last interval.
• Gap-filled buckets carry a null value, which threw NPE when unboxed into SubmissionData.volume (primitive double). Gaps within a covered day are submitted as 0.0.
• Positions were sent in descending order. The API requires ascending.
• scheduleAtFixedRate received an absolute epoch-millis initial delay and a millisecond period, both read as MINUTES, so the task never fired.

Logging

Gap logging distinguishes trailing from interior gaps. A partly covered final day is the expected steady state and logs at FINE with the boundary position, so a horizon that is systematically short by a fixed number of intervals stays diagnosable. A gap inside the forecast still warns, because the producer writes every interval it covers and those positions go out as 0.0.

Config

DISTRO_ENERGY_TIMEZONE sets the market timezone and defaults to Europe/Amsterdam. DISTRO_ENERGY_CLIENT_KEY, DISTRO_ENERGY_BASE_URL and REQUEST_INTERVAL are unchanged.

Handler deployment is wrapped in try/catch. DistroEnergyHandler throws when DISTRO_ENERGY_CLIENT_KEY is unset, which would otherwise fail EMS service startup for every deployment that does not use Distro Energy.

Testing

./gradlew :ems:test passes for DistroEnergyHandlerTest, GOPACSHandlerTest and GOPACSHandlerEanTest: 46 tests, 0 failures. GOPACSHandlerHttpTest was not run locally because it needs the OpenRemote Postgres and Keycloak stack; CI covers it.

DistroEnergyHandlerTest has 22 cases covering 92/96/100 under both Amsterdam and UTC storage, gap filling, null buckets, a partly covered day filled to midnight, a genuine all-zero forecast, a value belonging to a neighbouring day, and the fall-back collapse. It is a plain Specification on purpose: ManagerContainerTrait forces TIMER_CLOCK_TYPE: PSEUDO, whose init() calls TimeZone.setDefault("UTC") JVM-wide, which would hide the DST behaviour under test. Expected counts are cross-checked against shapeshifter's DateTimeCalculation.numberOfIspsOnDay.

Known effects

• Not retro-active. Days already submitted as all-zeros stay zero at Distro until the horizon reaches them and a later run overwrites.
• Stopping at the first uncovered day means a single anomalous empty day truncates the run, and it is indistinguishable from the real horizon without probing past it. Acceptable given the producer assumption above.
• cancel(true) can log a stack trace on teardown if it interrupts an in-flight POST. Inherited from the GOPACS pattern, and rare since the task is idle between runs.

Status attributes

EmsDistroEnergyAsset gains two READ_ONLY attributes so a stalled handler shows in the UI without logs (from #97): lastSubmission (TIMESTAMP, written when a run submitted at least one day) and daysSubmitted (the forecast horizon in days, written on every run). A run that finds no forecast leaves a fresh daysSubmitted of 0 next to a stale lastSubmission; a handler that stopped running leaves both stale. The handler takes the Distro Energy asset id for this. Covered by DistroEnergyHandlerStatusTest.

The DST-collapse warning in buildSubmissionData is now one line per day with a count instead of one per position.

./gradlew :ems:test --tests '*DistroEnergy*': 27 tests, 0 failures.

[wborn]

This is an initial AI-assisted review.

The Distro Energy integration looks well structured overall, and the DST handling is especially thorough. The 92/96/100 interval handling is consistent with the current predicted-datapoint timestamp behavior, and the accompanying tests cover the important transition cases.

One lifecycle issue should be fixed before merging: each DistroEnergyHandler creates its own RESTEasy client, but the client is never closed when the handler is undeployed. Since handlers are recreated whenever the corresponding asset is updated, this can leave old clients and their connection pools allocated over time.

[Miggets7]

@wborn could you review again?

[wborn]

The previously raised lifecycle, parent-validation and missing-forecast issues have been addressed.

The updated handler lifecycle, forecast horizon handling, DST behavior, status attributes, and scheduling changes were re-checked. The implementation now looks consistent with the intended behavior, and the Distro Energy-specific tests cover the important normal-day, spring-forward, fall-back, missing-data and partial-horizon cases.

No remaining issue was identified that should block merging.

This review was AI-assisted.