iobroker.goodwe-sems 0.1.15 → 0.1.16

package/README.de.md

@@ -151,6 +151,14 @@ Pull Requests willkommen, insbesondere um zusätzliche, vom Portal gelieferte Fe
 -->
 ### **WORK IN PROGRESS**
 
+### 0.1.16 (2026-07-19)
+
+- (Stefan Bühler) Großer Fund: Manche Konten, deren SEMS+-Login abgelehnt wird und die auf die Legacy-CrossLogin-API zurückfallen, landen gar nicht auf dem klassischen `semsportal.com`-artigen Backend - sie bekommen eine Session für eine komplett andere, moderne Microservice-API ("SEMS+-Gateway", `eu-gateway.semsportal.com`). Das erklärt, warum `GetMonitorDetailByPowerstationId` unter keinem der in 0.1.14/0.1.15 versuchten Pfade (`v1`/`v2`/`v3`) je funktionieren konnte. Bestätigt durch einen echten Browser-HAR-Mitschnitt (`eu-semsplus.goodwe.com`), der die tatsächlich genutzten Endpunkte zeigt (`sems-plant/api/stations/...`, `sems-plant/api/equipments/<sn>/telemetry` usw.)
+- (Stefan Bühler) Die Gateway-API verlangt zusätzlich einen berechneten `x-signature`-Header bei jedem Request, sonst wird er stillschweigend abgelehnt. Das Signatur-Schema (`base64(sha256(`${ts}@${uid}@${token}`) + "@" + ts)`) wurde empirisch aus ~230 echten Request/Response-Paaren rekonstruiert - 100 % Treffer, keine Ausnahmen
+- (Stefan Bühler) `getMonitorDetail()` fällt jetzt automatisch auf diese Gateway-API zurück (Stations-Basisdaten, Geräteliste, Telemetrie/Telecounting pro Gerät), wenn alle drei klassischen Pfade 404 liefern, und wandelt das Ergebnis in dieselbe `info`/`kpi`/`inverter[]`-Struktur um, die der Rest des Adapters bereits erwartet - keine Änderungen in der Mapping-/State-Erzeugungs-Schicht nötig
+- (Stefan Bühler) Bewusst konservative erste Version: Nur Felder mit gesichertem Einheiten-/Format-Nachweis werden befüllt (aktuelle Leistung, Tages-/Gesamtertrag, Wechselrichter-Werte für AC/PV/Temperatur); der stationsweite Leistungsfluss (PV/Verbrauch/Netz/Batterie) wird noch nicht befüllt, da alle bisherigen Mitschnitte nachts erfolgten und dafür ein leeres Objekt lieferten
+- (Stefan Bühler) 2 neue Regressionstests (47 Unit-Tests insgesamt), darunter einer, der die tatsächliche Signaturberechnung gegen die echte, reverse-engineerte Formel verifiziert
+
 ### 0.1.15 (2026-07-19)
 
 - (Stefan Bühler) Fix: Der v3→v2-Fallback aus 0.1.14 für `GetMonitorDetailByPowerstationId` reichte nicht aus - bei einem echten Konto lieferte das Legacy-Login-Backend `404 Route Not Found` für **beide** Pfade, `v2` und `v3`. Community-Referenzen widersprechen sich, welche Version korrekt ist (pygoodwe verwendet fest `v2`, ein separater Artikel von 2023 nutzt `v1`, unsere eigene Traffic-Analyse beobachtete `v3`) - `getMonitorDetail()` probiert jetzt alle drei Versionen der Reihe nach durch (`v3` → `v2` → `v1`) und nutzt die erste, die keinen 404 liefert

package/README.md

@@ -151,6 +151,14 @@ Pull requests are welcome, especially to add further fields delivered by the por
 -->
 ### **WORK IN PROGRESS**
 
+### 0.1.16 (2026-07-19)
+
+- (Stefan Bühler) major finding: some accounts whose SEMS+ login is rejected and fall back to the legacy CrossLogin API do not end up on the classic `semsportal.com`-style backend at all - they get a session for a completely different, modern microservice API ("SEMS+ gateway", `eu-gateway.semsportal.com`), which explains why `GetMonitorDetailByPowerstationId` could never succeed under any of the `v1`/`v2`/`v3` paths tried in 0.1.14/0.1.15. Confirmed via a real account's browser HAR capture (`eu-semsplus.goodwe.com`) showing the actual endpoints in use (`sems-plant/api/stations/...`, `sems-plant/api/equipments/<sn>/telemetry`, etc.)
+- (Stefan Bühler) the gateway API additionally requires every request to carry a computed `x-signature` header or it is silently rejected. The signature scheme (`base64(sha256(`${ts}@${uid}@${token}`) + "@" + ts)`) was reverse-engineered empirically from ~230 real request/response pairs captured from the web app - 100% match, no exceptions
+- (Stefan Bühler) `getMonitorDetail()` now automatically falls back to this gateway API (station basic info, device list, per-device telemetry/telecounting) when all three classic paths 404, and reshapes the result into the same `info`/`kpi`/`inverter[]` shape the rest of the adapter already expects - no changes needed in the mapping/state-creation layer
+- (Stefan Bühler) deliberately conservative first version: only fields with a confirmed unit/shape are populated (current power, today's/total generation, per-inverter AC/PV/temperature values); the station-level power-flow split (PV/load/grid/battery) is not populated yet, since every real-account capture so far happened at night and returned an empty object for it
+- (Stefan Bühler) 2 new regression tests (47 unit tests in total), including one that verifies the actual signature computation against the real, reverse-engineered formula
+
 ### 0.1.15 (2026-07-19)
 
 - (Stefan Bühler) fix: 0.1.14's v3→v2 fallback for `GetMonitorDetailByPowerstationId` was insufficient - a real-world account's legacy-login backend returned `404 Route Not Found` for **both** the `v2` and `v3` paths. Community references disagree on which version is correct (pygoodwe hardcodes `v2`, a separate 2023 write-up uses `v1`, our own traffic inspection observed `v3`), so `getMonitorDetail()` now tries all three versions in sequence (`v3` → `v2` → `v1`) and uses whichever one doesn't 404

package/io-package.json

@@ -1,8 +1,21 @@
 {
     "common": {
         "name": "goodwe-sems",
-        "version": "0.1.15",
+        "version": "0.1.16",
         "news": {
+            "0.1.16": {
+                "de": "Großer Fund: Konten, deren SEMS+-Login abgelehnt wird und die auf die Legacy-CrossLogin-API zurückfallen, landen teils auf einem komplett anderen, modernen SEMS+-Gateway-Backend (eu-gateway.semsportal.com) statt dem klassischen semsportal.com - das erklärt, warum v1/v2/v3 GetMonitorDetailByPowerstationId dort NIE funktionieren konnten. Der Adapter spricht jetzt zusätzlich dieses Gateway-Backend (eigene Endpunkte, eigenes Antwortformat, inkl. der zur Authentifizierung nötigen Request-Signatur) und nutzt es automatisch als letzten Fallback, wenn alle klassischen Pfade fehlschlagen.",
+                "en": "Major finding: accounts whose SEMS+ login is rejected and fall back to the legacy CrossLogin API sometimes end up on a completely different, modern SEMS+ gateway backend (eu-gateway.semsportal.com) instead of the classic semsportal.com one - explaining why v1/v2/v3 GetMonitorDetailByPowerstationId could never work there. The adapter now also speaks this gateway backend (its own endpoints, response format, and required request signature) and automatically uses it as a last-resort fallback when all classic paths fail.",
+                "ru": "Major finding: accounts whose SEMS+ login is rejected and fall back to the legacy CrossLogin API sometimes end up on a completely different, modern SEMS+ gateway backend (eu-gateway.semsportal.com) instead of the classic semsportal.com one - explaining why v1/v2/v3 GetMonitorDetailByPowerstationId could never work there. The adapter now also speaks this gateway backend (its own endpoints, response format, and required request signature) and automatically uses it as a last-resort fallback when all classic paths fail.",
+                "pt": "Major finding: accounts whose SEMS+ login is rejected and fall back to the legacy CrossLogin API sometimes end up on a completely different, modern SEMS+ gateway backend (eu-gateway.semsportal.com) instead of the classic semsportal.com one - explaining why v1/v2/v3 GetMonitorDetailByPowerstationId could never work there. The adapter now also speaks this gateway backend (its own endpoints, response format, and required request signature) and automatically uses it as a last-resort fallback when all classic paths fail.",
+                "nl": "Major finding: accounts whose SEMS+ login is rejected and fall back to the legacy CrossLogin API sometimes end up on a completely different, modern SEMS+ gateway backend (eu-gateway.semsportal.com) instead of the classic semsportal.com one - explaining why v1/v2/v3 GetMonitorDetailByPowerstationId could never work there. The adapter now also speaks this gateway backend (its own endpoints, response format, and required request signature) and automatically uses it as a last-resort fallback when all classic paths fail.",
+                "fr": "Major finding: accounts whose SEMS+ login is rejected and fall back to the legacy CrossLogin API sometimes end up on a completely different, modern SEMS+ gateway backend (eu-gateway.semsportal.com) instead of the classic semsportal.com one - explaining why v1/v2/v3 GetMonitorDetailByPowerstationId could never work there. The adapter now also speaks this gateway backend (its own endpoints, response format, and required request signature) and automatically uses it as a last-resort fallback when all classic paths fail.",
+                "it": "Major finding: accounts whose SEMS+ login is rejected and fall back to the legacy CrossLogin API sometimes end up on a completely different, modern SEMS+ gateway backend (eu-gateway.semsportal.com) instead of the classic semsportal.com one - explaining why v1/v2/v3 GetMonitorDetailByPowerstationId could never work there. The adapter now also speaks this gateway backend (its own endpoints, response format, and required request signature) and automatically uses it as a last-resort fallback when all classic paths fail.",
+                "es": "Major finding: accounts whose SEMS+ login is rejected and fall back to the legacy CrossLogin API sometimes end up on a completely different, modern SEMS+ gateway backend (eu-gateway.semsportal.com) instead of the classic semsportal.com one - explaining why v1/v2/v3 GetMonitorDetailByPowerstationId could never work there. The adapter now also speaks this gateway backend (its own endpoints, response format, and required request signature) and automatically uses it as a last-resort fallback when all classic paths fail.",
+                "pl": "Major finding: accounts whose SEMS+ login is rejected and fall back to the legacy CrossLogin API sometimes end up on a completely different, modern SEMS+ gateway backend (eu-gateway.semsportal.com) instead of the classic semsportal.com one - explaining why v1/v2/v3 GetMonitorDetailByPowerstationId could never work there. The adapter now also speaks this gateway backend (its own endpoints, response format, and required request signature) and automatically uses it as a last-resort fallback when all classic paths fail.",
+                "zh-cn": "Major finding: accounts whose SEMS+ login is rejected and fall back to the legacy CrossLogin API sometimes end up on a completely different, modern SEMS+ gateway backend (eu-gateway.semsportal.com) instead of the classic semsportal.com one - explaining why v1/v2/v3 GetMonitorDetailByPowerstationId could never work there. The adapter now also speaks this gateway backend (its own endpoints, response format, and required request signature) and automatically uses it as a last-resort fallback when all classic paths fail.",
+                "uk": "Major finding: accounts whose SEMS+ login is rejected and fall back to the legacy CrossLogin API sometimes end up on a completely different, modern SEMS+ gateway backend (eu-gateway.semsportal.com) instead of the classic semsportal.com one - explaining why v1/v2/v3 GetMonitorDetailByPowerstationId could never work there. The adapter now also speaks this gateway backend (its own endpoints, response format, and required request signature) and automatically uses it as a last-resort fallback when all classic paths fail."
+            },
             "0.1.15": {
                 "de": "Weiterer Fix für die GoodWe-API-Versionierung: getMonitorDetail() probiert jetzt v3, v2 UND v1 der Reihe nach durch (statt nur v3->v2), da GoodWe je nach Konto/Backend unterschiedliche API-Versionen für denselben Endpunkt verwendet. Zusätzlich vollständige Request-URL im Debug-Log für einfachere Diagnose.",
                 "en": "Further fix for GoodWe API versioning: getMonitorDetail() now tries v3, v2 AND v1 in sequence (not just v3->v2), since GoodWe uses different API versions for the same endpoint depending on account/backend. Also logs the full request URL in debug mode for easier diagnosis.",
@@ -80,19 +93,6 @@
                 "pl": "rozwiązano bardziej rygorystyczne kontrole PR ioBroker.repositories: encryptedNative/protectedNative przeniesiono do katalogu głównego io-package.json, zaktualizowano zależności, przepisano CI, README przetłumaczono na angielski (wymagane)",
                 "uk": "усунено суворіші перевірки PR ioBroker.repositories: encryptedNative/protectedNative перенесено в корінь io-package.json, оновлено залежності, переписано CI, README перекладено англійською (обов'язково)",
                 "zh-cn": "解决更严格的 ioBroker.repositories PR 检查:将 encryptedNative/protectedNative 移至 io-package.json 根目录,更新依赖项,重写 CI,将 README 翻译为英文(必需)"
-            },
-            "0.1.8": {
-                "en": "address ioBroker adapter-check findings: remove news entries for versions that were never actually published to npm (0.1.1, 0.1.2), remove deprecated common.title/common.main fields, update @iobroker/adapter-core to ^3.2.2",
-                "de": "ioBroker-Adapter-Check-Befunde behoben: News-Einträge für nie tatsächlich auf npm veröffentlichte Versionen entfernt (0.1.1, 0.1.2), veraltete Felder common.title/common.main entfernt, @iobroker/adapter-core auf ^3.2.2 aktualisiert",
-                "ru": "устранены замечания adapter-check: удалены записи news для версий, никогда не публиковавшихся в npm (0.1.1, 0.1.2), удалены устаревшие поля common.title/common.main, обновлён @iobroker/adapter-core до ^3.2.2",
-                "pt": "resolvidas as constatações do adapter-check: removidas entradas de news de versões nunca publicadas no npm (0.1.1, 0.1.2), removidos campos obsoletos common.title/common.main, @iobroker/adapter-core atualizado para ^3.2.2",
-                "nl": "adapter-check bevindingen opgelost: news-items voor nooit op npm gepubliceerde versies verwijderd (0.1.1, 0.1.2), verouderde velden common.title/common.main verwijderd, @iobroker/adapter-core bijgewerkt naar ^3.2.2",
-                "fr": "corrections des remarques adapter-check : suppression des entrées news pour des versions jamais publiées sur npm (0.1.1, 0.1.2), suppression des champs obsolètes common.title/common.main, mise à jour de @iobroker/adapter-core vers ^3.2.2",
-                "it": "risolti i rilievi di adapter-check: rimosse le voci news per versioni mai pubblicate su npm (0.1.1, 0.1.2), rimossi i campi deprecati common.title/common.main, aggiornato @iobroker/adapter-core a ^3.2.2",
-                "es": "se resolvieron los hallazgos de adapter-check: se eliminaron entradas de news de versiones nunca publicadas en npm (0.1.1, 0.1.2), se eliminaron los campos obsoletos common.title/common.main, se actualizó @iobroker/adapter-core a ^3.2.2",
-                "pl": "rozwiązano uwagi adapter-check: usunięto wpisy news dla wersji nigdy niepublikowanych na npm (0.1.1, 0.1.2), usunięto przestarzałe pola common.title/common.main, zaktualizowano @iobroker/adapter-core do ^3.2.2",
-                "uk": "усунено зауваження adapter-check: видалено записи news для версій, які ніколи не публікувалися в npm (0.1.1, 0.1.2), видалено застарілі поля common.title/common.main, оновлено @iobroker/adapter-core до ^3.2.2",
-                "zh-cn": "解决 adapter-check 发现的问题:移除从未真正发布到 npm 的版本的 news 条目(0.1.1、0.1.2),移除已弃用的 common.title/common.main 字段,将 @iobroker/adapter-core 更新至 ^3.2.2"
             }
         },
         "titleLang": {

package/lib/semsApi.js

@@ -55,6 +55,24 @@ const MONITOR_DETAIL_PATHS = [
     "/v1/PowerStation/GetMonitorDetailByPowerstationId",
 ];
 
+// --- SEMS+ "gateway" API (eu-gateway.semsportal.com) -----------------------
+// Some accounts' session ("api" field from CrossLogin) resolves to a modern
+// microservice gateway host instead of the classic semsportal.com backend -
+// confirmed against a real account where ALL THREE classic paths above
+// 404'd. That gateway speaks a completely different, undocumented API:
+// different paths (e.g. "/sems-plant/api/stations/flow"), a different
+// response envelope (top-level "code":"00000" instead of 0, "description"
+// instead of "msg"), AND every request additionally requires a computed
+// "x-signature" header or the gateway silently rejects it. The signature
+// scheme was reverse-engineered from ~230 real request/response pairs
+// captured from the eu-semsplus.goodwe.com web app (100% match, no
+// exceptions found):
+//   x-signature = base64( sha256(`${ts}@${uid}@${token}`).hexdigest() + "@" + ts )
+// where `ts` is the request's own signing time in epoch milliseconds
+// (Date.now() at call time - independent of the token's login timestamp)
+// and uid/token are the same values sent in the "token" header.
+const GATEWAY_CLIENT = "semsPlusWeb";
+
 // Observed rate-limit response code. GoodWe does not document a retry-after
 // value, community projects settled on a 5 minute cool-down.
 const RATE_LIMIT_CODE = "GY0429";
@@ -114,6 +132,49 @@ async function httpPostJson(url, init, timerFns) {
     }
 }
 
+/**
+ * Converts the gateway API's metadata-driven "factors" arrays (used by both
+ * the telemetry and telecounting endpoints) into a flat {code: rawValue}
+ * lookup. Each response is an array of named groups (e.g. "ac_parameters",
+ * "telecounting_today"), each holding a "factors" array of
+ * {code, data, dataType, unit, alias, ...} entries - we only need the inner
+ * code/data pairs. A field simply being absent from "data" (observed e.g.
+ * at night, when a value is omitted entirely instead of being sent as 0) is
+ * preserved as `undefined` rather than guessed at.
+ *
+ * @param {Array<{code?:string, factors?: Array<{code:string, data?: *}>}>} groups
+ * @returns {Record<string, *>}
+ */
+function flattenGatewayFactors(groups) {
+    const flat = {};
+    if (!Array.isArray(groups)) {
+        return flat;
+    }
+    for (const group of groups) {
+        const factors = Array.isArray(group && group.factors) ? group.factors : [group];
+        for (const factor of factors) {
+            if (factor && factor.code !== undefined) {
+                flat[factor.code] = factor.data;
+            }
+        }
+    }
+    return flat;
+}
+
+/**
+ * Minimal numeric coercion for gateway values we need to do arithmetic on
+ * (kW->W scaling, summing across inverters).
+ *
+ * @param {*} value
+ */
+function gatewayNum(value) {
+    if (value === undefined || value === null || value === "") {
+        return undefined;
+    }
+    const n = Number(value);
+    return Number.isFinite(n) ? n : undefined;
+}
+
 class SemsApi {
     /**
      * @param {object} opts
@@ -413,10 +474,245 @@ class SemsApi {
                         "debug",
                         `${path} nicht gefunden (404) - versuche ${nextPath} als Fallback (API-Version unterschiedlich je nach Konto/Backend).`,
                     );
+                } else {
+                    this.log(
+                        "debug",
+                        `${path} nicht gefunden (404) - alle klassischen PowerStation-Pfade fehlgeschlagen, versuche die SEMS+-Gateway-API als letzten Fallback.`,
+                    );
+                }
+            }
+        }
+        try {
+            return await this._getMonitorDetailGateway(powerStationId);
+        } catch (gatewayError) {
+            this.log(
+                "debug",
+                `SEMS+-Gateway-Fallback ebenfalls fehlgeschlagen (${gatewayError.message}) - melde den ursprünglichen Fehler.`,
+            );
+            throw lastError;
+        }
+    }
+
+    /**
+     * SHA-256-based request signature required by the SEMS+ gateway API - see the GATEWAY_CLIENT comment above.
+     *
+     * @param {string} uid
+     * @param {string} token
+     */
+    _gatewaySignature(uid, token) {
+        const ts = Date.now();
+        const hash = crypto.createHash("sha256").update(`${ts}@${uid}@${token}`, "utf8").digest("hex");
+        return Buffer.from(`${hash}@${ts}`, "utf8").toString("base64");
+    }
+
+    /** Derives the gateway host from the current session's (already validated) API base. */
+    _gatewayBase() {
+        if (!this.session) {
+            throw new SemsAuthError("Keine aktive SEMS-Session - login() wurde nicht (erfolgreich) aufgerufen.");
+        }
+        let host;
+        try {
+            host = new URL(this.session.api).hostname;
+        } catch {
+            host = "eu-gateway.semsportal.com";
+        }
+        return `https://${host}/web/sems`;
+    }
+
+    _gatewayHeaders(gatewayBase) {
+        const tokenPayload = {
+            uid: this.session.uid,
+            timestamp: String(this.session.timestamp),
+            token: this.session.token,
+            client: GATEWAY_CLIENT,
+            version: "",
+            language: "en",
+            api: gatewayBase,
+            region: "eu",
+        };
+        return {
+            "Content-Type": "application/json",
+            Accept: "application/json, text/plain, */*",
+            "User-Agent": DEFAULT_USER_AGENT,
+            token: JSON.stringify(tokenPayload),
+            "x-signature": this._gatewaySignature(this.session.uid, this.session.token),
+        };
+    }
+
+    /**
+     * Authenticated request against the SEMS+ gateway API (a different
+     * backend from the classic PowerStation API - see the GATEWAY_CLIENT
+     * comment above). No automatic re-login-and-retry here (unlike
+     * _authenticatedPost): if the gateway session is stale, getMonitorDetail()
+     * will simply fall through to its own caller's retry/re-login handling
+     * on the next poll cycle.
+     *
+     * @param {"GET"|"POST"} method
+     * @param {string} path e.g. "/sems-plant/api/stations/flow"
+     * @param {object} [query] query-string params
+     */
+    async _gatewayRequest(method, path, query) {
+        if (!this.session) {
+            await this.login();
+        }
+        const base = this._gatewayBase();
+        const qs = query && Object.keys(query).length ? new URLSearchParams(query).toString() : "";
+        const url = base + path + (qs ? `?${qs}` : "");
+
+        const { json } = await httpPostJson(
+            url,
+            {
+                method,
+                headers: this._gatewayHeaders(base),
+                timeoutMs: this.requestTimeoutMs,
+            },
+            this._timerFns,
+        );
+
+        this.log("debug", `SEMS-Gateway-Antwort ${url}: ${JSON.stringify(json)}`);
+
+        const code = json && json.code;
+        if (!SUCCESS_CODES.has(code)) {
+            const msg = (json && (json.description || json.msg || json.message)) || "unbekannter Fehler";
+            throw new SemsProtocolError(`SEMS-Gateway-Aufruf ${path} fehlgeschlagen: ${msg} (code=${code})`);
+        }
+        return json.data;
+    }
+
+    /**
+     * Gateway equivalent of the classic GetMonitorDetailByPowerstationId call:
+     * fetches station basic info, the device list and per-device
+     * telemetry/telecounting from the SEMS+ gateway API, and reshapes the
+     * result into the SAME "detail" object shape the classic API returns
+     * (info/kpi/inverter[]/...), so lib/mapping.js's mapMonitorDetail() does
+     * not need to know (or care) which backend the data actually came from.
+     *
+     * Deliberately conservative for its first version: only fields with a
+     * confirmed unit/shape (from the gateway's own response metadata or
+     * direct observation) are populated. In particular, the station-level
+     * "stations/flow" endpoint (PV/load/grid/battery power split) is NOT
+     * used yet - every real-account capture so far happened at night, where
+     * it returns an empty object, so neither its field names nor its unit
+     * could be confirmed. kpi.pac/power/total_power are instead computed by
+     * summing the per-inverter telemetry/telecounting values, which DO carry
+     * confirmed units ("kW"/"kWh") in the API's own response metadata.
+     *
+     * @param {string} powerStationId
+     */
+    async _getMonitorDetailGateway(powerStationId) {
+        const basicInfo =
+            (await this._gatewayRequest("POST", "/sems-plant/api/portal/stations/basic/info", {
+                stationId: powerStationId,
+            })) || {};
+
+        let deviceList = [];
+        try {
+            const allStatus = await this._gatewayRequest("GET", "/sems-plant/api/stations/device/all-status", {
+                stationId: powerStationId,
+            });
+            const detailLists = (allStatus && allStatus.deviceDetailList) || [];
+            for (const typeGroup of detailLists) {
+                const statusDetails = Array.isArray(typeGroup && typeGroup.statusDetailList)
+                    ? typeGroup.statusDetailList
+                    : [];
+                for (const statusDetail of statusDetails) {
+                    const detailMap = (statusDetail && statusDetail.detailMap) || {};
+                    for (const sn of Object.keys(detailMap)) {
+                        deviceList.push({
+                            sn,
+                            deviceType: (typeGroup && typeGroup.deviceType) || "INVERTER",
+                            ...detailMap[sn],
+                        });
+                    }
                 }
             }
+        } catch (error) {
+            this.log("debug", `SEMS-Gateway: Geräteliste nicht verfügbar (${error.message}).`);
+        }
+
+        const inverters = [];
+        for (const device of deviceList) {
+            const sn = device && device.sn;
+            if (!sn) {
+                continue;
+            }
+            const deviceType = device.deviceType || "INVERTER";
+            let telemetryFlat = {};
+            let telecountingFlat = {};
+            try {
+                const telemetry = await this._gatewayRequest(
+                    "GET",
+                    `/sems-plant/api/equipments/${encodeURIComponent(sn)}/telemetry`,
+                    { deviceType, pwId: powerStationId },
+                );
+                telemetryFlat = flattenGatewayFactors(telemetry);
+            } catch (error) {
+                this.log("debug", `SEMS-Gateway: telemetry für ${sn} fehlgeschlagen (${error.message}).`);
+            }
+            try {
+                const telecounting = await this._gatewayRequest(
+                    "GET",
+                    `/sems-plant/api/equipments/${encodeURIComponent(sn)}/telecounting`,
+                    { deviceType, pwId: powerStationId },
+                );
+                telecountingFlat = flattenGatewayFactors(telecounting);
+            } catch (error) {
+                this.log("debug", `SEMS-Gateway: telecounting für ${sn} fehlgeschlagen (${error.message}).`);
+            }
+
+            const pacKw = gatewayNum(telemetryFlat.pAc);
+            inverters.push({
+                sn,
+                name: device.name,
+                status: device.status,
+                pac: pacKw === undefined ? undefined : pacKw * 1000,
+                eday: gatewayNum(telecountingFlat.proPvStatsToday),
+                etotal: gatewayNum(telecountingFlat.proPvStatsTotal),
+                temperature: telemetryFlat.Temperature,
+                invert_full: {
+                    vpv1: telemetryFlat["MPPT-1:Vpv"],
+                    ipv1: telemetryFlat["MPPT-1:Ipv"],
+                    vpv2: telemetryFlat["MPPT-2:Vpv"],
+                    ipv2: telemetryFlat["MPPT-2:Ipv"],
+                    vac1: telemetryFlat["PHASE-A:Vac"],
+                    iac1: telemetryFlat["PHASE-A:Iac"],
+                    fac1: telemetryFlat.Fac,
+                    vac2: telemetryFlat["PHASE-B:Vac"],
+                    iac2: telemetryFlat["PHASE-B:Iac"],
+                    fac2: telemetryFlat.Fac,
+                    vac3: telemetryFlat["PHASE-C:Vac"],
+                    iac3: telemetryFlat["PHASE-C:Iac"],
+                    fac3: telemetryFlat.Fac,
+                },
+            });
         }
-        throw lastError;
+
+        const totalPac = inverters.length
+            ? inverters.reduce((sum, inv) => sum + (Number.isFinite(inv.pac) ? inv.pac : 0), 0)
+            : undefined;
+        const totalToday = inverters.length
+            ? inverters.reduce((sum, inv) => sum + (Number.isFinite(inv.eday) ? inv.eday : 0), 0)
+            : undefined;
+        const totalLifetime = inverters.length
+            ? inverters.reduce((sum, inv) => sum + (Number.isFinite(inv.etotal) ? inv.etotal : 0), 0)
+            : undefined;
+
+        return {
+            info: {
+                stationname: basicInfo.name,
+                capacity: basicInfo.pvCapacity !== undefined ? basicInfo.pvCapacity : basicInfo.installedPower,
+                address: basicInfo.googleAddress || basicInfo.address,
+                latitude: basicInfo.latitude,
+                longitude: basicInfo.longitude,
+                status: basicInfo.status,
+            },
+            kpi: {
+                pac: totalPac,
+                power: totalToday,
+                total_power: totalLifetime,
+            },
+            inverter: inverters,
+        };
     }
 }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "iobroker.goodwe-sems",
-  "version": "0.1.15",
+  "version": "0.1.16",
   "description": "ioBroker adapter to read GoodWe inverter data from the SEMS Portal cloud API (for installations without local/LAN access to the inverter).",
   "author": {
     "name": "bueste",