Request for integration with Tuya

pierre-gilles · June 26, 2026, 3:05pm

What is the « Index export » feature?

Terdious · June 27, 2026, 8:42pm

This is the index of energy reinjected into the grid, i.e. the solar production surplus that is sent back. On Tuya, this corresponds to the reverse energy total.

« Export » for export to the grid.

pierre-gilles · June 29, 2026, 8:53am

Ok, I left a comment

github.com/GladysAssistant/Gladys

Tuya - Smart Meter (cloud+local) + Thing Model strategy + fixture harness - PR5 (#2470#pullrequestreview-4590274661)

master ← Terdious:tuya-v2-smart-meter-support

ouvert 01:16PM - 28 Feb 26 UTC

Terdious

+2841 -155

### 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 - 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.

Terdious · June 30, 2026, 7:21pm

It’s done @pierre-gilles, thanks to you!!

Terdious · July 2, 2026, 6:10pm

Hi @GBoulvin

I’ve made progress on several Tuya devices (up to PR10) and I’d like us to do a full validation pass, both locally AND in the cloud, before merging. I’ve pushed a test Docker image reusing the previous one so you can directly chain as if you were moving to the new version from your current test database (don’t hesitate to restart it once before updating the image to refresh the states and compare):

Test Image: terdious/gladys:tuya-smart-meter

Could you check the following points (tick local + cloud each time)? I indicate what works on my side.

#	Device to test	Local	Cloud	At my place (Terdious)
Base	What already worked (PR1/PR4) — see your previous report	☐	☐	my plug still works perfectly (protocol v3.3)
PR5 (#2470)	Smart Meter	☐	☐	I don’t have one
PR7 (#2476)	LSC Power Plug	☐	☐	I don’t have one
PR8 (#2478)	Thermostat controller	☐	☐	my 2 thermostats work well (v3.5)
PR9 (#2591)	Air conditioner	☐	☐	my Airton air conditioners OK (2 in v3.3, 1 in v3.5)
PR10 (#2594)	Video doorbell (settings)	☐	☐	I don’t have one

PR10 details (doorbell): for now only the 5 on/off settings (motion detection, recording, image flip, LED, OSD). Point to watch: the local poll of these P2P doorbells tends to timeout — if that’s your case, let me know, it will confirm that we stay in the cloud for this type of device. The bell and the camera will come in PR10-Bis.

Thanks a lot for the tests

Terdious · July 3, 2026, 2:17pm

Alright @pierre-gilles, on Tuya’s side, if you can, it would be great to review these 3 PRs.

PR6-Bis appeared while I was coding the doorbell device for GBoulvin, it turned out we found how to maintain a permanent connection to have live info locally.

I am therefore ready on:

github.com/GladysAssistant/Gladys

Tuya - Smart Meter (cloud+local) + Thing Model strategy + fixture harness - PR5 (#2470)

master ← Terdious:tuya-v2-smart-meter-support

ouvert 01:16PM - 28 Feb 26 UTC

Terdious

+2843 -155

### 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.

github.com/GladysAssistant/Gladys

Tuya - Add degraded-local backoff and follow-up hardening pass - PR6 (#2471)

master ← Terdious:tuya-follow-up-hardening

ouvert 02:55PM - 01 Mar 26 UTC

Terdious

+4396 -191

### 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. ## Scope Scope vs the immediate parent branch in the stack (`tuya-v2-smart-meter-support`, PR #2470): | Area | Insertions | Deletions | |---|---:|---:| | `server/services/tuya` (prod) | +241 | -14 | | `server/test/services/tuya` (tests) | +1242 | -25 | | `front/src/routes/integration/all/tuya` (prod) | +77 | -7 | | `front/src/config/i18n` (translations) | +6 | -3 | | **Total (37 files)** | **+1566** | **-49** | 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 <ip>: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: <hex>") 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`) ### 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.

github.com/GladysAssistant/Gladys

Tuya - Persistent local connection (real-time push) - PR6-Bis (#2595)

master ← Terdious:tuya-persistent-local-push

ouvert 08:39PM - 02 Jul 26 UTC

Terdious

+5807 -231

### Pull Request check-list - [x] If your changes affect the code, did you writ…e 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? ### Description of change ## Summary - Add a **persistent local connection** for Tuya devices configured in local mode (`LOCAL_OVERRIDE=true`): keep a long-lived socket open per device and receive **pushed DP updates in real time** (`data` / `dp-refresh`) instead of only one-shot polling. - This unlocks **event-like features** (e.g. a doorbell ring) and **real-time states** for mains-powered devices, while battery / asleep / offline devices **gracefully fall back to the scheduled poll** — the split is **driven by connection behavior**, no battery flag needed. - Connections follow the **device lifecycle**: they are (re)opened on device create/update and torn down on delete, via the DeviceManager `postCreate`/`postUpdate`/`postDelete` hooks. - **Continuous sensors are throttled** on the push path (one state per 10 s per feature) so a chatty running device does not flood the DB — event-like features stay instantaneous. - Layered on top of PR6's degraded-local backoff (hence "PR6-Bis"), so PR7→PR10 inherit it via cascade-merge. ## Scope Compared to `tuya-follow-up-hardening` (PR6, #2471): | Area | Insertions | Deletions | |---|---:|---:| | `server/services/tuya` (prod) | +667 | -41 | | `server/test/services/tuya` (tests) | +745 | 0 | | **Total (11 files)** | **+1412** | **-41** | ## Details - **`tuya.persistentConnection.js`** (new): per-device connection manager — connect + listen (`connected`/`data`/`dp-refresh`/`disconnected`/`error`), a push handler that **reuses the exact poll pipeline** (`emitLocalDpsStates`, single source of truth shared with the scheduled poll), bounded reconnect (3 tries, 3s/10s/30s) wired to the `degraded` backoff, a health/staleness check and `recyclePersistentConnection` for stale sockets. - **`issueRefreshOnPing`**: each heartbeat (~10s on 3.3 / ~25s on 3.5) pulls the current state over the **same open socket**, so idle devices stay fresh **locally** and the poll skips entirely instead of hitting the cloud. - **Single local session per device is respected** (Tuya allows only one). `setValue` sends the command **through the open persistent socket**; `poll` skips the local read while the socket is healthy. Priority for a local device: **persistent → local poll → cloud**. - **Device lifecycle hooks** (`postCreate` / `postUpdate` / `postDelete` on the handler, called by the core DeviceManager `device.notify`): pushed DPS are mapped against the device attached to the connection, so an update that adds features would silently drop their pushed states with a stale connection. Create/update now recycles the connection with the fresh device (also covering local mode being switched on or off by the update), delete tears it down, and a newly created local device gets its connection immediately instead of at the next restart. - **Continuous-sensor push throttle**: a running device can push several DP updates per second (e.g. an AC ambient sensor flapping between 23 and 24 °C), flooding the DB/websockets/scene triggers with states the 10s poll used to naturally cap. Push-driven emissions of continuous sensors (measured temperature, power, energy, indexes, voltage, current) are capped at one per 10 s per feature, as a DPS pre-filter in `handlePushedDps` — event-like features (switches, doorbell, modes, target temperature) remain instantaneous and the poll path is unchanged. - **Log hygiene**: persistent socket error messages are truncated at 160 chars (the newgen lib parser embeds the whole raw TCP buffer in `Prefix does not match` errors when a chatty device bursts coalesced 3.5 frames). - **Decoupled from the cloud**: started in `init()`, torn down on the **service `stop()`** (not on a cloud `disconnect()`), so local control keeps working even when the Tuya cloud is disconnected. - **Kill-switch**: `TUYA_PERSISTENT_PUSH_ENABLED` (default enabled). ## Tests Unit tests cover: connect → healthy, pushed `data`, partial `dp-refresh`, bounded reconnect → `failed`, protocol 3.4/3.5 routing, kill-switch off, teardown, recycle, `sendCommandViaPersistentConnection`, the poll coexistence gate (skip local when connected/healthy, cloud refresh when connected-but-silent, normal local otherwise), the lifecycle hooks (postCreate opens, postUpdate recycles with the fresh device, postUpdate stops when local config is removed, postDelete stops, non-Tuya external ids are ignored), the continuous-sensor throttle (fake timers: capped within the window, passes after it, no throttle without an entry) and the socket error truncation. ## Notes - Sits on top of the whole Tuya stack (PR3→PR6). Propagated to PR7→PR10 by cascade-merge. - Follow-ups: cloud **Pulsar Message Service** push (for battery / cloud-only setups) is a later PR (PR11), which will also cover global connection management — including a flapping detector for devices that keep dropping their persistent socket (N disconnects in M minutes → poll-only cooldown; today a successful reconnect resets the retry counter so flapping never reaches the `failed` fallback). - Runtime-validated on mains smart sockets, pilot-wire thermostats and air conditioners (local `setValue` ~1-2s, on par with the SmartLife app; real-time state via push; poll skipped; app-side state changes fed back instantly). ## Summary by CodeRabbit * **New Features** * Added Tuya smart-meter support with expanded energy sensors, including “Export index”. * Enhanced Local Mode with a “degraded/unstable” warning (showing an “until” time) and automatic cloud fallback. * Enabled real-time persistent local push updates for supported Tuya devices (when enabled). * **Bug Fixes** * Preserved device/feature mappings across partial refreshes; hardened discovery ranking/sorting and local scan/poll fallbacks. * Improved error reporting during status checks and more reliable local-device rebuild/carry-forward after polling. * **Documentation** * Updated EN/DE/FR translations and UI wording for Tuya Local Mode and energy categories.

All the following ones up to PR10 are also ready, only the tests are missing for PR7 and PR10. PR8 and PR9 are tested on my side with at least 2 types of corresponding devices each.

pierre-gilles · July 3, 2026, 2:34pm

PR5 is ok and merged, can you update PR6 with master?

Terdious · July 3, 2026, 4:21pm

PR6 update

Terdious · July 3, 2026, 5:57pm

@GBoulvin (We’re starting to think it’s harassment… I’m sorry ^^ just let me know if it’s too much ),

After the tests requested in the post Tuya : Intégration chauffage et climatiseur - #85 par Terdious, could you continue with the doorbell for additional tests?
I’ve prepared (with my Glaude of course ^^) a small diagnostic view to try to retrieve everything in one go ^^ on your doorbell (and see others along the way like your cameras if you can)
For this second pass, this time it will be a new Docker image that I provide (you can start from the same database, no need to start from scratch): docker pull terdious/gladys:tuya-diag-video-doorbell-support.

What’s new: a « Diagnostic » page in the Tuya integration

This image includes a temporary diagnostic page, solely intended for debugging (it will be removed before the final PR — don’t be surprised by its « lab tool » side). You will find it directly in Integrations → Tuya → Diagnostic (left menu), or via the « Diagnostic » button on a device card.

What you will see (see my screenshots):

A device selector at the top: « All devices » for the overall flow, or a specific device. When a device is selected, a status line is displayed (protocol, IP, persistent connection, degraded state).
**« Feature values (live) »: 3 sections — Supported, Not supported and Ignored — with for each feature its Tuya code, its local DP, its cloud path, the raw value received from the device (with its origin: local push / cloud, and the time), and the Gladys transformed value. Each raw value has its small copy button, and the **« Copy content » button copies the entire card in Markdown.
**« Live events »: the service log in real-time (connections, DPS pushed by the device with their raw payload, reads, commands, errors), filterable by level and by text, with pause and **« Copy content » also.

What we expect from you with your doorbell

The goal: capture the raw payloads that your doorbell sends when it rings or detects motion — that’s what we’re missing to implement the display of photo snapshots in Gladys.

Open the Diagnostic page and select your doorbell from the list.
Press the doorbell button (real ring), and if possible also trigger a motion detection by passing in front.
Leave the page open for a few moments, then:

**« Copy content » of the Live events card → paste the result here (we are especially looking for the push_dps events with the DP 136 (doorbell_active), 154 (doorbell_pic) and 115 (movement_detect_pic));
**« Copy content » of the Feature values card → paste it too (the Not supported / Ignored sections should show the raw values of the photo DP).

Check at the same time that the ring is reported in Gladys: this image adds a « Doorbell » feature (button) on your doorbell — after a real ring, you should see an event in its history, and be able to use it as a scene trigger. Let us know if it « ghosts » (trigger without press) or if a press is not reported.

Your doorbell is battery-powered, so it sleeps most of the time: it’s normal if it appears disconnected between two events. The important thing is to ring/pass in front while the page is open.

If you’re in doubt about what to copy: in doubt, copy everything The photo payloads look like long base64 strings — that’s exactly what we’re looking for (they don’t contain your local key, only temporary encrypted references).

And of course, the page works for all your Tuya devices — if you see strange behavior on the outlets/other devices from previous PRs, a « Copy content » and we’ll have everything we need to investigate.
Don’t hesitate to try with your cameras as well and you can paste the contents in the corresponding issues

Thanks in advance, I’m available if needed, I’ll check the forum regularly!

Some images:

GBoulvin · July 5, 2026, 8:58pm

On the homepage, the first time, there should be a prompt saying that the service is not configured and that you need to go to the « configuration » page as in the other integrations.

For PR5, Smart Meter, everything is OK (local and cloud). However, once selected locally, the message « suggest new features » appears (I would find « features » more appropriate

PR7, LSC Power Plug in 3.5, everything is OK (local and cloud). The ‹ child Lock › has arrived!

For PR10, the doorbell is well detected in the cloud but does not poll locally. I will test the dedicated image right away.

GBoulvin · July 5, 2026, 9:15pm

Tuya device snapshot — Visiophone Wifi

selector: tuya-bf0e59548489fcb4ea62of — external_id: tuya:bf0e59548489fcb4ea62of
device_type: video-doorbell — product_id: i5e3a4qxcsthszin
protocol: - — ip: - — local_override: 0
persistent: none — degraded: no

Supported features

Feature	Code	Local DP	Cloud path	Raw input (origin)	Raw at	Gladys value	Last change
Status LED	basic_indicator	101	Indicator (dp 101) [spec.fn, spec.st, model, shadow]	true (cloud)	2026-07-05T21:12:48.132Z	1	2026-07-05T21:12:17.898Z
Image flip	basic_flip	103	Vision Flip (dp 103) [spec.fn, spec.st, model, shadow]	false (cloud)	2026-07-05T21:12:48.132Z	0	2026-07-05T21:12:17.898Z
On-screen display	basic_osd	104	OSD Watermark (dp 104) [spec.fn, spec.st, model, shadow]	true (cloud)	2026-07-05T21:12:48.132Z	1	2026-07-05T21:12:17.898Z
Motion detection	motion_switch	134	Motion Alert (dp 134) [spec.fn, spec.st, model, shadow]	true (cloud)	2026-07-05T21:12:48.132Z	1	2026-07-05T21:12:17.898Z
Doorbell	doorbell_active	136	Doorbell Active (dp 136) [spec.st, model, shadow]	(cloud)	2026-07-05T21:12:48.132Z	null	-
Recording	record_switch	150	Record Switch (dp 150) [spec.fn, spec.st, model, shadow]	true (cloud)	2026-07-05T21:12:48.132Z	1	2026-07-05T21:12:17.898Z

Unsupported (raw only)

Feature	Code	Local DP	Cloud path	Raw input (origin)	Raw at	Gladys value	Last change

Ignored

Feature	Code	Local DP	Cloud path	Raw input (origin)	Raw at	Gladys value	Last change
sd_format_state	sd_format_state	-	Formatted State (dp 117) [spec.st, model, shadow]	-20000 (cloud)	2026-07-05T21:12:48.132Z	-	-
sd_status	sd_status	-	Memory Card Status (dp 110) [spec.st, model, shadow]	5 (cloud)	2026-07-05T21:12:48.132Z	-	-
motion_sensitivity	motion_sensitivity	-	Motion Sensitivity (dp 106) [spec.fn, spec.st, model, shadow]	1 (cloud)	2026-07-05T21:12:48.132Z	-	-
record_mode	record_mode	-	Recording Mode (dp 151) [spec.fn, spec.st, model, shadow]	2 (cloud)	2026-07-05T21:12:48.132Z	-	-
basic_nightvision	basic_nightvision	-	Night Vision (dp 108) [spec.fn, spec.st, model, shadow]	0 (cloud)	2026-07-05T21:12:48.132Z	-	-
basic_device_volume	basic_device_volume	-	Device Volume Control (dp 160) [spec.fn, spec.st, model, shadow]	10 (cloud)	2026-07-05T21:12:48.132Z	-	-
sd_storge	sd_storge	-	Get Memory Card Capacity (dp 109) [spec.st, model, shadow]	100	0	100 (cloud)	2026-07-05T21:12:48.132Z
sd_format	sd_format	-	Format Memory Card (dp 111) [spec.fn, spec.st, model, shadow]	false (cloud)	2026-07-05T21:12:48.132Z	-	-
doorbell_pic	doorbell_pic	-	Someone ring doorbell (dp 154) [spec.st, model, shadow]	(cloud)	2026-07-05T21:12:48.132Z	-	-
movement_detect_pic	movement_detect_pic	-	Motion Detected (dp 115) [spec.st, model, shadow]	eyJidWNrZXQiOiJ0eS1ldS1zdG9yYWdlMzAtcGljIiwiZmlsZXMiOltbIi8xNzYwNzMtMTYxODY5NDE2LXBwMDFiZjAwZWI2YTFhOTZjZDUwL2RldGVjdC8xNzgzMjg1ODQzLmpwZWc/cGFyYW09YUJyTFFoc1RvZVBqMzdWMHVCOWo5MHpoNVZzOEx2UGhSTHpZTklERGtjQT0iLCIiXV0sInYiOiIzLjAifQ== (cloud)	2026-07-05T21:12:48.132Z	-	-

2026-07-05T21:12:48.133Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:12:17.897Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:11:47.907Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:11:17.901Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:10:47.852Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:10:17.896Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:09:47.927Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:09:17.892Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:08:51.632Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":1,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:08:50.566Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[set_sent\] Command sent via cloud (motion_switch)
2026-07-05T21:08:50.324Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[set_command\] Command motion_switch -> true {"command":"motion_switch","value":1,"transformed":true}
2026-07-05T21:08:47.924Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:08:22.928Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:07:47.891Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:07:17.935Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:06:47.920Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:06:17.900Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:05:47.847Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:05:32.328Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":5,"cloud_missing":0,"fallback":"none"}

GBoulvin · July 5, 2026, 9:39pm

Ci-dessus donc le copier-coller

J’ai activé via Gladys la détection de mouvement. C’est bien activé dans l’app et sur l’appareil.

Par contre, le tableau de bord dit :

Après détection et appui sur le bouton…

Le mode local ne veut pas fonctionner (en 3.1 : Échec de la lecture locale : Invalid local poll response: parse data error, en 3.3 : Échec de la lecture locale : Local poll timeout)

La sonnette n’est pas sur batterie (c’est un ancien modèle, alimenté en 5V)

J’ai refais un test. Appui et detection de mouvement à 23h30 et le retour dans Gladys s’est fait plus d’une minute plus tard :

2026-07-05T21:33:17.949Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:32:47.924Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:32:17.922Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:31:47.914Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:31:17.919Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:30:47.923Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:30:17.943Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:29:47.917Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:29:17.919Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:28:47.922Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:28:17.951Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:27:47.924Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:27:17.918Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:26:47.924Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:26:17.918Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:25:47.926Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:25:17.929Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:24:47.947Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:24:17.916Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:23:47.913Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:23:17.935Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:22:47.915Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:22:17.915Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:21:47.916Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:21:17.906Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:20:47.922Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:20:17.940Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:19:47.996Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:19:17.910Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:18:47.909Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:18:17.902Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:17:47.913Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:17:17.938Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:16:47.906Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:16:18.078Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:15:47.934Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:15:17.906Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:14:47.922Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:14:17.930Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:13:47.906Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:13:18.067Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:12:48.133Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:12:17.897Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:11:47.907Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:11:17.901Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:10:47.852Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:10:17.896Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:09:47.927Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:09:17.892Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:08:51.632Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":1,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:08:50.566Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[set_sent\] Command sent via cloud (motion_switch)
2026-07-05T21:08:50.324Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[set_command\] Command motion_switch -> true {"command":"motion_switch","value":1,"transformed":true}
2026-07-05T21:08:47.924Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:08:22.928Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:07:47.891Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:07:17.935Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:06:47.920Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:06:17.900Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:05:47.847Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":0,"cloud_missing":0,"fallback":"none"}
2026-07-05T21:05:32.328Z \[debug\] \[Visiophone Wifi (bf0e59548489fcb4ea62of)\] \[poll_summary\] Poll completed {"mode":"cloud","local_handled":0,"local_changed":0,"cloud_handled":6,"cloud_changed":5,"cloud_missing":0,"fallback":"none"}

Tuya device snapshot — Visiophone Wifi

selector: tuya-bf0e59548489fcb4ea62of — external_id: tuya:bf0e59548489fcb4ea62of
device_type: video-doorbell — product_id: i5e3a4qxcsthszin
protocol: - — ip: - — local_override: 0
persistent: none — degraded: no

Supported features

Feature	Code	Local DP	Cloud path	Raw input (origin)	Raw at	Gladys value	Last change
Status LED	basic_indicator	101	Indicator (dp 101) [spec.fn, spec.st, model, shadow]	true (cloud)	2026-07-05T21:33:47.927Z	1	2026-07-05T21:31:47.915Z
Image flip	basic_flip	103	Vision Flip (dp 103) [spec.fn, spec.st, model, shadow]	false (cloud)	2026-07-05T21:33:47.927Z	0	2026-07-05T21:31:47.916Z
On-screen display	basic_osd	104	OSD Watermark (dp 104) [spec.fn, spec.st, model, shadow]	true (cloud)	2026-07-05T21:33:47.927Z	1	2026-07-05T21:31:47.916Z
Motion detection	motion_switch	134	Motion Alert (dp 134) [spec.fn, spec.st, model, shadow]	true (cloud)	2026-07-05T21:33:47.927Z	1	2026-07-05T21:31:47.917Z
Doorbell	doorbell_active	136	Doorbell Active (dp 136) [spec.st, model, shadow]	(cloud)	2026-07-05T21:33:47.927Z	null	-
Recording	record_switch	150	Record Switch (dp 150) [spec.fn, spec.st, model, shadow]	true (cloud)	2026-07-05T21:33:47.927Z	1	2026-07-05T21:31:47.917Z

Unsupported (raw only)

Feature	Code	Local DP	Cloud path	Raw input (origin)	Raw at	Gladys value	Last change

Ignored

Feature	Code	Local DP	Cloud path	Raw input (origin)	Raw at	Gladys value	Last change
sd_format_state	sd_format_state	-	Formatted State (dp 117) [spec.st, model, shadow]	-20000 (cloud)	2026-07-05T21:33:47.927Z	-	-
sd_status	sd_status	-	Memory Card Status (dp 110) [spec.st, model, shadow]	5 (cloud)	2026-07-05T21:33:47.927Z	-	-
motion_sensitivity	motion_sensitivity	-	Motion Sensitivity (dp 106) [spec.fn, spec.st, model, shadow]	1 (cloud)	2026-07-05T21:33:47.927Z	-	-
record_mode	record_mode	-	Recording Mode (dp 151) [spec.fn, spec.st, model, shadow]	2 (cloud)	2026-07-05T21:33:47.927Z	-	-
basic_nightvision	basic_nightvision	-	Night Vision (dp 108) [spec.fn, spec.st, model, shadow]	0 (cloud)	2026-07-05T21:33:47.927Z	-	-
basic_device_volume	basic_device_volume	-	Device Volume Control (dp 160) [spec.fn, spec.st, model, shadow]	10 (cloud)	2026-07-05T21:33:47.927Z	-	-
sd_storge	sd_storge	-	Get Memory Card Capacity (dp 109) [spec.st, model, shadow]	100	0	100 (cloud)	2026-07-05T21:33:47.927Z
sd_format	sd_format	-	Format Memory Card (dp 111) [spec.fn, spec.st, model, shadow]	false (cloud)	2026-07-05T21:33:47.927Z	-	-
doorbell_pic	doorbell_pic	-	Someone ring doorbell (dp 154) [spec.st, model, shadow]	(cloud)	2026-07-05T21:33:47.927Z	-	-
movement_detect_pic	movement_detect_pic	-	Motion Detected (dp 115) [spec.st, model, shadow]	eyJidWNrZXQiOiJ0eS1ldS1zdG9yYWdlMzAtcGljIiwiZmlsZXMiOltbIi8xNzYwNzMtMTYxODY5NDE2LXBwMDFiZjAwZWI2YTFhOTZjZDUwL2RldGVjdC8xNzgzMjg3MDA5LmpwZWc/cGFyYW09U3dnelJjQXYzMVhOelpvV2Z0ald5aHM1ckJVN09EcXhTbWpmQld5MlpUdz0iLCIiXV0sInYiOiIzLjAifQ== (cloud)	2026-07-05T21:33:47.927Z	-	-

Voilà, en espérant que cela a pu aider…

Dans tous le cas, Merci @Terdious pour ton investissement dans le projet !

Terdious · July 6, 2026, 11:07am

Hi @GBoulvin,

A huge thank you for this test pass.

Here is the handling of each of your points:

1. « Service not configured » message on the homepage fixed You had the eye: the message only existed on the Configuration page, the Devices page (the landing page) gave no clue. This is corrected in PR6: it now displays the same type of warning as the Discovery page, with a direct link to the Tuya configuration page. You will see it in the next image.

2. Smart Meter: « propose new functions » that appears locally need you to decide Two distinct things here:

The label: corrected, the button now says « Propose features » — the goal was to shorten this text for a nicer display on smaller screen formats. But indeed, if needed, it will be part of a UI/UX review. Let’s stay consistent
The substance: in local mode, this button appears when reading the DP returns DPS that are neither managed nor intentionally ignored — so either your meter exposes DPS that the cloud does not have (and the button then does exactly its job: inviting us to add them!), or there is a matching issue. To decide, can you simply click on the button and create the issue? It precisely lists the unknown DPS. Even better if you are on the diagnostic image: select the Smart Meter on the Diagnostic page and « Copy the content » of the Feature Values card — the Unsupported section will show us these DPS with their values. Depending on the result, we will complete the meter mapping. You can also do both, open the issue and paste the diagnostics in a follow-up message.

3. PR7 (LSC Power Plug 3.5) Nothing to add: local + cloud + child lock validated — thanks to you, PR7 is now functionally validated from end to end. Thank you!

Topic		Replies	Views
Prises en charge des devices avec l'application Smartlife/tuya [Archive] Demande de fonctionnalités feature-integration , tuya	100	6289	July 10, 2023
Détection de présence via le réseau local [Archive] Demande de fonctionnalités feature-integration , capteur-présence	148	5127	May 13, 2023
Broadlink service Développement feature-integration	84	2161	May 17, 2024
[TP-Link] Développement nouveau service Développement	56	2569	January 14, 2022
THR320 Sonoff Tasmota - résolution problèmes Configuration	26	1883	October 4, 2022

Request for integration with Tuya

What’s new: a « Diagnostic » page in the Tuya integration

What we expect from you with your doorbell

Tuya device snapshot — Visiophone Wifi

Supported features

Unsupported (raw only)

Ignored

Tuya device snapshot — Visiophone Wifi

Supported features

Unsupported (raw only)

Ignored

Related topics