-
Notifications
You must be signed in to change notification settings - Fork 56
Allow MQTT to update local antenna display names #2880
Copy link
Copy link
Closed
Labels
GUIUser interfaceUser interfaceenhancementImprovement to existing featureImprovement to existing featureexternal devicesFlexControl, MIDI, serial port, USB peripheralsFlexControl, MIDI, serial port, USB peripheralsmaintainer-reviewRequires maintainer review before any action is takenRequires maintainer review before any action is taken
Metadata
Metadata
Assignees
Labels
GUIUser interfaceUser interfaceenhancementImprovement to existing featureImprovement to existing featureexternal devicesFlexControl, MIDI, serial port, USB peripheralsFlexControl, MIDI, serial port, USB peripheralsmaintainer-reviewRequires maintainer review before any action is takenRequires maintainer review before any action is taken
Type
Fields
Give feedbackNo fields configured for issues without a type.
Problem
AetherSDR now supports local antenna display names for canonical radio antenna tokens such as
ANT1,ANT2,RX_A, andXVTA. In real shacks, those local names can change dynamically when an external coax switch or automation system changes the routing. Examples include 4O3A Antenna Genius 8x2 setups and other station controllers that decide which physical antenna is currently connected to each radio port.Without an automation input, the operator has to manually keep AetherSDR's local labels synchronized with external routing state.
Proposal
Let the MQTT station automation integration update AetherSDR's local antenna display aliases while preserving canonical radio protocol tokens.
Suggested default topic contract:
aethersdr/antenna/name/ANT1with payload80m Dipoleaethersdr/antenna/nameswith payload{"ANT1":"80m Dipole","ANT2":"Hexbeam","RX_A":"Beverage NE"}""ornullclears that local nameThese updates should call the existing local alias APIs only. Radio commands must continue using canonical tokens like
ANT1,ANT2, andRX_A.Topic design note
The initial implementation can use fixed AetherSDR-owned default topics as a stable integration contract. A configurable topic prefix may be useful later for multi-station or site-specific MQTT namespaces, but fixed defaults keep the first version small and predictable.
Acceptance criteria