SolarEdge One API unstable

[GenMurdock]

Just to give heads up, since last weekend the data from SolarEdge One# (One API) is very unstable and may result in Optimizers not showing after the upgrade to 2.4.11.
Just check in your SolarEdge webportal if data is being presented for the optimizers... to ensure the data is there ....

[AndrewTapp]

Yes, overnight and this morning for me as well.

Although as of 11:00 GMT this morning it seems to have stabilised.

Am guessing some kind of outage at SolarEdge!!

[AndrewTapp]

SolarEdge Optimizers – Log Analysis

Analysis of Home Assistant log file home-assistant_2026-03-09T19-24-36.777Z.log for solaredgeoptimizers warnings and errors.

Log period: 2026-03-08 12:47:15 → 2026-03-09 19:24:10 (UTC) — about 30 hours 37 minutes.

---

Summary

Almost all issues are SolarEdge’s servers returning 504 Gateway Time-out and 502 Bad Gateway. The integration treats these as temporary and, where implemented, falls back to cached data. No bugs in the integration logic were identified.

---

1. Prevalence by Endpoint / Use Case

Failures in the log are grouped by API endpoint / use case. Counts below are from this log only.

Rank	Use case	Endpoint / behaviour	WARNINGs	ERRORs	Total	Notes
1	Optimizer live data (single)	POST .../layout/information/optimizers (one serial per request during full refresh)	238	238	476	Most prevalent. Each failure = one WARNING + one ERROR.
2	Batch light check	Same .../layout/information/optimizers (batch of ~5 serials for “has any panel updated?”)	51	0	51	Coordinator logs “Lightweight update check failed” (52 times).
3	Per-optimizer lifetime energy	GET .../layout/energy-graph/site/{id}/optimizers?optimizer-serials=...	36	0	36	Parallel per-optimizer requests; some 502/504 or read timeouts.
4	Optimizer temperatures	GET .../layout/energy/site/{id}/by-inverter?include-max-temperature=true or site layout	18	0	18	Falls back to “Using previous cache”.
5	Site-level lifetime/layout	GET .../layout/logical/generic/v2/site/{id}?include-optimizers=true	7	0	7	Used for lifetime energy and layout; “Using previous cache” on failure.

So in this log:

• Optimizer live data (endpoint .../layout/information/optimizers) is by far the most common source of warnings and errors, both for full refresh (single-optimizer calls in the period analysed) and for batch light checks.
• Lifetime energy (per-optimizer and site-level) and optimizer temperatures show fewer failures and already use cache fallback.

---

2. Error Types

Type	Meaning	Seen in log
504 Gateway Time-out	SolarEdge gateway did not get a response in time from their backend.	Yes, multiple times.
502 Bad Gateway	SolarEdge gateway received an invalid response from their backend.	Yes, multiple times.
Read timeout	Request ran longer than client timeout (e.g. 30s) before any response.	Yes (e.g. “Lifetime energy for … failed: Read timed out”).

All point to SolarEdge’s monitoring API (monitoring.solaredge.com) being slow or temporarily unavailable, not to a bug in the integration.

---

3. When Failures Occur

In this log, many failures are concentrated at night (e.g. 01:33–07:51 UTC on 2026-03-09), which often aligns with:

• Maintenance or deployments on SolarEdge’s side
• Higher gateway/backend load or instability

So the time of day is a common factor for when issues appear.

---

4. How the Integration Handles These

Scenario	Behaviour
Timeout (read/connect)	One retry for the optimizer POST in _post_optimizers_with_retry.
HTTP 5xx (502/504)	No retry; logs WARNING/ERROR and raises. One 5xx = one failed request for that cycle.
Lifetime energy / temperatures	On fetch failure, logs “Using previous cache” and keeps using last good values.
Full refresh	Per-optimizer requests in parallel; a 5xx fails only that optimizer’s request for that cycle.
Batch light check	One 5xx fails the whole light check for that cycle (coordinator logs “Lightweight update check failed”).

So the common areas where users see the most warnings/errors are:

1. Optimizer live data – single-optimizer and batch calls to .../layout/information/optimizers (no 5xx retry).
2. Batch light check – same endpoint; one failure fails the check for that interval.
3. Lifetime energy / temperatures – failures are already softened by cache fallback.

---

5. Recommendations

1. No change required for correctness
   The integration correctly treats 504/502 as temporary server errors and uses cached data where implemented. The log noise is largely from SolarEdge’s availability.

2. Optional: retry on 5xx for optimizer requests
   To reduce ERROR/WARNING spikes when SolarEdge is flaky, consider adding a short retry with backoff for HTTP 502/504 (and optionally other 5xx) in _post_optimizers_with_retry in solaredge_one_api.py. That would make the integration more resilient without changing behaviour when the API is healthy.

3. SolarEdge side
   Repeated 504/502, especially in a fixed time window, are typically maintenance or backend/gateway issues. If it recurs at the same time of day, you could report it to SolarEdge (e.g. reliability of monitoring.solaredge.com during those hours).

4. Optimizer live data (single)
   Update the integration so that SolarEdge One full refresh uses one batch POST for all optimizers instead of N single-optimizer calls. Newer logs will show at most one optimizer-data request per full refresh (plus fallback to per-optimizer only if that batch fails).

---

