Stefan: bei aktuellen near()-Watcher gibt's nur "solange drin". Reale
Szenarien wollen aber differenzieren:
- VORWARNUNG vor Ziel (Blitzer-Warner 2 km vorher) → entered_near mit grossem r
- ANKUNFT exakt am Ziel → entered_near mit kleinem r
- VERLASSEN (Parkplatz, hast du was vergessen) → left_near
- KONTINUIERLICH-DRIN (bin noch in der Naehe?) → near (Default, throttled)
Zwei neue Funktionen in der Condition-Whitelist:
- entered_near(lat, lon, r): True NUR im Moment des Uebergangs
draussen → innen. Fires einmal pro Eintritt.
- left_near(lat, lon, r): True NUR im Moment des Uebergangs innen →
draussen. Fires einmal pro Austritt.
State-Tracking:
- pro Trigger pro near-Aufruf wird der letzte Auswertungs-Wert (true/
false) im Watcher-Manifest gespeichert (Field "near_states", Key
"lat.6,lon.6,radius"). Background-Loop liest's vor dem Eval, gibt's
per collect_variables(prev_near_states=...) in die Closure, schreibt
nach dem Eval die neuen Werte zurueck — UNABHAENGIG ob gefeuert
wurde, sonst greift die Uebergangs-Erkennung nicht.
Background _tick:
- Aufteilung in Watcher-Pass (mit prev_near_states pro Trigger) und
Timer-Pass (ohne State, gemeinsame vars). Bisher war collect_variables
einmal pro Tick — jetzt einmal pro Watcher. Disk-Stats sind teuer
aber unter 30 Watchern unkritisch; bei mehr koennen wir cachen.
ARIA-Tool-Description erweitert (trigger_watcher): erklaert die drei
Modi mit Use-Cases und empfohlenen Throttle-Werten (kurz fuer entered/
left, lang fuer near).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
duffyduck
435b77e1df