after WiFi.begin, the localIP() should return immediately because WiFi.begin waits for DHCP. how do you initialize WiFi?

I am also setting timeout to zero, because wifi connection is not mandatory on my device. Its priority is to control connected devices. The control cycle has 1 millisecond resolution. I can handle aprx 20mills a common modem-esp32 exchange, but i cannot handle 5 seconds blocking call.

I made PR that fixes this by adding localIPNonBlocking() function.

PR:

• Add Non-blocking Version of localIP Function for WiFiS3 library and fix FifoBuffer.h #408

I hope it fixes your issue and have a nice day :)

am also setting timeout to zero, because wifi connection is not mandatory on my device

but then don't call localIP() if there is no WiFi connoection

am also setting timeout to zero, because wifi connection is not mandatory on my device

but then don't call localIP() if there is no WiFi connoection

You don't understand. My controller is running in the main loop where many operations are scheduler depend on various conditions such a time, sensors or status of various components. One component is Wifi connection. So the task calls WiFi.begin(), then periodically checks for status (while returning CPU thread back to the main loop) and then , when status is OK, retrieves localIP.

now consider environment with bad wifi connection. The WiFi status is OK, but immediately after the wifi connection is lost and localIP blocks. Or other scenario, when WiFi.status is OK, but probably DHCP handshake is still in progress. As I understand, this is the main reason, why the function is blocking. So non-blocking version can simply return "still in progress" and we are good, the Task object can postpone the operation until next cycle.

I made PR that fixes this by adding localIPNonBlocking() function.

I hope it fixes your issue and have a nice day :)

Thank you, I already happily forked this PR.

correct solution is change the esp32 firmware to not wait for localIP()

I made PR that fixes this by adding localIPNonBlocking() function.

I hope it fixes your issue and have a nice day :)

Thank you, I already happily forked this PR.

Glad you solved it! Have a nice day.

correct solution is change the esp32 firmware to not wait for localIP()

You mean using ESP-IDF?

But i think solution is solution.

I looked more into it. the firmware returns immediately.
the localIP() function should not try multiple times. there should not be the loop with a delay. it makes no sense to do that.

cc: @pennam

I looked more into it. the firmware returns immediately. the localIP() function should not try multiple times. there should not be the loop with a delay. it makes no sense to do that.

cc: @pennam

Unfortunately, some code expects blocking version of this function, like here

some code expects blocking version of this function, like here

no. that doesn't require a blocking localIP(). config() sets the static IP settings.

some code expects blocking version of this function, like here

no. that doesn't require a blocking localIP(). config() sets the static IP settings.

I don't know. I assume that setDNS doesn't expect that localIP fails.

EDIT: apparently end() is there, but it is missing in documentation and no mention anywhere on internet.

vvvvvvv

Actually I don't like that code. It is weird. It calls config, however it requires connected wifi. It is really strange. I prefer to set config and then call begin(). And I also missing end() - which I already implemented in my forked version, as calling SOFTRESETWIFI, which should be also available at public API. There is a lot issues with real usage of Wifi beyond of this discussion.

by the way, the above code is formally wrong, but luckily works for this specific usage.

I looked more into it. the firmware returns immediately. the localIP() function should not try multiple times. there should not be the loop with a delay. it makes no sense to do that.

cc: @pennam

@JAndrassy I will look at it for the next release, 1.3.x is already in the oven