Remove EMAC related code for devices that don't have one

[LennartF22]

It does not make sense to be able to configure Ethernet via the internal EMAC for targets other than the "original" ESP32, as they don't have one! Devices from the ESP32-C or ESP32-S series only support Ethernet via an external MAC, like the W5500. Therefore, the user should not be able to configure it and neither should see it in the pin configuration on the "Device-Manager" page of the OpenDTU web interface.

Furthermore, the usage of ETH_PHY_LAN8720 in the PinMappingClass caused a compilation error when using Arduino core v3.0, because with v3.0 the definition only exists for targets where internal EMAC support is configured (see ETH.h).

[schlimmchen]

@LennartF22 @tbnobody FYI: hoylabs@d6d5f32

[tbnobody]

Haven't tested it yet, but what happens if pins are defined via define and the pin mapping contains a empty or non-exsiting eth section?

[schlimmchen]

You will then (still) see the category "eth" in the web UI if and only if the firmware was compiled with CONFIG_ETH_USE_ESP32_EMAC, as also the #defines for the respective pins are guarded by this #define.

Or in general: A category will appear in the device manager web UI if it is included in curPin at the api/device/config endpoint, regardless of whether or not it is in the pin mapping. Sections in the pin mapping are masked if the firmware says "I don't know this category of pins", which I think makes sense in general.

[LennartF22]

Haven't tested it yet, but what happens if pins are defined via define and the pin mapping contains a empty or non-exsiting eth section?

The defines from the platformio.ini are ignored, since they are never used due to my patch. However, when Ethernet pins are defined in the pin_mapping.json, they will still be shown in the web interface, because without the patch from @schlimmchen, the web interface will happily show anything configured in the pin_mapping.json.

[schlimmchen]

because - as far as I know - the web interface will happily show anything configured in the pin_mapping.json.

That's exactly what the one-liner in hoylabs@d6d5f32 prevents. The categories (and only the categories, not the individual pins) are filtered by the known/supported categories of the firmware.

[LennartF22]

That's exactly what the one-liner in helgeerbe@d6d5f32 prevents. The categories (and only the categories, not the individual pins) are filtered by the known/supported categories of the firmware.

Yes, sorry, I only noticed that @tbnobody‘s question was directed towards your change after writing my comment, but I already updated it ^^