Hallo,
Ich möchte gerne einfach herausfinden, zu welcher Uhrzeit meine Haustür geöffnet wurde.
Dazu habe ich ein binäres Diagramm erstellt, das den Zustand meines Türsensors anzeigt, aber ich finde das nicht so toll.
Erstens macht das Diagramm, was man ihm sagt: Es zeigt den Zustand meines Sensors im Zeitverlauf an, aber eine Tür öffnet und schließt sich in 10 Sekunden, daher sieht man auf der Skala des Diagramms (im besten Fall 1 Stunde) fast nichts (nur einen Peak, manchmal schmaler als 1 Pixel).
Und zweitens ist es nicht sehr schnell zugänglich, ich habe gesehen, dass ich auf das Diagramm klicken kann, um mehr Details zu erhalten, aber das bleibt mühsam (man muss an die richtige Stelle klicken usw.)
Gibt es eine andere Möglichkeit, das zu tun?
Oder gäbe es nicht ein „Objekt vom Typ Tür“, das man erstellen könnte, um das zu verwalten?
Ich öffne die Frage
Hallo,
ich denke, dass ein Verlauf praktisch sein kann, aber nicht viel weiter geht als das Bedürfnis, das ich formuliert habe.
Wenn ich darüber nachdenke, sage ich mir, dass, wenn man unter / neben / … das Datum der letzten Zustandsänderung anzeigt (also ob meine Tür von offen auf geschlossen oder umgekehrt wechselt), das ziemlich einfach und generisch für jeden binären Sensor wäre.
Das könnte in der Dashboard-Bearbeitung angeboten werden, wenn man einen binären Zustand anzeigt, mit einem Kontrollkästchen „Datum der letzten Änderung anzeigen“ zum Beispiel, wenn man die Sache parametrierbar machen möchte
Das ist nicht schlecht! Vor allem, weil wir das bereits für Bewegungsmelder und für das Widget „Anwesende Benutzer“ machen:
Hallo, wird diese Entwicklung berücksichtigt? Danke
Hallo @NineStars
Gibt es einen bestimmten Punkt, der dich interessiert?
Um ehrlich zu sein, ist die Anfrage im Moment nicht sehr klar. Der Titel lässt nicht wirklich erkennen, was erwartet wird, daher ist er nicht sehr „umsetzbar“, besonders wenn man die Liste durchgeht, ohne in jedes Thema einzusteigen (es gibt bereits 234 offene Anfragen ).
Idealerweise sollte der Titel allein ausreichen, um die gewünschte Entwicklung zu verstehen. Und wenn du mehrere Ideen hast, zögere nicht, mehrere separate Anfragen zu erstellen
Danke auf jeden Fall für dein Feedback!!
Hallo @pierre-gilles , ich dachte, dein vorheriger Kommentar hätte die Anfrage klar genug gemacht. Ich werde das Thema umbenennen.
Super, könntest du bitte deine erste Nachricht durch das Bild ersetzen, das du in der letzten Nachricht gepostet hast, und eine Erklärung hinzufügen?
Ich würde alle anderen Diskussionen löschen, damit es klar ist!
Hallo zusammen!
Dieses Thema ist nun in Entwicklung .
Ein Pull Request wurde erstellt, um das Datum der letzten Statusänderung der binären Sensoren anzuzeigen:
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.
Folgt dem Pull Request, testet ihn so früh wie möglich und gebt hier euer Feedback.
Hallo danke!
Das Mainboard meines Intel NUCs ist durchgebrannt, ich habe den Ersatz gestern erhalten, ich kann diese Neuheit also bald ausprobieren