wifi.radio: provide "connected" and "access point is up" boolean properties

[dhalbert]

I have seen many people asking how to find out whether a wifi.Radio connection is up or not. The method usually described is to try to fetch the current IP address. If that fails, the connection is not up.

I think more straightforward boolean properties would be helpful in the API, even if they are bit redundant.

Station mode

Existing API

• wifi.Radio.connect(): connects to a specified network as a Station.
• wifi.Radio.start_station(): start running as a Station.
• wifi.Radio.stop_station(): stop running as a Station.

Additional proposed API

• wifi.Radio.connected: bool: True if up and running as a Station. Read-only
  OR
  - wifi.Radio.station_active: bool
  OR
• wifi.Radio.station_up: bool

Access Point mode

Existing API

• wifi.Radio.start_ap()
• wifi.Radio.stop_ap()

Additional proposed API

• wifi.radio.ap_active: bool
  OR
• wifi.radio.ap_up: bool

Any comments on the idea and the names? In the current documentation, Station and Access Point are capitalized, not sure why.

This is quite simple to implement.

[anecdata]

I like wifi.radio.connected, it's direct and reflexive of connect(). And it's the word people seem to use most conversationally. The start/stop station are under-the-hood things that most people probably don't use, but with station mode (and moreso with AP mode) they can be useful to change modes and change some properties before starting the mode back up.

Maybe started for AP since start() is the verb?

For espressif, the implementation is that the event handler changes state to connected upon IP address being available, so that's 1:1. I'm not sure if there's a foolproof way for RP2040... there can sometimes be a delay of some tens of ms after connect() returns until the IP address is valid. Maybe there is CYW API that tells us directly if it's connected?

Note we also don't have a disconnect(). It is a little redundant since you can stop_station() or wifi.radio.enable = False to disconnect (each requiring two statements to re-connect), but it's a little less direct than a single-statement re-connect.

[dhalbert]

@anecdata thanks for the comments. If we were starting from scratch, the API might be more symmetric, but I would not be inclined to change that now.

Maybe started for AP since start() is the verb?

It looks to me like the CYW43 can be in an intermediate state where the AP has "started to start" but there is no IP yet. I'm thinking ap_started() may not mean "ap ready right now". So I think "ap active" or "ap up" might make it clearer that it's up and ready to use.

[RetiredWizard]

I also like the wifi.radio.connected option, although, I'd offer a suggested change to wifi.radio.is_connected since adafruit_esp32spi.ESP_SPIcontrol already uses that property.

[tannewt]

I agree with @anecdata and would rather not use up. It is a network term that makes no sense without that background.

[dhalbert]

I did most of a PR when I opened this issue. Will try to finish it soon.

[anecdata]

Could this play into a possible major version API change to allow async network actions, like in the present case: async wifi connection (rather than blocking for several seconds)?

[theBoatbuilder]

@dhalbert
I would really appreciate wifi.radio.is_connected or equivalent being made available.
Any idea on timescale please.
Many thanks

[cn-schuh]

Great, many Thanks to You. Just started to rebuild my esp32-s2 wifi connection function.

omg folks, you made my day. i am so excited!