FAQ
TL;DR: OpenESP8266 now boots on 1MB, 2MB, 4MB, and 8MB ESP8266/ESP8285 boards, and one developer called the OTA fix "merge-ready" after partition issues were corrected. This FAQ helps builders flash, size, and troubleshoot OpenBeken on ESP8266-class hardware with ESP-Flasher or esptool. [#21597042]
Why it matters: ESP8266 support is usable for testing and many real devices, but flash mode, partition size, OTA headroom, and pin indexing still decide whether a build boots cleanly or crashes.
| Topic |
1MB flash |
2MB flash |
4MB/8MB flash |
| Firmware style seen in thread |
factory app |
OTA layout |
OTA layout |
| Example boot result |
confirmed boot |
confirmed boot after DOUT flashing |
confirmed boot |
| LFS space seen |
64KB |
128KB |
192KB in shown 4MB/8MB layouts |
| OTA status in thread |
fixed build exists |
fixed after partition change |
fixed after partition change |
Key insight: Most "bad firmware" symptoms in this thread were not random. They came from three concrete causes: wrong flash mode, wrong partition layout, or too little free flash/RAM for OTA and runtime features. [#21596825]
Quick Facts
- Boot logs in the thread show OpenESP8266 running with SPI flash sizes of 1MB, 2MB, 4MB, and 8MB. The reported AP fallback IP is 192.168.4.1 after first boot. [#21599222]
- A full device-hosted WebApp was measured at 287,278 bytes before aggressive minification and 195,261 bytes after complete minification, which is why gzip and LFS matter on small flash targets. [#21597082]
- On one stable ESP8285 1MB test, free heap stayed around 28,680–29,360 bytes with Wi-Fi connected and no extra drivers started. That is workable, but not generous. [#21599222]
- OTA failures were traced to partition layout first, then later to oversized builds and active runtime load. One failing OTA log showed a mapped segment of 732,660 bytes before image validation failed. [#21757126]
How do I flash OpenBeken/OpenESP8266 firmware onto an ESP8266 or ESP8285 with ESP-Flasher or esptool, including the correct boot mode wiring and flash address?
Flash the UART or factory image at address
0x0 with the chip in download mode. 1. Wire
TX↔RX, hold
GPIO0 to GND, and power the module. 2. In ESP-Flasher, write the image to
0x0; with esptool, the thread shows
write_flash 0 ...bin. 3. If boot fails on ESP8285-class boards, retry with
--flash_mode dout. One tester said the ESP-12F process was the same as ESP-01: GPIO0 low, normal serial wiring, flash to 0x0, and boot succeeded.
[#21757469]
Why does OTA update on OpenESP8266 fail with errors like "unaligned segment length 0xffffffff" or "image is corrupted" when the build gets too large?
OTA fails because the second app slot no longer has enough room for the new image. In one failing case, the OTA log mapped a segment of
732,660 bytes and then reported
unaligned segment length 0xffffffff and
Image validation failed. Later testing showed OTA started working again after removing some compiled drivers and, in practice, stopping running drivers before update. The thread ties this to image size and memory pressure, not to Wi-Fi alone.
[#21758993]
What is LFS in OpenBeken/OpenESP8266, and why do logs show messages like "lfs is absent" after first boot?
LFS is a small on-device file system used to store files such as scripts and WebApp assets.
"LFS is a flash file system that stores user files inside a dedicated partition, separate from the app image, so firmware can read scripts or web assets after boot." Fresh boots often show
lfs is absent because the partition exists in the table but no files have been uploaded yet. The same logs also show
failed to get file autoexec.bat, which matches an empty LFS rather than a bad firmware flash.
[#21595385]
What is GPIO_NUM_NC in the ESP8266 pin mapping, and how is it used for hidden or non-usable pins like flash-connected GPIOs?
GPIO_NUM_NC marks entries that exist in the index map but should not be driven as real GPIOs. In the proposed ESP8266 remap, indexes
6, 7, 8, and 11 were set to
GPIO_NUM_NC, labeled
NC, and hidden in the UI so the index numbers could line up with real IO names like
IO12 and
IO16. The same discussion added a separate
ADC entry while keeping unusable flash-connected pins out of normal configuration.
[#21759275]
Which partition layout should I use for OpenESP8266 on 1MB, 2MB, 4MB, and 8MB flash chips?
Use the layout that matches the actual flash size and OTA strategy shown by the working boots. The 1MB build used
nvs at 0x9000,
factory app at 0x10000, and
lfs at 0x0f0000. The working 2MB DOUT build used
otadata,
app0 at 0x10000,
lfs at 0x0f0000,
app1 at 0x110000, and
nvs at 0x1f0000. The 4MB and 8MB examples kept
app0/app1 at 0x10000 and 0x0f0000 with larger LFS space around
0x1d0000.
[#21597261]
Why does an ESP8266 or ESP8285 boot only after flashing with --flash_mode dout, even when the boot log later reports QIO?
Because the flash write mode used during programming can still decide whether the image lands in a bootable form. In the thread, a
1MB ESP8285H08 booted only after
esptool write_flash 0 ... --flash_mode dout, even though the later log still printed
SPI Mode : QIO. A separate
2MB case also failed until a flasher run produced a boot log that explicitly showed
SPI Mode : DOUT. The practical fix was simple: use DOUT when the module refuses to boot after normal flashing.
[#21599222]
What’s the difference between ESP8266 and ESP8285 when running OpenBeken, especially regarding RAM, internal flash, and supported firmware sizes?
They run the same firmware class with the same RAM budget, but they differ in flash packaging. One developer stated that
ESP8266 and ESP8285 have the same amount of RAM, while
ESP8285 has built-in 1MB flash and
ESP8266 uses external SPI flash. That is why the thread shows ESP8285 tests mainly on
1MB and
2MB parts, while ESP8266 boards were tested with
2MB, 4MB, 8MB, and even 16MB-modified hardware. Runtime limits still come mostly from RAM, not just flash size.
[#21599257]
How does OpenESP8266 OTA from Tasmota differ from normal OBK OTA, and why does the RTOS SDK vs NONOS SDK mismatch matter?
Tasmota-to-OpenESP8266 OTA is not the same as normal OpenBeken OTA because the frameworks differ. The thread states that Tasmota uses the
Arduino framework with NONOS SDK, while OpenESP8266 uses
ESP8266 RTOS SDK, so their image expectations and upgrade paths are incompatible by default. A manual bridge is possible only with a special FOTA workflow from Espressif. Standard OBK OTA assumes an RTOS-compatible partition layout and image format, which is why direct Tasmota-style upgrades are not the normal path.
[#21597062]
Why is the DHT11 or other sensor shown on the wrong pin number in the OpenESP8266 home page or console when using higher GPIOs like IO14-IO16?
The display is wrong because the UI and some console paths used pin indexes instead of real GPIO aliases. The thread shows DHT11 configured on
GPIO14 appearing as
pin 10, and other tests found pins
14–16 displayed as
10–12. One maintainer explained that this happens because
IO6–IO8 are flash pins and were removed from the visible list, so later entries shift. The sensor was not necessarily wired wrong; the mapping layer was.
[#21691202]
What causes Wi-Fi connection problems on OpenESP8266, including first-connect issues, reconnect bugs, and failure to join WPA3 networks?
Early Wi-Fi failures came from unfinished porting, and WPA3 still did not work in the thread. One developer explicitly posted that they
fixed Wi-Fi first connect and reconnect, and later testers confirmed the Wi-Fi fix. By contrast, a later log shows repeated handler warnings and immediate disconnect when joining a
WPA3 SSID, with no IP address assigned. So first-connect and reconnect bugs were fixed during July 2025, but WPA3 remained unsuccessful in the reported tests.
[#21614400]
In OpenBeken on ESP8266, how should pin indexes map to real pin names like IO12 or IO16, and what is the best way to avoid confusion in startDriver commands?
Map indexes so they match real IO numbers, or accept string pin names in commands. The thread shows why users get confused: on the older ESP8266 mapping,
IO12 could require index
8 in
startDriver, not
12. A proposed fix used
NC placeholders for missing pins so
index 12 equals IO12 and
index 16 equals IO16. Another maintainer preferred parsing names like
IO12 directly in commands, which avoids platform-specific mental math entirely.
[#21759160]
Where does the free heap go on ESP8266 when enabling MQTT, Home Assistant discovery, Berry, or multiple drivers, and how can low-memory crashes be reduced?
It goes into protocol buffers, task stacks, HTTP client work, and discovery payloads, and ESP8266 does not have much spare RAM. One report shows free heap dropping from
34,284 to
16,812 bytes after Home Assistant discovery, with malloc failure causing a crash. Berry also triggered a
Stack canary watchpoint in the HTTP client path, and maintainers said there is simply not enough RAM for heavy features together. Reduce crashes by compiling fewer drivers, disabling active drivers during OTA, and avoiding Berry execution through the HTTP client path.
[#21819086]
Which OpenBeken features have been confirmed working on ESP8266 so far, such as PWM, UART, DHT, DS18B20/DS1820, BMP280, ADC, Charts, MAX72XX, and WebApp hosting?
Many core features now work, but some remain rough. Confirmed in the thread are
PWM,
UART, Wi-Fi reconnect,
DHT11/DHT22,
DS18B20/DS1820,
BMP280,
Charts,
MAX72XX, and device-hosted
WebApp tests. ADC was later added to HAL and UI work was underway. Limits remain: PWM was once inverted, GPIO0 PWM could bootloop, OTA had size limits, and some sensor timing on ESP8266 needed hacky workarounds. Still, by late 2025 multiple testers had real, repeatable success across these drivers.
[#21758993]
How can gzip-compressed WebApp files be stored and served from LFS in OpenBeken to save flash space on ESP8266 and other small devices?
Store the WebApp files precompressed in LFS and return them with
Content-Encoding: gzip. The thread proposed an LFS lookup that checks for
filename.gzip first, then streams that compressed file while keeping a normal fallback path. A maintainer then implemented an
"upload as GZIP" button and simple gzip header handling in firmware so the browser decodes the file on the fly. This matters because the fully minified WebApp was measured at
195,261 bytes, which is large for small-flash targets.
[#21601376]
ESP8266 vs Tasmota for OpenBeken migration: which JSON naming and sensor reporting conventions should be followed for compatibility with DS18B20, MQTT, and external scripts?
Follow Tasmota naming where possible, especially for DS18B20 JSON keys. The thread shows a real compatibility issue: OpenBeken originally reported
DS1820, while Tasmota used
DS18B20, forcing external scripts to handle both keys. Maintainers agreed that OBK should follow the Tasmota standard, then changed it and also checked Tasmota’s multi-sensor format using names like
DS18B20-1 with an
Id field. That keeps MQTT consumers and simple PHP or Home Assistant tooling more portable.
[#21702907]
Generated by the language model.
