Hello,
I would like to easily know at what time my front door was opened.
For that I created a binary graph displaying the value of my door sensor, but I don’t find it great.
First, the graph does what it’s told: it shows my sensor’s state over time, except a door opens and closes in 10s, so at the graph’s scale (at best 1h) you hardly see anything (just a spike, sometimes narrower than 1 pixel).
And it’s not very quick to access: I saw that I can click the graph to get more detail, but it’s still cumbersome (you have to click in the right spot, etc.)
Is there another way to do this?
Otherwise, wouldn’t it be possible to create a « door-type object » to manage this?
I’m opening the question
Hi,
I think a history can be useful, but it doesn’t go much further than the need I had described.
On reflection, I think that if we display under / next to / … the date of the last state change (i.e., when my door changes from open to closed, or vice versa) it would be quite simple, and generic for any binary sensor.
It could be offered in the dashboard editor, when displaying a binary state with a checkbox « show date of last change », for example if we want to make it configurable
That’s not bad! Especially since it’s already something we do for motion sensors, and for the « Users present » widget:
Hello, will this update be taken into account? Thanks
Hi @NineStars
Is there a specific point that interests you?
To be honest, the request isn’t very clear as it stands. The title doesn’t really help understand what is expected, so it’s not very « actionable », especially when browsing the list without going into each topic (there are already 234 pending requests ).
Ideally, the title should be enough on its own to understand the desired development. And if you have several ideas, don’t hesitate to create several separate requests
Thanks for your feedback anyway!!
Hi @pierre-gilles , I thought your previous comment made the request clear enough. I’ll rename the topic.
Sure, could you replace your first message with the image you posted in the last message along with an explanation?
I would delete all other discussions to make it clear!
Hi everyone!
This topic is now in development .
A PR has been opened to display the date of the last state change of binary sensors:
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.
Don’t hesitate to follow the PR, test as soon as possible, and give your feedback here.
Hi thanks!
The motherboard of my Intel NUC had fried, I received its replacement yesterday, I’ll be able to try out this new feature quickly