Log file: home-assistant_2026-03-09T19-24-36.777Z.log · Period: 2026-03-08 12:47:15 – 2026-03-09 19:24:10 UTC

[AndrewTapp]

Reducing SolarEdge Portal API Calls

This document explains how the integration uses the SolarEdge monitoring portal and suggests ways to reduce the number of API calls.

---

Current Call Pattern (SolarEdge One API)

Trigger	Frequency	What is called	Approx. calls per event
Coordinator tick	Every 2 min (UPDATE_DELAY)	Decides: light check or full refresh	—
Light check	Every 2 min (when data fresh) or 15 min (when stale)	1× POST .../layout/information/optimizers (batch of 5 serials)	1
Full refresh	When light check sees new data, or first boot, or revert retry	Site layout + all optimizers + lifetime energy + temperatures	1 + N + (N or 1) + 1 (see below)

Full refresh breakdown

On each full refresh the integration currently does:

1. Site layout – GET .../layout/logical/generic/v2/site/{id} (cached 1 h) → 0 or 1
2. Optimizer live data – SolarEdge One: 1× POST .../layout/information/optimizers with all serials in the body. Legacy: N separate POSTs (one per optimizer). → 1 (One) or N (legacy)
3. Lifetime energy – if cache expired (1 h): N× GET .../layout/energy-graph/.../optimizers?optimizer-serials=X (One API only; parallel) → 0 or N
4. Temperatures – if cache expired (15 min): 1× GET .../layout/energy/.../by-inverter?include-max-temperature=true → 0 or 1

So a single full refresh with SolarEdge One is up to 1 + 1 + N + 1 calls when caches are cold (e.g. ~20 for 17 optimizers). The dominant cost when caches are cold is per-optimizer lifetime energy (N requests); optimizer live data is a single batch POST.

---

Recommendations to Reduce Calls

1. Use one batch POST for full refresh

Before: Full refresh called requestSystemData(serial) once per optimizer → N requests to .../layout/information/optimizers.

After: Full refresh calls requestSystemDataBatch(optimizer_ids) once → 1 request with all serials in the body.

Effect: For 17 optimizers, each full refresh drops from 17 calls to 1 for optimizer live data. Same API endpoint and response shape; only the request payload is a list of all serials instead of one at a time.

---

2. Increase coordinator and light-check intervals (configurable)

Constant	Current	Suggestion	Effect
UPDATE_DELAY	2 min	5 min	Fewer coordinator ticks; light checks and full refreshes run less often.
Light check when data “fresh”	2 min	5 min	Fewer light-check calls during the day when data is recent.
LIGHT_CHECK_MIN_INTERVAL	2 min	5 min	After a full refresh, wait longer before allowing another (avoids rapid full refreshes).

Where: const.py – UPDATE_DELAY, and in coordinator.py the timedelta(minutes=2) / timedelta(minutes=15) used for desired_interval and LIGHT_CHECK_MIN_INTERVAL.

Trade-off: Dashboards and sensors update less often (e.g. every 5 min instead of 2).

---

3. Lengthen cache TTLs (optional)

Cache	Current TTL	Suggestion	Effect
Panel/site layout	1 h	2 h	Fewer layout GETs.
Lifetime energy	1 h	2 h	Fewer per-optimizer lifetime energy GETs.
Temperatures	15 min	30 min	Fewer temperature GETs.

Where: solaredge_one_api.py – _panels_cache_ttl, _lifetime_energy_cache_ttl, _temperature_cache_ttl.

Trade-off: Layout, lifetime energy, and temperatures can be up to 2 h or 30 min stale after changes (e.g. new optimizer, or long-term energy totals).

---

4. Less frequent light checks when data is stale

When there is no recent measurement (e.g. at night), the coordinator uses a 15 min interval for light checks. Increasing that to e.g. 30 min reduces night-time calls.

Where: coordinator.py – in _should_do_light_check, the timedelta(minutes=15) used when measurement_age is None or measurement_age > stale_delta.

---

5. Optional: configurable scan interval (future)

Expose the coordinator interval (and possibly light-check / full-refresh behaviour) as an integration option so users can choose “fewer updates, fewer calls” vs “more frequent updates” without editing code.

---

Summary

Change	Calls saved	Trade-off
Batch POST for full refresh	N−1 per full refresh (e.g. 16 for 17 optimizers)	None; same data, one request.
Longer UPDATE_DELAY / light-check interval	Fewer ticks and light checks	Slower sensor/UI updates.
Longer cache TTLs	Fewer layout/lifetime/temperature fetches	Staler layout, energy, and temperatures.

The single change that reduces portal load the most with no data trade-off is using one batch POST for all optimizers on full refresh (recommendation 1).

[AndrewTapp]

I'm currently looking at implementing 1. Use one batch POST for full refresh from the last post, towards the end of this week and currently testing to see what impact it has.

[AndrewTapp]

Around 24 hours now and looking a lot better, will aim to release a new version probably tomorrow.

[AndrewTapp]

@GenMurdock Just wondering if you were still experiencing any issues?

[GenMurdock]

Andrew, on my side after update no issues seen anymore. Seems to be stable as far as that is possible with Solar Edge constantly playing on their servers.

[AndrewTapp]

Many thanks for the confirmation, with v2.4.12 I updated the integration to do a batch update of optimizers instead of doing one at a time, so that helped. But I also think SE were having issues!!

Am going to close this discussion now, take care.