Skip to content

feat: human aircraft type names in notifications - #70

Merged
ifnull merged 3 commits into
mainfrom
feat/aircraft-type-name
Sep 30, 2026
Merged

ifnull merged 3 commits into
mainfrom
feat/aircraft-type-name

Conversation

@ifnull

@ifnull ifnull commented Sep 30, 2026

Copy link
Copy Markdown
Owner

Alert notifications printed bare ICAO designators (T38, BE20). This adds a readable name.

What

  • Mictronics parser now keeps the long_type column as a per-designator table: the most common name for each type, ~1.8k entries (BE20 → BEECH 200 Super King Air, T38 → Northrop T-38C Talon).
  • Enricher adds db_metadata.type_name for any track whose designator has a name. The lookup is by type, so aircraft missing from the per-hex DB but broadcasting t get a name too.
  • Alert blueprint shows the name, falling back to the code. The automation and dashboard examples do the same.
  • Release 1.1.8.

Why this shape

  • Per-type table, not a per-hex field. Adding a key to each of ~600k entry dicts costs RSS on the 2 GB Pi the loader has already been OOM-killed on, and the name only depends on the type anyway. On the real file the cost is +0.3 s parse time (2.0 → 2.3 s) and a 1.8k-entry dict.
  • Not ADSBex model. For FAA-registered aircraft it's raw registry text ("200" / "A200" for a King Air), so it can't name a type reliably.

Notes

  • Requires enable_databases with the Mictronics source.
  • The blueprint must be re-imported in HA to take effect.
  • Names keep Doc 8643 casing (BEECH 200 Super King Air, AIRBUS A-320); no normalization.
  • Additive payload field; schema_version is unchanged.

Test plan

  • uv run pytest: 844 passed
  • uv run mypy src, ruff check, ruff format --check
  • Parsed the live Mictronics file and spot-checked names for T38, BE20, H60, K35R, P8, GLF5

🤖 Generated with Claude Code

ifnull and others added 3 commits September 30, 2026 00:07
Notifications printed bare designators (T38, BE20) because nothing carried
a readable name. Mictronics already ships one per row (long_type), which the
parser discarded. ADSBex `model` isn't a substitute: for FAA-registered
aircraft it is raw registry text ("200" for a King Air).

The name is kept as a per-designator table (~1.8k entries, most common
long_type per type) rather than a new key on each of ~600k hex entries.
The name only depends on the type, and growing every entry dict costs RSS
on a 2 GB Pi that the loader has already been OOM-killed on. Keying by type
also names aircraft missing from the per-hex DB, and rows whose own
long_type is blank.

Enrichment surfaces it as db_metadata.type_name — additive, optional.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Resolved in the blueprint's variables rather than the message so the
message template, and its render tests, stay unchanged; the bare ICAO code
remains the fallback when the DB has no name or databases are off. The
dashboard example now prefers type_name over ADSBex `model` for the same
reason the enricher does not use `model`: it reads "200" for FAA rows.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Patch, following the 1.1.7 precedent for additive enrichment: type_name is a
new optional key inside db_metadata, so the payload contract and
schema_version are untouched and no config changes are needed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ifnull
ifnull merged commit d06897d into main Sep 30, 2026
3 checks passed
@ifnull
ifnull deleted the feat/aircraft-type-name branch September 30, 2026 05:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant