[Test build] Testers for new upcoming build (June '26)

[TD-er]

I've just uploaded the latest GH Actions build to the web flasher

So I would like to summon the very appreciated testing crew :)
@fly74 @ghtester @chemmex @alex-kiev @iz8mbw @Wookbert @Dickesplumpel @thomastech

And some new users who have shown interest in the new builds lately
@wutz-ESP @kuppe234

This is a slightly different testers-request compared to earlier ones as I know there are still some (minor) issues left which for sure need to be fixed before the final release build.

However I am struggling a bit to how they should be fixed properly, so I also need some feedback on that too.

The changes for this build are HUGE!

New Network tab

First of all, the entire way of handling networks has changed and new concepts have been added (even new tabs in the web UI).

Since there are still some minor issues left, I'll give some new commands and explain some new concepts to help you out when you might get stuck. (see also: https://espeasy.readthedocs.io/en/latest/Network/_Network.html )

Here the new Network tab layout on an ESP32-P4 (also new :) )

As can be seen, there are several networks.

• Nr. 1 is always WiFi STA (station)
• Nr. 2 is always WiFi AP (Access Point)

There are 2 types of Ethernet plugins:

• RMII as was used for ESP32-classic and is also present on ESP32-P4
• SPI as was present in the other "ETH" builds.

In the screenshot, there are several new concepts:

• Active (related to "Fallback" and "Delay Startup" which are also new concepts)
• Route Prio
• A secondary ESP for WiFi (currently only on the ESP32-P4)

"Active" concept

This new concept was needed to allow for another new concept called the "Fallback Interface".
For example you have a standard ESP board with only WiFi. Then you can consider the WiFi AP as a fallback interface. Meaning the AP is "Enabled" but no need to set it "Active" as long as you can connect to your normal WiFi network.
Only when one or more set conditions are met, then the AP will be activated.
I hope this will simplify the concept of when interfaces are started and make them way more intuitive.
See also: https://espeasy.readthedocs.io/en/latest/Network/_Network.html#fallback-interface

Some example use cases:

• Do not set AP as fallback and have it active continuously, allowing other nodes/devices to use the ESP node to act as a router/gateway using "NAPT" which is also new.
• Have WiFi STA set as fallback for Ethernet (or PPP for a LTE modem). When there is no connection via Ethernet (or PPP) you can try using WiFi STA as backup.
• Have PPP (for connection via LTE) as fallback, so it will only be used if any of the other interfaces failed to get a connection.
• Have Ethernet set to lowest startup delay, WiFi STA as fallback with longer startup delay and PPP as fallback with the longest startup delay. This way the preferred interface is Ethernet, WiFi the second and as last resort the LTE modem.

Route Prio

The active interface with the highest 'route prio' value is the default interface for new outgoing connections.
This means the ESP is still reachable via other interfaces when needed, but new connections will be made only via the default route.
N.B. it is possible to block web access per interface via the checkbox for Block Web Access

This leads to the first known issue:
Do not set two interfaces active to same route prio as this may lead to undefined behavior.
When running Windows with Wireshark installed, consider uninstalling the npcap driver as switching network interfaces on ESPEasy which are reachable via the same broadcast network may lead to BSoD screens on Windows.
To reduce the risk of these BSoD's I did make the reported hostname different per interface, but still those may occur on Windows with npcap installed. It may also be related to the network chip or driver used, but I tried it using several Intel and Realtek network adapters and still got BSoD's (1 Gbps, 2.5 Gbps, 10 Gbps, PCIe, USB. In total 6 different chips tested)

Still to do:
ESPEasy p2p is not yet working well with multiple active network interfaces.

Secondary ESP

The ESP32-P4 does not have any radio hardware on the chip. So most ESP32-P4 boards do have a 2nd ESP module.
Typically this is an ESP32-C6, though there is at least 1 board with an ESP32-C5. The combination of ESP32-P4 and ESP32-C5 is not yet supported (!!)
The ESP32-C6 is running the ESP-Hosted-MCU firmware from Espressif.
Typically new boards are running version 0.0.6 of that firmware, which doesn't yet support a lot of WiFi commands. And even worse, when trying to call unsupported commands, the whole ESP32-P4 board may crash. One of those commands not yet supported is to query the firmware version.

