# Tuya: Integration von Heizung und Klimaanlage **URL:** \ **Category:** Demandes livrées\ **Created:** [10. Februar 2026 um 06:42 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983 "2026-02-10T06:42:29Z")\ **Posts on this page:** 20\ **Page:** 4
**Author:** ![GBoulvin](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/gboulvin/32/10006_2.png) [@GBoulvin](https://community.gladysassistant.com/u/GBoulvin)\ **Post date:** [11. Mai 2026 um 14:42 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/61 "2026-05-11T14:42:51Z")
Kein Problem, kein Stress! Für mich ist die PR2 - Protokoll 3.5 also tatsächlich funktionsfähig. Ich habe es nicht auf meiner Produktion getestet, aber ich kann es tun, wenn nötig. ---
**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\ **Post date:** [12. Mai 2026 um 04:16 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/62 "2026-05-12T04:16:12Z")
Danke @GBoulvin, > [@GBoulvin](#): > > Das Protokoll 3.5 funktioniert problemlos! Allerdings bekomme ich das mit 3.4 nicht zum Laufen. Es hat doch früher funktioniert… Die Fehlermeldung lautet: „Lokaler Poll-Timeout“. Ich habe das Docker-Image aktualisiert, das nun auch 3.4 unterstützt: Es wird jetzt an den Fork `@demirdeniz/tuyapi-newgen` weitergeleitet (derselbe, der 3.5 verwaltet), und ein Parser für Version 3.4 wurde zum lokalen UDP-Scan zwischen den Parsern 3.1 und 3.5 hinzugefügt. Du kannst es jederzeit mit dem neuen Image erneut testen. Falls möglich, bitte auch den UDP-Scan (unabhängig) testen, um sicherzustellen, dass alles funktioniert. Vielen Dank im Voraus > [@GBoulvin](#): > > Für mich ist die PR2 - Protokoll 3.5 also tatsächlich funktionsfähig. Ich habe es nicht auf meiner Produktion getestet, aber ich kann es tun, wenn nötig. Auf meiner Seite normalerweise nicht nötig: Die Änderungen fügen eine strikte Weiterleitung hinzu, die nur durch `protocolVersion === '3.4'` oder `'3.5'` ausgelöst wird. Geräte mit 3.1 und 3.3 verwenden weiterhin die Legacy-Bibliothek `tuyapi` ohne jegliche Änderung des Aufrufpfads — also kein Risiko von Rückschritten bei dem, was bereits funktioniert hat. Das heißt, wenn du die Gelegenheit nutzen möchtest, um es auf deiner Produktion zu validieren, ist das ideal: Deine Geräte 3.4 (die nicht funktioniert haben) sollten jetzt funktionieren, und deine Geräte 3.1/3.3/3.5 sollten unverändert bleiben. Keine Verpflichtung, es ist nur ein Bonus, wenn du 5 Minuten Zeit hast. **EDIT** : Zur Information @pierre-gilles, ich habe den PR-Namen geändert, indem ich die explizite Hinzufügung von 3.4 neben 3.5 benannt habe, wobei beide dieselbe Bibliothek verwenden. Der PR ist etwas größer, aber wir bleiben unter 600 Zeilen Änderungen, es sind vor allem die Tests, die umfangreich sind (stellen die Hälfte der hinzugefügten Zeilen dar) ---
**Author:** ![GBoulvin](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/gboulvin/32/10006_2.png) [@GBoulvin](https://community.gladysassistant.com/u/GBoulvin)\ **Post date:** [12. Mai 2026 um 16:51 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/63 "2026-05-12T16:51:38Z")
Vielleicht eine dumme Frage, aber ist das Bild immer noch auf demselben Tag (pr1)? ---
**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\ **Post date:** [12. Mai 2026 um 18:00 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/64 "2026-05-12T18:00:04Z")
Ja immer ^^ Besser fragen ^^ ---
**Author:** ![GBoulvin](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/gboulvin/32/10006_2.png) [@GBoulvin](https://community.gladysassistant.com/u/GBoulvin)\ **Post date:** [13. Mai 2026 um 16:42 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/65 "2026-05-13T16:42:55Z")
Hallo! Ich habe die verfügbare Version getestet und das Protokoll 3.4 wird erkannt und funktioniert direkt. Auch die Erkennung der lokalen IP-Adresse (für 3.4, ja, aber nicht für 3.5. Ich hatte das schon bemerkt, aber meine Netzwerkinstallation ist nicht die beste, um das zu testen, also schwer zu sagen, ob es am Protokoll liegt). Alles gut für mich also! Danke!! ---
**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\ **Post date:** [18. Mai 2026 um 09:56 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/66 "2026-05-18T09:56:47Z")
Die folgenden 2 PRs warten auf eine Überprüfung: - Hinzufügen der Unterstützung für Protokolle 3.4 und 3.5: > > > \### Pull Request check-list > > To ensure your Pull Request can be accepted as fa…st as possible, make sure to review and check all of these items: > > \- \[x\] If your changes affect the code, did you write the tests? > \- \[x\] Are tests passing? (\`npm test\` on both front/server) > \- \[x\] Is the linter passing? (\`npm run eslint\` on both front/server) > \- \[x\] Did you run prettier? (\`npm run prettier\` on both front/server) > \- \[x\] If you are adding a new feature/service, did you run the integration comparator? (\`npm run compare-translations\` on front) > \- \[x\] Did you test this pull request in real life? With real devices? If this development is a big feature or a new service, we recommend that you provide a Docker image to the community (\[forum\](https://community.gladysassistant.com/)) for testing before merging. > \- \[\] If your changes modify the API (REST or Node.js), did you modify the API documentation? (Documentation is based on comments in code) > \- \[\] If you are adding a new features/services which needs explanation, did you modify the user documentation? See \[the GitHub repo\](https://github.com/GladysAssistant/v4-website) and the \[website\](https://gladysassistant.com). > \- \[\] Did you add fake requests data for the demo mode (\`front/src/config/demo.js\`) so that the demo website is working without a backend? (if needed) See \[https://demo.gladysassistant.com\](https://demo.gladysassistant.com). > > NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. > > \### Description of change > > \## Summary > > Adds support for \*\*Tuya local protocols 3.4 and 3.5\*\* to the Tuya integration. Stacks on top of \[PR #2434\](https://github.com/GladysAssistant/Gladys/pull/2434) which is now merged into \`master\`. > > The official \`tuyapi@7.2.0\` only supports protocols 3.1 and 3.3 — it has \*\*no cipher or parser\*\* for 3.4 (the "3.4" dropdown option was pointing to a non-functional path) and obviously none for 3.5. A second client (\`@demirdeniz/tuyapi-newgen\`) is added and used \*\*only\*\* when \`protocolVersion === '3.4'\` or \`'3.5'\`. Protocols 3.1 and 3.3 keep using the original \`tuyapi\` client and are not impacted. > > \## Details > > \*\*Protocol routing\*\* > \- \`tuya.localPoll.js\` and \`tuya.setValue.js\` pick the local API class based on an \`isNewGenProtocol\` flag (\`isProtocol34 || isProtocol35\`). > \- For 3.5 only: \`keepAlive\` is disabled and \`socketTimeout\` is floored at 5 s because the 3.5 handshake takes longer than the others. > \- For 3.5 only: a small fallback chain (\`{schema:true}\` → \`{schema:true, dps:\[1\]}\` → \`{}\`) because some firmwares reject a bare schema get on first contact. 3.4 uses a single schema attempt. > \- Protocol 3.4 reuses the existing \`tuyapi-newgen\` \`\_decrypt34\` cipher and \`0x6699/0x9966\` UDP framing. > > \*\*UDP local scan\*\* > \- \`tuya.localScan.js\` now parses incoming packets with three \`MessageParser\` instances in order \`\[3.1, 3.4, 3.5\]\` and keeps the first one that succeeds. > \- \`localScan(input)\` accepts either a number or an object so existing callers passing \`{ timeoutSeconds: N }\` still work. > \- \`timeoutSeconds\` is sanitized into \`\[1, 30\] s\`. > > \*\*Robustness improvements (touched along the way)\*\* > \- \`localPoll.timeoutMs\` is sanitized into \`\[500, 30000\] ms\` to prevent immediate timeouts or pathologically long hangs. > \- \`setValue\` now throws \`BadParameters\` when the external\_id has no command instead of silently falling back to the cloud. > > \*\*Front (\`TuyaDeviceBox.jsx\`)\*\* > \- Protocol 3.5 is enabled in the dropdown (3.4 was already listed but non-functional before this PR). > \- \`pollLocal()\` adds 3.5 to the fallback list and captures \`currentDevice\` once at the start of the async loop to avoid stale \`this.state.device\` reads across protocol attempts. > \- Obsolete i18n keys \`protocol35OptionUnsupported\` and \`protocolVersionRequired\` removed (en/fr/de). > > \*\*Dependency\*\* > \- \`@demirdeniz/tuyapi-newgen\` is \*\*pinned\*\* to exact version \`8.1.5\` (no caret), since it is a single-maintainer scoped fork. License MIT, integrity hash present in lockfile. > > \## Scope > > Computed against \`master\` (PR #2434 already merged). > > \- \*\*server (prod)\*\* : ~150 lines (3 files: \`tuya.localPoll.js\`, \`tuya.localScan.js\`, \`tuya.setValue.js\`) > \- \*\*server (tests)\*\* : ~325 lines (3 files: \`tuya.localPoll.test.js\`, \`tuya.localScan.test.js\`, \`tuya.setValue.test.js\`) > \- \*\*front (prod)\*\* : ~29 lines (\`TuyaDeviceBox.jsx\`) > \- \*\*translations\*\* : ~18 lines (\`en.json\`, \`fr.json\`, \`de.json\`) > \- \*\*packages / lockfiles\*\* : ~75 lines (\`package.json\`, \`package-lock.json\`) > > Total : ~597 lines across 12 files. > > \## Validation > > \- \`npm run test-service --service=tuya\` → \*\*159 passing, 0 failing\*\* > \- \`eslint server/services/tuya server/test/services/tuya\` → clean > \- \`eslint front/src/routes/integration/all/tuya\` → clean > > > > > \## Summary by CodeRabbit > > \* \*\*New Features\*\* > \* Local device polling with multi-protocol fallback, UDP local discovery, connection status, manual disconnect, reconnect logic, and cloud/local mode controls. > > \* \*\*UI\*\* > \* Richer Tuya setup UI with new credential fields and connection states; device view shows masked IP, product/device identifiers, protocol/IP controls, local-poll actions, GitHub issue shortcut, and improved discovery ordering/status. > > \* \*\*Localization\*\* > \* Expanded DE/EN/FR translations for setup, discovery, devices, statuses, errors, and guidance. > > \* \*\*Tests\*\* > \* Extensive new and updated tests for local poll/scan, discovery, config, status, setValue, and lifecycle. - Hinzufügen der ersten Bausteine für die Zuordnung Cloud/Lokal und insbesondere die lokale UDP-Erkennung: > > > \### Pull Request check-list > > To ensure your Pull Request can be accepted as fa…st as possible, make sure to review and check all of these items: > > \- \[x\] If your changes affect the code, did you write the tests? > \- \[x\] Are tests passing? (\`npm test\` on both front/server) > \- \[x\] Is the linter passing? (\`npm run eslint\` on both front/server) > \- \[x\] Did you run prettier? (\`npm run prettier\` on both front/server) > \- \[x\] If you are adding a new feature/service, did you run the integration comparator? (\`npm run compare-translations\` on front) > \- \[x\] Did you test this pull request in real life? With real devices? If this development is a big feature or a new service, we recommend that you provide a Docker image to the community (\[forum\](https://community.gladysassistant.com/)) for testing before merging. > \- \[\] If your changes modify the API (REST or Node.js), did you modify the API documentation? (Documentation is based on comments in code) > \- \[\] If you are adding a new features/services which needs explanation, did you modify the user documentation? See \[the GitHub repo\](https://github.com/GladysAssistant/v4-website) and the \[website\](https://gladysassistant.com). > \- \[\] Did you add fake requests data for the demo mode (\`front/src/config/demo.js\`) so that the demo website is working without a backend? (if needed) See \[https://demo.gladysassistant.com\](https://demo.gladysassistant.com). > > NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. > > \### Description of change > > This PR introduces a mapping core for Tuya devices to make local/cloud handling more consistent and future device integrations easier. > > \## Summary > > Brings PR3 in sync with master + PR1/PR2 review fixes (PR1 was squash-merged > in \`bf8bbff1\`; PR2 carries the master merge and its own review-feedback > batch). PR3's own contribution — Tuya mapping core, \`convertDevice\` / > \`convertFeature\` refactor, \`tuya.deviceMapping\` / \`tuya.localMapping\`, > poll hardening, and Smart Socket reference implementation — is preserved > on top of the aligned base. > > \## Details > > Merge of \`tuya-local-protocol-3.5\` (PR2) into PR3 brings forward: > > \- master alignment via PR2's merge commit (\`0c457670\`): Gladys 4.73.0, > Matter.js 0.16.11, Airplay sender rewrite, energy/i18n updates > \- PR1 review fixes baked-in via the master squash (single > \`/configuration\` endpoint, reconnect prototype refactor moved to > \`lib/tuya.reconnect.js\` with proper wiring in \`lib/index.js\`, > \`stopReconnect()\` call in \`lib/tuya.disconnect.js\`, \`addSelector\` > in \`convertDevice\` / \`convertFeature\`, \`MarkupText\` invalid-paragraph > fix in \`SetupTab.jsx\`, \`discoverDevices\` JSDoc fix, \`bridge minimal\` > \`services/tuya/index.js\`) > \- PR2 review feedback (\`6b760790\`): exact \`@demirdeniz/tuyapi-newgen\` > pin to \`8.1.5\`, \`socketTimeout\`/\`keepAlive\` documented for protocol > 3.5, DPS fallback chain documented, dropped redundant \`localKey\` > guard in \`updateDiscoveredDeviceAfterLocalPoll\`, dropped redundant > double-disconnect in \`localPoll\` outer catch > \- PR2 protocol 3.4 newgen routing (\`2679dba6\`): \`localScan\` ordered > parsers \`\[3.1, 3.4, 3.5\]\`, \`localPoll\` / \`setValue\` route 3.4 via > \`isNewGenProtocol\` > > Conflict resolutions (manual, then validated via tests + lint): > > \- \`tuya.localPoll.js\`: PR2 base (proto 3.4 routing + comments) + > PR3 add-on reposed (\`logDps\`, \`addFallbackBinaryFeature\`, \`dps\` passing) > \- \`tuya.poll.js\`: PR3 refactor kept; obsolete PR2 baseline snippet dropped > \- \`tuya.convertFeature.js\`: PR3 imports + PR1 \`addSelector\` combined > \- \`SetupTab.jsx\` and \`i18n/fr.json\`: PR3 pre-PR1-fix workarounds dropped > \- \`tuya.poll.test.js\`: PR3 tests kept (cover PR2 baseline by equivalence) > \- \`tuya.localScan.test.js\`: PR2 added test > \`should instantiate parsers for protocols 3.1, 3.4 and 3.5\` kept > \- \`tuya.convertFeature.test.js\`: selector expectation harmonised to > the slugified form (consistent with the rest of the file) > > Validation: > > \- \`npm run test-service --service=tuya\`: \*\*209 passing\*\* > \- \`npx nyc --include='services/tuya/\*\*'\`: \*\*99.59% lines / 99.60% stmts / > 99.39% functions / 88.94% branches\*\* > \- \`eslint server/services/tuya server/test/services/tuya\`: clean > \- \`eslint front/src/routes/integration/all/tuya\`: clean > > \## Scope > > Scope vs the immediate parent branch in the stack > (\`tuya-local-protocol-3.5\`, PR #2438): > > | Area | Insertions | Deletions | > |---|---:|---:| > | \`server/services/tuya\` (prod) | +987 | -178 | > | \`server/test/services/tuya\` (tests) | +1313 | -26 | > | \`front/src/routes/integration/all/tuya\` (prod) | +13 | -8 | > | \*\*Total\*\* | \*\*+2313\*\* | \*\*-212\*\* | > > No translation, package or lockfile changes (the \`localModeLimitInfo\` > restoration in commit \`865e2cc3\` was a fix for a key dropped during the > merge of PR2, with zero net delta vs PR2). > > 27 files changed, 0 leak outside the Tuya scope. > > > > > > \## Summary by CodeRabbit > > \* \*\*New Features\*\* > \* Local UDP discovery and local polling for Tuya devices; cloud/local mode toggle, manual cloud disconnect, and explicit Save → Connect flow. > \* Real-time connection status and disconnect controls with improved reconnect handling. > > \* \*\*Improvements\*\* > \* Updated setup copy and field labels (Client ID/Client Secret, App UID, App Username) with validation and user-friendly error messages. > \* Device panel shows identifiers, IP/protocol, product info, local-poll controls/progress, success/error indicators and clearer "unknown" value labels. @GBoulvin, wenn du PR3 testen möchtest, habe ich ein neues Image `terdious/gladys:tuya-PR3` erstellt, insbesondere: - mit deiner Basis des letzten Tests starten, - dann einen lokalen Auto-UDP-Scan durchführen - dann die bereits registrierten Geräte löschen, dich abmelden, dann wieder anmelden und einen neuen lokalen Auto-UDP-Scan starten, um sicherzustellen, dass alles wiedergefunden wird. Vielen Dank im Voraus. ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [1. Juni 2026 um 13:32 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/67 "2026-06-01T13:32:50Z")
> [@Terdious](#): > > Unterstützung für die Protokolle 3.4 und 3.5 hinzugefügt: Für mich ist das mit dem PR2 in Ordnung, es ist gemerged und wird in der nächsten Version von Gladys 🙂 mit dabei sein. Beim PR3 gibt es nach dem Merge Konflikte, sag mir Bescheid, sobald ich mir das anschauen kann! Danke für die Entwicklung! ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [1. Juni 2026 um 14:59 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/68 "2026-06-01T14:59:31Z")
Verfügbar in Gladys Assistant 4.77: > [@Gladys Assistant 4.77: Ein Sprachassistent in Gladys 🎙️](https://community.gladysassistant.com/t/gladys-assistant-4-77-un-assistant-vocal-dans-gladys/10249): > > Une nouvelle version de Gladys est disponible avec plusieurs améliorations sympa slight_smilestudio_microphone Nouveau widget Assistant Vocal Vous pouvez désormais ajouter un widget Assistant Vocal directement sur votre tableau de bord. [[Je parle à ma maison… et elle me répond exploding_head] ](https://www.youtube.com/watch?v=7LBeCTegKsY) Pratique sur une tablette murale, un smartphone :slight\_smile: Je suis preneur de vos retours, c’est avant tout une première preuve de concept qui pourrait évoluer vers plus de voix dans Gladys si v… ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [15. Juni 2026 um 14:52 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/69 "2026-06-15T14:52:35Z")
Hallo @Terdious, Ich würde die [PR 3](https://github.com/GladysAssistant/Gladys/pull/2466) gerne mergen, aber es gibt Konflikte: ![Bildschirmfoto 2026-06-15 um 16.51.01](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/0/0/004b88ad14fffc424c04fca84ed7fa3bbe58ad9e.png) Sobald du Claude darauf ansetzen kannst, um sie zu lösen, lass es mich wissen und ich werde sie mergen 😉 ---
**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\ **Post date:** [18. Juni 2026 um 05:22 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/70 "2026-06-18T05:22:28Z")
Hallo @pierre-gilles, Ich kümmere mich gleich darum und schaue es mir an!! Danke EDIT: Alles klar bei mir. ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [18. Juni 2026 um 17:44 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/71 "2026-06-18T17:44:09Z")
Super danke @Terdious! Es ist gemerged! Ist der PR 4 bereit? 😃 ---
**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\ **Post date:** [19. Juni 2026 um 11:03 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/72 "2026-06-19T11:03:43Z")
Hallo @pierre-gilles, Danke für das Mergen der PR3 👍 Für die [PR4 #2467](https://github.com/GladysAssistant/Gladys/pull/2467) ist sie bereit. Ich habe gerade `master` darin gemerged, um die 3 Konflikte zu lösen, die GitHub angezeigt hat. ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [19. Juni 2026 um 11:42 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/73 "2026-06-19T11:42:13Z")
Das ist für mich in Ordnung für PR4, es ist gemerged und wird in der nächsten Version von Gladys veröffentlicht 🙂 Danke für die PR 🙌 ---
**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\ **Post date:** [19. Juni 2026 um 13:12 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/74 "2026-06-19T13:12:16Z")
Top, vielen Dank für das Mergen der PR4 und aller vorherigen 🙌 🚀 Bei PR5 habe ich gerade `master` aktualisiert, sie ist bereit zur Überprüfung: [#2470](https://github.com/GladysAssistant/Gladys/pull/2470) _ **Kleiner Hinweis** _ : Du kannst dir Zeit für diese nehmen, ich würde lieber warten, bis @GBoulvin ein Feedback zum Docker-Image `Terdious:tuya-smart-meter` (im Bau) gibt, bevor wir mergen. Es ist die erste vollständige Tuya-Integration mit Cloud- und lokaler Verwaltung, und die Cloud-Thing-Model-Strategie ist neu — ein Test unter realen Bedingungen an seinem Zähler schadet nicht, bevor es in die Veröffentlichung geht, auch wenn er es bereits zuvor getestet hat. Wir haben einige Änderungen in den ersten drei PRs vorgenommen (normalerweise nicht beeinträchtigend) 🙂 * * * Hallo @GBoulvin PR5 ist code-seitig fertig und das Docker-Image `Terdious:tuya-smart-meter` wird in etwa 30 Minuten verfügbar sein (Build läuft). Könntest du es an deinem Smart Meter testen, wenn du Zeit hast? Das Ziel ist es, unter realen Bedingungen zu validieren: - die Erkennung des Geräts in der Cloud - das Lesen der Werte (momentane Leistung, Gesamtenergie, Spannung, Strom) - die Stabilität des Cloud-Pollings über die Zeit - die Erkennung des Geräts lokal - das Lesen der Werte (momentane Leistung, Gesamtenergie, Spannung, Strom) lokal - die Stabilität des lokalen Pollings über die Zeit Dein Feedback wird das Mergen bei Pierre-Gilles beeinflussen. Vielen Dank im Voraus 🙏 Edit: Von meiner Seite getestet und funktionierend (aber nicht speziell mit einem Smart Meter getestet ^^) ---
**Author:** ![GBoulvin](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/gboulvin/32/10006_2.png) [@GBoulvin](https://community.gladysassistant.com/u/GBoulvin)\ **Post date:** [19. Juni 2026 um 19:14 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/75 "2026-06-19T19:14:38Z")
Hallo @Terdious, Kleines Problem mit den Zugriffsrechten für dein Testbild (nicht öffentlich?). Falls du einen Blick darauf werfen könntest… Entschuldige für meine langsame Reaktion! Edit: Ich habe es gefunden: terdious/gladys:tuya-smart-meter 😉 ---
**Author:** ![GBoulvin](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/gboulvin/32/10006_2.png) [@GBoulvin](https://community.gladysassistant.com/u/GBoulvin)\ **Post date:** [19. Juni 2026 um 19:51 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/76 "2026-06-19T19:51:32Z")
Hier mein Feedback. Ich habe es getestet und es scheint, dass alles funktioniert. Es ist stabil, ich habe wie ein Wilder geklickt und überall Nullen eingesetzt und alles hat gehalten 😉 Die Einheiten sind gut, das lokale und Cloud-Polling läuft ohne Probleme. Nur eine Sache, die nicht so wichtig ist: ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/3/d/3dbfbfd57b3804e7c9a93b9177736b71462cb49e.png) Es steht forword statt forward. Ich bin mir nicht mal sicher, ob das von der PR kommt o:-) Frage zur Energieerfassung, müssen die Berechnungen „alle 30 Minuten“ noch implementiert werden oder ist das bereits vorgesehen? Ich lasse es dieses Wochenende laufen, um zu sehen, wie es sich verhält, aber für mich ist alles gut! Danke @Terdious! ---
**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\ **Post date:** [19. Juni 2026 um 20:20 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/77 "2026-06-19T20:20:09Z")
Oups !! ^^ Entschuldigung für den falschen Bildnamen. Vielen Dank für die Tests 🙏 @GBoulvin > [@GBoulvin](#): > > Es steht forword statt forward. Ich bin mir nicht mal sicher, ob das von der PR kommt o:-) Gut aufgepasst ^^ tatsächlich, der von der Tuya-API zurückgesendete DP-Code für diese Zähler ist wörtlich als energy\_forword\_a / energy\_forword\_b geschrieben, also ist es ein Fehler auf ihrer Seite, den ich aus Kohärenz mit der API-Dokumentation übernommen habe… aber es stört mich auch 😅 @pierre-gilles, was denkst du? Beibehaltung des Fehlers oder Korrektur auf Seiten von Gladys für die Benennung des Features? Ansonsten, nach den überzeugenden Tests, überlasse ich dir die Prüfung des PR, wenn du Zeit hast 😉 ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [22. Juni 2026 um 05:36 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/78 "2026-06-22T05:36:04Z")
> [@Terdious](#): > > @pierre-gilles, was denkst du? Fehler beibehalten oder Korrektur auf Gladys-Seite für die Benennung der Funktion? Korrektur auf Gladys-Seite 🙂 Es wäre schade, einen Fehler in unseren eigenen Funktionen zu perpetuieren. 😄 ---
**Author:** ![GBoulvin](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/gboulvin/32/10006_2.png) [@GBoulvin](https://community.gladysassistant.com/u/GBoulvin)\ **Post date:** [22. Juni 2026 um 09:52 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/79 "2026-06-22T09:52:42Z")
Nach 48 Stunden Test, kein Bug, keine Abmeldung oder so etwas! ---
**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\ **Post date:** [23. Juni 2026 um 11:25 UTC](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983/80 "2026-06-23T11:25:08Z")
Hallo @pierre-gilles, Erledigt, die Features wurden umbenannt. Danke dir. Ich bin bereit, die Überprüfung für PR5 - Hinzufügen der Unterstützung für Smart Meter - zu starten, ich habe sie dir zugewiesen: > > > \### Pull Request check-list > > To ensure your Pull Request can be accepted as fast… as possible, make sure to review and check all of these items: > > \- \[x\] If your changes affect the code, did you write the tests? > \- \[x\] Are tests passing? (\`npm test\` on both front/server) > \- \[x\] Is the linter passing? (\`npm run eslint\` on both front/server) > \- \[x\] Did you run prettier? (\`npm run prettier\` on both front/server) > \- \[x\] If you are adding a new feature/service, did you run the integration comparator? (\`npm run compare-translations\` on front) > \- \[x\] Did you test this pull request in real life? With real devices? If this development is a big feature or a new service, we recommend that you provide a Docker image to the community (\[forum\](https://community.gladysassistant.com/)) for testing before merging. > \- \[\] If your changes modify the API (REST or Node.js), did you modify the API documentation? (Documentation is based on comments in code) > \- \[\] If you are adding a new features/services which needs explanation, did you modify the user documentation? See \[the GitHub repo\](https://github.com/GladysAssistant/v4-website) and the \[website\](https://gladysassistant.com). > \- \[\] Did you add fake requests data for the demo mode (\`front/src/config/demo.js\`) so that the demo website is working without a backend? (if needed) See \[https://demo.gladysassistant.com\](https://demo.gladysassistant.com). > > NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. > > \### Description of change > > Closes #2486. Closes #2487. > > \## Summary > > \- Add support for Tuya Smart Meter devices, based on issue #2464 (\`product\_id: bbcg1hrkrj5rifsd\`). > \- Add both cloud and local mappings for Smart Meter features. > \- Route Tuya cloud reads through the Thing Model shadow API when devices do not expose legacy status specifications. > \- Introduce a fixture-based Tuya test harness so adding new device types becomes more industrialized and easier to maintain. > \- Curate user-facing feature names so Tuya code typos (\`energy\_forword\_a\`, \`energy\_reserse\_b\`) never surface in the UI: the Tuya code stays the API key (\`external\_id\`) while the display name is taken from the mapping. > > \## Scope > > Scope vs the immediate parent branch in the stack > (\`tuya-local-github-issues\`, PR #2467): > > | Area | Insertions | Deletions | > |---|---:|---:| > | \`server/services/tuya\` (prod) | +515 | -146 | > | \`server/test/services/tuya\` (tests) | +2304 | -5 | > | \`front/src/routes/integration/all/tuya\` (prod) | +14 | -1 | > | \`front/src/config/i18n\` (translations) | +6 | -3 | > | \*\*Total\*\* | \*\*+2839\*\* | \*\*-155\*\* | > > No package or lockfile changes. The bulk of the test delta comes from the > fixture-based onboarding harness (Smart Meter and Smart Socket reference > fixtures, per-device expected payloads, cloud/local events, mapping > sanity tests). Front production stays minimal because the GitHub issue > flow refactor already lives in PR4; PR5 only touches TuyaDeviceBox to > surface the cloud read strategy. > > 48 files changed, 0 leak outside the Tuya scope. > > \## Details > > \- Add Smart Meter device detection through Tuya mapping index. > \- Add dedicated cloud mapping for Smart Meter values such as: > - total power > - forward energy total > - reverse energy total > - voltage > - current > \- Add dedicated local DPS mapping for Smart Meter. > \- Persist the cloud read strategy at device conversion time so runtime polling can directly choose the right Tuya cloud route. > \- Support both Tuya cloud read strategies: > - legacy \`/v1.0/iot-03/devices/{id}/status\` > - thing shadow \`/v2.0/cloud/thing/{id}/shadow/properties\` > \- Extend Tuya device readers to support Smart Meter values safely even when \`specifications.status\` is empty and the device only exposes a Thing Model. > \- Add fixture-based tests covering: > - device conversion > - local mapping > - polling > - setValue flows > \- Add reusable fixture helpers and example fixture structure so future Tuya devices can be integrated with less ad hoc test code. > \- Feature naming (\`convertFeature.js\` + \`mappings/cloud/smart-meter.js\`): > - \`convertFeature\` now prefers a curated \`mapping.name\` over the raw Tuya code for the display name; device types without a mapping name keep the code as name (unchanged behaviour). > - The smart-meter cloud mapping defines clean English names for its 12 features (e.g. \`energy\_forword\_a\` -\> "Forward energy A"). > - Unit tests cover both the mapping-name override (typo kept only as the API key) and the code fallback. > > \## Why this matters > > This PR does more than add one device. > > It also introduces a repeatable fixture-based approach for Tuya device integration: > > \- take the raw Tuya device payload > \- define the expected Gladys device output > \- define expected poll/setValue behavior > \- validate everything through reusable tests > > It also closes an important gap for Tuya devices that are cloud-readable through the Thing Model shadow API but do not expose legacy cloud status specifications. > > This makes onboarding future Tuya devices more industrialized, faster, and safer. > > > \## Summary by CodeRabbit > > \## Release Notes > > \* \*\*New Features\*\* > \* Added support for smart meter devices with multi-phase energy monitoring (power, voltage, current, energy export/import indices). > \* Enabled local device polling for improved responsiveness and reduced cloud dependency. > \* Enhanced device discovery and cloud read strategy optimization. > > \* \*\*Documentation\*\* > \* Updated translations for energy sensor "Export index" feature in German, English, and French. PR6, eine PR, die hauptsächlich Korrekturen enthält, wird ebenfalls zur Überprüfung bereit sein: > > > \### Pull Request check-list > > To ensure your Pull Request can be accepted as fast… as possible, make sure to review and check all of these items: > > \- \[x\] If your changes affect the code, did you write the tests? > \- \[x\] Are tests passing? (\`npm test\` on both front/server) > \- \[x\] Is the linter passing? (\`npm run eslint\` on both front/server) > \- \[x\] Did you run prettier? (\`npm run prettier\` on both front/server) > \- \[x\] Did you test this pull request in real life? With real devices? If this development is a big feature or a new service, we recommend that you provide a Docker image to the community (\[forum\](https://community.gladysassistant.com/)) for testing before merging. > > NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. > > \### Description of change > > \## Summary > > \- Add an in-memory \*\*degraded-local backoff\*\* (\`degradedDevices\` map on the \`TuyaHandler\` instance): when a device repeatedly fails local communication with network errors (\`ECONNRESET\` / \`ETIMEDOUT\` / \`EHOSTUNREACH\` / ...), Gladys stops attempting local for 5 minutes and silently falls back to cloud, avoiding the cascading failure pattern observed on some Tuya 3.3 firmwares that enter a protective state after stress. > \- New GET \`/api/v1/service/tuya/local-status\` endpoint and warning badge in \`TuyaLocalPollSection\` so the user knows when a device is in fallback mode and when it will recover. Clicking "Lecture locale des DP" resets the backoff for that device. > \- Save-time fix on the Devices page: \`tuya\_mapping\` (and other Tuya transient enrichment) is now preserved after \`POST /api/v1/device\`, so the "partial support" banner no longer appears erroneously between save and refresh. > \- Final hardening pass: clearer local-poll error reporting, null-safety on cloud detail loading, sparse local-scan packet preservation, and a defensive guard in the Tuya cloud account validation flow. > \- Curate user-facing feature names for the global and smart-socket Tuya cloud mappings (e.g. \`cur\_power\` -\> "Active power", \`power\` -\> "On/off", \`bright\_value\_v2\` -\> "Brightness"), completing the naming clean-up started for the smart-meter in PR5. Tuya codes stay as API keys. > \- \*\*Post-review follow-ups\*\*: forced degraded backoff on repeated invalid local payloads, a safety cap on the recursive cloud pagination, i18n consistency fixes on the degraded-status message, and truncation of oversized local socket error messages in logs. > > \- \*\*Tester feedback (GBoulvin)\*\*: a "service not configured" banner on the Devices landing page (same pattern and link as the discover page one), and the partial-support button now says "features" instead of "functions". > > \## Scope > > Scope vs \`master\` (the former parent \`tuya-v2-smart-meter-support\`, PR #2470, is now merged): > > | Area | Insertions | Deletions | > |---|---:|---:| > | \`server/services/tuya\` (prod) | +241 | -14 | > | \`server/test/services/tuya\` (tests) | +1242 | -25 | > | \`front/src/routes/integration/all/tuya\` (prod) | +102 | -8 | > | \`front/src/config/i18n\` (translations) | +9 | -3 | > | \*\*Total (38 files)\*\* | \*\*+1594\*\* | \*\*-50\*\* | > > No package or lockfile changes. No leak outside the Tuya scope. > > \## Details > > \### Degraded-local backoff (new) > > \- New module \`server/services/tuya/lib/utils/tuya.degraded.js\`: > - \`isDegradingError(error)\` — recognizes \`ECONNRESET\` / \`ECONNABORTED\` / \`ECONNREFUSED\` / \`ETIMEDOUT\` / \`EHOSTUNREACH\` / \`EHOSTDOWN\` / \`ENETUNREACH\` either via \`.code\` or via message substring > - \`recordLocalFailure(map, deviceId, error, now?, force?)\` — accumulates failure timestamps in a sliding 30 s window, flips the entry to \`status: 'degraded'\` once 3 failures hit and pushes \`until = now + 5 min\`; the \`force\` flag records non-network errors too (used for repeated invalid local payloads) > - \`recordLocalSuccess(map, deviceId)\` and \`resetLocalStatus(map, deviceId)\` — clear the entry > - \`getLocalStatus(map, deviceId, now?)\` — returns \`{status, until}\` or \`null\`, auto-clearing expired entries > - \`isLocalSkipNeeded(map, deviceId, now?)\` — convenience boolean used by callers > - \`getAllDegraded(map, now?)\` — used by the front-facing endpoint > \- \`this.degradedDevices = {}\` initialized in the \`TuyaHandler\` constructor (\`server/services/tuya/lib/index.js\`) > \- \`server/services/tuya/lib/tuya.poll.js\`: > - skips the local branch with \`fallback=device\_degraded\` when an active backoff exists > - calls \`recordLocalSuccess\` on a successful local poll (full or partial) and \`recordLocalFailure\` in the \`catch (e)\` of the local block > - a non-throwing but malformed local payload (\`invalid\_local\_payload\`) now records a \*\*forced\*\* failure so a device stuck returning garbage trips the backoff too > \- \`server/services/tuya/lib/tuya.setValue.js\`: > - same logic in \`runLocalSet\`: skip when degraded, record success/failure based on outcome > \- \`server/services/tuya/api/tuya.controller.js\`: > - new \`GET /api/v1/service/tuya/local-status\` returning either \`{deviceId, status}\` (when \`?deviceId=X\` is provided) or \`{devices: {...}}\` (full map of active entries) > - the existing \`POST /local-poll\` now resets the degraded entry up-front so the manual user-triggered test is never blocked by the backoff > - Feature naming (\`mappings/cloud/global.js\`, \`mappings/cloud/smart-socket.js\`): > - every mapped code now carries a clean English display name; the raw Tuya code remains the external\_id/selector key. > - \`convertFeature\`'s \`mapping.name || code\` fallback is covered by a proxyquire stub (all real mappings now provide a name). > > \### UI indicator > > \- \`front/src/routes/integration/all/tuya/TuyaLocalPollSection.jsx\`: > - \`componentDidMount\` and \`componentDidUpdate\` (on device change) refresh the local status via the new endpoint > - \`pollLocal\` re-fetches the status on both success and failure so the badge always reflects post-action state > - warning badge \`alert alert-warning\` rendered when \`status === 'degraded'\`, with the expected recovery time formatted as \`HH:MM\` > \- 3 new i18n keys (\`integration.tuya.device.localStatusDegraded\`) for FR / EN / DE, with \`{{time}}\` interpolation; the quoted button label now matches the actual \`localPollButton\` text in each locale, and the FR string uses "repli" instead of the English "fallback" > > \### Save-time \`tuya\_mapping\` preservation > > \- \`front/src/routes/integration/all/tuya/TuyaDeviceBox.jsx\`: > - \`saveDevice\` merges the saved response with the previously-known transient fields (\`tuya\_mapping\`, \`specifications\`, \`tuya\_report\`) since \`POST /api/v1/device\` does not persist them > - \`componentWillReceiveProps\` adds \`tuya\_mapping\` to the same carry-forward set already used for \`specifications\` and \`tuya\_report\` > \- Fixes the cosmetic "partial support" banner that appeared on the Devices page right after saving a Smart Socket with intentionally-ignored DPs (the banner disappeared on page refresh — the bug was purely transient state loss). > > \### Reliability hardening > > \- Local poll diagnostics (\`tuya.localPoll.js\`): > - new \`formatSocketError(err)\` helper that maps \`EHOSTUNREACH\` / \`EHOSTDOWN\` / \`ENETUNREACH\` / \`ECONNREFUSED\` / \`ETIMEDOUT\` to \`Local device unreachable at \:6668\` instead of the generic \`Local poll socket error\` > - oversized socket error messages are truncated at 160 chars: Tuya lib parser errors ("Prefix does not match: \") embed the whole raw TCP buffer in the message, printing multi-kB log lines when a chatty device bursts coalesced frames > \- Cloud device pagination (\`tuya.loadDevices.js\`): > - \`MAX\_DEVICE\_PAGES\` safety cap (100 pages ≈ 10 000 devices) on the recursive pagination: a misbehaving upstream that keeps returning full non-empty pages with \`has\_more=true\` now stops with a warning instead of recursing forever; no change for normal accounts > \- Cloud device detail loading (\`tuya.loadDeviceDetails.js\`): > - null-safe access on fulfilled Tuya responses before reading \`.result\`, so a successful settled result with a missing \`value\` no longer throws > \- Local scan resilience (\`tuya.localScan.js\`): > - duplicate device packets no longer overwrite previously discovered \`ip\` / \`version\` / \`productKey\` with sparse values (the richer prior entry is preserved) > \- Cloud account validation (\`tuya.connect.js\`): > - empty response from the Tuya validation endpoint now maps to \`TUYA\_APP\_ACCOUNT\_UID\_INVALID\` instead of crashing on \`.success\` > \- Dead code removal (\`tuya.convertDevice.js\`): dropped an unused \`name\` assignment in the thing-model group building (never read by \`convertFeature\`) > > \### Tester feedback (post #90) > > \- \*\*Not-configured banner on the Devices page\*\*: the integration landing page now shows the same warning as the discover page (text + inline link to the setup page) when the cloud credentials are missing. The condition uses the \`configured\` field of \`GET /api/v1/service/tuya/status\` (credentials presence) rather than the \`not\_initialized\` status, which is also used after a manual cloud disconnect. > \- \*\*Wording\*\*: the partial-support GitHub-issue button now reads "Proposer des fonctionnalites" / "Suggest new features" / "Neue Funktionalitaten vorschlagen". > > \### Tests & coverage > > \- 29 tests added for the degraded backoff: > - 19 unit tests on \`tuya.degraded.js\` (every public helper, every threshold, the forced-record path, both fallback branches) > - 6 integration tests across \`tuya.poll\`, \`tuya.setValue\`, \`TuyaController\` (skip when degraded, record on failure, clear on success, reset on manual poll, \`GET /local-status\` in all 4 modes) > \- 12 coverage-cleanup tests for \`tuya.config.buildConfigHash\`, \`tuya.report.mergeTuyaReport\` carry-forward paths, \`TuyaController.saveConfiguration\` and \`req.body\` defaults > \- Follow-up tests: pagination safety cap, forced degraded record, socket error truncation > \- Coverage on \`services/tuya/\*\*\`: \*\*100% patch coverage\*\* (codecov) > > \## Notes > > \- This is the follow-up hardening PR on top of \`tuya-v2-smart-meter-support\` (#2470). The previously broader scope (cloud shadow reads, Smart Meter detection, GitHub issue flow, etc.) has been absorbed by the upstream stack now that PR3, PR4 and PR5 carry their own review fixes baked in. > \- The degraded-local map lives only in process memory — Gladys restart resets all backoffs (intentional: a power-cycled or unplugged device should not be permanently blocked from local mode by a stale entry). > \- The current implementation exposes a single \`'degraded'\` status. The API field \`status\` is forward-compatible: an \`'unreachable'\` value can be added later for devices that fail recovery across multiple backoff cycles, without API break. Same goes for per-user-tunable thresholds (currently constants in \`tuya.degraded.js\`) and persistence across restarts (could go through the Tuya gladys variables namespace if real-world need emerges). > \- Downstream in the stack, PR6-Bis (#2595) builds its persistent-connection fallback on top of this backoff. > > > \## Summary by CodeRabbit > > \* \*\*New Features\*\* > \* Local network discovery, polling and direct control for Tuya devices with protocol selection. > \* GitHub issue creation workflow for devices with partial support. > \* Expanded cloud vs. local setup UI with new labels, help text and validation messages (DE/EN/FR). > > \* \*\*Improvements\*\* > \* Richer device metadata & feature mappings, including improved handling of partial/unknown features. > \* Enhanced connection status reporting, manual disconnect and automatic reconnect behavior. > \* Expanded test coverage and fixtures for Tuya flows. Danke!! [Vorherige Seite](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983.md?page=3) [Nächste Seite](https://community.gladysassistant.com/t/tuya-integration-chauffage-et-climatiseur/9983.md?page=5)