Ethernet W5500 Module and ESP32Cam

[KHome]

Hi.

First thank you for the brilliant approach and solution.
Due to some WLAN issues, I would like to request following feature:
(I'm aware of several WLAN solutions, like external antenna; WLAN repeater, ...)

• Ethernet with the "5500" Module connected to the ESP32CAM

A solution is already present and with a CS (Chip selected) connection, with which it should be possible to keep the access to the SD-Card reader. The solution is described in this article:
https://maker.wiznet.io/2021/07/06/ethernet-library-for-esp32-cam-using-hspi-interface-and-w5500-module/
and Source code is published here:
https://github.com/arhi/EthernetSPI2

Hoping for a reply.
Best regards,
KHome

[jomjol]

Great solution, have not seen this so far.
Unfortunetaly I don't have the capacity to implement this in the next future.

I will put this to the feature request list.

[beetronic]

Cool, may I suggest to take also a look at the W5500 module with PoE as this would make an additional 5V source cable obsolete.
https://wiki.iteadstudio.com/POE_W5500_Ethernet_Shield
Cheers

[KHome]

There are several solutions for a W5500 with PoE, which I not have seen yet.
Of course this costs more, but is a great option to reduce power supply issue with local 5V .

https://www.seeedstudio.com/Squame-Ethernet-Arduino-W5500-Ethernet-Board-with-PoE-p-4822.html

Looking for this solution I found this alternative including a CAM (OV2640) and ESP32 (-D0WDQ6-V3)
https://eckstein-shop.de/M5Stack-PoE-Camera-W5500

@jomjol: Thanks for adding this request (W5500) to your feature request list.
a) I'm not sure if the PoE "extension" requires more implementation work - at least ~20-30€ more to invest ;-)
b) and if a -V3 ESP32 is compatible with the current source code. For me it's not an use-case - due to the invest of 50€ in total

[jomjol]

Just to make it sure: the feature request list is only a collection of ideas. I don't have capacity in the next month to follow them.
But I'm more than happy if someone would take one or the other task and implements it. I will merge it to the main code.

[aleks-mariusz]

I picked up a few of these w5500 modules for my esp32-cam boards.. @jomjol wondering if/when this was ever implemented, as i can't find it in the feature-request page (anymore?)..

what is needed to use these (my goal is to fix both the need for power and connectivity with one cable, as my watermeter is in the ground in a pit, at the front of my driveway, where there is no wifi reach nor power available).. running one ethernet cable is about all i can really do here

[SybexX]

w5500 is not recommended because we don't use the SD in SPI mode (too slow). CH9121 is more likely to be an option.
https://www.waveshare.com/wiki/2-CH_UART_TO_ETH

[aleks-mariusz]

Oh that looks like an interesting chip. what would be needed to use that?

I didn't catch the part about why the w5500 not being recommended, can't we do software-spi - also what does the SD card have to do with ethernet? They both can be on the SPI bus? But SD card is not on the SPI bus then wouldn't that make using an spi-based ethernet controller more feasible?

[SybexX]

The ESP32 camera pins are very scarce, so the SD must be operated in SPI mode and the w5500 must be connected to the same pins(same SPI), except the SCS pin. In SPI mode, the SD read/write speeds are much slower than in the currently used mmc mode.
And since the SD access speed is very important for the website and the rest of the processing, I would not recommend using the w5500 module.
The CH9121 would be used on GPIO1 and GPIO3 (TX, RX uart) and a lot of useful information is already output there. In order to fully use the chip, you would have to send all data to the uart interface instead of to the WiFi module.

[aleks-mariusz]

hey thank you so much for the thorough explaination and continuing to entertain my questions. What you said makes a lot of sense, however I am still wondering what the potential real-world impact of changing sd-card to SPI to allow the w5500 to be used might be?

So I haven't gotten as far with this project as having it deployed yet (due to the challenges of nearly non-existent wifi in the water-meter pit in front of the driveway in my house and no easily-accessible power there), so I have no real-world figures to draw up on, but it would be useful to get an idea of:

• typical processing time for a single meter-read workflow - gives us a baseline of performance utilizing what we currently do for sd-card access (mmc-mode). I had some research and statistics-wise, it seems you can get 10-100 MB/s in this mode for reads (and 5-90 MB/s for writes, but from what i understand, the project rarely does any writing unless you enable logging).
• with this, i can get an idea of what the potential impact may be, as it seems SPI-mode would reduce the rate of reads to a measly 0.4-1 MB/s (which is a factor of up to 10x-100x slower).

On paper, if for example it takes 30 seconds in the current configuration to do a workflow, it could potentially take between 5 minutes and almost an hour) at absolute worst case. Agreed, that's faaaar from ideal, but considering the huge advantage of solving two major challenges for (at least) my deployment (connectivity & power), I have still not fully given up on the idea.

And as far as alternatives like the CH9121 goes (which i researched a bit more), it looks like it's essentially a serial-interface "bridge" over ethernet/tcp-ip - however ultimately i want to integrate this into a home-assistant deployment, and the reduction/simplification of the communication here this chip requires, i believe could impact the feasibility of HA integration to some non insignificant degree.

For example, I envision (and correct me if i'm wrong), that the CH9121 would effectively just be a way to have (over-an-IP-network) an "interactive session" w/ the end-device (e.g. basically what a serial console gives you), but something would still need to interrogate it (which changes the mode to "pull-based" from what it currently is, more like a push-based model, since the IOT device/endpoint simply pushes its data which seems to me more reliable). I guess the project could be reconfigured/updated to also "push" over serial, but this wouldn't be as straightforward as what we currently have w/ the wifi-based communication approach we have today.

What i already got in my hands tho is a pair of esp32 (one for water, one for gas - the latter of which presents its own challenges as although it's not an analog digit but a digital read-out, it would only update when a button is pushed, so that also needs to be automated, with consideration to it being battery powered and not polling it too frequently), i also have a pair of w5500 breakout boards, two poe injectors & splitters. I guess I could switch-focus and just get a pair of CH9121 boards as well, but for now, i'd like to give the w5500 a try, and at least see how bad things might be w/ this approach before i throw the extra bits into the parts-bin and change the approach w/ the serial-bridge approach.

That is of course, unless anyone has already implemented the CH9121 ? Caveat, I'm quite inexperienced in writing embedded code so do prefer minimal-effort if possible.