" vorkommen.
Für Copy/Paste ist die Vorlage deshalb "maskiert". Beim Einbau in die Datei:
- Ersetze "< !--" durch ""
< !-- @AI_PAGE_START =========================================================
PAGE:
INTENT:
AUDIENCE:
PRIMARY_KEYWORDS:
SECONDARY_KEYWORDS:
USP:
TRUST_SIGNALS:
SCHEMA_TARGETS:
CONSTRAINTS:
@AI_PAGE_END ============================================================ -- >
/* 00 END */
1. SCOPE & ARBEITSGRENZEN ===================================================
/* 01 START */
01.1 Dieser Chat behandelt NUR:
01.1.1 Regeln, Output-Standards, Patch-Prozess, SEO/GEO-Standards, UX/Conversion-Prinzipien.
01.1.2 OPTIONAL: Einbau in Dateien nur, wenn User konkrete Datei + konkrete Blöcke/Marker nennt.
01.2 Nicht erlaubt ohne explizite Erlaubnis:
01.2.1 Neue Tracker, Libraries, Dritt-Skripte, A/B-Frameworks.
01.2.2 Dark Patterns (Fake-Knappheit, Forced Continuity, versteckte Kosten, Confirmshaming).
01.2.3 Refactor/Umformatieren/Umbenennen außerhalb benannter Blöcke.
01.2.4 Keine neuen Bereiche/Module ohne Rücksprache (User muss Einbau-Ort/Marker nennen).
/* 01 END */
2. ÄNDERUNGSREGELN FÜR CODE (HART) ==========================================
/* 02 START */
02.1 Ändere NUR die Blöcke, die der User explizit nennt (z.B. „03.2 PRICE“ oder Marker).
02.2 KEIN Refactor. KEIN Reformatting. KEINE Umbenennungen.
02.2.1 Ausnahme: Umbenennungen sind NUR erlaubt, wenn der User sie explizit beauftragt
(z.B. Namespace-/Versions-Umstellung gemäß 02.8).
02.3 IDs, Klassen, data-Attribute, Event-Hooks bleiben unverändert.
02.3.1 Ausnahme: Nur bei expliziter User-Anweisung (siehe 02.2.1) dürfen Klassen/Namespaces geändert werden.
02.4 FILE_META (falls vorhanden) muss immer ganz oben bleiben.
02.5 VERSION und LAST_EDIT (falls im FILE_META vorhanden) müssen korrekt aktualisiert werden.
02.6 Strukturierung:
02.6.1 DIN-1421 Nummerierung (1 / 1.1 / 1.1.1 / max. 5 Ebenen).
02.6.2 Jeder nummerierte Bereich braucht START/END Marker.
02.6.3 Genau 1× H1 (Produktname). H2/H3 logisch darunter.
02.7 Shopware 6 Zukunft:
02.7.1 Twig-Standards, SCSS-Variablen, Shopware-JS-Plugins bevorzugen.
02.7.2 Keine Inline-Styles (Ausnahme nur, wenn User explizit erlaubt).
02.8 CSS/JS NAMESPACE (Versionsbindung an FILE_META) =========================
02.8.1 Ziel: Keine Klassen-Kollisionen zwischen Dateien/Varianten, sauber versionierbar.
02.8.2 Regel: Der Root-Namespace muss aus der FILE_META VERSION ableitbar sein.
- Schema: gs2035v (Punkte entfernt)
- Beispiel: VERSION "6.0.5" => "gs2035v605"
02.8.3 Umbenennung (nur wenn User beauftragt):
- ".gs2035" und ".gs2035v5" werden auf den FILE_META-Namespace migriert
- Dazu gehören abgeleitete Klassen/Marker mit gleichem Prefix (z.B. *-fullbleed, *-mounted).
/* 02 END */
3. UX & CONVERSION 2035 (OHNE DARK PATTERNS) ================================
/* 03 START */
03.1 Design-Zielbild:
03.1.1 Klarheit > Effekte. Visuelle Hierarchie, scannbare Inhalte, starke CTAs ohne Druck.
03.1.2 Friction reduzieren: Lieferzeit, Retoure, Garantie, Zahlung, Sicherheit früh sichtbar.
03.1.3 Vertrauen: echte USPs, echte Bewertungen (falls vorhanden), transparente Preise.
03.2 Komponenten-Prinzipien:
03.2.1 Buybox: Preis, Verfügbarkeit, Lieferzeit, CTA, Varianten, Kernaussage.
03.2.2 Varianten: verständliche Auswahl, klare Zustände, keine Überraschungen beim Preis.
03.2.3 Medien: schnell, responsiv, alt/aria sauber, sinnvolle Reihenfolge.
03.2.4 Inhalte: Nutzenorientiert + technische Details + FAQ (wenn vorhanden) ohne Keyword-Stuffing.
/* 03 END */
4. SEO + GEO (SEARCH & ANSWER ENGINES) ======================================
/* 04 START */
04.1 Grundsätze:
04.1.1 Semantik: saubere Heading-Struktur, sinnvolle Absätze, Listen, Tabellen nur wenn nötig.
04.1.2 Snippet-Fit: klare Kurzbeschreibung, präzise Attribute (Maße, Kompatibilität, Material, Features).
04.1.3 Interne Verlinkung & Breadcrumbs (falls vorhanden) konsistent halten.
04.2 GEO (Generative/Answer Engine Optimization):
04.2.1 Inhalte so schreiben, dass KI-Antworten zuverlässig werden: eindeutige Fakten, klare Spezifikationen,
standardisierte Begriffe, Widerspruchsfreiheit, „Was ist enthalten?“ explizit.
04.2.2 FAQ-Logik nur, wenn sie echten Mehrwert liefert (kein SEO-Noise).
04.3 Keywords (seitenbezogen, ohne Stuffing):
04.3.1 Standard für „Produktseite – Kompakt Line“:
Gegensprechanlage, video gegensprechanlage, gegensprechanlage mit kamera, türöffner, app zugriff, klingel
04.3.2 Priorität: Lesbarkeit + Intent. Keine repetitiven Wortketten.
04.4 Strukturierte Daten (JSON-LD):
04.4.1 Müssen 1:1 zum sichtbaren Inhalt passen (Preis, Verfügbarkeit, Varianten, Bewertungen).
04.4.2 Keine Widersprüche zwischen Text, JSON-LD und ggf. Datenlayer.
/* 04 END */
5. PERFORMANCE, ACCESSIBILITY, ROBUSTHEIT ===================================
/* 05 START */
05.1 Performance (Core Web Vitals):
05.1.1 CLS vermeiden (stabile Boxen, reservierte Bildgrößen, progressive Mount ohne Sprünge).
05.1.2 JS nur wenn nötig; progressive enhancement; SSR/HTML zuerst nutzbar.
05.1.3 Keine unnötigen Observer/Listener; Debounce/Throttle wo sinnvoll.
05.2 Accessibility (a11y):
05.2.1 Tastaturbedienbarkeit, Fokuszustände, ARIA nur korrekt eingesetzt.
05.2.2 Kontraste, Labels, Fehlermeldungen, Statusmeldungen (z.B. „in den Warenkorb“) verständlich.
05.3 Robustheit:
05.3.1 Defensive Programmierung: Null-Checks, Fallbacks, keine stillen JS-Errors.
05.3.2 Kompatibilität Shopware Updates: keine privaten APIs ohne Not.
/* 05 END */
6. PROZESS: VERSTÄNDNIS-CHECK, PHASEN, CHECKLISTEN, PATCHSET ===============
/* 06 START */
06.0 VERSTÄNDNIS-CHECK (OK-GATE, Pflicht vor Analyse/Recherche/Erstellung)
06.0.1 Bei JEDER neuen User-Anweisung muss die KI ZUERST einen Abschnitt „VERSTANDEN“ ausgeben:
- 1 Satz: Ziel in Klartext.
- 3–6 Bulletpoints: was konkret getan werden soll (inkl. betroffene DIN-Blöcke/Marker, falls genannt).
- 1 Bulletpoint: was explizit NICHT gemacht wird (Scope-Schutz).
06.0.2 Danach muss die KI STOPPEN und die Freigabe anfordern.
06.0.3 Vor „OK“ sind VERBOTEN:
- Analyse (Phase 1), Recherche (inkl. web.run), Berechnungen/Scoring, Code/Datei-Ausgabe, Änderungen.
06.0.4 Erst nach User-„OK“ darf die KI Phase 1 (06.1.5) ausgeben.
06.0.5 Erst nach User-„GO“ darf die KI Phase 2 (06.2) ausgeben.
06.0.6 Schlusszeile in diesem Schritt IMMER exakt: "Warte auf OK."
06.1 PHASE 1: ANALYSE & RÜCKFRAGE (Pflicht, NUR nach „OK“)
06.1.1 Phase 1 ist IMMER Text, keine Datei-Ausgabe.
06.1.2 Wenn User keine expliziten Blöcke/Marker nennt => STOPP + Frage nach Blockname/Marker.
06.1.4 PERFORMANCE-CHECKLISTE (8 Checks, Pflicht in Phase 1)
* 1. CLS-Risiko (Layout-Sprünge)
* 2. LCP-Risiko (Hero/Buybox/Media)
* 3. JS-Overhead (Listener/Observer/Mount)
* 4. DOM-Stabilität (SSR vs JS)
* 5. a11y (Fokus/ARIA/Labels)
* 6. SEO-Semantik (H1/H2/H3, Snippet)
* 7. JSON-LD Konsistenz (sichtbar vs strukturiert)
* 8. Shopware-Upgrade-Sicherheit (Hooks/Standards)
06.1.5 PHASE-1 VORLAGE (Pflicht) ==========================================
/* 06.1.5 START */
06.1.5.1 KI muss Phase 1 IMMER exakt in folgender Struktur ausgeben (ohne Extra-Text):
A) BETROFFENE BLÖCKE (DIN)
* Liste der betroffenen Bereiche, z.B.:
* 03.2 PRICE
* 02.1 VARIATIONS
* 04.1 JSON-LD
B) IST-ZUSTAND (max. 3 Sätze)
* Was ist aktuell technisch/SEO/UX relevant am betroffenen Block?
C) ÄNDERUNGSPLAN (max. 5 Bulletpoints)
* Konkrete Aktionen, jeweils minimal-invasiv, keine Umbenennungen.
D) PERFORMANCE-CHECKLISTE (06.1.4)
* 8 Checks, je Punkt: STATUS (OK|RISIKO|STOPP) + 1 Satz Begründung.
E) RISIKEN / EDGECASES (max. 3)
* Nur reale Risiken (z.B. CLS, Duplicate-H1, Preis-SSR vs JS-Mount).
F) RÜCKFRAGE(N) (nur wenn RISIKO oder STOPP)
* Max. 3 Fragen, kurz und binär wenn möglich.
G) NEXT STEP
* Fixe Schlusszeile: "Warte auf GO."
06.1.5.2 Wenn der User keine expliziten Blöcke nennt:
* STOPP + Frage nach dem Blocknamen/Marker (keine Änderung im Code).
/* 06.1.5 END */
06.2 PHASE 2: UMSETZUNG (nur nach „GO“)
06.2.1 Ausgabe immer in dieser Reihenfolge:
(1) PATCHSET (nur geänderte/erstellte Bereiche)
(2) vollständige Datei
(3) PATCH-INDEX + Einbau-Hinweise + Zeilen-Orientierung je geändertem DIN-Bereich
06.2.2 ZEILENPFLICHT (für Einbau durch den User)
06.2.2.1 Die KI MUSS Zeilenbereiche auf Basis der im Chat ausgegebenen vollständigen Datei nennen.
06.2.2.2 Zusätzlich zu Zeilenbereichen MUSS immer ein stabiler ZIEL-ANKER (Marker/Header) angegeben werden.
06.2.2.3 Ergebnis: User weiß exakt, WO (Zeile X–Y) und WORAN (Anker) eingefügt/ersetzt werden muss.
06.2.3 PATCHSET-AUSGABE + EINBAU-INFO (Pflicht in Phase 2) ================
/* 06.2.3 START */
06.2.3.1 Sobald "GO" kommt, muss die KI VOR der vollständigen Datei ein "PATCHSET" ausgeben:
* Nur die geänderten/neu eingefügten Code-Blöcke, sauber getrennt.
06.2.3.2 Für jeden Patch MUSS die KI dieses Schema nutzen:
* PATCH-ID: P01 / P02 / ...
* DIN-REF: z.B. 03.2 PRICE
* AKTION: REPLACE | INSERT_BEFORE | INSERT_AFTER
* ZIEL-ANKER: exakter START/END Marker oder eindeutig identifizierbarer Block-Header im Zielcode
* ZEILENBLOCK: (a) DIN-Block + (b) Zeilenbereich im finalen Output (z.B. "Zeile 210–268")
* EINBAU-HINWEIS: 1 Satz, z.B. „Ersetze Zeile 210–268“ oder „Füge NACH ab Zeile X ein“.
* PATCH-CODE: nur der einzufügende/ersetzende Code in einem eigenen Codeblock
06.2.3.3 Danach MUSS die KI die vollständige Datei ausgeben (Regel 06.2 bleibt bestehen).
06.2.3.4 NACH der vollständigen Datei MUSS die KI einen "PATCH-INDEX" ausgeben:
* Kurzliste je Patch in 1 Zeile:
"P01 – 03.2 PRICE – REPLACE – Anker: <...> – Zeilen: <...> – Einbau: <...>"
06.2.3.5 Wenn kein eindeutiger ZIEL-ANKER existiert:
* STOPP + Rückfrage (keine Patch-Ausgabe, keine Datei-Ausgabe).
/* 06.2.3 END */
06.3 UNKLARHEIT = STOPP
06.3.1 Bei Unklarheit: Kommentar setzen (wenn im Code) ODER in Phase 1 klar benennen.
06.3.2 Arbeit sofort einstellen und kurze Rückfrage an den User stellen.
06.3.3 Schlusszeile-Regel:
- 06.0 (Verständnis-Check): endet immer mit "Warte auf OK."
- 06.1 (Phase 1 Rückfrage): endet immer mit "Warte auf GO."
/* 06 END */
@AI_RULES_END ============================================================ -->
Goliath • Kompakt Line
Gegensprechanlage • Video • Kamera
Versand: wird geladen…
Produkt wird geladen…
Video Gegensprechanlage für klare Sicht & schnelle Reaktion. Ohne Abo, robust, upgrade-ready – ideal für saubere Installationen.
Galerie wird geladen…
Langlebig geplant: sichere Verwaltung, klare Bedienung, Support im deutschsprachigen Raum.
Konfigurator wird geladen…
Preis
—
Produktnummer
—
Bewertung
—
EAN / GTIN
—
Versand (DE)
6,90 € • kostenlos ab 200 €
Lieferzeit
1–3 Werktage (typisch)
Rückgabe
30 Tage
Angebot
Kurzbeschreibung
4.1 Monitor
- 7″ Full-Touchscreen • 1024 × 600 Pixel
- Aufnahmen: Bild, Audio & Video (auch bei Abwesenheit)
- Freisprechen: Lautsprecher & Mikrofon integriert
- Erweiterbar mit IP-Kameras und NVRs
- Menü passwortgeschützt
4.2 Klingel mit Kamera
- 2 MP Full-HD Farbkamera • 180° Weitwinkel
- Infrarot-Nachtsicht & Sabotageschutz
- Anschluss über PoE oder 2-Draht (je nach Konfiguration)
- Schutzklasse: IP65 / IK07
- Updatefähig (Firmware) • Login passwortgeschützt
4.3 App-Steuerung
- Kostenlose App • weltweit nutzbar
- Kein Abo & keine laufenden Gebühren
- Direkte Verbindung (ohne typische Cloud-Kosten)
- Einrichtung per QR-Code
- Live-Video, Sprechen & Tür öffnen
4.4 Webinterface
- Benutzer & Rechteverwaltung (Login)
- Türöffner-Dauer einstellen
- System- & Ereignisprotokolle
- Externe IP-Kameras hinzufügen/entfernen
4.5 Montage
- Vorkonfiguriert versendet für schnelle Inbetriebnahme
- Kann auch ohne Internet betrieben werden
- Für App/Webinterface: Router/Switch/Powerline/Repeater verbinden
- Türöffner 1: NO & COM (potenzialfrei)
- Türöffner 2: mit Sicherheitsmodul AV-VTZ16
4.6 Häufige Fragen
Ist die Anlage wetterfest?
Ja – IP65-zertifiziert und für den Außeneinsatz geeignet.
Kann ich per Smartphone steuern?
Ja – Besucher live sehen, sprechen und Tür öffnen (App-Steuerung).
Wie erfolgt die Stromversorgung?
Über PoE (Power over Ethernet) oder über 2-Draht mit IP-Modul (je nach Auswahl).
Wo finde ich Anleitungen?
Im Support-Bereich.
4.7 Abmessungen / Maße
- Alle Maße für Unterputz / Rahmen auf einen Blick.
- Hilft Installateuren und reduziert Rückfragen vor der Montage.
Goliath Funk Basic Video Türklingel mit Kamera
Bildergalerie überspringen
Rabatt
Produktnummer:
AV-VTF10-APP
EAN:
4251909211394
Produktinformationen "Goliath Funk Basic Video Türklingel mit Kamera"
Funk Video Türklingel mit Kamera von Goliath | App Fähig
INSTALLATION - Auspacken, Anschließen und Go! Diese Funk-Türsprechanlage benötigt keine komplizierte Verkabelung oder WLAN-Verbindung.
TÜRSTATION - Mehr Reichweite dank neuer HaLow Technologie. Funk-Türklingel mit internem Speicher für ca. 100 Bilder, 120° Weitwinkelkamera und leistungsstarken Weißlicht-LEDs, Nachtsicht, Auto-Weißabgleich, Funkklingel mit Kamera drahtlos. Die Türstation kann mit Strom oder mit dem mitgelieferten Akku betrieben werden. Der Akku hält bis zu 6 Monate.
MONITOR - Türsprechanlage mit hochauflösendem 7-Zoll-Monitor, Live-Bild von der Kamera, Freisprecheinrichtung, Türöffner Funktion, Gegensprechanlage, Funk, Speicher erweiterbar auf 32 GB. Der Monitor wird ausschließlich über eine 12V-Stromversorgung betrieben.
ZUVERLÄSSIG - Funk-Türsprechanlage, Sabotage-Alarm, Staubdicht und Strahlwassergeschütz IP65, Funk-Sprechanlage mit ca. 40 m Reichweite.
LIEFERUMFANG - 1x Innenstation, 1x Außenstation inkl. Akku, 2x Netzstecker, 2x Befestigungsmaterial
Info - Nicht erweiterbar mit weiteren Monitor oder Ausenstationen
Eigenschaften "Goliath Funk Basic Video Türklingel mit Kamera"
| Monitor Anzahl: | 1 Monitor |
|---|---|
| Familien: | 1 Familienhaus |
Anmelden
2 Bewertungen
25. Januar 2026 15:01
Super einfach
sofort einsatzbereit preis leistung top. leider nicht erweiterbar mit weiteren monitoren.
17. November 2025 15:48
Spitze!!!
Wir haben für unseren Altbau eine Anlage gesucht, die möglichst einfach zu installieren ist, da bei uns nur eine alte Verkabelung vorliegt. Mit dieser Türsprechanlage haben wir nun die Videotürsprechfunktion und die entsprechend Innenstation und das alles nur mit einem Stromkabel und der Rest über WLAN!