[ifnull]

Two independent drone-alert bugs, both surfaced by field testing after 1.1.6.

1. Restart replays the last alert as a new one

Retained alert/<rule>/active outlives the process. A rule that was on at exit stayed retained on, and on_connect published status: online before any evaluation ran — so Home Assistant flipped the binary_sensor unavailable -> on off a stale value and fired the notification automation for a detection that never happened. It couldn't self-correct either: publish_alert_active only runs on transitions, so a quiet rule never republished.

on_connect now asserts the true state of every configured rule while still marked offline, then flips availability. client.py already guarded status this way; the alert topics never got the same treatment.

It publishes the genuine active set (AlertEvaluator.alert_states()), not a blanket clear — on a mid-run broker reconnect rules are legitimately active, and forcing off would flap them off and back on, i.e. the same duplicate push by another route. The snapshot is synchronous and takes no tracker lock: the hook runs on the MQTT loop, and a tick blocked enqueueing a publish while holding that lock would deadlock.

Clearing on graceful shutdown was considered and rejected — it does nothing for a SIGKILL.

2. Light aircraft pushed as drones

MatchBlock keys are purely geometric (distance, altitude, closing vector), so nothing could express "this is a drone". A drone_nearby rule built from geometry matched any low, close track — observed pushing a light twin at ~1,500 ft as a drone.

Adds a derived drone flag on every Remote ID track, composable like any flag (flags: ["drone"]). The Phase-3 notes already anticipated it, and ORBIT_FLAG / SPOOF_FLAG set the precedent. Applied in Enricher after evaluate_flags, which reassigns state.flags wholesale.

Latent rather than new, but 1.1.6 surfaced it: the AGL fix made these rules match drones for the first time, so the manned-aircraft matches stopped being the whole behavior and became visible false positives.

Backwards-compatible — the flag changes no rule until composed into it.

The flag does not belong on drone_conflict

The two example rules have opposite subjects behind a shared prefix:

Rule	Watches	flags: ["drone"]
drone_conflict	a low manned aircraft inbound over the area your own drone may be flying in, so you can land	no — would silence the traffic it exists to report
drone_nearby	someone else's drone near the watchpoint	yes

The example config now says so explicitly, restores drone_conflict to its documented bounds (10.8 nm / 600 s — consumer-drone radio range), and rewrites the drone_nearby rationale, which had described itself as covering what drone_conflict misses as though both watched drones.

Verification

• 835 tests pass; mypy and ruff clean. New tests cover on-connect ordering (fresh start and mid-run reconnect), alert_states() snapshots, flag derivation and its ordering against configured flags, and a regression pinning the observed false positive.
• Live feed data through the real Enricher + rule_matches: four manned aircraft that matched the geometry-only rule do not match the flag-gated rule.
• End-to-end against a live Remote ID sim: drone_nearby fires for the drone (flags: ["drone"], hex: null) and not for overhead manned traffic.

Reviewer notes

• Drone payloads now carry "drone" in flags — a new value in an existing field, so schema_version stays at 1.
• Existing installs keep false positives until flags: ["drone"] is added to drone_nearby in their own config; the code makes it expressible, it doesn't apply it.
• Version bumped to 1.1.7 for the version-guard job.

🤖 Generated with Claude Code