the same problem appeared
CURRENT: upload_protocol = esptool
Looking for upload port...
TimeoutError: Could not automatically find serial port for the `NodeMCU 1.0 (ESP-12E Module)` board based on the declared HWIDs=[['0x10C4', '0xEA60']]
Error: Please specify `upload_port` for environment or use global `--upload-port` option.
For some development platforms it can be a USB flash drive (i.e. /media/<user>/<device name>)
*** [upload] Explicit exit, status 1
But the platform doesn’t declare those anymore. Is that project using https://github.com/platformio/platform-espressif8266.git too?
used to
[env:nodemcuv2]
platform = espressif8266@^2
board = nodemcuv2
Write
[env:nodemcuv2]
platform = https://github.com/platformio/platform-espressif8266.git
board = nodemcuv2
framework = arduino
instead. (Or downgrade the PlatformIO core)
This is kinda bad timing. The core enforces the HWIDs really hardcore but the platforms are not yet up to speed in their stable versions 
Your version of platformio works. How “downgrade the PlatformIO core”?
Do we have reports for other boards? It is not a problem to bump patch releases for the affected dev-platforms.
Things like Arduino Uno clone boards that have CH340 chips on them instead of the ATMega16U2 as USB-UART bridge should be broken too (no 1A86:7523 HWID in uno.json).
The STM32 platform should be really broken too if it uses HWIDs to identify the serial port because the generic boards like platform-ststm32/genericSTM32F103C8.json at develop · platformio/platform-ststm32 · GitHub dictate HWIDs from the LeafLabs USB DFU bootloader that surely not everyone is using with those boards. (Think e.g.: just flash via STLink and monitor via some USB UART adapter)
I also personally ran into this problem with my platform-raspberrypi implementation when wanting to treat my Raspberry Pi Pico board as an Adafruit Feather RP2040 board (needed for some testing), PlatformIO stopped being able to monitor since it had the HWID mismatch – though I guess I could correct this in my board files.
I still have the opinion that the HWIDs should be seen as a “hint” or “priority choice”, not as a hard “if your HWID is not there we refuse to do anything”.
The goal of that refactoring was to improve situations when multiple boards are connected to the machine and PlatformIO picked the wrong port. Also, if HWID field is declared, PlatformIO will wait for the board following the default timeout. This also solves problems with boards that have a special bootloader.
How to solve the issue when a user tries to -t upload -t monitor and the board is not ready after uploading? That was the problem when we pick the wrong port (any serial port).
Does it look like a board definition problem? I prefer the declarative approach. If we receive a lot of complaints, it makes sense to revert back to the recent changes.
Do you have any ideas on how to improve this code?
No it’s not.
A device can have multiple HWID sorted in most to least suitable for it.
A HWID is a combination of bus type, manufacturer, and device identifier. 1 or 2 hwid could be defined in platformio.ini superseded the default HWID declared by core platformio. in this case core used default in nothing is defined. if not defined and doesn’t work , use the HWID defined in platformio.ini. if also mean that HWID can be clear by definition in platformio.ini in case of there is no HWID identified.
Thanks for this.
I solved the issue on windows by specifying upload port as so in platformio.ini file:
upload_port = COM6
It should fall back on the generic port finding (the behavior of PIO Core <6.1). You can ignore " TimeoutError: Could not automatically find serial port for the NodeMCU 1".
What is your board? Also, nodemcu?
I’ve just updated the port finder a little bit. It will throw errors only in the verbose mode
Please re-test with pio upgrade --dev.
Yes an original Lolin nodemuc version 3 (the not breadboard friendly one) comes with a CH340 USB converter.
does not work well with ESPAsyncWebServer