Hola ,
Me gustaría saber fácilmente a qué hora se abrió mi puerta de entrada.
Para ello, he creado un gráfico binario que muestra el valor de mi sensor de apertura, pero no me parece muy útil.
Primero, el gráfico hace lo que se le dice: muestra en función del tiempo el estado de mi sensor, pero una puerta se abre y se cierra en 10 segundos, por lo que a la escala del gráfico (lo mejor es 1 hora) casi no se ve nada (solo un pico, a veces menos ancho que 1 píxel).
Y luego no es muy rápido de acceder, he visto que puedo hacer clic en el gráfico para obtener más detalles, pero sigue siendo laborioso (hay que hacer clic en el lugar correcto, etc).
¿Habría otra forma de hacerlo?
De lo contrario, ¿no habría un “objeto tipo puerta” que podríamos crear para gestionarlo?
Abro la pregunta
Hola,
creo que un historial puede ser útil, pero no va mucho más allá de la necesidad que había formulado.
Al pensarlo, me digo que si mostramos debajo / al lado / … la fecha del último cambio de estado (es decir, que mi puerta pase de abierta a cerrada, o al revés) sería bastante simple y genérico para cualquier sensor binario.
Podría proponerse en la edición del panel de control, cuando se muestra un estado binario con una casilla de verificación « mostrar la fecha del último cambio » por ejemplo si se quiere hacer el asunto configurable
¡No está mal! Sobre todo porque ya es algo que hacemos para los sensores de movimiento y para el widget « Usuarios presentes »:
Hola, ¿se tendrá en cuenta esta evolución? Gracias
¡Hola @NineStars !
¿Hay algún punto en particular que te interese?
Para ser honesto, la solicitud no está muy clara en este momento. El título no permite realmente entender lo que se espera, por lo que no es muy “actionable”, especialmente cuando se recorre la lista sin entrar en cada tema (ya hay 234 solicitudes pendientes ).
Lo ideal es que el título sea suficiente por sí solo para entender el desarrollo deseado. Y si tienes varias ideas, no dudes en crear varias solicitudes distintas
¡Gracias por tus comentarios de todos modos!!
Hola @pierre-gilles , creía que tu comentario anterior hacía la solicitud lo suficientemente clara. Voy a renombrar el tema
¡Genial! ¿Podrías reemplazar tu primer mensaje con la imagen que pusiste en el último mensaje junto con una explicación?
¡Eliminaría todas las demás discusiones para que quede claro!
¡Hola a todos!
Este tema ahora está en desarrollo .
Se ha abierto una PR para mostrar la fecha del último cambio de estado de los sensores binarios:
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.
No duden en seguir la PR, probarla tan pronto como sea posible y dar sus comentarios aquí.
¡Hola, gracias!
La placa base de mi Intel NUC se quemó, recibí su reemplazo ayer, podré probar rápidamente esta novedad