As soon as ESPEasy is installed on a new ESP32-P4 board and a network connection is active (with access to the internet), it is strongly adviced to run the command wifiotahostedmcu via the console. This will then install the most recent ESP-Hosted-MCU firmware matching the installed build of ESPEasy.

Example of shown firmware of the secondary ESP and the firmware version expected in ESPEasy running on the ESP32-P4:

Since the state the WiFi firmware of a freshly installed ESP32-P4 is unknown, I have for now set the wifi STA adapter to 'disabled' by default. The Ethernet interface will be set active. (as long as there aren't any new boards with a different Ethernet chip)
To set the WiFi STA interface to enabled, you can call:

networkenable,1

This is also why WiFi STA is always index 1 and WiFi AP is index 2.
N.B. there is of course also a networkdisable

I am still thinking about whether we may also need a networkactive or ActivateNetwork (and the deactivate counterpart) as you may want to toggle this via rules also without changing the enabled/disabled state.
The 'active' state is a runtime variable while enabled/disabled is stored in the settings.
So I like some input from you, the testers.

When getting stuck or locked out of an ESPEasy node due to incorrect network settings, there are 2 new commands:

• NetworkExportConfig
• NetworkImportConfig

See: https://espeasy.readthedocs.io/en/latest/Network/_Network.html#export-import-network-parameters

NAPT

(ESP32-only)

Another new feature is NAPT for the WiFi-AP.
This allows ESPEasy to act as a router/gateway.

Traffic while forwarding using NAPT on an ESP32-P4: (values are in Bytes, not bits)

On an ESP32-P4 when routing traffic from WiFi AP to Ethernet, a network speed of 10 - 20 Mbps was possible.
Other ESP32 boards (even WiFi AP to WiFi STA) managed to forward 2 - 5 Mbps.
The only outlier is the ESP32-S3. For some unknown reason this one is much slower at 100 - 300 kbps and may even crash when using multiple connections like when using speedtest.net.

N.B. Make sure to uncheck "Force /setup in AP-Mode" when routing using NAPT.

New supported ESP chips & web(flasher) tools

Now a bit about the other changes.

As can be seen here: https://espeasy.readthedocs.io/en/latest/ESPEasy/ESPchips.html
There are a lot of new chips supported:

• ESP32-C5 which has also 5 GHz WiFi (and WiFi-6 like the ESP32-C6)
• ESP32-C61, similar to the ESP-C6 but with PSRAM, lower clock speed and no Zigbee/Thread support (not yet supported in ESPEasy)
• ESP32-P4/ESP32-P4X As discussed above, a chip without RF hardware.

A special note about the ESP32-P4/ESP32-P4X
Espressif did recently introduce a new (incompatible) silicon version of the ESP32-P4.
And to make the confusion even worse, it is unclear how to distinguish both versions as the new version is called "ESP32-P4" and the older version is renamed internally by Espressif from "ESP32-P4" to "ESP32-P4-ES" as in "Engineering Sample"
The only way to detect which version it is, is looking at the silicon revision, which is either 1.x or 3.x.
The Espressif official store on AliExpress calls the new dev boards "ESP32-P4X" and this extra "X" is also used in their product selector. Nowhere else this extra "X" is being used.

The web flasher does detect which board is present and does select the correct build.
When in doubt, you can also use this really useful web tool: https://thelastoutpostworkshop.github.io/ESPConnect/
It tells you a lot about your ESP, allows you to inspect the stored files on the file system, make backups, etc.
I highly recommend it to bookmark.

Another great tool for when you may experience flashing issues using the ESPEasy web flasher is this one: https://jason2866.github.io/esp32tool/

Another new concept: Interfaces

We moved the I2C and SPI config from the Hardware tab to the new Interfaces tab.
Also there are now multiple SPI buses supported and depending on how long ESPEasy wasn't updated, also multiple I2C buses :)
To make the web UI a bit less crowded, unused buses (and multiplexers) are 'folded'.
Later we will also add other bus types like Modbus RTU, Mbus and others.

N.B. for some builds, the previously set defaults may no longer be the same defaults. (as they were not the actual defaults of the chip)
So if before a non-custom SPI config was chosen, you may need to change the settings to a custom config and enter the pins manually.

Logging

Since a lot of crashes in the past were caused by processing logs, either due to memory issues, failed sending to syslog, etc. I decided to redesign how logs are being handled.

Now there is a single log queue and there are several log consumers.
A log consumer 'subscribes' to some log level.
For example syslog may subscribe to LOG_LEVEL_ERROR, while weblog may subscribe to LOG_LEVEL_DEBUG and serial only to LOG_LEVEL_INFO.
When a log message has no more subscribers or simply exceeds its timeout, it will be removed from the log queue.
the timeout depends on:

• Log level
• Amount of free memory

This way, a log message exists only once in memory (well... for a short time a copy is made while being processed by a log consumer) and a log message may also just contain a pointer (and a small header incl timestamp and subscriber flags) if only a flash string is sent to the log.

This consumer/producer approach is way more efficient and resource friendly.

Still todo: Sending to syslog is using the default route, which may not even be reachable via that interface.

SendToHTTP and HTTP controllers connecting to HTTPS

Access to HTTPS is now working as expected using a new library.
Also the new command to update the ESP-Hosted-MCU firmware is fetching this file via HTTPS.

Tools -> PinStatesBuffer

For ESP32-only
There is now an elaborate table showing the internal states of used GPIO pins and which peripheral is using it.
This can be useful for debugging, or understanding why something behaves the way it does. (e.g. pull-up or -down resistor enabled)

Key-Value writers

A significant part of the internal processing in ESPEasy already has been converted in using the new key-value pair writers. This allows to either write HTML to the web interface or JSON by simply changing the writer.
This greatly simplifies the code, reduces code duplication and also made processing quite a lot faster.

It will also allow for future ideas like 'headless' nodes which may be accessed only via a proxy node. This would then hopefully allow for smaller builds or maybe even distributed resources among nodes. (and other ideas I have)

MQTT AutoDiscovery

Ton had put a lot of effort in adding MQTT Auto Discovery.
See: https://espeasy.readthedocs.io/en/latest/Controller/C005.html#mqtt-auto-discovery
As first initial test, you may want to start with a sysinfo task, as this already sets the correct units-of-measure.
Almost all other plugins that can set a default UoM may do so, but there are others like the 'dummy' which simply cannot set a unit-of-measure automatically.

Well there are quite a few other new features and concepts, but I guess this is already a good start :)

Please let me know what is working and what not.

Known issues:

• Conversion of existing Ethernet config may not always work well. Best to make a screenshot first before updating to know which pins are being used.
• With Ethernet active and no configured WiFi, there are lots of attempts to restart services
• ESP32-P4 with factory image on ESP32-C6 with version 0.0.6 may cause crashes of ESP32-P4 board (also latest ESP32-P4X board)
• Maybe some defaults for networking when importing existing settings are not the most intuitive
• NeoPixel plugins do not work on ESP32-S3 OPI PSRAM builds. Use ESP32-S3 build without PSRAM for addressable LEDs
• WiFi credentials set via the /setup page are stored in "WiFi Credentials Extra", but somehow this can sometimes be interpreted as 'no credentials set'.
• Conversion of existing SPI defaults may not be automatically converted to a 'custom' SPI config.
• PWM fade causes watchdog crashes: [ledc] ledcFade causes wdt timeout on ESP32-classic espressif/arduino-esp32#12709

Suggested fixes/changes:

• Add IP-config for AP-mode: [Test build] Testers for new upcoming build (June '26) #5534 (comment)
• Change of DNS hostname, maybe change the -AP and not change the -WiFi ???
• Tools icon not clear/intuitive
• /download missing in some builds
• %iswifi% no longer working
• Add DEFAULT_xxx for netenable/disable
• Do not re-init ESPEasy console on Serial0 after loading settings
• Captive Portal is not working well on some ESP32-xx variants (all???)
• Wifi may sometimes need 5 minutes to detect it is disconnected and needs to reconnect.
• Sorting variables numerical instead of alfabetical

[fly74]

Wow. Can the network in/out made accessible via prometheus metric?

in testing:

ESP_Easy_mega_20260420_climate_A_ESP8266_4M1M
ESP_Easy_mega_20260420_display_B_ESP32_4M316k
ESP_Easy_mega_20260420_neopixel_ESP32_4M316k
ESP_Easy_mega_20260420_normal_ESP32_4M316k
ESP_Easy_mega_20260420_normal_ESP8266_4M1M

[fly74]

First little issue:

ESP_Easy_mega_20260420_display_B_ESP32_4M316k
ESP_Easy_mega_20260420_neopixel_ESP32_4M316k

changed the dnshostname at the router to host"-Wifi" after the update, took me a moment to catch it. But can be a router related thing.

ESP_Easy_mega_20260420_climate_A_ESP8266_4M1M has no /backup download.

The tools icon is not really good - looks like something is in warning state. 🔧 or 🛠️ would be better

[tonhuisman]

Can the network in/out made accessible via prometheus metric?

What metrics would you expect to be included?

[fly74]

Can the network in/out made accessible via prometheus metric?

What metrics would you expect to be included?

TX Bytes / RX Bytes

[fly74]

In rule %iswifi% don't work anymore - it is always =1

if %iswifi%=7
  NeoPixel,3,0,255,0
else
  NeoPixel,3,255,0,0
endif

[tonhuisman]

Hmm, %is...% variables have the intent to return a boolean value, so in rules that would be either 0 or 1. But except for this one I see. The massive changes in the networking code are the cause, probably one of the items to fix.

[TD-er]

Yep, is almost certain a newly introduced bug and for sure something that never occured to me to test.
So good find :)

