Some general guidance needed to deal with logic quagmire

[zliudr]

I am running the esp-azure iot device twin sample code. The logic in the code is: there is an event handler that monitors a few wifi-related events and attempts to reconnect wifi if it gets disconnected:

Code: Select all

static esp_err_t event_handler(void *ctx, system_event_t *event)
{
    switch(event->event_id) {
    case SYSTEM_EVENT_STA_START:
        ESP_LOGI(TAG, "SYSTEM_EVENT_STA_START");
        ESP_ERROR_CHECK(esp_wifi_connect());
        break;
    case SYSTEM_EVENT_STA_GOT_IP:
        ESP_LOGI(TAG, "SYSTEM_EVENT_STA_GOT_IP");
        ESP_LOGI(TAG, "Got IP: '%s'",
                ip4addr_ntoa(&event->event_info.got_ip.ip_info.ip));
        xEventGroupSetBits(wifi_event_group, CONNECTED_BIT); // dev twin
		//ESP_ERROR_CHECK(start_file_server("/spiffs", server)); // file server
        break;
    case SYSTEM_EVENT_STA_DISCONNECTED:
        ESP_LOGI(TAG, "SYSTEM_EVENT_STA_DISCONNECTED");
        ESP_ERROR_CHECK(esp_wifi_connect());
        xEventGroupClearBits(wifi_event_group, CONNECTED_BIT); // dev twin

        break;
    default:
        break;
    }
    return ESP_OK;
}

It sounds nice. Once STA starts, connect to AP with credential. If STA gets IP, it means connected so set event group bit for other tasks to start. In case of disconnection, immediately attempts to reconnect and clear event group bit. It's quite alright if you start with a valid credential.

What I'm trying to do is to switch AP by supplying esp32 new credential. So one task receives the new credential, calls disconnect, then set config and call connect(). That crashed the cpu. I guess on disconnect, the SYSTEM_EVENT_STA_DISCONNECTED is triggered so the event handler calls connect() immediately. Then my other task calls connect() again, causing cpu to crash.

OK no calling connect() from two different routines. I'll just set new config and only call disconnect() then let the event handler do its connect(). That worked! There's always a BUT. If the new credential is not valid (such as wrong info or AP not turned on), then I supply yet another new credential, then the system doesn't connect anymore. Because I bet SYSTEM_EVENT_STA_DISCONNECTED is only generated when the system actually disconnects from an AP. If the system is still trying to connect to an AP but not yet connected, you call disconnect(), then there is no SYSTEM_EVENT_STA_DISCONNECTED event generated so the single place where connect() is called doesn't know it should call connect().

So should I abandon the event handler logic or not? If I abandon it, then I have to set up a separate task to monitor wifi and perform checking etc. If I don't abandon it, should I set up some additional event group bits to indicate whether connect() has been called and thus shouldn't be called? How would I trigger the connect() that is in the event handler? Can I manually throw a SYSTEM_EVENT_STA_DISCONNECTED somehow? I want connect() to only exist in one spot to avoid retry. Throwing an event will be great to have. Can I do it?

Thank you!