feature-requests
feature-requests copied to clipboard
esphome
support for ethernet RTL8201FI
name: Feature request about: Suggest an idea for ESPHome
Describe the problem you have/What new integration you would like support for ethernet RTL8201FI
Please describe your use case for this integration and alternatives you've tried:
WESP32 boards from revision 7 now use the RTL8201FI PHY.
This board was great as it is as far as I know the only board with 12v+ out with POE ethernet support. Naturally WIFI still works and the Power itself can work without ethernet, but I prefer use hardwired connections. Unfortunately the manufacturer has changed from LAN8720 to RTL8201 so this no longer works. Apparently it only requires a change in the PHY definition in the code, but I have no idea how this works with respect to ESPhome so hopefully this is an easy feature to add :)
Additional context
Manufacturer of the wESP32 here. I took a look at the code and it's a little more involved here than just changing the PHY definition from LAN8720 to RTL8201 as can be done for instance in MicroPython or ESP32 Arduino.
This code seems to be some odd mix of Arduino (listed as a requirement for the Ethernet driver) and the older IDF 3, which didn't support the RTL8201. IDF 4 does add this support, as does ESP32 Arduino core 2.0+, but the Ethernet support code in ESPhome seems to be written for IDF 3 and will have to be changed.
As I said, I took a quick look to see if I could do it, but I'm not familiar enough with the internal workings of ESPhome to do this, I'm afraid.
Ah that's too bad, thanks for taking a look anyway! will have to see what the ESPhome team thinks when they have a chance to look at it
Asking for updates, or posting +1 to the bug tracker for that matter, is bad form.
If you want to help bring attention to this issue, encourage others that want it to thumbs-up the first post.
i wish i knew that before buying wesp32.
might make sense to update documentation. it hit me by surprise that even though wesp32 is mentioned in ethernet component doc, it is in fact not supported :(
i wish i knew that before buying wesp32.
might make sense to update documentation. it hit me by surprise that even though wesp32 is mentioned in ethernet component doc, it is in fact not supported :(
Same - wish the wesp manufacture would make an integration. Don’t bother asking him though.
Could we get some comments on how the implementation might need to be attacked? If this involves porting the driver or changing IDF version or Arduino libs?
I do not know much about the internal structure of ESPHome so this may be of limited use, but here's the problem as I see it.
RTL8201FI support was added in ESP-IDF 4 and ESP32 Arduino Core version 2. From looking at the current code, it looks to me like it uses a mixture of IDF 3 and Arduino Core before version 2. I could be off on this. When this issue was first raised I tried to rewrite the code for IDF 4 but I could not get it to compile.
What are the current versions of ESP-IDF and/or Arduino Core that ESPHome is based on? If it's still IDF 3 and Arduino Core pre-v2, are there plans to port it to the newer versions since IDF v3 has been EOL since February? Is there a development branch that uses IDF 4 where this driver could be added?
Despite @adrummond-github's best efforts to vilify me and make it seem like I don't care, this is not the case. I would love to see this support added and am willing to contribute, but I don't know enough about ESPHome to take this on without help.
I wasn’t going to get all into it but hey, thanks for the mention. I just think it’s kinda unethical you knew your product was used, and advertised compatibility over at ESPHome, and you changed the hardware without notifying them, knowing it would break support. You even discussed the issue here, acknowledging the issue. Nearly a year later and they were still advertising support for your product. Your website specifically excludes returns after flashing from the default load, so those expecting ESPhome support end up with paperweights after they load esp home and it doesn’t work. But hey to be fair you never advertised it had support right? I should have read the reviews of other having the exact same issue. I notified ESPhome and they updated their documentation the same day… seems like the right thing to do, so others aren’t dealing with this issue. I’d hardly say my comment an attempt to vilify, I reached out to you directly to find out why you changed the hardware (and why wasn’t ESPHome notified when you clearly knew) and if you’d work with ESPHome to with an integration since the product no longer worked and you were all around unhelpful. Seriously pages and pages of emails of how I’m a terrible customer for leaving a poor review and a useless manager type. Seriously. childish. behavior. Either way, ESPHome is using outdated software and it needs to be updated, if it brings back support for WESP32 that’s great as that ecosystem is sorely lacking poe Ethernet options. We’ll be looking at the olimex boards in the mean time as well as non esphome options.
@adrummond-github As far as I can remember the Wesp was never advertised as compatible with ESPhome from Xorbit, it was a possible configuration on the ESPhome documentation. that documentation should have been updated more promptly, but until you have contacted them likely no-one had and they likely were not aware of this breaking change.
I don't think its on the manufacturer to trawl the internet and ask permission to change their design if it breaks compatibility with 3rd party system. remember the new WESP still works perfectly fine in other environments with up to date IDFs, and its not like the change in eth adapter was hidden, it was clearly mentioned on the store page (At least when I purchased mine)
I posted this FR in the hope it was an easy fix, clearly its going to take a bit more work from the the ESPhome team, but given this likely only affects a tiny subset of ESPhome users its likely very far down their priority list. Until the ESPhome team is ready to work on the issue I don't know what you expect Xorbit to do given he has already made an attempt to fix himself.
Totally a fair opinion, like I said I reached out and it turned into a bunch of drama with the guy. I’ve opened a couple of feature requests to address the issues with ESPHome and I took care of the compatibility notice on the ESPHome site, not sure that was my job either. But hey - trying to help the community, unfortunately not everyone takes the time to move the community forward. I wish you had notified them when you ran into this last year but here we are, I’m agree it’s a small number of people were using the WESP32 board with HA but we were in the market for potentially a couple hundred boards. We currently buy control by web products using http with HA but would prefer a tighter integration (and the controls by web products lack an official integration). Hopefully the olimex board will do what we want - what product did you end up using instead of the wesp32?
yeah i never considering contacting them (well i kind of thought this feature request would be a quick fix so the documentation would just added to, not removed lol)
I'm still using the wesp, I preferred hardwired to WIFI but luckily its not essential for me as i have good wifi coverage in my house. I still have it wired via POE for power and just connect wirelessly. Not ideal but at least if there is a software fix I can likely easily fix the issue. for me the 12v out is was an absolute must to control some 10v analogue circuits, i think the olimex esp32 POE was the only other one i found that had voltage output but i think it was limited to 5v which means i need a boost circuit or something else which i couldn't be bothered with.
Not a problem - ya it seems like a good design and the fit/finish is nicer than the olimex boards. The 5v output isn’t a deal breaker for me. Unfortunately our use case is in environments where we don’t have Wi-Fi coverage so functional Ethernet is a must. Poe isn’t a hard requirement for us, but it’s certainly a bonus and makes powering them easier and cheaper (we already have poe available for ip cameras).
I'll leave it to others to judge where the "drama" came from, enough has been said about that.
I'm not sure which docs were updated, this page still lists the wESP32 config as it was. What ideally should happen is that this can be changed to something like "wESP32 with LAN8720, rev 5 and below", and when the project is updated and we have a driver for the RTL8201 there can be a separate "wESP32 with RTL8201, rev 7+".
@hachi since you asked about how to attack the problem, are you one of the devs? If not, do you possibly know enough about the project to know where things are headed with respect to IDF v4? I saw somewhere that support for the ESP32-C3 is coming, and as far as I know this will require IDF v4 as well.
@xorbit from what I understand the main conversion has been done and closed here #1414, you can see in the comments there are still some compenents left to migrate includinging ethernet here #1683.
Cool, glad to see this is underway!
Unfortunately when I tried to follow the link to the esp-idf branch mentioned in that post I get a 404 error. Is this branch not public?
@xorbit I assume that branch has now been merged and the branch was cleaned up. You can see the code on the pull request that brought the change in.
It doesn't appear that the PR linked above addresses the RTL8201 issue that is the root cause of the WESP32 rev7 not being supported for Ethernet in esphome. Am I missing something?
It seems to be a necessary step in the right direction but it doesn't seem to be enough for me to know what to do next. Part of my problem is that I don't "get" how ESPHome works well enough. For instance, how dependency versions are handled.
I found this piece of code in esphome/components/esp32/__init__.py:
# NOTE: Keep this in mind when updating the recommended version:
# * New framework historically have had some regressions, especially for WiFi.
# The new version needs to be thoroughly validated before changing the
# recommended version as otherwise a bunch of devices could be bricked
# * For all constants below, update platformio.ini (in this repo)
# The default/recommended arduino framework version
# - https://github.com/espressif/arduino-esp32/releases
# - https://api.registry.platformio.org/v3/packages/platformio/tool/framework-arduinoespressif32
RECOMMENDED_ARDUINO_FRAMEWORK_VERSION = cv.Version(1, 0, 6)
# The platformio/espressif32 version to use for arduino frameworks
# - https://github.com/platformio/platform-espressif32/releases
# - https://api.registry.platformio.org/v3/packages/platformio/platform/espressif32
ARDUINO_PLATFORM_VERSION = cv.Version(3, 5, 0)
# The default/recommended esp-idf framework version
# - https://github.com/espressif/esp-idf/releases
# - https://api.registry.platformio.org/v3/packages/platformio/tool/framework-espidf
RECOMMENDED_ESP_IDF_FRAMEWORK_VERSION = cv.Version(4, 3, 2)
# The platformio/espressif32 version to use for esp-idf frameworks
# - https://github.com/platformio/platform-espressif32/releases
# - https://api.registry.platformio.org/v3/packages/platformio/platform/espressif32
ESP_IDF_PLATFORM_VERSION = cv.Version(3, 5, 0)
So it seems RECOMMENDED_ESP_IDF_FRAMEWORK_VERSION is currently 4.3.2 (which would support RTL8201FI) but ESP_IDF_PLATFORM_VERSION is 3.5.0 (which would not support it). Similar for Arduino versions but reversed, the recommended is old and the other one is newer. How does this work? Which one is actually used when building the software? And what does PlatformIO have to do with it all? I have no clue.
All I know is that the current driver esphome/components/ethernet still is written for IDF 3, since it has the TLK110 which doesn't seem to be supported anymore in IDF 4. It should not be able to compile with IDF 4.
Well this is very frustrating, I just got my WESP32 from Mouser, only to find out it's not supported!
https://github.com/esphome/esphome-docs/pull/2096
@xorbit The platform version refers to the PlatformIO platform-espressif32 version. As the comment just above (the FRAMEWORK_VERSION line) says, you can look at the GitHub Release Notes to see that Platform 3.5.0 = Framework 4.3.2
On another note, I need to implement the KSZ8081, which requires Arduino version 2.0.3+ and Platform version 5.0.0+ (Framework 4.4+). Still looking at the best way to do that to get a PR accepted quickly and that will work in the future. Maybe a version check in ethernet_component ? I know MicroPython does it and it works, I still have a PR open for it.
Edit: It seems this functionality was already implemented in ethernet_component.cpp, for example:
#ifndef ESP_IDF_VERSION_VAL
#define ESP_IDF_VERSION_VAL(major, minor, patch) (((major) << 16) | ((minor) << 8) | (patch))
#endif
...
#if ESP_IDF_VERSION >= ESP_IDF_VERSION_VAL(3, 3, 4)
I gave this a day, and came up with something that compiles without warnings or errors. But it doesn't run (yet), the log is just stuck at waiting for download after a POWERON_RESET. Here is the fork
Implementing new PHYs requires changing from Arduino 1.0.6 to 2.0.0+, so it is not trivial (to me anyway).
Might also relate to https://github.com/esphome/esphome/pull/3564. @jesserockz, you might be interested in this.
I am myself looking for a bit of help on this, as I don't have a grasp on everything that's going on, and have absolutely no idea where to go from here.
Edit: and here is the .yaml config I use to test:
esphome:
name: esptest
esp32:
board: esp32dev
framework:
type: arduino
version: 2.0.4
platform_version: 5.1.1
ethernet:
type: KSZ8081
mdc_pin: GPIO32
mdio_pin: GPIO33
clk_mode: GPIO0_IN
phy_addr: 0
# Enable logging
logger:
level: VERBOSE
@ma-lalonde Great work, I'm glad to see you got it to the point of compiling, something I never succeeded in. You obviously have a much better understanding of how ESPHome works than I ever will. I am a hardware and firmware guy, I don't think I'll ever understand complicated build systems with sprawling dependencies.
Since I saw in your code that you implemented all the IDF4 PHYs including the RTL8201, I'd like to test your fork to see if I get the same results as you see on the wESP32 rev 7. But as an immediate illustration of my lack of understanding, how do I make sure I run your fork and not the official ESPHome? Can you give me a pointer?
@xorbit sure! I think the following should work, copied from the docs (which are not too easy to use IMO):
pip3 uninstall esphome
git clone -b feature/ethernet-arduino-2 https://github.com/Connaxio/esphome.git
cd esphome
script/setup
esphome run esptest.yaml
If it runs, and you want to make sure you're using the right version, just add a typo to ethernet_component.h, like #include ETH2.h instead of #include ETH.h, and re-run esphome, it should throw an error.
Unfortunately I don't have more time to spend on this at the moment, unless someone comes up with more pointers. I actually had a similar issue previously (https://github.com/esphome/issues/issues/3542), which I did not manage to solve. Maybe a JTAG debugger would help, I don't have a setup ready.
Tried this config:
esphome:
name: wesptest
esp32:
board: esp32dev
framework:
type: arduino
version: 2.0.4
platform_version: 5.1.1
# Enable logging
logger:
level: VERBOSE
ethernet:
type: RTL8201
mdc_pin: GPIO16
mdio_pin: GPIO17
clk_mode: GPIO0_IN
phy_addr: 0
Sigh. Seems to build, but fails to even upload.
xorbit@galena:~/Projects/esphome$ esphome run wesptest.yaml --device /dev/ttyUSB0
INFO Reading configuration wesptest.yaml...
WARNING The selected Arduino framework version is not the recommended one. If there are connectivity or build issues please remove the manual version.
WARNING The selected Arduino framework version is not the recommended one. If there are connectivity or build issues please remove the manual version.
INFO Generating C++ source...
INFO Compiling app...
******************************************************************************************************
Obsolete PIO Core v6.0.2 is used (previous was 6.1.4)
Please remove multiple PIO Cores from a system:
https://docs.platformio.org/en/latest/core/installation/troubleshooting.html
******************************************************************************************************
Processing wesptest (board: esp32dev; framework: arduino; platform: platformio/espressif32 @ 5.1.1)
------------------------------------------------------------------------------------------------------
Removing unused dependencies...
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
- toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch3
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
Dependency Graph
|-- WiFi @ 2.0.0
|-- Ethernet @ 2.0.0
|-- ESPmDNS @ 2.0.0
Compiling .pioenvs/wesptest/src/esphome/components/esp32/core.cpp.o
Compiling .pioenvs/wesptest/src/esphome/components/esp32/gpio_arduino.cpp.o
Compiling .pioenvs/wesptest/src/esphome/components/esp32/gpio_idf.cpp.o
Compiling .pioenvs/wesptest/src/esphome/components/esp32/preferences.cpp.o
Compiling .pioenvs/wesptest/src/esphome/components/ethernet/ethernet_component.cpp.o
Compiling .pioenvs/wesptest/src/esphome/components/logger/logger.cpp.o
Compiling .pioenvs/wesptest/src/esphome/components/mdns/mdns_component.cpp.o
Compiling .pioenvs/wesptest/src/esphome/components/mdns/mdns_esp32_arduino.cpp.o
Compiling .pioenvs/wesptest/src/esphome/components/mdns/mdns_esp8266.cpp.o
Compiling .pioenvs/wesptest/src/esphome/components/mdns/mdns_esp_idf.cpp.o
Compiling .pioenvs/wesptest/src/esphome/components/network/util.cpp.o
Compiling .pioenvs/wesptest/src/esphome/core/application.cpp.o
Compiling .pioenvs/wesptest/src/esphome/core/color.cpp.o
Compiling .pioenvs/wesptest/src/esphome/core/component.cpp.o
Compiling .pioenvs/wesptest/src/esphome/core/component_iterator.cpp.o
Compiling .pioenvs/wesptest/src/esphome/core/controller.cpp.o
Compiling .pioenvs/wesptest/src/esphome/core/entity_base.cpp.o
Compiling .pioenvs/wesptest/src/esphome/core/helpers.cpp.o
Compiling .pioenvs/wesptest/src/esphome/core/log.cpp.o
Compiling .pioenvs/wesptest/src/esphome/core/scheduler.cpp.o
Compiling .pioenvs/wesptest/src/esphome/core/util.cpp.o
Compiling .pioenvs/wesptest/src/main.cpp.o
Generating partitions .pioenvs/wesptest/partitions.bin
Compiling .pioenvs/wesptest/lib157/WiFi/WiFi.cpp.o
Compiling .pioenvs/wesptest/lib157/WiFi/WiFiAP.cpp.o
Compiling .pioenvs/wesptest/lib157/WiFi/WiFiClient.cpp.o
Compiling .pioenvs/wesptest/lib157/WiFi/WiFiGeneric.cpp.o
Compiling .pioenvs/wesptest/lib157/WiFi/WiFiMulti.cpp.o
Compiling .pioenvs/wesptest/lib157/WiFi/WiFiSTA.cpp.o
Compiling .pioenvs/wesptest/lib157/WiFi/WiFiScan.cpp.o
Compiling .pioenvs/wesptest/lib157/WiFi/WiFiServer.cpp.o
Compiling .pioenvs/wesptest/lib157/WiFi/WiFiUdp.cpp.o
Compiling .pioenvs/wesptest/lib518/Ethernet/ETH.cpp.o
Compiling .pioenvs/wesptest/lib900/ESPmDNS/ESPmDNS.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/Esp.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/FirmwareMSC.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/FunctionalInterrupt.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/HWCDC.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/HardwareSerial.cpp.o
Archiving .pioenvs/wesptest/lib157/libWiFi.a
Indexing .pioenvs/wesptest/lib157/libWiFi.a
Compiling .pioenvs/wesptest/FrameworkArduino/IPAddress.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/IPv6Address.cpp.o
Archiving .pioenvs/wesptest/lib518/libEthernet.a
Indexing .pioenvs/wesptest/lib518/libEthernet.a
Compiling .pioenvs/wesptest/FrameworkArduino/MD5Builder.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/Print.cpp.o
Archiving .pioenvs/wesptest/lib900/libESPmDNS.a
Indexing .pioenvs/wesptest/lib900/libESPmDNS.a
Compiling .pioenvs/wesptest/FrameworkArduino/Stream.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/StreamString.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/Tone.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/USB.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/USBCDC.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/USBMSC.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/WMath.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/WString.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/base64.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/cbuf.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-adc.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-bt.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-cpu.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-dac.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-gpio.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-i2c-slave.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-i2c.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-ledc.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-matrix.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-misc.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-psram.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-rgb-led.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-rmt.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-sigmadelta.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-spi.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-time.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-timer.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-tinyusb.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-touch.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/esp32-hal-uart.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/firmware_msc_fat.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/libb64/cdecode.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/libb64/cencode.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/main.cpp.o
Compiling .pioenvs/wesptest/FrameworkArduino/stdlib_noniso.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/wiring_pulse.c.o
Compiling .pioenvs/wesptest/FrameworkArduino/wiring_shift.c.o
Archiving .pioenvs/wesptest/libFrameworkArduino.a
Indexing .pioenvs/wesptest/libFrameworkArduino.a
Linking .pioenvs/wesptest/firmware.elf
RAM: [= ] 12.2% (used 39976 bytes from 327680 bytes)
Flash: [==== ] 42.4% (used 777713 bytes from 1835008 bytes)
Building .pioenvs/wesptest/firmware.bin
Creating esp32 image...
Successfully created esp32 image.
esp32_create_combined_bin([".pioenvs/wesptest/firmware.bin"], [".pioenvs/wesptest/firmware.elf"])
Flash params set to 0x0020
Wrote 0xcf480 bytes to file /home/xorbit/Projects/esphome/.esphome/build/wesptest/.pioenvs/wesptest/firmware-factory.bin, ready to flash to offset 0x0
==================================== [SUCCESS] Took 7.98 seconds ====================================
INFO Successfully compiled program.
usage: esptool write_flash [-h] [--erase-all]
[--flash_freq {keep,80m,60m,48m,40m,30m,26m,24m,20m,16m,15m,12m}]
[--flash_mode {keep,qio,qout,dio,dout}] [--flash_size FLASH_SIZE]
[--spi-connection SPI_CONNECTION] [--no-progress] [--verify] [--encrypt]
[--encrypt-files <address> <filename> [<address> <filename> ...]]
[--ignore-flash-encryption-efuse-setting] [--compress | --no-compress]
<address> <filename> [<address> <filename> ...]
esptool write_flash: error: argument <address> <filename>: [Errno 2] No such file or directory: '/home/xorbit/Projects/esphome/.esphome/build/wesptest/.pioenvs/wesptest/patched_bootloader.bin'
INFO Upload with baud rate 460800 failed. Trying again with baud rate 115200.
usage: esptool write_flash [-h] [--erase-all]
[--flash_freq {keep,80m,60m,48m,40m,30m,26m,24m,20m,16m,15m,12m}]
[--flash_mode {keep,qio,qout,dio,dout}] [--flash_size FLASH_SIZE]
[--spi-connection SPI_CONNECTION] [--no-progress] [--verify] [--encrypt]
[--encrypt-files <address> <filename> [<address> <filename> ...]]
[--ignore-flash-encryption-efuse-setting] [--compress | --no-compress]
<address> <filename> [<address> <filename> ...]
esptool write_flash: error: argument <address> <filename>: [Errno 2] No such file or directory: '/home/xorbit/Projects/esphome/.esphome/build/wesptest/.pioenvs/wesptest/patched_bootloader.bin'
What's this patched_bootloader.bin that it seems to want and doesn't have, and where is it supposed to come from?
Flashed the image manually with:
xorbit@galena:~/Projects/esphome/.esphome/build/wesptest/.pioenvs/wesptest$ esptool.py --port /dev/ttyUSB0 write_flash 0x0 firmware-factory.bin
Same result as reported by @ma-lalonde:
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:QIO, clock div:2
load:0x3fff0030,len:1184
load:0xffffffff,len:-1
ets Jul 29 2019 12:21:46
rst:0x10 (RTCWDT_RTC_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
Anyone have a clue what is wrong? I assume the bootloader considers the image in the flash invalid and since it can't boot it switches to serial download.