Ich würde gerne eine Kamera (per Knopfdruck oder noch besser auch über eine Szene) deaktivieren, ohne sie zu löschen.
Anwendungsfall:
Im Winter werden die Kameras an den Nistkästen deaktiviert und geben daher Fehler in den Logs aus, da die Abfrage weiterhin stattfindet.
Wenn wir zu Hause sind, möchte ich einen „Privatmodus“ haben (meine Kinder, die eine Party feiern, müssen nicht wissen, dass wir auch eine feiern, und umgekehrt).
Manche Kunden kommen ganz diskret, sie müssen nicht auf dem Dashboard im Wohnzimmer erscheinen…
Super Bedarf !!
mutmut
17. August 2026 um 13:12
3
Du hast die Option, eine Steckdosenleiste mit Schalter zu verwenden, die ein- und ausschaltet, wenn du sie brauchst, und das garantiert zu 100 %, dass die Kamera nicht aufnimmt.
Das ist komplizierter… Die Kameras in den Nistkästen laufen auf RPi0 und das Abschalten des Stroms sollte man eher vermeiden
Aber ja, ich könnte MQTT hinzufügen usw., aber das löst nicht das Problem mit dem Poll und den Fehlern in den Logs…
Hallo zusammen!
Dieses Thema ist nun in Entwicklung .
Ein Pull Request wurde erstellt, um eine Kamera (Privatmodus) zu deaktivieren, ohne sie zu löschen:
master ← claude/camera-disable-private-mode
ouvert 02:45AM - 18 Aug 26 UTC
Implements feature request: https://community.gladysassistant.com/t/desactiver-u… ne-camera-mode-prive/10645
### Description
A camera can now be turned **off** from the UI or from a scene, without being deleted.
The state is one new device feature on the camera itself: `camera` / `enabled` (`DEVICE_FEATURE_TYPES.CAMERA.ENABLED`), a binary read/write feature (`1` = enabled, the default, `0` = disabled). Modeling it as a feature is what makes it work everywhere for free: it renders as a toggle in the device rows, and the existing `device.set-value` scene action turns it on/off from a scene with no new plumbing — which is how the requested "private mode when we are home" is built.
**A camera without the feature is always considered enabled**, so existing installs are unaffected.
#### What happens when a camera is disabled (all gated in the core, so every camera integration benefits)
| Path | Behavior |
|---|---|
| `device.poll` | The device is skipped before the service is even looked up — no image fetch, no error log. This is the concrete pain point of the request (nest-box cameras unplugged for the winter flooding the logs every minute). |
| `camera.getImage` (dashboard snapshot) | Rejects with `Camera is disabled`. The **last known image is never served** — serving it would defeat the privacy purpose. |
| `camera.getLiveImage` (live snapshot, chat intent, scene "send camera image") | Rejects with `Camera is disabled` before reaching the integration. |
| `camera.getImagesInRoom` (chat "show me the cameras in the living room", MCP tool) | Disabled cameras are excluded from the query. |
| `rtsp-camera` `startStreaming` | Rejects with `CAMERA_IS_DISABLED`. |
| `rtsp-camera` `setValue` (new) | RTSP has no control channel, so `enabled` is its only writable feature; setting it to `0` **stops the running live stream immediately**, so a dashboard already streaming stops right away. |
#### Frontend
- **Camera widget**: loads the camera device, and when disabled renders a clear "camera disabled" placeholder instead of the image, requests no image and offers no live button. It listens to the feature's state over the WebSocket, so turning the camera off from a scene or another dashboard clears the image and stops an ongoing live view without a page reload; turning it back on refreshes the image.
- **Device rows** (`device-in-room`): `camera`/`enabled` joins the supported-types allowlist and renders as a plain on/off toggle.
- MQTT device page defaults, feature icon and translations (`en`, `fr`, `de`).
#### Feature creation / backward compatibility
- New RTSP cameras are created with the feature (enabled).
- Migration `20260818090000-add-camera-enabled-feature` adds it (enabled, `last_value = 1`) to RTSP cameras created before this change. It is idempotent and a no-op when the service is not installed.
- Other integrations (MQTT cameras, external integrations) declare the feature themselves — nothing is auto-created for them, since a feature the owning integration does not know about would have no owner.
#### Standard alignment and taxonomy
Matter 1.4's Camera AV Stream Management cluster models privacy with three attributes (`SoftRecordingPrivacyModeEnabled`, `SoftLivestreamPrivacyModeEnabled`, `HardPrivacyModeOn`). This PR deliberately diverges with **one inverted boolean**, and the justification (plus the full `docs/specs/device-feature-categories.md` checklist) is written up in the new living spec `docs/specs/camera-enable-disable.md`, added in this same diff and registered in `AGENTS.md`.
#### Out of scope (deliberately)
- Per-camera scheduling ("disable every evening"): a scene with a time trigger already does it.
- A global "disable all cameras" switch: a scene acting on several `enabled` features covers it.
- Deleting images already recorded when a camera is disabled (the stored image is simply never served again).
- A read-only "hard privacy" feedback feature (physical shutter): no integration exposes one today.
This pull request was created by an automated Claude Code run.
## Forum
Forum: https://community.gladysassistant.com/t/desactiver-une-camera-mode-prive/10645
### Checklist
- [x] Tests pass: `cd server && npm run coverage` (Codecov requires 100% coverage on changed lines) and Cypress (`npm run cypress:run`) if the UI changed
- [x] Linter and prettier pass on both front and server (`npm run eslint`, `npm run prettier`)
- [x] No undocumented breaking change
<sub>Notes on the checklist: the full server suite was run locally (`npm test`) — the only failures are pre-existing environment ones in this sandbox (no `sqlite3` binary, no Docker, no outbound network for the Gladys Plus gateway tests), identical to the failures on `master`. Coverage of every changed server file was verified at 100% with `c8`. Front: `prettier-check`, `eslint`, `compare-translations` and `npm run build` all pass. Cypress was **not** run (binary not installed in this environment).</sub>
---
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---
_Generated by [Claude Code](https://claude.ai/code/session_01YXRz5JiaM9N42djviseBRu)_
## Summary by CodeRabbit
* **New Features**
* Added camera enable/disable controls for privacy mode.
* Disabled cameras no longer poll, serve or ingest images, appear in room results, or start live streams.
* Active streams stop immediately when a camera is disabled.
* Added live status updates, dashboard placeholders, device controls, MQTT support, and translations.
* Existing cameras default to enabled for compatibility.
* **Documentation**
* Added camera privacy-mode behavior specification.
* **Bug Fixes**
* Improved camera refresh and stream cancellation to prevent stale content or hidden sessions after status changes.
Zögert nicht, dem PR zu folgen, es zu testen (optional, besonders bei kleinen Anfragen) und euer Feedback hier zu hinterlassen, falls nötig.
Ich habe zugestimmt
(Übrigens, kann man Vögel beobachten als Voyeurismus bezeichnen?)