Ece

A quick way to see which layer is failing: open the browser's network tab, filter to the WebSocket or event-stream connection, and watch it.

You will see either the handshake failing outright: which points at the upgrade headers - or the connection establishing and then closing after a consistent interval, which points at a timeout, and the interval tells you whose timeout it is.

That single observation separates the two main causes without changing anything.

Version 3 of the ESP32 board package removed the old LEDC functions. They are not deprecated with a warning, they are gone, which is why you get an undeclared-in-this-scope error rather than anything more helpful.

The old pattern was two calls: configure a channel with a frequency and resolution, then attach a pin to that channel. Version 3 replaced it with a pin-centric API, you attach a pin directly, giving the frequency and resolution at the same time, and then write to the pin rather than to a channel number.

So every tutorial written before that change fails to compile, and there are a great many of them. That is the entire population of people hitting this.

The rewrite is small: two calls become one, and the write takes the pin instead of the channel. Channels are still allocated underneath, automatically.

On which way to go, and I would push towards rewriting rather than pinning.

Rewrite. The new calls are simpler, the code is shorter, and you stay on a package that receives fixes and supports newer chips. If you have a handful of PWM lines, this is fifteen minutes.

Pin the old version. In the boards manager you can select the last 2.x release, and everything compiles again immediately. This is the right answer when you are mid-project, or depend on a library that has not been updated, or are following a course written against the old API. It is a decision to stay on a version that will stop receiving support, so treat it as buying time.

Compatibility shim. Defining the old function names in terms of the new ones works and I would avoid it. It hides which API you are on, and the next person to read the code has no idea why it compiles.

A caution about the vendor package that is worth stating plainly: it pins itself to specific distribution releases, and it can leave you unable to upgrade.

It replaces parts of the graphics stack with its own versions. When your distribution moves to a new release and the vendor has not published a build for it, you are choosing between removing the package and staying put.

So if you do not have a concrete requirement that only it satisfies, not installing it is not laziness - it is avoiding a dependency that constrains the machine for years.

And if you do install it, note somewhere that you did, because a future upgrade failing with graphics errors is otherwise a genuine mystery.