Quand on ajoute un appareil Zigbee ou MQTT, il est possible pour chaque fonctionnalité de l’appareil de définir si on veut conserver l’historique ou non :
Dans l’intégration Zigbee2Mqtt :
Dans l’intégration Appareils Virtuels Mqtt :
Ce n’est pas possible pour les appareils créés par les intégrations externes. Ce serait utile de pouvoir le faire.
Salut tout le monde !
Ce sujet est désormais en cours de développement .
Une PR a été ouverte pour permettre de configurer la conservation de l’historique par fonctionnalité sur les appareils des intégrations externes :
master ← claude/external-integration-keep-history
ouvert 02:30AM - 18 Aug 26 UTC
Implements feature request: ``https://community.gladysassistant.com/t/pouvoir-co… nfigurer-la-conservation-ou-non-des-appareils-des-integrations-externes``/10615
### Description
Devices created by external integrations did not expose the per-feature "keep state history" toggle that Zigbee2mqtt and the MQTT virtual devices already offer, so a user had no way to stop storing the history of a feature published by an external integration.
**Frontend** — the Devices screen of an external integration (`front/src/routes/integration/all/external-integration/device-page/`) now shows the standard "Keep state history?" switch for each feature of a device card. It is the only editable part of a feature published by an integration (name, category, type, unit and bounds stay the integration's), and saving goes through the standard `POST /api/v1/device`, which purges the stored history of a feature that was just switched off — exactly as for an internal service. Text features carry no switch: a string state is never historized (same rule as the MQTT device screen). No new translation key: the existing `editDeviceForm.keepHistory*` labels are reused.
**Server** — a UI toggle that gets wiped on the next sync would be useless, so the user's choice is now preserved across re-publications. `externalIntegration.getDiscoveredDevices` reinjects the `keep_history` stored in DB over the published value on every feature of an already-created device (matched by `external_id`), the same way the energy features and the energy pipeline params are already reinjected. The "Update" gesture of the Discovery screen therefore applies the new structure without silently restoring the integration's default. `keep_history` stays out of the structure signature, so a value flipped by a new integration version is not a structural change and does not push the user to update.
**Spec** — `docs/specs/external-integrations.md` is updated in the same diff (C.3 republication rules and the B.8 Devices screen row), as required by `AGENTS.md` for any change to an external-integration behavior.
New tests: `server/test/lib/external-integration/externalIntegration.keepHistory.test.js` (6 tests covering the published default, the user choice winning, a feature not created yet, `structure_changed` unaffected, and the in-memory published list left untouched).
This PR was created by an automated Claude Code run.
## Forum
Forum: ``https://community.gladysassistant.com/t/pouvoir-configurer-la-conservation-ou-non-des-appareils-des-integrations-externes``/10615
### Checklist
- [x] Tests pass: `cd server && npm test` (full suite green; the new lines of `externalIntegration.getDiscoveredDevices.js` are 100% covered). Cypress was not run: the binary is not installed in this environment.
- [x] Linter and prettier pass on both front and server (`npm run eslint`, `npm run prettier` / `prettier-check`), plus `npm run compare-translations` and `npm run build` on the front
- [x] No undocumented breaking change
---
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---
_Generated by [Claude Code](https://claude.ai/code/session_01YXRz5JiaM9N42djviseBRu)_
N’hésitez pas à suivre la PR, à tester (optionnel, surtout pour les petites demandes) et à faire vos retours ici si besoin.
