[e131] Fix E1.31 on ESP8266 and RP2040 by restoring WiFiUDP support#14086
[e131] Fix E1.31 on ESP8266 and RP2040 by restoring WiFiUDP support#14086
Conversation
|
To use the changes from this PR as an external component, add the following to your ESPHome configuration YAML file: external_components:
- source: github://pr#14086
components: [e131]
refresh: 1s(Added by the PR bot) |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #14086 +/- ##
=======================================
Coverage 74.11% 74.11%
=======================================
Files 55 55
Lines 11590 11590
Branches 1578 1578
=======================================
Hits 8590 8590
Misses 2598 2598
Partials 402 402 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
8a72b8f to
5209440
Compare
Memory Impact AnalysisComponents:
📊 Component Memory Breakdown
🔍 Symbol-Level Changes (click to expand)Changed Symbols
New Symbols (top 15)
Removed Symbols (top 15)
This analysis runs automatically when components change. Memory usage is measured from a representative test configuration. |
The socket abstraction layer on ESP8266/RP2040 (USE_SOCKET_IMPL_LWIP_TCP) only supports TCP. When E1.31 was migrated from WiFiUDP to sockets, it silently broke on these platforms since SOCK_DGRAM requests get TCP sockets that never receive UDP data. Restore WiFiUDP as the transport on LWIP_TCP platforms while keeping the socket-based implementation on BSD/LWIP socket platforms (ESP32, etc.). This follows the same dual-path pattern used by the udp and wake_on_lan components.
5209440 to
fe57153
Compare
There was a problem hiding this comment.
Pull request overview
This PR fixes a critical bug where E1.31 (sACN) stopped working on ESP8266 and RP2040 platforms after PR #4832 migrated the component from WiFiUDP to the socket abstraction layer. The socket implementation on these platforms (USE_SOCKET_IMPL_LWIP_TCP) only supports TCP, causing E1.31 UDP packets to never be received. The fix restores WiFiUDP for LWIP_TCP platforms while keeping the socket-based implementation for platforms with full socket support (ESP32, etc.), following the established dual-path pattern used by the udp and wake_on_lan components.
Changes:
- Added conditional compilation to use WiFiUDP on ESP8266/RP2040 (LWIP_TCP) and socket API on other platforms (BSD_SOCKETS/LWIP_SOCKETS)
- Modified destructor, setup(), and loop() methods to handle both transport mechanisms
- Guarded socket_ nullptr check to only compile on platforms with socket support
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| esphome/components/e131/e131.h | Added conditional includes for socket.h vs WiFiUdp.h and conditional member variable (socket_ vs udp_) based on platform |
| esphome/components/e131/e131.cpp | Added dual-path implementation in destructor, setup(), and loop() for socket vs WiFiUDP transport |
| esphome/components/e131/e131_packet.cpp | Added preprocessor guard around socket_ nullptr check so it only compiles on socket-supporting platforms |
|
thanks |
PR esphome#14086 added #if/#elif/#endif guards for LWIP TCP support in loop(). PR esphome#14133 then unified the BSD sockets path using read_() and removed the #if and #endif, but the merge left the #elif and its #endif from esphome#14086 intact, causing a #endif without #if compile error. Restore the opening #if guard to match setup() and the destructor. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
What does this implement/fix?
The socket abstraction layer on ESP8266/RP2040 (
USE_SOCKET_IMPL_LWIP_TCP) only supports TCP. When E1.31 was migrated from WiFiUDP to the socket abstraction in #4832, it silently broke on these platforms —SOCK_DGRAMrequests get TCP sockets that never receive UDP data.This restores WiFiUDP as the UDP transport on
LWIP_TCPplatforms while keeping the socket-based implementation on BSD/LWIP socket platforms (ESP32, etc.). This follows the same dual-path pattern already used by theudpandwake_on_lancomponents.Changes:
e131.h: Conditionally includesocket/socket.horWiFiUdp.hand declare the appropriate member (socket_vsudp_)e131.cpp: Add#elifdual paths in destructor,setup(), andloop()for socket vs WiFiUDP. The WiFiUDP path uses awhile (parsePacket())loop to drain all pending packets per loop call, matching the original pre-Migrate e131 to use socket instead of WiFiUDP arduino library #4832 behavior.e131_packet.cpp: Guardsocket_ == nullptrcheck so it only compiles on platforms that have thesocket_memberTypes of changes
Related issue or feature (if applicable):
Pull request in esphome-docs with documentation (if applicable):
Test Environment
Example entry for
config.yaml:Test sender script
Install
sacn(pip install sacn) and run to verify E1.31 reception. Sweeps red, green, blue at 50 FPS:Checklist:
tests/folder).If user exposed functionality or configuration variables are added/changed: