Wifi(init): Unexpected behavior when initializing subsystems (IDFGH-12651)

[safocl]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

This line is misleading because it expects initialization with the config attached, but if the subsystem is already initialized it simply returns ESP_OK. From which it is not clear whether the attached config was applied or not. But the API does not provide the ability to check whether the subsystem was initialized earlier.

Perhaps we should return a code that signals that the subsystem is already running?

[KaeLL]

#8745 Welcome to the club

[mhdong]

Hi @KaeLL
It is recommended that if you want to reapply the new configuration in WiFi init, you first need to do WiFi deinit. Adding new error codes may damage certain applications. And we will update the document to describe this.

[safocl]

Hi @KaeLL It is recommended that if you want to reapply the new configuration in WiFi init, you first need to do WiFi deinit. Adding new error codes may damage certain applications. And we will update the document to describe this.

Why then are return codes needed at all, if everything is recommended in the documentation? This turns out to be an extra binary code.
Here the function returns the status OK, even when in reality the status is not OK (the action had no effect).

[safocl]

Hi @KaeLL It is recommended that if you want to reapply the new configuration in WiFi init, you first need to do WiFi deinit. Adding new error codes may damage certain applications. And we will update the document to describe this.

The esp_wifi_deinit function will return ESP_ERR_WIFI_NOT_INIT when wifi is not inited. From which it follows that without knowing whether Wi-Fi was launched earlier, it is not clear whether esp_wifi_deinit can be used or not.

esp-idf/components/esp_wifi/src/wifi_init.c

Line 234 in 636ff35

esp_err_t esp_wifi_deinit(void)

[safocl]

Maybe we should introduce a bool wifi_is_inited() check function?
bool esp_wifi_is_inited(){ return s_wifi_inited; }

[mhdong]

Hi @safocl
Yes，you can introduce a bool wifi_is_reset_init_config(const wifi_init_config_t *new_config) to check.
bool wifi_is_reset_init_config(const wifi_init_config_t *new_config) { if(global_old_config same as new_config) { return true; } else { return false; } }

Change in the esp_wifi_init function
if (s_wifi_inited && wifi_is_reset_init_config(config)) { return ESP_OK; } else { /*Prompt call deinitit then return. Or directly call deinit to continue the subsequent process*/ }
We suggest that users do not modify the init config.

[KaeLL]

@mhdong Did you really mean to reply to me? I don't care about reapplying configurations to an already initialized component. What I want is for init functions in IDF to be idempotent (like esp_wifi_init) but also to return a new esp_err_t code signaling that the component has already been initialized.
It's interesting how IDF can be inconsiderate of this issue, given that some components are global, like the default event loop or the GPIO interrupt, and also how inconsistent it can be, given that some components can be lazy-initialized and others can't, esp_wifi_init is idempotent while esp_event_loop_create_default isn't.