Unknown value '11NAHT20' for Wireless.ieeemode on NanoStation loco M5 (airOS 6, XW v6.3.22)

[giantoo]

The library logs Unknown value '11NAHT20' for Wireless.ieeemode and setup fails with
AirOSKeyDataMissingError for a NanoStation loco M5 running airOS 6.

IeeeMode in data.py currently has _11NAHT40MINUS and _11NAHT40PLUS, but no 20 MHz
variant for the 11NA (5 GHz 802.11n) family. My link runs at 20 MHz channel width, so the
device reports opmode: "11NAHT20".

Device / firmware

• Model: NanoStation loco M5 (devmodel), SKU LocoM5
• Firmware: v6.3.22, prefix XW, fw_major: 6
• Role: bridge, wireless mode sta, derived mode point-to-point
• Channel 42 / 5210 MHz, chwidth: 20, chanbw: 20, chains 2X2

Relevant part of the reported payload

{
  "opmode": "11NAHT20",
  "chwidth": 20,
  "chanbw": 20,
  "chains": "2X2",
  "frequency": 5210,
  "channel": 42,
  "antenna": "Built in - 13 dBi"
}

Traceback (shortened)

airos.data  Unknown value '11NAHT20' for Wireless.ieeemode
mashumaro.exceptions.InvalidFieldValue: Field "wireless" of type Wireless6 in AirOS6Data
airos.exceptions.AirOSKeyDataMissingError

Suggested fix

_11NAHT20 = "11NAHT20"  # 5 GHz 802.11n at 20 MHz, seen on a v6 XW NanoStation loco M5

Tested locally by adding this line to IeeeMode — the integration then sets up and polls
correctly.

Version affected: airos 0.6.9, as shipped with Home Assistant 2026.9.1.

Happy to provide the full status payload if useful.

[dosubot]

Hi @giantoo! I'm Dosu and I'm helping the Tom's Org team.

This was already fixed. A near-identical report for a PowerBeam M5 400 on v6.3.24 XW with the same opmode: "11NAHT20" led the maintainer to add _11NAHT20 = "11NAHT20" to the IeeeMode enum. That fix shipped in airos 0.6.12, released September 6, 2026 [1] — which post-dates the 0.6.9 version bundled with Home Assistant 2026.9.1 you're running.

For context on why it fails the way it does: the Wireless6.__pre_deserialize__ hook copies opmode into ieeemode, upper-cases it, and validates it against the IeeeMode enum. When the value isn't recognized, _check_and_log_unknown_enum_value logs the warning and deletes the key, leaving ieeemode missing — which then triggers the MissingField → InvalidFieldValue → AirOSKeyDataMissingError cascade you saw [2].

Upgrading python-airos to 0.6.12+ (once Home Assistant picks up that release) should resolve this without any local patches. Since your device is a NanoStation loco M5 rather than the PowerBeam the fix was originally tested against, it'd be worth confirming everything reports correctly after upgrading — feel free to follow up here if anything is still off.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.