You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-**Enhanced ePaper Display Support** - New unified SPI ePaper component
28
-
-**Security Enhancements** - SHA256 OTA authentication and password deprecation
28
+
-**Security Enhancements** - SHA256 OTA authentication, password deprecation, and API hardening with OOM protection
29
29
-**API Improvements** - Home Assistant action responses and configurable connection limits
30
30
-**Extensive Memory Optimizations** - Flash and RAM savings across all platforms
31
31
-**New Sensor Components** - WTS01 and LM75B temperature sensors
32
32
33
33
## Z-Wave Proxy
34
34
35
35
The new {{< docref "/components/zwave_proxy" >}} component enables network-based connectivity for Z-Wave hardware
36
-
by proxying serial communication between a Z-Wave modem SoC and Z-Wave JS over WiFi or Ethernet.
36
+
by proxying serial communication between a Z-Wave modem SoC and Z-Wave JS over WiFi or Ethernet. This component was
37
+
specifically designed for the [Home Assistant ZWA-2 Z-Wave Adapter](https://www.home-assistant.io/connect/zwa-2/), which combines an ESP32 and a Z-Wave modem in a single device, but could support other Z-Wave hardware in the future.
37
38
38
39
**Key Features:**
39
40
@@ -47,24 +48,51 @@ by proxying serial communication between a Z-Wave modem SoC and Z-Wave JS over W
47
48
This component is particularly useful for optimizing Z-Wave mesh network topology by placing the Z-Wave controller in
48
49
a central location, even when your server is in a basement or closet.
49
50
50
-
## Arduino as IDF Component (Breaking Change)
51
+
## Arduino as IDF Component (Major Architectural Change)
51
52
52
-
A significant architectural change in this release integrates Arduino as an ESP-IDF component rather than a
53
-
separate framework. This unification brings:
53
+
This release includes a fundamental change in how ESP32 Arduino builds work - **Arduino is now integrated as an ESP-IDF component** rather than a separate framework. This is the biggest architectural change for ESP32 in ESPHome's history.
54
54
55
-
**Benefits:**
55
+
Previously, Arduino came as a precompiled framework with everything baked in - you got whatever upstream decided, whether you needed it or not. This led to bloated builds that often **couldn't even fit on devices** with limited flash space. You were stuck with the upstream choices and locked out of ESP-IDF features.
56
56
57
-
-**Better compatibility** between Arduino and ESP-IDF features
58
-
-**Simplified build process** with unified toolchain
59
-
-**Access to latest ESP-IDF features** while maintaining Arduino compatibility
60
-
-**Improved memory efficiency** through shared libraries
61
-
-**Future-proof architecture** aligning with Espressif's direction
57
+
Now Arduino is built as an ESP-IDF component alongside your configuration. ESPHome compiles only what you actually use, eliminating the bloat. You get access to ESP-IDF features while still using Arduino libraries when you need them. This aligns with Espressif's recommended approach and is how the Arduino ecosystem is evolving.
62
58
63
-
**Migration Notes:**
59
+
**Memory Savings:**
64
60
65
-
- Most configurations will work without changes
66
-
- Custom components may need minor adjustments
67
-
- Framework version handling has been improved (see breaking changes section)
61
+
-**20-30KB RAM savings** on Arduino builds
62
+
-**Additional ~8KB RAM savings** if using the web server
63
+
-**Smaller binary sizes** overall
64
+
- Better memory efficiency through shared libraries
65
+
66
+
**Development Benefits:**
67
+
68
+
-**Faster fixes for underlying components** - Many components now share the same implementations between Arduino and ESP-IDF, eliminating duplicate maintenance
69
+
-**Access to latest ESP-IDF 5.4** features while using Arduino libraries
70
+
-**Reduced maintenance burden** - One framework to maintain instead of two separate paths
71
+
-**Future-proof** - Follows Espressif's direction for the ESP32 ecosystem
72
+
73
+
**Build Time Trade-off:**
74
+
75
+
- Arduino builds now take longer (Arduino is compiled on top of ESP-IDF)
76
+
- ESP-IDF builds are now **2-3x faster** than Arduino builds
77
+
-**Consider migrating to ESP-IDF** if build time matters to you
78
+
79
+
### Should You Migrate to ESP-IDF?
80
+
81
+
**We recommend ESP-IDF for most users**, especially for:
82
+
83
+
- Bluetooth Proxy devices (lower memory usage)
84
+
- New projects
85
+
- Configurations where you want faster builds
86
+
87
+
Arduino is still fully supported and works great if you need it for specific Arduino libraries. See our {{< docref "/components/esp32#migrating-from-arduino" "Arduino to ESP-IDF migration guide" >}} for help switching - it's easier than you might think!
88
+
89
+
### What You Need to Know
90
+
91
+
**Most users:** Your configuration will work without changes. ESPHome handles the framework integration automatically.
92
+
93
+
**External component developers:** If you maintain external components using Arduino-specific APIs, review [Espressif's Arduino as ESP-IDF component documentation](https://docs.espressif.com/projects/arduino-esp32/en/latest/esp-idf_component.html) and test your components with this release.
94
+
95
+
**Breaking change details:** Framework version handling has been improved with stricter validation. See the breaking changes section for specifics.
68
96
69
97
## ePaper SPI Display Component
70
98
@@ -86,25 +114,74 @@ new architecture provides a more maintainable codebase for future ePaper display
86
114
87
115
## Security Enhancements
88
116
89
-
ESPHome 2025.10.0 significantly improves security with several key changes:
117
+
ESPHome 2025.10.0 significantly improves security with several key changes. We conducted an internal security audit that didn't find any privilege escalation issues but identified many hardening opportunities. We've addressed these in this release and will continue to focus on internal security testing in the coming months.
90
118
91
119
### SHA256 OTA Authentication
92
120
121
+
OTA authentication has been upgraded from MD5 to SHA256 for better security:
-**Hardware acceleration** on supported ESP32 variants (S3, etc.)
95
-
-**Backward compatible** transition period
96
125
-**Non-blocking authentication** for better performance
126
+
-**Graceful transition period** - Both SHA256 and MD5 are accepted through 2025.12.x
127
+
-**MD5 will be rejected starting with 2026.1.0** on platforms that support SHA256
128
+
129
+
During the transition, you'll see a warning when MD5 is used. After 2026.1.0, downgrading to older ESPHome versions will require serial flashing instead of OTA.
130
+
131
+
**Bonus improvement:** Extended handshake timeout (20s) makes OTA more reliable on poor WiFi connections without freezing the device.
97
132
98
-
### API Password Deprecation
133
+
### API Password Deprecation - Heads Up
99
134
100
-
-**API passwords are now deprecated** in favor of encryption keys
101
-
-**Mutual exclusivity** enforced between password and encryption
102
-
-**Improved security model** with modern cryptographic practices
103
-
-**Migration warnings** guide users to encryption-based authentication
135
+
If you're still using password authentication for the API, now's the time to switch to encryption. Password support will be removed in **version 2026.1.0**.
136
+
137
+
This release adds better warnings so you'll know if you need to update your configuration:
138
+
139
+
-**You'll see a clear warning** if you're using passwords - no surprises when support is removed
140
+
-**Can't use both** - if you try to configure both password and encryption, ESPHome will stop you (this combination has never worked properly and causes connection failures)
141
+
-**Easy migration** - just switch from `password:` to `encryption:` with a key
142
+
-**You have time** - password support works until 2026.1.0, giving you plenty of time to update
104
143
105
144
> [!warning]
106
-
> API password authentication is deprecated and will be removed in a future release. Please migrate to
107
-
> encryption-based authentication using the `encryption:` key.
145
+
> If you're using `password:` in your API configuration, please migrate to `encryption:` before version 2026.1.0.
146
+
> Password authentication will be removed at that time. You can't use both password and encryption together -
147
+
> pick one (and encryption is the better choice for security).
148
+
149
+
## Dashboard Improvements
150
+
151
+
The ESPHome Dashboard now uses WebSockets instead of HTTP polling for real-time updates:
152
+
153
+
-**Instant updates** - Device status changes appear immediately (no more 1-2 second polling delay)
154
+
-**Snappier interface** - Everything feels more responsive
155
+
-**Lower server load** - More efficient than constant HTTP polling
156
+
-**Logs start instantly** - The logs command now skips external component updates, eliminating 5-30 second delays when internet is unavailable
157
+
158
+
If you manage multiple devices, the dashboard will feel noticeably faster and more responsive. Viewing logs is now instant even in offline or isolated network environments.
159
+
160
+
## Device Onboarding Improvements
161
+
162
+
Getting your ESPHome devices online has never been easier. This release brings major improvements to the initial setup experience, particularly for ESP32-IDF devices and the [Made for ESPHome](https://esphome.io/guides/made_for_esphome/) program.
163
+
164
+
### Captive Portal for ESP-IDF
165
+
166
+
**This is huge.** ESP-IDF devices now have full captive portal support, which means you don't have to figure out which IP address to type into your browser anymore. When you connect to the device's access point, your phone or computer automatically detects the captive portal and opens the configuration page - just like connecting to hotel or airport WiFi.
167
+
168
+
This brings ESP-IDF up to feature parity with Arduino for onboarding, and since most new ESPHome devices are running ESP-IDF, this dramatically improves the out-of-box experience. The implementation includes a lightweight DNS server that runs in ESPHome's event loop, responding to all DNS queries with the device's IP address to trigger captive portal detection on iOS, Android, and other platforms.
169
+
170
+
### Improved Improv BLE Performance
171
+
172
+
[Improv Wi-Fi over BLE](https://www.improv-wifi.com/ble/) is the standard way to provision ESPHome devices over Bluetooth, and we've made it significantly faster and more reliable:
173
+
174
+
**Performance improvements:**
175
+
176
+
-**26x faster service lookups** for typical 3-service configurations by replacing HashMap with vectors
177
+
-**1KB flash savings** plus reduced RAM usage
178
+
-**Better discoverability** - Device names are now visible to passive BLE scanners, making ESPHome devices easier to find on a wider range of BLE scanning technologies
179
+
180
+
**Why passive scanning matters:** Many home automation systems and BLE scanners only support passive scanning (not active scanning). Making the device name visible to passive scanners means your devices show up in more scanning apps and are easier to identify during setup.
181
+
182
+
These improvements directly support the [Made for ESPHome program](https://esphome.io/guides/made_for_esphome/), which requires Improv provisioning via BLE for Wi-Fi projects to ensure a consistent, high-quality setup experience across all ESPHome-compatible products.
183
+
184
+
The Made for ESPHome program requires Improv BLE provisioning for Wi-Fi projects. See the [certification requirements](https://esphome.io/guides/made_for_esphome/) for details.
108
185
109
186
## Home Assistant Action Responses
110
187
@@ -141,29 +218,34 @@ inclusion and saving memory.
ESPHome 2025.10.0 brings major memory efficiency improvements, with **nearly 3KB of RAM savings** on typical configurations. As ESPHome has grown more capable over the years, memory usage has naturally increased with new features. ESP8266 devices with their ~40KB of free RAM were starting to feel the squeeze, and ESP32-C3 Bluetooth proxies were experiencing stability issues under load.
145
222
146
-
**Flash Savings:**
223
+
**We've made these use cases much better.** Through systematic optimization efforts, we've reclaimed precious RAM and improved stability across the board. ESP8266 users get more headroom for complex configurations. ESP32-C3 Bluetooth proxy users get better stability with multiple active connections. All platforms benefit from faster performance and lower memory overhead.
147
224
148
-
- **Lock component**: 388 bytes flash + 23 bytes RAM per lock via bitmask optimization
149
-
- **ESP32 BLE Server**: 1KB flash + 26x faster service lookups using vectors instead of HashMap
- **Logger**: 35-72% faster log formatting through optimized string handling
152
-
- **Web Server**: Significant reduction through lookup tables and IDF server unification
225
+
The improvements come from replacing heavy C++ STL containers (vectors, maps, sets) with lighter alternatives and moving data from RAM to flash storage where possible. Each optimization might save a few hundred bytes, but they add up quickly when applied across the codebase.
226
+
227
+
**This is just the beginning** - we're continuing this optimization work in 2025.11.0 and beyond. Expect more memory savings and performance improvements in upcoming releases.
228
+
229
+
**RAM Savings:**
153
230
154
-
**RAM Optimizations:**
231
+
- **~3KB total RAM savings on ESP8266, ~1-2KB on ESP32** from all optimizations combined
232
+
- **Lock component**: 388 bytes flash + 23 bytes RAM per lock via bitmask optimization
233
+
- **ESP32 BLE Server**: 1KB flash savings by replacing HashMap with vectors (26x faster lookups)
- **Script names**: Moved to flash storage instead of RAM
237
+
- **Component metadata**: Named structs replace std::pair overhead
238
+
- **API**: Zero-copy techniques eliminate unnecessary data copying in Bluetooth proxy, Z-Wave proxy, and base API calls (authentication, time zones), reducing allocations and improving performance
155
239
156
-
- **StaticVector** for mDNS/OpenThread services with compile-time capacity
157
-
- **Script names** stored in flash instead of RAM
158
-
- **Component metadata** using named structs instead of std::pair
159
-
- **Reduced allocations** through zero-copy API techniques
240
+
**Performance Improvements:**
160
241
161
-
**Architecture Improvements:**
242
+
- **Logger**: 35-72% faster log formatting through optimized string handling
243
+
- **Web Server**: Significant reduction through lookup tables and IDF server unification
If you contribute to ESPHome or maintain external components, you'll notice some big improvements to the development experience:
274
+
275
+
**CI Testing Improvements:**
276
+
277
+
- **Much faster CI for large PRs** - Large PR test time reduced from ~1 hour to ~20 minutes through intelligent component grouping
278
+
- **Release builds 6-7x faster** - Release test time reduced from 12+ hours to 1h40m
279
+
- **Smarter component testing** - Changed components get isolated test runners with full validation, while dependency-only components are grouped for speed
280
+
- **Better feedback loops** - Get results faster, making it easier to iterate on contributions
281
+
- **More reliable testing** - APT package caching (2m30s → 5s), retry logic for downloads, and utilization of a larger available disk partition (66GB instead of 23GB)
282
+
283
+
These improvements make it much easier to contribute to ESPHome by reducing wait times and making the CI system more efficient and reliable.
284
+
189
285
## Breaking Changes
190
286
191
287
ESPHome 2025.10.0 includes several breaking changes requiring attention:
0 commit comments