The basic tools for developing for ESP-32 in VSCode.
https://docs.espressif.com/projects/esp-idf/en/stable/get-started/index.html
Currently on "Step 6". Virtual environment exists in C:\Users\Blake\Desktop\esp-idf\examples\get-started\hello_world. You have to run C:\Users\Blake\Desktop\esp-idf\export.ps1 to configure the pwsh session w/ the proper environment variables to execute idf.py build.
When selecting any release other than stable during VSCode onboarding, some things may not work quite right. The esp-idf repo that is downloaded contains important scripts export.ps1 and install.ps1. But if python is not callable (i.e. python is not on $Env:PATH), this process fails. I don't necessarily want python on path everywhere, so I created a .env file in the root of the repo with the contents below, opened PowerShell, let my profile automatically run Set-PsEnv, and thus got python on path for that terminal session only. Then, install.ps1 and export.ps1 worked smoothly.
`PATH := C:\Users\Blake\AppData\Local\Programs\Python\Python37`
The GitHub repo itself is downloaded when automatically configuring ESP-IDF through VSCode. Windows Defender exclusions are not added during this automated setup. Without Defender exclusions, real-time protection scans files as you build them. Defender was consuming 50% of the CPU during build without exclusions. I found esp-idf\tools\windows\tool_setup\tools_WD_excl.ps1 inside the GitHub repo that was downloaded. It's a PowerShell command-line tool to recursively add exclusions. Run something like the following command (mind the ellipses) so that Defender will ignore files created by the build tools. There is also an associated tools_WD_clean.ps1 script, which can be used to clean up exclusions that were added in this manner.
...\tools_WD_excl.ps1 -AddExclPath "...\.espressif\tools\*.exe"For advanced development in everything from Arduino to ESP-32. Probably worth looking into after getting ESP-IDF to work.
https://docs.platformio.org/en/latest/platforms/espressif32.html
https://docs.micropython.org/en/latest/esp32/tutorial/intro.html
This is probably the way to go. Lots of legwork already done for remote triggers and actions.
Currently, I can run the server via a Docker container forwarding to a port on localhost. Other devices on the network can even access the dashboard via internal IP and the port number. The thing is, I need ESPHome to recognize the ESP-32 development board on the USB COM port it's plugged into. This isn't easily done from Windows to an isolated Linux Docker container. The "--device" mount flag is meant for passing devices from a Linux host into a Linux container. I could use a Windows-based container, but this is way too involved.
Instead, let's hold off on this until we have a spare Raspberry Pi to use as the host of the ESPHome dashboard and devices on the network. Then we can put a shortcut to the static internal IP of the host RPi, and plug devices directly into it for configuration. Then they can roam remotely and be handled by the dashboard. This would enable a remote power on for Remy (and other) development.