Are you using the high level RMT driver? I would try commenting out this line: https://github.com/espressif/esp-idf/blob/7a305c0284b7af7cd8b8f12b48f72e2685d9a363/components/esp_driver_rmt/src/rmt_tx.c#L767 So that each channel is setup and ready to transmit, just waiting on that START bit, and then ...

I think Sprite nailed it with the request body not matching the expected key=value format. There's also the JSON content type header which, at best, your server will ignore but may be messing things up too. From a quick search you should be able to get the raw request body with file_get_contents('ph...

You have set mode to GPIO_MODE_OUTPUT which will enable output. The level is determined by whatever is in the GPIO's output level register at that point in time. I assume this is 0 by default for all of them.

Use gpio_set_level *before* gpio_config to prepare the desired output level.

And even if the certificate does expire, the ESP32 won't know or care because, in most configurations, it doesn't have a reliable source for the current time (eg. NTP, GPS).

Even then, you would need to enable the relevant option in mbedTLS if you actually want this behaviour.

I recall lwIP's TCP slow timer having an annoying wakeup pattern like this, even when all networking is idle.

I think I may have also seen a very recent ESP-IDF commit to address this

Can you increase the sleep time (eg. 5s) to determine if it's having issues while asleep or upon wakeup? Can you share more of your code, especially immediately after esp_light_sleep_start? Can you add some tracing on the very next line after esp_light_sleep_start? Ideally simple like toggling a GPI...

You aren't sending a content length header, so I suspect what's happening is that the client is keeping the socket open and the while loop is being entered immediately again until it times out and reaches the client.stop. One of the big downsides with Arduino is that there's so much abstraction it's...

Put a vTaskDelete(NULL); as the last line in your setup(). It won't completely solve your problem but the loopTask on core 1 busily doing nothing in loop() isn't helping your situation.

When I read the first 4 bytes from app2 partition, I see 0xE9 0x05 0x02 0x22. How are you doing this? esptool.py? I trust the bootloader when it says there's actually 00 05 02 02 there. Have you erased that region of flash beforehand? Not doing this is likely to be your problem based on those seque...

Probably related (WiFi driver retrying many times): https://github.com/espressif/esp-idf/issues/9383

And that indicates that no changes are planned so you might consider exclusively using broadcasts instead, with your own acknowledgement implementation on top of that if necessary.