[TD-er]

First little issue:

ESP_Easy_mega_20260420_display_B_ESP32_4M316k ESP_Easy_mega_20260420_neopixel_ESP32_4M316k

changed the dnshostname at the router to host"-Wifi" after the update, took me a moment to catch it. But can be a router related thing.

This was intended, but maybe better to change the hostname of the AP and not the -WiFi ?
I did mention this in the changes in the first post as it has to do with multiple interfaces being active causing issues on the network (and for sure also with mDNS)

ESP_Easy_mega_20260420_climate_A_ESP8266_4M1M has no /backup download.

The tools icon is not really good - looks like something is in warning state. 🔧 or 🛠️ would be better

The rest of your issues, I noted at the end of the first post so I can later find them when looking into those.

[wutz-ESP]

Controllers - FHEM HTTP have some problem if Append Unit Number to hostname is active
(same in Git Build: mega-20220328)

If hostname is configured like this working like expected

**-

Append Unit Number to hostname**

ESP_Easy 177 - ESP_Easy_mega_20220328_normal_ESP8266_4M1M Mar 28 2022

[fly74]

Hmm, %is...% variables have the intent to return a boolean value, so in rules that would be either 0 or 1. But except for this one I see. The massive changes in the networking code are the cause, probably one of the items to fix.

Must not be fixed, if now is 1 connected and 0 is not it is ok. I don't know why it was 7 before as integer.

[wutz-ESP]

WT32-ETH01 updated from Build20240822 network WiFi, Ethernet and AP
.

. . .

[tonhuisman]

ESP_Easy_mega_20260420_climate_A_ESP8266_4M1M has no /backup download.

That's because the TAR backup option is disabled for LIMIT_BUILD_SIZE builds, to reduce the build-size by ca. 5kB and make these builds fit again in the limited available space 😅

[TD-er]

WT32-ETH01 updated from Build20240822 network WiFi, Ethernet and AP

Is this what you expected, or is there something non-intuitive?

I guess the best option for your use case is to make the WiFi STA also marked as 'fallback', so it will then only use the STA interface when ETH is not connected.

[TD-er]

Controllers - FHEM HTTP have some problem if Append Unit Number to hostname is active (same in Git Build: mega-20220328)

If hostname is configured like this working like expected

I'm not 100% sure I see the problem here.
Calling the node "ESPEasy" and set the unit nr to '123' with that append checkbox checked should result in a hostname "ESPEasy-123"
And if you already name the unit "ESPEasy_123", with that checkbox checked it will be "ESPEasy-123-123" (underscore is changed to '-' when creating the hostname)
Without it being checked, it is "ESPEasy-123".

So is the main problem that we need some warning somewhere (e.g. in the docs)?