# Halloween: interaktives atmendes Grab Stand: 1. Oktober 2026. Status: Entwurf zur Abstimmung; erste Software mit Livebild und simulierter Steuerung vorhanden, reale Mechanik noch offen. ## Zielbild Eine Grabattrappe im Vorgarten atmet langsam. Nähert sich ein Besucher, stoppt die Bewegung. Nach einer kurzen wechselnden Pause folgen Kratzen, ein kräftiger Geräuschimpuls, eine kurze Bewegung und Licht. Optional hebt sich eine Skelett-Hand innerhalb der Attrappe. Die Weboberfläche zeigt das Livebild, Betriebszustand und Ereignisse. Bilder und kurze Videoclips lassen sich auf dem Laptop speichern und manuell prüfen. Die Erkennung meldet Personen oder Bewegungen in definierten Bereichen; sie identifiziert keine Personen. ## Bisherige Wünsche und Bestand - Einsatz draußen im Vorgarten; möglichst starker Schreckeffekt. - Nutzerwunsch für die Graboberfläche: Folie, darüber grobes Gewebe und Blätter. Die Attrappe soll ungefähr die Proportionen eines Jugendlichen haben; „besenstiellang“ war die erste Größenbeschreibung. Exakte Länge, Breite und bewegter Bereich sind noch offen. - Die Atembewegung soll wie im Referenzvideo mehrere ungleichmäßige, örtliche Wölbungen erzeugen. Die Gestaltung darf detailreicher und realistischer werden als die Vorlage. - Am vorgesehenen Standort stehen nach grober Schätzung des Nutzers etwa 2 m² zur Verfügung. Länge, Breite und Abstand zum Besucherweg sind noch nicht gemessen. - [Originalclip](references/atmendes-grab-original.mp4) als Referenz vom Nutzer bereitgestellt; [öffentliche Quelle](https://www.facebook.com/joshua.brawer/videos/1075933321689584/). - Raspberry Pis 3–5 vorhanden. Raspberry Pi 5 anhand der Platinenbeschriftung auf Nutzerfoto bestätigt; vermutlich 8 GB RAM laut Nutzer, noch zu prüfen. - Der Pi 5 unterstützt laut [Herstellerdaten](https://www.raspberrypi.com/products/raspberry-pi-5/) 2,4- und 5-GHz-WLAN (Wi-Fi 5/802.11ac). Empfang am Aufstellort und die tatsächliche Verbindung sind noch nicht geprüft. - Aufkleber am Pi zeigt `raspi5WLAN.local` und darunter `_2`; tatsächlicher Hostname und Erreichbarkeit sind noch nicht geprüft. - „2mini“ vorhanden: genaue Bezeichnung noch klären. - Kamera: Raspberry Pi Camera Module 3 NoIR, anhand der Beschriftung auf dem Nutzerfoto identifiziert. Funktion noch nicht getestet; Display eventuell vorhanden. - LEDs, Servos und Lötwerkzeug vorhanden; weitere Teile können gekauft werden. - Kameraauswertung soll Hinweise auf kleine Kinder berücksichtigen. - Der volle Schreck soll nach Auslösung automatisch ablaufen, ohne Freigabe für jeden einzelnen Besucher. - „Voller Schreck“ ist der gewünschte Standardmodus; der Modus soll später in der WebUI auf Sanft, Atmosphäre oder Aus umstellbar sein. - Liveansicht sowie Speicherung von Fotos und Videoclips auf dem Laptop. - Wunsch nach Prüfung verdächtiger Rückkehr: Ereignisübersicht und manuelles Vergleichen der Clips; keine automatische personenübergreifende Identifizierung. ## Erkenntnisse aus dem Referenzvideo Im etwa 17,5 Sekunden langen Clip ist ein rechteckiger Holzrahmen zu sehen. Eine längs durch den Rahmen geführte Stange trägt mehrere versetzt befestigte Kunststoffflaschen. Ihre Lage ändert sich im Video; sie wirken wie leichte Exzenter, die die Abdeckung an mehreren Stellen unterschiedlich anheben. Anschließend wird eine dunkle Folie über den Rahmen gelegt. Im fertigen Aufbau liegen darüber ein grobes helles Gewebe und Blätter; blaue Beleuchtung verstärkt den Eindruck. Die Abdeckung wölbt sich örtlich, statt als starre Fläche insgesamt hochzufahren. Das Video belegt weder Antriebsmodell noch Drehmoment, genaue Abmessungen, Hub oder wetterfeste Ausführung. Die Flaschen sind eine Anschauung für das Bewegungsprinzip, noch keine Festlegung für unseren Bau. Die Kombination aus Folie, Gewebe und Blättern ist nun als gewünschter Aufbau festgehalten. **Gestaltungsvorschlag für mehr Realismus:** Matte, unregelmäßig fallende Gewebeschicht statt sichtbarer glänzender Folie; unterschiedlich dichte Laubstellen und eine flache, nicht symmetrische Kontur. Rahmenkanten, Antrieb und Kabel werden aus Besucherperspektive verdeckt. Grabmarkierung, Licht und Geräusche sollen die Illusion unterstützen, ohne die bewegte Fläche unnötig zu beschweren. Materialoptik bei Tageslicht und bei der geplanten Nachtbeleuchtung prüfen; lose Blätter und nasses Gewebe gehören zum Belastungstest. ## Vorgeschlagene Architektur | Komponente | Aufgabe | |---|---| | Pi 5 | Kamera, anonyme Personenerkennung, WebUI, Ereignisse und Clip-Puffer | | Pi 3 oder 4 (optional) | Effekte, Ablaufsteuerung und lokale Bedienelemente | | Laptop | WebUI aufrufen, Livebild ansehen, Clips herunterladen | | Treiber und separate Versorgung | Motoren, Servos und Beleuchtung versorgen | Der gewählte Auslöser meldet Ereignisse an die Effektsteuerung. Diese begrenzt Sequenzdauer und Wiederholungen selbst. Bei Kommunikationsverlust führt sie keine neuen Schreckbefehle aus. **Architekturentscheidung:** In Phase 3 den vollständigen Ablauf mit einem Pi und simulierten Ausgängen prüfen. Über einen zweiten Pi nach Integration von Kamera und WebUI entscheiden, wenn Leitungswege, Aufstellung und Last bekannt sind. Lokaler Stopp und sichere Abschaltung der Antriebe dürfen in keiner Variante von WebUI oder WLAN abhängen. Falls zwei Pis nötig sind, erhält jeder Schreckbefehl eine begrenzte Gültigkeit; nach Verbindungsverlust bleibt die Effektseite ohne neue Auslösung. ### Software-Stack Der gesamte Code wird in Python umgesetzt. Vorgeschlagene Technologien: | Bereich | Vorschlag | |---|---| | WebUI / API | FastAPI mit uvicorn | | Livebild | picamera2 oder gstreamer, je nach Test | | Personen-/Bewegungserkennung | OpenCV, optional Raspberry Pi AI Kit / Hailo | | GPIO / Effekte | gpiozero oder lgpio | | Konfiguration | YAML- oder JSON-Dateien | | Logging / Clips | Standardbibliothek `logging`, Video mit OpenCV/FFmpeg | ### Code-Struktur Die Dateien bleiben, soweit sinnvoll, unter 400 Zeilen. Dabei bleibt Wartbarkeit wichtiger als sture Einhaltung der Grenze. Vorgesehene Module: - `config.py` – zentrale Konfiguration und Validierung - `camera.py` – Kamerazugriff und Capture-Puffer - `detector.py` – anonyme Personen-/Bewegungserkennung - `events.py` – Ereignisverwaltung und Clip-Speicherung - `effects.py` – Effektablaufsteuerung, bei Bedarf auf dem Effekt-Pi - `web.py` – FastAPI-Endpunkte und MJPEG-Livebild in der ersten Version - `main_controller.py` – Start, Verbindung und Hauptloop auf Pi 5 - `main_effects.py` – bei zwei Pis: Start und Überwachung auf dem Effekt-Pi - `shared/protocol.py` – bei zwei Pis: Nachrichtenformat zwischen Pis Der Laptop muss für Liveansicht eingeschaltet sein. Vorgeschlagen ist ein begrenzter Clip-Puffer auf dem Pi, damit Ereignisse auch ohne Laptop später abrufbar bleiben. Speicherziel und Löschfrist sind noch offen. Für einen vollen Speicher ist ein sichtbarer Fehlerzustand vorzusehen; die Effektsteuerung darf dadurch nicht blockieren. Für die erste nutzbare Version genügen ein Auslösebereich, ein kurzer Effektablauf, lokaler Stopp, Betriebsanzeige und ein abrufbarer Ereignisclip. Hand, Display und weitere Effekte folgen erst nach bestandenem Außentest dieses Ablaufs. ## Kamera und Nachtbetrieb Das vorhandene Camera Module 3 NoIR besitzt Autofokus und keinen IR-Sperrfilter. Mit zusätzlicher Infrarotbeleuchtung ist Nachtbetrieb möglich; ohne Beleuchtung liefert es in völliger Dunkelheit kein brauchbares Bild. IR-Leuchte, Reichweite, Position und Reflexionen am Schutzfenster müssen am Aufstellort getestet werden. Für Pi 5 wird ein Kamerakabel von Standard (15-polig, kameraseitig) auf Mini (22-polig, Pi-seitig) benötigt. Die Pi-seitige Ausführung des vorhandenen Kabels ist auf dem Foto nicht sichtbar und bleibt zu prüfen. Wetterschutz und Sichtfeld sind noch offen. Personenmodelle müssen mit den tatsächlichen Nachtbildern geprüft werden; NoIR allein garantiert keine zuverlässige Erkennung. Vor dem Bau am Aufstellort Sichtfeld, Dunkelbild, Gegenlicht und Reflexionen prüfen. Dabei entscheiden, ob die Kamera zuverlässig auslösen kann oder ob ein zusätzlicher, noch auszuwählender Sensor den Auslöseimpuls liefert und die Kamera Bild und Clip aufzeichnet. Quellen: [Camera Module 3](https://www.raspberrypi.com/products/camera-module-3/) und [Kamerakabel](https://www.raspberrypi.com/products/camera-cable/). ## Effektablauf und Modi 1. Ruhe: langsames Atmen, schwaches Licht, gelegentliche Geräusche. 2. Annäherung: Atmen stoppt, kurze Stille. 3. Auslösung: Kratzen, kurzer Tonimpuls, begrenzter Ruck und Licht. 4. Optional: leichte Hand hebt sich am Grabrand. 5. Rückkehr in sicheren Zustand, anschließend Sperrzeit. Modi: Aus, Atmosphäre, Sanft, voller Schreck und Wartung/Test. Vorschlag: Ohne gespeicherte Auswahl ist „voller Schreck“ der Standard; eine Änderung in der WebUI bleibt nach normalem Neustart erhalten. Ein lokaler Stopp muss unabhängig vom Browser funktionieren. Im Modus „voller Schreck“ startet die Sequenz nach einem gültigen Trigger automatisch; Sperrzeit und Stopp bleiben wirksam. Nach dem Einschalten erst Betriebsbereitschaft und einen freien Auslösebereich abwarten. Nur ein neuer Trigger danach darf eine Sequenz starten; ein alter Zustand löst nichts aus. Nach Stopp oder Fehler ist ein bewusstes Rücksetzen nötig. Vor der Umsetzung für jeden Aktor die sichere Ruhelage, mechanischen Anschlag und maximal erlaubte Laufzeit festlegen. Ein gut erreichbarer lokaler Schalter soll die Antriebsversorgung unabhängig vom Programm unterbrechen können; danach darf kein selbsttätiger Neustart erfolgen. Ein weiterer Trigger während der Sequenz löst keinen zweiten Effekt aus. Bei unklarem Steuersignal endet die Bewegung. Körpergröße im Kamerabild ist nur ein unsicherer Hinweis. Abstand, Verdeckung, Kostüme und Kinderwagen können die Auswertung verfälschen. Eine zuverlässige automatische Altersentscheidung ist damit nicht möglich. Der Nutzer wünscht dennoch „voller Schreck“ als Standard mit automatischer Auslösung. Im vollen Modus können deshalb auch Kinder den vollen Effekt abbekommen. Die WebUI bietet Sanft für entsprechende Betriebssituationen an. Ob ein unsicherer Kamerahinweis zusätzlich automatisch auf Sanft zurückschaltet oder nur als Hinweis angezeigt wird, bleibt vor Umsetzung zu entscheiden. Keine Freigabe pro Besucher. ## Weboberfläche - Livebild mit Auslösebereich und optional maskierten Bildbereichen. - Moduswahl, manuelle Effektknöpfe und klar sichtbarer Stopp. - Kamera- und Steuerungsstatus sowie letzte Auslösung. - Ereignisliste mit Zeit, Vorschaubild, Ereignistyp und Clip. - Bild-/Clip-Download auf den Laptop. - Einstellungen für Lautstärke, Sperrzeit, Bereiche und Aufbewahrung. - Lokaler Zugangsschutz; keine öffentliche Internetfreigabe vorgesehen. - Aufnahmebereich vor dem Einsatz begrenzen und nötige Bildbereiche maskieren; Tonaufnahme bleibt standardmäßig aus. ## Phasen mit Abnahmekriterien ### 1. Anforderungen und Hardware klären - [ ] Hardware- und Sicherheitsplan vor Bau und Aktoranschluss abschließen. - [x] Kameramodell anhand des Fotos feststellen: Camera Module 3 NoIR. - [ ] Pi-5-Kabel, Kamerafunktion und Nachtbild mit IR-Beleuchtung prüfen. - [ ] Sichtfeld und mögliche Auslösung am echten Aufstellort prüfen; Kamera- oder Zusatzsensor als Trigger festlegen. - [ ] Pis, Display, Servos und vorhandene Netzteile konkret erfassen. - [x] Raspberry Pi 5 anhand des Nutzerfotos identifiziert. - [ ] RAM, tatsächlichen Hostnamen, Betriebssystem, Netzteil und Kühlung des Pi 5 prüfen. - [ ] Die grob geschätzten 2 m² am Aufstellort als Länge × Breite und mit Abstand zum Besucherweg nachmessen; daraus jugendlich wirkende Grabmaße festlegen. Gewicht von Folie/Gewebe/Blättern und Hub messen. - [ ] Aufstellort, Besucherweg, Wetterschutz, Strom und Netzverbindung klären. - [ ] Budget, Clip-Aufbewahrung und Reaktion auf unsichere Kamerahinweise bei Kindern abstimmen. - [x] Automatische Auslösung statt Freigabe pro Besucher festgelegt. - [x] „Voller Schreck“ als Standard, per WebUI umstellbar, festgelegt. - [ ] Sichere Ruhelage, Bewegungsgrenzen und Stoppkonzept je Aktor festlegen. - [ ] Akzeptable Auslöseverzögerung, Sperrzeit und Fehlalarmrate festlegen. Abnahme: konkrete Bauteile, Abmessungen, Grenzen und ein am Einsatzort plausibler Auslöser sind dokumentiert. ### 2. Mechanischen Prototyp bauen - [ ] Leichten Rahmen und bewegte Oberfläche konstruieren. - [ ] Lokale Wölbungen durch eine längs gelagerte Stange mit weichen, versetzten Hebepunkten im Tischversuch bewerten. - [ ] Folie, Befestigung und Blattauflage auch im nassen Zustand prüfen. - [ ] Abdeckung aus Besucherperspektive bei Tag und Nacht auf sichtbare Mechanik, glänzende Stellen und verrutschende Blätter prüfen. - [ ] Atembewegung mit geeignetem Antrieb auf dem Tisch testen. - [ ] Schreckimpuls separat auswählen und begrenzen. - [ ] Anschläge, Abdeckungen und lokalen Stopp einplanen. Abnahme: wiederholbare Bewegung ohne zugängliche Quetschstellen; keine Bewegung in den Besucherweg. Dauerbetrieb und Stopp sind praktisch geprüft. ### 3. Effektsteuerung entwickeln - [x] Einen vollständigen Ablauf zunächst mit simulierten Ausgängen umsetzen. - [ ] Licht, Ton und Bewegung einzeln anschließen und testen. - [ ] Modi, Sperrzeit, Sequenzbegrenzung und Fehlerzustände umsetzen. - [ ] Stopp, Neustart, hängenden Befehl und Verbindungsverlust testen. - [x] Prüfen, dass nach Start erst ein freier Bereich und danach ein neuer Trigger die automatische Auslösung ermöglichen. - [x] Moduswechsel per Web-API und gespeicherten Modus nach Neustart lokal prüfen. Abnahme: vollständiger Ablauf funktioniert ohne Kamera und Laptop. Nach Stopp oder Fehler bleibt der Antrieb aus und startet nur nach bewusstem Rücksetzen neu. ### 4. Kamera und WebUI ergänzen - [x] MJPEG-Livebild, Schnappschuss und WebUI im Demo-Modus lokal prüfen. - [ ] Livebild und geschützten lokalen Zugriff bereitstellen. - [ ] Person-/Bereichserkennung ohne Identitätsbestimmung einrichten. - [ ] Gewählten Auslöser mit dem Effektablauf verbinden und Fehlalarme messen. - [ ] Ereignisse mit begrenztem Vor- und Nachlauf aufzeichnen. - [ ] Übersicht, Download und automatische Löschung umsetzen. - [ ] Speichergrenze und sichtbaren Fehler bei vollem Speicher prüfen. - [ ] Unsichere Erkennung und Sanftmodus sichtbar darstellen. Abnahme: ein Ereignis erscheint mit passendem Clip, lässt sich herunterladen und wird nach der festgelegten Frist gelöscht; ohne Laptop gehen vorgesehene Ereignisse innerhalb der Speichergrenzen nicht verloren. ### 5. Außentest und Erweiterungen - [ ] Dunkelheit, Beleuchtung, Verkleidungen und Personengruppen testen. - [ ] Auslösebereich und Fehlalarme praktisch prüfen. - [ ] Wetterschutz, Kabel und Temperatur im geschützten Aufbau prüfen. - [ ] Gesamtablauf mehrfach testen und Lautstärke abstimmen. - [ ] Stopp und Strom-/Netzausfall am aufgebauten Grab erneut prüfen. - [ ] Optional Skelett-Hand, Display oder weitere Effekte ergänzen. - [ ] Kurze Anleitung für Aufstellen, Start, Stopp und Abbau erstellen. Abnahme: zuverlässiger Betrieb am vorgesehenen Ort; Grenzen der Erkennung sind bekannt und der Betreiber kann jederzeit stoppen oder sanft schalten. ## Offene Entscheidungen für den nächsten Schritt 1. Ist ein Pi-5-kompatibles Kamerakabel und eine IR-Leuchte vorhanden? 2. Wie verteilen sich die grob geschätzten 2 m² auf Länge und Breite, und welcher Abstand zum Besucherweg bleibt für das Grab? 3. Welches Budget ist vorgesehen? 4. WLAN oder Kabel am Aufstellort? Wo kommen Netzteile geschützt unter? 5. Clips auf dem Pi vorhalten oder nur bei eingeschaltetem Laptop speichern? 6. Wie lange sollen Aufnahmen bleiben und wer darf die WebUI bedienen? 7. Soll ein unsicherer Kamerahinweis auf kleine Besucher automatisch auf Sanft zurückschalten oder in der WebUI nur warnen? 8. Soll die Kamera auslösen, oder soll ein zusätzlicher Sensor auslösen und die Kamera nur dokumentieren? 9. Reicht nach dem ersten Test ein Pi, oder begründen Aufbau und Last einen zweiten Pi? ## Fortschritt - [x] Projektregeln und erster Plan angelegt. - [x] Allgemeines Uploadskript und Anleitung für Projektdateien vorbereitet. - [x] Erste Kamera-WebUI mit Demo-Feed und simulierter Steuerung erstellt; fünf lokale Softwaretests bestanden. - [x] Optionales Installationsskript für WebUI-Autostart beim Pi-Start und Integration in das Uploadskript erstellt; nur lokal geprüft. - [x] Lokale Git-Versionsverwaltung für Code, Planung und bearbeitbare Blender-Szenen vorbereitet; Renderdateien bleiben lokal. - [ ] Plan abgestimmt und freigegeben. - [x] Softwareumsetzung begonnen; echte Kamera und Aktoren nicht geprüft. Die WebUI ist lokal per ASGI und Demo-Bild geprüft. Pi-Kamera, SSH-Tunnel, Netz, Verdrahtung, Aktoren und Außeneinsatz sind nicht praktisch verifiziert. Das Upload- und Autostartskript wurde nur lokal geprüft; eine Verbindung zum Pi, die Unit-Installation und ein Neustart wurden noch nicht getestet. Einkaufslisten mit konkreten Modellen folgen nach Phase 1. ## Blender-Konzeptvorschau (separat freigegeben) - [x] Vorgarten, Grabattrappe und kostümierte Besucher als Blender-Szene erstellt. - [x] 20-Sekunden-Ablauf mit sanfter Familiensequenz und Schreck für Erwachsene animiert. - [x] Selbst erzeugte Tonspur mit Atem-, Kratz- und Knurrgeräuschen erstellt. - [x] Drei Vorschaubilder geprüft und Nachtbeleuchtung/Bildausschnitt überarbeitet. - [x] Vollständiges Video gerendert: 20 Sekunden, 1280 × 720, 24 fps, H.264 + AAC. - [x] Zwölf Bilder aus der fertigen MP4-Datei dekodiert und visuell geprüft. Dateien liegen unter `preview/`; Reproduktionsskript: `tools/render_preview.py`. Die Figuren sind vereinfachte 3D-Modelle in Kapuzenkostümen. Garten, Maße und Reaktionen sind inszeniert; keine echte Kindererkennung oder mechanische Funktionsprüfung. Die Freigabe dieser Vorschau umfasst keine Effektsoftware oder Hardwareinstallation. ### Zweite Bildfassung nach Nutzerwunsch - [x] Dichte Laubschicht ergänzt, synchron mit der Atembewegung. - [x] Dunklere Stimmung, rotes Grablicht, kahle Äste und Bodennebel ergänzt. - [x] Kinder bleiben in der fiktiven Schreckszene bei den Erwachsenen. - [x] Gelenkige Beinbewegungen und schwingende Ärmel angelegt. - [x] Drei finale Beispielbilder visuell geprüft; nur Bilder gerendert. - [x] Acht animierte Beine und synchronisierte Laub-/Grabbewegung geprüft. - [ ] Laufbewegung im vollständigen Video prüfen, falls später beauftragt. Ergebnisse: `preview/v2/`. Das ursprüngliche Video und seine Blender-Datei bleiben erhalten. Die filmische Inszenierung mit Kindern ändert keine Sicherheits-/Freigaberegeln für den realen Betrieb. ### Dritte Bildfassung: mittige Hand und Laubwirbel - [x] Hand und verdeckte Austrittsöffnung in die Grabmitte versetzt. - [x] 110 rotierende Blätter steigen beim Handimpuls auf und fallen zurück. - [x] Drei Beispielbilder vor, während und nach dem Hochkommen gerendert und visuell geprüft. Ergebnisse: `preview/v3/`. - [ ] Neuer Videorender weiterhin nicht beauftragt. ### Vierte Bildfassung: dunklere Nachtbeleuchtung - [x] Dunkler Nachthimmel und schwächeres Mond-/Grablicht eingerichtet. - [x] Fensterlicht und sichtbare warme Hauslaterne als Lichtquellen ergänzt. - [x] Gerichteter Lichtimpuls, Kontaktschatten, dezente Reflexionen und Lichtstreuung im Bodennebel eingerichtet. - [x] Drei finale Standbilder visuell geprüft; Ergebnisse: `preview/v4/`. - [ ] Kein neuer Videorender beauftragt. ### Videorender der dunklen Fassung (freigegeben) - [x] Acht bewegte Beingelenke in der gespeicherten Szene überprüft. - [x] 20-Sekunden-Video in 720p/24 fps mit Ton fertig gerendert. - [x] MP4-Metadaten und zwölf dekodierte Bilder einschließlich Schrittstellungen geprüft. Ziel: `preview/v4/halloween_dark.mp4`, bearbeitbare Szene `preview/v4/halloween_dark.blend`. Das Renderprofil verwendet acht EEVEE-Bildsamples und 16 Nebelsamples; Lichtquellen, Schatten und Reflexionen der Bildfassung bleiben enthalten. Der vollständige Render erfolgte mit freigegebenem Grafikkartenzugriff. ### Tonergänzung beim Herauskommen der Hand - [x] Tiefes synthetisches Stöhnen mit kurzem Höhlennachhall ergänzt, Beginn bei 13,04 Sekunden, Ausklang bis etwa 16,6 Sekunden. - [x] Bestehende Videobilder mit neuer Tonspur exportiert; 20 Sekunden, 720p/24 fps und AAC-Spur geprüft. Ergebnis: `preview/v4/halloween_dark_groan.mp4`. - [x] Separate bearbeitbare Blender-Datei mit gepackter Tonspur gespeichert.