[JP Region] Integration Timeout (10s) Caused by Sluggish/Hanging Statistics Endpoints

[electricalbah]

Hello. @Bobsilvio,
Following the backend server/firmware updates deployed on the Japan cluster (://epcube.com) last night, the integration is experiencing a persistent 10-second master timeout failure (Timeout nella lettura dei dati principali). This failure is completely dropping the real-time sensor entities.

To clarify immediately: This is not a token expiration issue.

A fresh Bearer token was generated via the Streamlit web app and verified.
To isolate the failure, individual endpoints were tested directly via Postman. The responses reveal that the primary real-time endpoint works flawlessly, but the daily/historical calculation endpoints are completely hanging or taking too long to reply on the JP cloud cluster, causing the entire Home Assistant data coordinator block to timeout and fail.

Root Cause & Code Analysis:

The issue originates in custom_components/epcube/sensor.py inside the async_update_data_with_stats() function.The entire asyncio.gather() routine—which requests 8 separate API endpoints concurrently - is nested inside a strict with async_timeout.timeout(HTTP_TIMEOUT): context manager block. Because the JP server is currently ghosting, lagging, or dropping queries on the 4 cumulative/historical paths (total_data, annual_data, monthly_data, and yesterday_data), the execution time for the bundle exceeds 10 seconds. The master timeout context catches this delay, aborts execution completely, and prevents the valid real-time payload retrieved from homeDeviceInfo from ever being processed and mapped to Home Assistant entities.
Furthermore, this causes a cascading 10-second setup failure on dependent platforms like select.epcube.

Postman Verification:
1. Working Realtime Endpoint (/api/device/homeDeviceInfo) -> Returns complete data payload instantaneously (status: 200, batterySoc: 100, solarPower: 354.00).

2. Stalling/Broken Statistics Endpoint (/api/device/queryDataElectricityV2) -> Stalls indefinitely or returns empty datasets, pushing the aggregate asyncio.gather execution past the 10-second limit.

Relevant Logs:

Logger: custom_components.epcube
Source: helpers/update_coordinator.py:497
Integration: EP CUBE Energy Monitor
Error fetching epcube_data data: Timeout nella lettura dei dati principali

---

Logger: homeassistant.components.select
Source: runner.py:289
Integration: Select
Setup of select platform epcube is taking over 10 seconds.

Thank you for your continuous support of the JP region deployment! Let me know if you need any further raw JSON payloads from the affected endpoints to assist with updating the parsing model.

[Bobsilvio]

Your analysis was correct, and it pointed straight at the real problem.

Every supplementary fetch used the same HTTP_TIMEOUT as the master block and ran inside it, so one hanging queryDataElectricityV2 call consumed the whole budget and the valid homeDeviceInfo payload — already fetched — was thrown away with it.

Fixed in v1.6.0:

• supplementary endpoints (statistics, device info, deviceList, switch mode) now use a separate STATS_TIMEOUT of 12s, strictly below HTTP_TIMEOUT, so they can never exhaust the master budget
• asyncio.gather runs with return_exceptions=True and logs which specific fetch failed, instead of losing the whole batch on the first error

Practical effect on the JP cluster: if the statistics endpoints keep hanging, you lose the daily/monthly/yearly figures for that cycle and see a warning in the log naming the failed fetch — the live sensors keep updating normally.

Silvio

[Bobsilvio]

Heads-up: the fix was on main but there was no published release, so HACS kept offering 1.4.3.

v1.6.2 is now released and HACS will pick it up normally. Please read the note at the top of the release before updating — sensor.epcube_systemstatus changes from a number to a text state.

Let me know how it goes.

Silvio