Bonjour,
Je souhaite savoir facilement à quelle heure à été ouverte ma porte d’entrée.
Est-ce qu’il y aurait une autre façon de faire ?
Salut,
je pense qu’un historique peut être pratique, mais pas va bien plus loin que le besoin que j’avais formulé.
En y réfléchissant, je me dis que si l’on affiche sous / à côté / … la date du dernier changement d’état (donc que ma porte passe de ouverte à fermé, ou l’inverse) ça serait assez simple, et générique pour n’importe quel capteur binaire.
C’est pas mal ! Surtout que c’est déjà quelque chose qu’on fait pour les capteurs de mouvements, et pour le widget « Utilisateurs présents » :
Bonjour, est-ce que cette évolution sera prise en compte ? Merci
Salut @NineStars
Est-ce qu’il y a un point en particulier qui t’intéresse ?
Pour être honnête, la demande n’est pas très claire en l’état. Le titre ne permet pas vraiment de comprendre ce qui est attendu, donc ce n’est pas très “actionnable”, surtout quand on parcourt la liste sans entrer dans chaque sujet (il y a déjà 234 demandes en attente
L’idéal, c’est que le titre suffise à lui seul pour comprendre le développement souhaité. Et si tu as plusieurs idées, n’hésite pas à créer plusieurs demandes distinctes
Merci pour tes retours en tout cas !!
Salut @pierre-gilles , je pensais que ton commentaire précédent rendait la demande suffisamment claire. Je vais renommer le topic
Top, est-ce que tu pourrais remplacer ton premier message par l’image que tu as mise dans le dernier message avec une explication ?
Je supprimerais toutes les autres discussions pour que ce soit clair !
Salut tout le monde !
Ce sujet est désormais en cours de développement .
Une PR a été ouverte pour afficher la date du dernier changement d’état des capteurs binaires :
master ← claude/binary-last-change-date
ouvert 02:32AM - 16 Aug 26 UTC
Implements feature request: https://community.gladysassistant.com/t/capteur-bina… ire-afficher-la-date-du-dernier-changement-detat/10151
### Description
A binary chart is useless to know *when* a front door was last opened: a door opens for 10 seconds, which is an invisible spike at any chart scale (and reading it requires clicking at the right pixel).
This PR adds what was asked on the forum: a per-box option, **"display the date of the last state change"**, which shows under the state of every binary sensor of a `devices` / `devices in room` box the date at which this state was reached — as a relative time, like the "Users present" widget already does. It is generic: any read-only binary feature (opening sensor, motion sensor, presence, leak, smoke, lock…) benefits from it, and it stays configurable, off by default.
**Why not `last_value_changed`?** Because it is not the last *change*: it is refreshed on every state report, even when the device re-publishes the value it already had — this is exactly the bug #2871 fixed by removing the "last motion" date from motion sensors. The only source of truth for a real value change is the state history, where a change is a state whose value differs from the value of the state right before it. That is what this PR reads.
**Server**
- New `device.getLastStateChanges(deviceFeatureSelectors)` (`server/lib/device/device.getLastStateChanges.js`): resolves, for each requested feature, the date of its last real value change, using a `LAG(value) OVER (PARTITION BY device_feature_id ORDER BY created_at)` window function on `t_device_feature_state`.
- Features that are unknown or that do not keep history are simply left out of the response; a feature whose value never changed in its history is returned as `null`.
- The query runs over progressively widening lower time bounds (1 h → 1 day → 7 days → 30 days → 365 days → unbounded), stopping as soon as every feature has an answer. This follows the same reasoning as `device.getDeviceStatesHistory`: states of all features are interleaved in time order, so a `created_at >= ?` bound lets DuckDB prune old row groups with its zone maps, and the common case (a door opened today) is answered by the first, cheapest query. Windows are anchored on the most recent activity of the requested features so stale devices do not burn every narrow window.
- New authenticated route `GET /api/v1/device_feature/last_state_changes?device_feature_selectors=a,b` returning `{ "<selector>": "<date>" | null }`.
**Front**
- New checkbox in the box editor of both the `devices` and `devices in room` boxes (shared `DisplayLastStateChangeOption` component), stored as `display_last_state_change` in the box config.
- `DevicesBox` fetches the dates only when the option is enabled and only for read-only binary features, and refreshes them live over the websocket — but only when the new value actually differs from the displayed one, so a sensor re-publishing the same value never resets the displayed date.
- `SensorDeviceFeature` renders the relative date under the state, or "No state change recorded" when the history holds no change.
- New i18n keys added to `en`, `fr` and `de`.
## Forum
Forum: https://community.gladysassistant.com/t/capteur-binaire-afficher-la-date-du-dernier-changement-detat/10151
### Checklist
- [x] Tests pass: `cd server && npm test` — the only failures are the ~17 pre-existing environment failures of this sandbox (gateway backup/restore needing the `sqlite3` CLI, Docker/network tests); nothing touched by this PR fails. New tests: `server/test/lib/device/device.getLastStateChanges.test.js` (10 cases, 100 % statement/branch/line coverage on the new lib file, verified locally with `c8`) and two new cases in `server/test/controllers/device/device.controller.test.js` for the new route. Cypress was not run (no browser binary available in the sandbox); no existing spec under `front/cypress/e2e/` covers the devices boxes.
- [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 — the option is off by default and no existing behavior changes when it is off.
---
⚠️ This pull request was opened by an automated Claude Code run. It needs a human review before merging: please check the behavior on real devices (in particular the widening-window query on a large history) before shipping it.
---
_Generated by [Claude Code](https://claude.ai/code/session_01BRdJPgpjHkz9LKu39n8fm8)_
## Summary by CodeRabbit
* **New Features**
* Added an option to display when read-only binary sensor values last changed.
* Device dashboards now show relative last-change times, with a fallback when unavailable.
* The setting is available when configuring device-in-room dashboards.
* Added localized English, German, and French text.
* **Bug Fixes**
* Repeated identical sensor readings are no longer treated as state changes.
* Last-change timestamps now accurately reflect actual value changes and remain current with live updates.
N’hésitez pas à suivre la PR, à tester dès que possible et à faire vos retours ici.
).