You're missing translation keys for this

Valid point, would the below make sense? (Keeping state length sensibly minimum)

+    AirOSSensorEntityDescription(
+        key="wireless_role",
+        translation_key="wireless_role",
+        device_class=SensorDeviceClass.ENUM,
+        value_fn=lambda data: data.wireless.mode.value.replace("-", "_").lower(),
+        options=WIRELESS_MODE_OPTIONS,
+    ),
     AirOSSensorEntityDescription(
         key="wireless_mode",
         translation_key="wireless_mode",

with

       "wireless_mode": {
         "name": "Wireless mode",
+        "state": {
+          "ap_ptp": "Point-to-Point",
+          "ap_ptmp": "Point-to-Multi-Point",
+          "sta_ptp": "Point-to-Point"
+        }
+      },
+      "wireless_role": {
+        "name": "Wireless role",
         "state": {
           "ap_ptp": "Access point",
+          "ap_ptmp": "Access point",
           "sta_ptp": "Station"
         }
       },

Why do we introduce a second entity?

Thought about it some more reading other integrations, commit will suggest hub as terminology

Also. We should not have strings that are the same in here. As in, when someone is automating they should now pick between "access point" and "access point" and they both trigger on different data. Which is horrible to automate with this

Which is why I landed on 191aca5

          "ap_ptmp": "Access hub",
          "ap_ptp": "Access point",
          "sta_ptp": "Station"

I think we should pick the thing that the user wants and what the user recognizes. If the unifi software talks about Access point in both cases, we shouldn't invent one ourselves. Otherwise, we should map this to access_point and station while it's still in beta

The airOS software doesn't necessarily, looked up the documentation and this has the following list:

The 2 PTMP modes are the same from the API/JSON returned, it's flagging in the Web UI when using specific bandwidths that you can't use non-ac stations. Wrt Station PTMP, I have not seen the option nor the API/JSON equivalent (probably 'st-ptmp' but we'll cross that bridge when we know what it will be.

airOS 8 supports the following wireless modes:
Access Point PTP
Access Point Point-to-MultiPoint (PtMP) airMAX ac
Access Point PtMP airMAX Mixed
Station PtP
Station PtMP

Changed to use the above naming to stay coherent with airOS documentation bd427a0

For reference, the user only sees the UI as

AP on = AP, off = Station
PTP on = PTP, off = PTP
"Dependent on bandwidth" = AC only (but having tried all of them, this doesn't change in the API/JSON output)

I think we need to decide what would be the easiest for the user to understand, I think we could also do binary sensors for these. Up to you. It also kinda depends on what users will use this with. As in, will people automate on the fact what mode the device is in? Or that it is in PTP mode?

Binary sensors might make sense or eventually when we start controlling in a switch. I'll remove 'm for now so we can continue the merge and we'll bring 'm back later on.

I'll add an another docs PR to appropriately remove wireless_mode: home-assistant/home-assistant.io#40274