Standort-Funktionen

Der blaue Punkt auf einer Karte wirkt simpel. Ist er nicht. Dieser kleine Punkt ist ein Vertrauensvertrag zwischen dir, deinem Gerät, dem Betriebssystem und allem, was du dieses Signal nutzen lässt.

Standort-Funktionen in OpenClaw funktionieren am besten, wenn du diesen Vertrag eng hältst. Nutze sie für nützlichen Kontext und kleine Automationen, nicht um in deinem eigenen Leben einen Überwachungsapparat zu basteln.

Wofür Standort-Funktionen gedacht sind

Denk bei Standort in OpenClaw eher an eine Veranda-Lampe mit Bewegungssensor. Sie sollte aufwachen, wenn sich etwas Relevantes ändert, eine nützliche Sache tun und dann wieder ruhig werden.

Genau dazu passt die aktuelle OpenClaw-Richtung. Die Dokumentation beschreibt Standort als Node-Fähigkeit für gekoppelte Geräte, besonders für iOS- und Android-Companion-Nodes, mit bewegungsbasierten Anwendungsfällen wie Ankunft, Verlassen von Geofences, signifikante Bewegung und Besuchserkennung.

Anders gesagt: Es geht nicht primär darum, einen wandernden Punkt auf einem Dashboard zu beobachten. Es geht darum, deinem Agenten genug Kontext zu geben, damit er im richtigen Moment reagiert.

Was die aktuellen Dokumente sagen

• Standort ist standardmäßig aus.
• Pro Gerät gibt es einen Modus wie off oder while using.
• Präziser Standort ist ein separater Schalter.
• Android unterstützt aktuell nur Vordergrund-Standort für direkte Anfragen wie location.get.
• Der dokumentierte Zweck sind Automations-Signale, nicht dauerhaftes GPS-Polling.

Gerade der letzte Punkt ist wichtig. Der schnellste Weg in ein unangenehmes Setup ist die Idee, dass jede Fähigkeit immer laufen sollte. OpenClaw geht bewusst in die andere Richtung.

Was du damit bauen kannst

Gute Standort-Workflows sind klein und klar. Ein paar Beispiele:

• Ankunfts-Automationen: Wenn du im Büro ankommst, kann OpenClaw eine Status-Zusammenfassung vorbereiten oder dein Morning-Canvas öffnen.
• Abfahrts-Automationen: Wenn du einen Ort verlässt, kann es an etwas erinnern, eine Notiz sichern oder den Interaktionsmodus wechseln.
• Bewegungsbasierte Hinweise: Erkennt das Telefon signifikante Bewegung, kann der Agent nicht dringende Arbeit zurückhalten, bis du wieder still bist.
• Kontextbewusste Antworten: Wenn du bei aktiver Node nach Umfeld fragst, kann OpenClaw den aktuellen Standort als weiteres Signal nutzen.

FedEx hat die Kundenerwartung schon vor Jahren verändert, indem Standort nicht als Dauerkarte, sondern als Folge relevanter Ereignisse sichtbar wurde. Genau das ist hier das richtige Denkmodell. Der Wert steckt nicht in den Rohkoordinaten. Der Wert steckt darin zu erkennen, wann sich etwas genug verändert hat, um wichtig zu sein.

Wie Standort technisch funktioniert

Der dokumentierte Befehl heißt location.get und läuft über die Node-Befehlsschicht. Das heißt: Dein gekoppeltes Gerät teilt den Standort über eine Node-Fähigkeit und nicht direkt über einen Messaging-Kanal.

Wenn du die CLI-Form sehen willst, sieht das so aus:

openclaw nodes location get --node <id>

Die dokumentierte Antwort enthält Felder wie Breite, Länge, Genauigkeit, Geschwindigkeit, Richtung, Zeitstempel und die Information, ob der Wert präzise ist.

{
  "lat": 48.20849,
  "lon": 16.37208,
  "accuracyMeters": 12.5,
  "timestamp": "2026-01-03T12:34:56.000Z",
  "isPrecise": true,
  "source": "gps"
}

Auch das Steuerungsmodell ist in der Dokumentation gut sichtbar:

location:
  enabledMode: whileUsing
  preciseEnabled: false

Das ist ein gesundes Design. Es trennt sauber zwei Fragen: Soll Standort überhaupt verfügbar sein und, wenn ja, wie exakt darf er sein?

