support for ethernet RTL8201FI #1462
Comments
|
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 |
|
+1 for this FR |
1 similar comment
|
+1 for this FR |
|
Anyone I can pay to do this? :) |
|
Any update? Its been 7-8 months. |
|
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. |
|
Thanks for the advice! Good job helping. |
|
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. |
|
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 # 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 All I know is that the current driver |
|
Well this is very frustrating, I just got my WESP32 from Mouser, only to find out it's not supported! |
|
@xorbit The platform version refers to the PlatformIO 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 Edit: It seems this functionality was already implemented in #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 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 esphome/esphome#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.yamlIf it runs, and you want to make sure you're using the right version, just add a typo to 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 (esphome/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: 0Sigh. Seems to build, but fails to even upload. What's this |
|
Flashed the image manually with: Same result as reported by @ma-lalonde: 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. |
|
Now that you mention it, I did have exactly the same errors (oops, my bad), and overcame them the exact same way. Not a pro on these things either, but the fact that there is a I see there is a branch called |
|
The release notes for ESPHome may not have caught up with that change and tries to flash the bootloader separately? Anyhow, manually flashing the image should have fixed that, but didn't. Out of curiosity, I tried this with Arduino version 2.0.3. Flashing did automatically work, indicating the flashing issue is indeed related to this change in 2.0.4. Also, the run behavior is a bit different, although not good either. The board sits in a loop doing this: I guess this is progress, since it looks like it's booting up and then crashing in your Ethernet code... 😆 |
|
Hey, we may be getting somewhere! With Arduino 2.0.3 and line 77 of I get this serial log: That looks like a successful Ethernet connection to me! |
|
Can confirm, it pings, simply by changing the version to 2.0.3! I added your changes and a mention to my fork. I am absolutely not sure about the typecast on |
|
Fyi: esphome/esphome#3751 |
|
@nagyrobi I don't think it is relevant to this because the IP101 was already supported in IDF 3.x / Arduino core 1.x for ESP32. The RTL8201FI and KSZ8081 PHYs require IDF 4.x / Arduino core 2.x. |
|
RTL8201 support added to 2022.12 (beta). All concerned please test and give some feedback. |
|
Hurray! Can confirm that 2022.12 (beta) works on wESP32 rev 7 using this config: esphome:
name: wesptest
esp32:
board: wesp32
logger:
level: VERBOSE
ethernet:
type: RTL8201
mdc_pin: GPIO16
mdio_pin: GPIO17
clk_mode: GPIO0_IN
phy_addr: 0Here's the console output for |
|
Is framework If it works, please add a PR to the docs with this config, similar to the pre-rev7 boards (keep the old rev example too). |
|
I tried it with both I'm not very familiar with the organization of the ESPHome repos, can you give me a link to the correct repo to update the docs? Thanks. |
|
Ok, I found it and added this PR: |
|
Thank you |
|
Many thanks to the work here, just dropping in to comment this is working great for me |
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
The text was updated successfully, but these errors were encountered: