ESP32 with wired LAN and PoE

[nagyrobi]

Have you looked for this feature in other issues and in the docs?
The need to run Tasmota on Ethernet-connected devices is obvious. We could finally dump all the issues WiFi may cause in certain cases and build stable and secure systems relying on cables.

Is your feature request related to a problem? Please describe.
wESP32 is a very professional approach to the ESP family. https://wesp32.com/

Basically what it does is that it uses some of the ESP32-WROOM-32 pins connected to an Ethernet PHY module, which is also PoE (supporting IEEE 802.3at standard and passive modes) not only for powering the ESP module itself, but also giving enough power to other accessories like sensors etc.

In the original firmware the module's WiFi part can be still used as a redundant backup connection to the network when wired network fails.

Describe the solution you'd like
Please add support for this wESP32 module, now that ESP32 platform starts to be supported by Tasmota.

Describe alternatives you've considered
There are none so far.

Additional context

I am aware this is not going to happen with two clicks, but it's worth the effort.

[s-hadinger]

The device costs 50€. That's quite high, especially compared to a regular esp32 and a POE splitter.

[nagyrobi]

It's not just an esp32 and a POE splitter. It has an Ethernet PHY module on it, allowing wired LAN connections with the module. How many other such modules are out there?

[Jason2866]

@s-hadinger this board looks interesting https://www.olimex.com/Products/IoT/ESP32/ESP32-POE/open-source-hardware

[nagyrobi]

Good find! Let's collect all such models in this issue.

[ascillato2]

Have you tested if LAN connection works fine using Arduino core? Do you have any small sketch using that ethernet chip?

[nagyrobi]

Look here: https://github.com/OLIMEX/ESP32-POE

[s-hadinger]

Tasmota, esp32, ble, poe, ethernet, arduino compatible and affordable. I start to like it very much. Nice find!

[hagenbuch]

I support this feature request strongly: This family of devices need some power supply, running from a battery is mostly impossible due to the relatively high power demand of the Wifi.

Therefor, it is an advantage if we can power it via one cable only, thus Ethernet/LAN.

Also, ESP32 is one of the rare chips able to handle HTTPS / SSL / TLS properly. This is a precondition to maiking things like electrical door locks and the like... WESP32 can even deliver 12 V 1 A, getting its power from PoE - this is what you need for a solenoid!

It would be awesome if you could add LAN support...

[austwhite]

Having ESP32 support and LAN support is something very interesting for me too. Supporting this request. Given these can be had quite economically now, it would be good to see this support.

[cg089]

+1 for ethernet support (esp32-poe works like a charm with ethernet and esphome)

[dweston]

The device costs 50€. That's quite high, especially compared to a regular esp32 and a POE splitter.

@s-hadinger US$55 for a 1 off wESP32 is expensive, I agree. However it can be purchased in volume with a price as low as US38/unit in quantities >100. At that latter price it is starting to become realistic as a LED driver/sensor board when you take into account the board can deliver circa 13W @ 12V. PoE driven LED lighting becomes feasible when driven from a variety of cost effective PoE switches. I'm using Netgear GS728TP switches, which have a 190W total PoE power budget supplied from 16 PoE 802.3af ports (15W capable) and 8 PoE+ 802.3at (38W capable) ports [can be purchased on eBay for as low as US $169.00]. Averaged out over many ports, taking into account the cost of conventional LED power supply components provision & installation, results in a more manageable cost overall. Furthermore the GS728TP can be monitored and controlled via SNMP, enabling innovation in sector lighting energy management. Quiescent power consumption of many LED drivers can be as high as several watts even with the luminaire (LED) fully turned off. So being able to fully disable the power supply to multiple drivers based on ambient light and body movement is attractive as well.

The dilemma remains with which firmware to implement on these devices. ESPHome on the wESP32 or the Olimex ESP32 PoE boards currently appears to be the way to go, but the prospect of a Tasmota variant becoming available is really the ultimate Holy Grail.

[s-hadinger]

Interesting perspectives. I believe anything above the $20 limit makes it harder for makers to hack and break. I'm still waiting my Olimex to arrive.

Tasmota on ESP32 is still early stage, but promising. Theo is very active on this front.

In order to drive LEDs at 13W, you will need both the on-board POE power supply to be sized for it (are they?) and some power drivers for the LEDs (MOSFET?). And a nice case to make it pretty.

Edit: according to the FAQ, the Olimex board can only deliver 4W, which leaves ~3W usable.

[nagyrobi]

Where do you take this $20 limit from? As soon as Theo provides a statement that wESP32 can run Tasmota, I'll be sure to order at least 2 pieces. I'm pretty fed up with unreliable chinese pieces, and WiFi coverage issuses in certain cases. wESP32 seems to be a premium quality and I am willing to wire up things as much as possible. And I bet I'm not the only one thinking like that.

[lbernstone]

Direct from the manufacturer: https://www.mouser.com/new/espressif/espressif-esp32-ethernet-kit/

[arendst]

Ordered the olimex iso one to play with...

[hagenbuch]

I can send you one for free, we are in Germany, right?

[arendst]

We are in the Netherlands, small province of Germany ;-)

[hagenbuch]

Not yet :) Well I can send it to the Netherlands too if you like.

[arendst]

Pls mail me from the github mainpage

[hagenbuch]

Done :)

[TrDA-hab]

https://norvi.lk/industrial-esp32-norvi-iiot/

[hagenbuch]

Yeah thanks, close but no LAN / Ethernet. Wifi inside a metal box is not exactly what I need :)

[TrDA-hab]

@hagenbuch Sorry! https://konnected.io/products/pre-order-the-konnected-alarm-panel-pro-12-zone-kit https://www.tindie.com/products/microwavemont/grande-esp32-monster-board/ https://aliexpress.ru/item/4000016520686.html https://ru.banggood.com/ESP32-Ethernet-Kit-Ethernet-to-Wi-Fi-Development-Board-PoE-Power-Supply-Wi-Fi-802_11bgn-JTAG-Debug-p-1568199.html?cur_warehouse=CN https://aliexpress.ru/item/4000188817036.html https://www.olimex.com/Products/IoT/ESP32/ESP32-GATEWAY/open-source-hardware https://olimex.wordpress.com/2017/02/09/esp32-evb-our-new-board-for-iot-first-prototypes-are-ready/ https://www.cnx-software.com/2019/11/28/esp32mx-e-esp32-board-ethernet-usb-c/

[hagenbuch]

Thank you. I knew most of them. Now the only question is: Are they all supported by Tasmota and / or how do we make a configuration file for them if they are not yet supported?

[nagyrobi]

Well, hopefully soon we will be able to make a config almost the same way as we would do with the ESP8266-based units.

Today I was in a place where I could have instantly suggested to use Tasmota for a small automation task, but was not able to because of the WiFi requirement of ESP8266. Here only Ethernet is available and deploying WiFis just for this reason is simply unacceptable.

[Jason2866]

@nagyrobi @hagenbuch @TrDA-hab Since Theo ordered a Olimex ESP32 ISO he will work on (for sure). Just give him a little time. It is done when it is done 😊

[nagyrobi]

I don't mean to rush anyone. I was just emphasizing that the need of LAN without any WiFi is a real need.

[arendst]

Currently only works on Olimex ESP32-PoE and I haven't tesetd the PoE functionality yet ;-)

[BBBits]

loaded the new build on an Olimex ESP32-PoE & noticed a couple of things. device rebooted repeatedly while connected via eth. It is still requiring the AP mode to be configured before it will stop restarting. can this be disabled by default ?

Lables for the different interfaces would make it clearer what is what in the information page. I.E. eth_hostname ,eth_mac ,eth_ip etc

[arendst]

It reboots repeatedly

Within seconds or every three minutes? If it's every 3 minutes you could have changed either wificonfig or disabled wifi al together with wifi 0. You could also have configured the correct wifi credentials to make it stop starting the AP mode.

Lables for the different interfaces would make it clearer what is what in the information page.

The top IP address is the ethernet IP address as can be seen from the Hostname ending in _eth. The second IP address is the wifi address. The third one is an AP address although at that time the AP is not even running. A remnant from the ESP32 implementation.

[arendst]

Were you able to use PoE?

[BBBits]

POE working fine, It rebooted every 3 mins perhaps , didn't time it. wasn't a short time. I do see what ip info is where , but it would make sense to define them clearly. there are lables all saying IP Address without specifically associating it to an interface. even a space between them would help

[BBBits]

I have disabled wifi to stop it restating , In the big picture , I would like to have all the local esp82xx's connect to the esp32 AP. can I leave the AP running without it rebooting ?

[arendst]

Currently you can't as the implementation is still based on esp8266 initial installation. How many clients do you expect the ESP32 can service? I don't know but I'm not expecting that many.

[kugelkopf123]

As far as i know there is a limit set to 10 devices on AP mode.

[arendst]

Ok. This looks better.

Now also tested with a Ubiquiti PoE adapter GP-V480-032G (48V) Another Ubiquiti PoE adapter GP-A240-050G (24V) fails to power my Olimex.

[arendst]

With the latest commit you get three new commands to configure "any" ESP32 ethernet interface either based on LAN8720 (Olimex) or TLK110.

You will also need a template for the Olimex to function well so before upgrading first install this template.

{"NAME":"Olimex ESP32-PoE","GPIO":[65504,65504,65504,65504,65504,65504,0,0,5536,65504,65504,65504,65504,0,5600,0,0,0,0,5568,0,0,0,0,0,0,0,0,65504,65504,65504,65504,65504,0,0,65504],"FLAG":0,"BASE":1}

Every device with supported ethernet hardware needs three template GPIOs configured being ETH POWER, ETH MDC and ETH MDIO. ETH POWER is optional. The ESP32 ethernet library uses the following fixed GPIOs:

 * GPIO17 - EMAC_CLK_OUT_180
 * GPIO19 - EMAC_TXD0(RMII)
 * GPIO21 - EMAC_TX_EN(RMII)
 * GPIO22 - EMAC_TXD1(RMII)
 * GPIO25 - EMAC_RXD0(RMII)
 * GPIO26 - EMAC_RXD1(RMII)
 * GPIO27 - EMAC_RX_CRS_DV

Using the defines

  // Olimex ESP32-PoE
  #define ETH_TYPE          0                    // [EthType] 0 = ETH_PHY_LAN8720, 1 = ETH_PHY_TLK110
  #define ETH_ADDR          0                    // [EthAddress] 0 = PHY0 .. 31 = PHY31
  #define ETH_CLKMODE       3                    // [EthClockMode] 0 = ETH_CLOCK_GPIO0_IN, 1 = ETH_CLOCK_GPIO0_OUT, 2 = ETH_CLOCK_GPIO16_OUT, 3 = ETH_CLOCK_GPIO17_OUT

in my_user_config.h or user_config_override.h you can set compile time options EXCEPT gpio options which need to be set in the Template.

[nagyrobi]

Theo, please be aware that according to the Ethernet standards a client device cannot have more than one default gateway set. Units operating with more gateways are the routers, which based on various (manual or automatic) routing tables are able to route traffic according to these.

I guess it's not the scope of Tasmota on ESP32 to implement an entire routing platform so may I suggest to draw a line here and accept a statement that a device can only have one single default gateway set. Things can get complicated when a user connects with a device to two different networks (LAN and WiFi on different subnets) using DHCP for example. Which one will win? The last one which connected will always overwrite the default gateway address?

Perhaps a kind of priority setting would be helpful here, helping to decide which interface is allowed to set the default gateway using DHCP and when. For example:

• Priority Ethernet: the default gateway is set from Ethernet when link established. When Ethernet not connected, default gateway can be set from WiFi.
• Priority WiFi (the other way around): the default gateway is set from WiFi when connected. If wifi not connected, default gateway can be set from Ethernet.

These all above of course only when using DHCP or with static addresses and default gateway set. One could configure manually static address to the interface and not set a default gateway - that's the easiest case because you take the default gateway from the other one.

Whenever the default gateway address changes due to intermittent connectivity, network connections have to be reset (web server, mqtt client etc).

[nagyrobi]

Another Ubiquiti PoE adapter GP-A240-050G (24V) fails to power my Olimex.

Note that this is not a standard 802.3af PoE adapter, this is a so-called passive, older Ubiquiti-proprietary adapter. This is not supposed work with 802.3af devices. Some Ubiquiti APs support both 802.3af and the proprietary PoE.

[BBBits]

Thanks Theo, good having the isolation between the interfaces. My usage idea is not huge. although I have a heap of devices , there are only 6 mini's that are hard wired to lights and also controlled by PIR's. the extra switch Input just sends out knx packets on some of them. I was hoping to just connect those 6 devices to the ESP32 . Haven't considered all the network issues yet but think an isolated one is probably less caos than a bridge. was considering changing the knx to broadcast instead of multicast on the isolated network.

[arendst]

@nagyrobi thanks for the PoE adapter info. Makes sense to me. I've also readup on this and noticed there is PoE and PoE.

Regarding the "router" functionality it will indeed NOT be supported by Tasmota. The fact you saw the AP info in the information page was just a remnant from the ESP8266 to ESP32 conversion which is fixed now; the AP was never allive.

So for now let's close this issue as being fixed and see when other ethernet hardware turns up what is not supported by the current solution. At least PoE is transparent to the software solution as far as I can see.

[dweston]

@nagyrobi have you tried flashing a wESP32 with this latest version of Tasmota32 as yet?

I have access to one of these modules via an IoT dev group I'm working with. I'm in the process of retrieving it in order to try flashing it with this latest version. If I'm successful I'll report it here.

[nagyrobi]

My wESP32 and Olimex are still on the way...

[BBBits]

i think there is an issue with the interface used as gateway. If I turn wifi off , timeserver is not contacted & we stay at 1970 Enable wifi & ntp update is ok

[nagyrobi]

Yep, that's what I was talking about. Extra care should be taken when enabling/disabling interfaces: unless somebody deliberately wants to avoid using gateway addresses (static IP without gateway set), it should be ensured that only one gateway address is always set correctly, depending on how interfaces go up or down. A priority optioning would help with that.

A special case is when the unit is in AP mode, that should be dealt separately. IMHO in that case gateway doesn't need to be set at all (the clients connect directly on the same layer, usage of a gateway is pointless).

[arendst]

There is only one gateway address supported within Tasmota. There is also only one network supported within Tasmota. So both ethernet AND wifi have to be in the same network if enabled.

The latest commit makes sure that if ethernet only is configured the DHCP supplied gateway, netmask and DNS server are set correctly.

[nagyrobi]

If both ethernet and wifi are in the same network, how does Tasmota decide which interface is actually used when sending packets? For example, when contacting the NTP server?

[arendst]

I don't know. Does it matter as long as it's the same network? I know Tasmota does nothing with regards to network selection.

[nagyrobi]

It does, as network switches handle packets based on MAC address in Layer2 networking (the same network). It will cause trouble if a packet goes out on one interface, but answer is coming back on the other. If we go one layer up, where the wifi interface and the ethernet interface have different IP addresses, communication will not establish if packet is sent out via one IP and the answer is coming back to the other.

With such an ESP32 having both LAN and WiFi we usually want redundant (backup) connections to achieve higher reliability, some kind of priority system would make the system more aware of what's happening there, like detect when ethernet link drops, and then automatically switch on to WiFi, and switch WiFi off as soon as Ethernet comes back etc

[arendst]

Understand. Will need to dive deep in the espressif/arduino/esp32 core code of available features to find how to bind what to what.

If anyone feels the need too I'm open for any hints.