[solaredge] Add Monitoring API V2 support

[rogrun]

Description

This adds support for SolarEdge Monitoring API V2 while retaining the existing Monitoring API V1 and private API integrations.

Monitoring API V2 can be used with either a Fleet Access App API key or OAuth site access. The OAuth implementation provides the initial browser-based authorization flow, persists the access and refresh tokens in openHAB storage, renews access tokens before expiry, and stores rotated refresh tokens.

The binding retrieves live site power, meter telemetry, and storage telemetry. It also retrieves aggregate production, grid, and storage data for day, week, month, and year channels. Consumption and direct PV self-consumption are derived from the available energy balance while preserving the semantics of the existing status channels.

The Thing exposes locally recorded API requests for the last 30 days and the latest rate-limit information returned by SolarEdge. The README documents V2 configuration, OAuth authorization, request consumption, rate limits, derived values, and the observed long-running test behavior.

Motivation and impact

SolarEdge presents Monitoring API V2 as the current developer-platform API and plans to deprecate Monitoring API V1. This change allows existing SolarEdge Things to migrate to V2 without introducing a new Thing type or changing the established channel IDs.

Testing

• mvn clean install
• 21 unit tests covering OAuth renewal and token rotation, V2 response transformation, energy-balance calculations, status compatibility, and the rolling request counter
• Karaf feature verification
• Long-running test with OAuth site access, repeated token rotations, live and aggregate channel updates, and HTTP 200 responses
• Runtime verification after rebasing onto the latest upstream/main

[wborn]

This AI review may help get the PR ready for review.

The Monitoring API V2 support covers a lot of ground, including OAuth authentication, V2 telemetry, aggregate values, request accounting, tests, and documentation. A few correctness and recovery issues seem worth addressing while the PR is still a draft:

• OAuth authorization can become unrecoverable because the pending external_id is removed before the token exchange and site validation succeed. A failed callback can therefore leave the Thing exposing an authorization URL that can no longer be used.
• V2 meter/storage polling and the yearly V2 aggregate job can still run when usePrivateApi=true. Those V2 requests are then authenticated using the private-API cookie instead of V2 authentication.
• Direct consumption supplied by SolarEdge can be overwritten by the consumption value calculated from the production/grid/storage balance. The derived value should only be used when direct consumption is unavailable.
• The balance freshness check records when responses are processed rather than which SolarEdge measurement or polling cycle they belong to. With the supported one-minute polling interval, values from consecutive polling cycles can therefore be combined.
• When refreshing an OAuth credential fails, getPublicApiV2Credential() returns an empty string. The request is still sent as Authorization: Bearer , which can replace the more useful CONFIGURATION_PENDING status and authorization information with a communication error.
• Missing charge/discharge telemetry is converted to zero in some aggregate calculations. Absence should remain unknown rather than becoming a valid zero value, otherwise incomplete telemetry can also satisfy the derived balance.
• tokenOrApiKey is now optional to support OAuth, but V1 and V2 API_KEY configurations can consequently proceed with an empty key. Validation should only allow the parameter to be omitted for V2 OAuth.
• pv_status, grid_status, and battery_status currently depend on the complete production/import/export/charge/discharge balance being available. These statuses can be derived independently from their corresponding inputs; only derived consumption/load needs the complete balance.
• The new OAuth servlet is registered using the legacy OSGi HttpService API. Current repository guidance requires new servlet registrations to use the OSGi HTTP Whiteboard and HttpWhiteboardConstants.

There are also a few static-analysis findings in the changed code, including implicit-default-time-zone warnings in the new V2 request classes, that seem worth cleaning up before marking the PR ready for review.

[rogrun]

@wborn

Thanks for the detailed review. I addressed all the points in commit e49fb5d:

• OAuth authorization attempts now remain pending until token exchange and site validation succeed.
• V2 telemetry and yearly aggregate polling are disabled when the private API is selected.
• Direct consumption values take precedence over derived values.
• Values are correlated using explicit polling-cycle IDs, preventing data from different cycles from being combined.
• Requests are skipped when no valid V2 credential is available, preserving the useful authorization status after a failed token refresh.
• Missing charge/discharge telemetry remains undefined instead of being treated as zero.
• API keys are now required for V1 and V2 API-key authentication, while remaining optional for V2 OAuth.
• PV, grid, and battery status values are updated independently from their respective telemetry.
• The OAuth servlet now uses the OSGi HTTP Whiteboard.
• The implicit time-zone findings in the new V2 request classes have been resolved while retaining local boundaries for daily aggregates.

I also added tests for direct consumption and incomplete battery telemetry. The full binding build passes with 24 tests, static analysis reports no errors, and the OSGi feature verification succeeds. The updated binding was additionally tested against a live SolarEdge site, including live and aggregate polling.