Präzise oder ungefähr?

Stell nicht automatisch auf präzise, nur weil es geht. Exaktheit ist nicht gratis. Mehr Genauigkeit bedeutet sensiblere Daten, höhere Erwartungen und mehr Gelegenheiten, sich über ein paar Meter Abweichung zu ärgern.

• Nutze ungefähren Standort für Stadt-Kontext, grobe Präsenz oder weite Automationszonen.
• Nutze präzisen Standort für Ankunftslogik, enge Geofences oder Workflows, bei denen ein kleiner Radius wirklich zählt.

GPS hat denselben Weg genommen wie viele frühere Militärtechnologien, bevor es zur langweiligen Alltagsinfrastruktur wurde. Erst war beeindruckend, dass das Signal überhaupt existiert. Danach wurde die eigentliche Frage: Wer darf es nutzen, wie genau und unter welchen Regeln? Genau an diesem Punkt ist Standort in OpenClaw schon angekommen.

Plattform-Grenzen, die du respektieren solltest

Die aktuelle OpenClaw-Dokumentation ist hier angenehm deutlich.

• iOS-App: Interne Vorschau mit Standort als Node-Fähigkeit neben Kamera, Canvas und Talk-Funktionen.
• Android-App: Noch nicht öffentlich veröffentlicht, und direkte location.get-Anfragen sind laut Doku nur im Vordergrund möglich. Ist die App im Hintergrund, ist ein Hintergrund-nicht-verfügbar-Fehler zu erwarten.
• Automationsziel: Nutze Bewegungs-, Besuchs- oder Geofence-Ereignisse als Signal. Missbrauche die Funktion nicht als Keep-Alive-Trick.

Genau dieser letzte Satz trennt Produktfunktion von batteriehungrigem Bastelprojekt.

Datenschutz-Regeln, die das Ganze vernünftig halten

Die sauberste Regel ist einfach: Standort sollte eine Frage beantworten, nicht eine Akte anlegen.

• Aktiviere ihn nur auf Geräten, die ihn wirklich brauchen
• Starte mit whileUsing statt mit großen Hintergrund-Fantasien
• Bevorzuge ungefähren Standort, solange präzise Koordinaten keinen echten Mehrwert bringen
• Halte Automationen eng, sichtbar und leicht abschaltbar
• Mische Standort nicht mit sensiblen Admin-Aktionen, solange der Freigabeweg nicht glasklar ist

Viele stellen sich Datenschutzversagen als dramatischen Hack vor. Viel häufiger ist es nur träge Ansammlung. Zu viele Logs, zu viel Aufbewahrung, zu viele Workflows, die eine Woche lang clever wirkten.

Troubleshooting

Standort-Anfragen scheitern sofort

• Prüfe, ob der Modus nicht auf off steht
• Bestätige, dass die OS-Berechtigung für den angeforderten Modus erteilt wurde
• Unter Android sicherstellen, dass die App für direkte Abfragen im Vordergrund ist

Die Koordinaten sind zu ungenau

• Präzisen Standort aktivieren, wenn der Workflow ihn wirklich braucht
• Das Timeout erhöhen, um einen besseren Fix zu bekommen
• Keine Wunder von Indoor-Standorten erwarten

Automationen lösen zu oft aus

• Größere Geofences oder weniger Event-Typen verwenden
• Debounce-Logik einbauen, damit wiederholte Ankünfte nicht alles zuspammen
• Lieber einen klaren Trigger als drei überlappende

Die Funktion fühlt sich invasiv an

• Präzisen Standort wieder ausschalten
• Auf while-using-Modus beschränken
• Den Workflow so weit kürzen, bis du ihn in einem Satz erklären kannst

Was du als Nächstes tun solltest

Wenn du das zum ersten Mal einrichtest, sei absichtlich langweilig. Starte mit genau einer Ankunfts- oder Abfahrts-Automation, genau einem Gerät und der geringsten Standortgenauigkeit, die noch funktioniert.

Dann verbindest du es mit den Teilen von OpenClaw, die gutes Timing brauchen: stehende Anweisungen, Kamera-Workflows oder Voice & Talk Mode. Gute Standort-Funktionen fühlen sich weniger nach Tracking an und mehr nach gutem Timing.