Project update 4 of 20
"The ESP32 is mostly known as a WiFi chip, so why even bother with Ethernet?" you might ask. Here are some good reasons!
In many IoT applications, and especially in building or factory automation applications, reliability is paramount. Ethernet really shines here in comparison to WiFi. WiFi may have made strides in most other performance metrics lately, but its reliability still pales in comparison to Ethernet, especially if you’re trying to connect many clients.
Ask yourself: when was the last time you had to reboot your router because WiFi wasn’t working? Now ask yourself: when was the last time you had to reboot your router because your Ethernet wasn’t working? You get the point.
Maybe it’s OK if your room temperature sensor is off-line until you reset your router, but in many applications, the flakiness of WiFi just won’t do. Imagine that temperature sensor is used to monitor the temperature of a vat of critical liquid in an industrial application instead. Or what if your door doesn’t unlock until someone resets the router? Connecting things over Ethernet can really give you peace of mind.
The wESP32 only has a 100 Mbps Ethernet connection, while the ESP32’s built-in WiFi supports 802.11n, which is capable of up to 150 Mbps. Surely this shows the WiFi performance is better, right? Wrong!
First of all, there’s the "up to" part, which immediately raises a red flag in marketing-aware people. Then there’s the extra overhead associated with managing a wireless connection, and interference from all the other 2.4GHz traffic that’s flying around your building.
In practice, this means no one has ever reported any data throughput close to this theoretical 150 Mbps from their ESP32. The best references I have seen have been people reporting around 20-30 Mbps with an ESP32 sitting right next to their router.
I hacked the ESP-IDF iperf example to work with Ethernet instead of WiFi so I could test Ethernet throughput on the wESP32. The testing results are documented in some of my project logs on Hackaday.io: up to 70 Mbps as client and 90 Mbps as server!
Now I’m sure if you need high bandwidth, there are better solutions than the ESP32, and anything you do with the data on an ESP32 is going to limit your throughput. But it shows that practical Ethernet performance is better even though the theoretical spec seems to favor WiFi, because Ethernet provides a clear, unshared, reliable communication channel for your application.
Even Tesla never got wireless power transfer over long distances to market. Until this happens, wires are going to be necessary for most network connected applications, and with Ethernet you already have a wire right there. Just add a PoE switch and you solve two problems at once!
It is actually easier to provision an Ethernet connected device than a WiFi connected device. Take a look at the examples on the wESP32 web site to see just how easy it is to get connected! For example, to connect the network on Arduino, all you need is:
#include <ETH.h> ETH.begin();
No credentials to manage and store — just start the peripheral and you’re done. In most WiFi example code, management of WiFi credentials is overly simplified, in fact, usually the SSID and password are just hard-coded! That is of course not possible in a production device, so problems related to entry and secure storage of WiFi credentials need to be taken care of by the developer.
The installer doesn’t need to figure out how to set up the device either: just plug in the Ethernet cable and it’s done!
There may of course be situations where it’s not possible to run a wire, and WiFi may be the only way to go. In those cases you have no choice but to put up with its limitations. But where possible, Ethernet is a superior solution for reliable IoT and automation.
Since the wESP32 offers both WiFi and Bluetooth in addition to Ethernet, you can use it as a base to create solutions that work in any situation: Ethernet (with or without PoE) where possible, WiFi where necessary, Bluetooth to connect external battery operated sensors. A very flexible core indeed!