>>21651947 I think all of mine can be merged, even 3.0.78.
LN882H IR while enabled by default, there is still a lot of free space remains. Even if everything in OBK was to be enabled, there would still likely be about 50-100kb free of ota space.
ESP-IDF is just update from v5.5 to v5.5.1. It only brings ESP32-C61 v1.0 support (currently only beta chips works, and with this update support for them was dropped).
TXW is in acceptable enough state.
were there any concerns still @p.kaczmarek2@max4elektroda? is it because it's quite a big change?
I would think it's safe to merge - we "only" change "HAL_Delay_us()", used in DHT and DS1820 driver.
The platforms affected from this change either still work with this PR, or (the ones not working before) do work with it.
There is only one discussable point I think, which is the new possibility to test HAL_Delay_us() on pins, wich can be enabled with "ENABLE_DS1820_TEST_US".
It's disabled now for all platforms, so it's no more than an option now..
I remember that the initial version of this PR (or similar one) broke timings on DHT or something, but if that's not the case anymore, I am happy to merge it.
it boots fully and creates connectable AP.
Wifi scan sees 5ghz networks.
My C5 also arrived. Had some problems how to connect for some tests but came up with the idea to fit it into my universal adapter.
Needed some paper to fit (though it should be 18mm as WROVER module), so right row is isolated, but the left row connects o.k.
To get infos or flash I used esptool with "--no-stub" (else got "A fatal error occurred: Unable to verify flash chip connection (No serial data received.)."
esptool.py -p /dev/ttyACM0 --no-stub -b 921600 write_flash 0 OpenESP32C5_1.18.171_4M.factory.bin
esptool.py v4.8.0
Serial port /dev/ttyACM0
Connecting...
Detecting chip type... ESP32-C5
Chip is ESP32-C5 (revision v1.0)
Features: WiFi 6, BT 5, IEEE802.15.4
Crystal is 48MHz
MAC: XX:XX:XX:XX:XX
BASE MAC: XX:XX:XX:XX:XX
MAC_EXT: ff:fe
ROM expects crystal freq: 48 MHz, detected 48 MHz
Changing baud rate to 921600
Changed.
Enabling default SPI flash mode...
Configuring flash size...
WARNING: In case of failure, please set a specific --flash_size.
Flash will be erased from 0x00000000 to 0x0012ffff...
Erasing flash...
Took 1.64s to erase flash block
Wrote 1244160 bytes at 0x00000000 in 7.9 seconds (1267.3 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
AP is only in 2.4GHz Wifi, but in scan I see 5GHz APs (Channel 116)
There's an AT CMD based firmware, it won't react to my input on ACM tty (from USB - and sadly RX/TX are on the opposite side, I isolated to fixate the module)...
Spoiler:
W (1048) wifi:WDEV_RXCCK_DELAY:960
W (1048) wifi:WDEV_RXOFDM_DELAY:256
W (1048) wifi:WDEV_RX_11G_OFDM_DELAY:257
W (1048) wifi:WDEV_TXCCK_DELAY:630
W (1048) wifi:WDEV_TXOFDM_DELAY:94
W (1058) wifi:ACK_TAB0 :0x 90a0b, QAM16:0x9 (24Mbps), QPSK:0xa (12Mbps), BPSK:0xb (6Mbps)
W (1068) wifi:CTS_TAB0 :0x 90a0b, QAM16:0x9 (24Mbps), QPSK:0xa (12Mbps), BPSK:0xb (6Mbps)
W (1068) wifi:WDEVBEAMFORMCONF:0x61d7120, HE_BF_RPT_RA_SET_OPT:1
W (1078) wifi:WDEVVHTBEAMFORMCONF: 0x61d7120, WDEV_VHT_BEAMFORMEE_ENA: 1, WDEV_VHT_NG_SEL: 0
W (1088) wifi:(agc)0x600a7128:0xd21f0c20, min.avgNF:0xce->0xd2(dB), RCalCount:0x1f0, min.RRssi:0xc20(-62.00)
W (1098) wifi:MODEM_SYSCON_WIFI_BB_CFG_REG(0x600a9c18):0x10003802
W (1098) wifi:(phy)rate:0x0( LP-1Mbps), pwr:20, txing:20
W (1108) wifi:(phy)rate:0x1( LP-2Mbps), pwr:20, txing:20
W (1108) wifi:(phy)rate:0x2(LP-5.5Mbps), pwr:20, txing:20
W (1118) wifi:(phy)rate:0x3( LP-11Mbps), pwr:20, txing:20
W (1118) wifi:(phy)rate:0x5( SP-2Mbps), pwr:20, txing:20
W (1128) wifi:(phy)rate:0x6(SP-5.5Mbps), pwr:20, txing:20
W (1128) wifi:(phy)rate:0x7( SP-11Mbps), pwr:20, txing:20
W (1138) wifi:(phy)rate:0x8( 48Mbps), pwr:17, txing:17
W (1138) wifi:(phy)rate:0x9( 24Mbps), pwr:19, txing:19
W (1148) wifi:(phy)rate:0xa( 12Mbps), pwr:19, txing:19
W (1148) wifi:(phy)rate:0xb( 6Mbps), pwr:19, txing:19
W (1158) wifi:(phy)rate:0xc( 54Mbps), pwr:17, txing:17
W (1158) wifi:(phy)rate:0xd( 36Mbps), pwr:19, txing:19
W (1168) wifi:(phy)rate:0xe( 18Mbps), pwr:19, txing:19
W (1168) wifi:(phy)rate:0xf( 9Mbps), pwr:19, txing:19
W (1178) wifi:(phy)rate:0x10, mcs:0x0, pwr(bw20:19, bw40:18), txing:19, HE pwr(bw20:19), txing:19
W (1188) wifi:(phy)rate:0x11, mcs:0x1, pwr(bw20:19, bw40:18), txing:19, HE pwr(bw20:19), txing:19
W (1198) wifi:(phy)rate:0x12, mcs:0x2, pwr(bw20:18, bw40:17), txing:18, HE pwr(bw20:18), txing:18
W (1208) wifi:(phy)rate:0x13, mcs:0x3, pwr(bw20:18, bw40:17), txing:18, HE pwr(bw20:18), txing:18
W (1208) wifi:(phy)rate:0x14, mcs:0x4, pwr(bw20:17, bw40:16), txing:17, HE pwr(bw20:17), txing:17
W (1218) wifi:(phy)rate:0x15, mcs:0x5, pwr(bw20:17, bw40:16), txing:17, HE pwr(bw20:17), txing:17
W (1228) wifi:(phy)rate:0x16, mcs:0x6, pwr(bw20:17, bw40:16), txing:17, HE pwr(bw20:17), txing:17
W (1238) wifi:(phy)rate:0x17, mcs:0x7, pwr(bw20:17, bw40:16), txing:17, HE pwr(bw20:17), txing:17
W (1248) wifi:(phy)rate:0x18, mcs:0x8, pwr(bw20:19, bw40:16), txing:19, HE pwr(bw20:16), txing:16
W (1258) wifi:(phy)rate:0x19, mcs:0x9, pwr(bw20:18, bw40:16), txing:18, HE pwr(bw20:15), txing:15
W (1268) wifi:(hal)co_hosted_bss:0, max_indicator:0, bitmask:0xff, mBSSIDsEnable:0
I (1268) wifi:11ax coex: WDEVAX_PTI0(0x55777555), WDEVAX_PTI1(0x00003377).
I (1278) wifi:mode : sta (XX:XX:XX:XX:XX:XX)
I (1278) wifi:enable tsf
W (1288) wifi:(BB)enable busy check(0x18), disable idle check(0xaa)
I (1288) esp32c5_wifi: ==========Wi-Fi STA started==========
Scanning Wi-Fi networks...I (8058) esp32c5_wifi: ==========Wi-Fi scan completed==========
5G AP: XXSSID1XX, RSSI: -94 dBm, BSSID: XX:XX:XX:XX:XX:XX
5G AP: XXSSID2XX, RSSI: -94 dBm, BSSID: XX:XX:XX:XX:XX:XX
5G AP: XXSSID3XX, RSSI: -94 dBm, BSSID: XX:XX:XX:XX:XX:XX
WiFi tool ready. Send AT+HELP for command list
I (8078) main_task: Returned from app_main()
Added after 5 [minutes]:
max4elektroda wrote:
To get infos or flash I used esptool with "--no-stub" (else got "A fatal error occurred: Unable to verify flash chip connection (No serial data received.)."
>>21689071 Crashes because uart is already initialized in DMX_Init?
Don't know why flush freezes, and is it really needed? It is only for RX, not TX. For TX use uart_wait_tx_done. (https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/uart.html#_CPPv410uart_flush11uart_port_t)
Probably I could investigate exactly what's done there under the hood, but still wanted to get faster approach.
insmod wrote:
>>21689071 For TX use uart_wait_tx_done. (https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/uart.html#_CPPv410uart_flush11uart_port_t)
I will try
Added after 1 [hours] 45 [minutes]:
UPDATE: DMX works, more or less. I am still not sure why it seems that data seems to be applied with second call, but i will resolve it soon, hopefully. I will also finish LED backend split.
The code in WINDOWS block crashes ESP32 due to repeated UART init. The code in else works incorrectly (second call pushes data). Probably that's as far as I can go today.
Added after 44 [seconds]:
It would help a lot to scope the UART but I am not sure if I have time to set this up tonight.
I didn't know about uart_write_bytes_with_break, I may check it soon.
I've accepted cache PR, good idea.
For now, I'm still focusing on LEDs.
What kind of UI do we need for RGBW strip? Should we allow RGB and W control at the same time? Or show RGBCW and try to emulate cool with RGB like on bulbs...
And what do you think about caching toolchains in workflow to speed-up build process? In some cases it builds faster by more than 1 minute. Full build of everything is only 6m 36s (https://github.com/openshwprojects/OpenBK7231T_App/actions/runs/17720392809)
https://github.com/openshwprojects/OpenBK7231T_App/pull/1793
Can it be this somehow broke Windows simulator build in "my" repo @insmod ?!? It works o.k. (e.g. in PR#7169), but for the same "local" I get:
Project "D:\a\OpenBK7231T_App\OpenBK7231T_App\openBeken_win32_mvsc2017.vcxproj" on node 1 (default targets).
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.Cpp.WindowsSDK.targets(46,5): error MSB8036: The Windows SDK version 10.0.17763.0 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". [D:\a\OpenBK7231T_App\OpenBK7231T_App\openBeken_win32_mvsc2017.vcxproj]
Done Building Project "D:\a\OpenBK7231T_App\OpenBK7231T_App\openBeken_win32_mvsc2017.vcxproj" (default targets) -- FAILED.
Hello! I wanted to try flashing my ESP32-C3 device on openesp. This is a 4-sensor leak controller. When there is a leak, 2 valves close. The "IF" operator doesn't work; the controller reboots and provides an access point. Everything works well on the Beken chips. Here's the script:
Does not work. addChangeHandler Channel8 == 1 if $CH6==1 then "setChannel 11 1" Does not work. addEventHandler OnChannelChange 8 if $CH6==1 then "setChannel 11 1" Does not work.
addChangeHandler Channel8 == 1 if $CH6==1 then "setChannel 11 1"
What's the solution to make it work reliably? Write a script in Berry?
Added after 1 [hours] 39 [minutes]:
p.kaczmarek2 wrote:
Does it work when ran from console?
If so, then maybe stack size..
Thank you so much! It's working. Could you tell me how to make a global float variable for the water meters? I would like to make a pulse counter. Where each pulse is 10 L of water
I tried to install the berry module on the ESP32-C3, but it also goes to the access point when I restart it. Is there any way to save data in flash? Help
>>21818678 I thought about it, but considering how much code is needed and how many esp variants there are, i decided against it.
If baud is different from 115200, it fails on C2. Works on 32, C3, C5, C6, C61, S3
Synced with ESP32!
Configuring SPI flash pins (SpiAttach)...
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
SPI_ATTACH failed (no response or error status).
Failed to configure SPI pins.
Thanks for testing, it's just a little experiment. I'll probably move it to PR and hide in main tree until it works. That's not a high priority.
Maybe I should focus first on BK7238 RF issue - but I don't have yet full information. What's exactly going on there? Can't we, in OBK, just use Tuya's RF location?
>>21818985 As it is now, it can be said that it's precompiled into app.
Default addr = 0x1E0000, T1 - 0x1E3000. And 0x1E3000 is where flash vars are stored.
After flash vars are moved, hal_flash_init would need to be modified to scan flash and modify BK_PARTITION_RF_FIRMWARE address accordingly
https://github.com/NonPIayerCharacter/beken_f...eken378/func/user_driver/BkDriverFlash.c#L708
✨ The discussion centers on configuring OpenBeken firmware for ESP32 devices with a default 4MB flash size using sdkconfig.defaults.esp32. Initial issues included missing sdkconfig.defaults.esp32 and bootloader offset misconfiguration, which were resolved to enable successful compilation and flashing. Various ESP32 variants were tested, including ESP32-C3, ESP32-C6, ESP32-CAM, ESP32-C2, ESP32-D0WDQ5-V3 (ESP-WROOM-32), and ESP32-S3, with reports on flash size detection, bootloader behavior, and peripheral support. Challenges encountered involved stack overflows on reboot, watchdog timer resets, and GPIO functionality inconsistencies, particularly on non-C/S ESP32 boards. Solutions included adjusting makefiles for 4MB flash, fixing bootloader offsets, increasing task stack sizes, and replacing software timers with hardware timers for improved timing accuracy. Peripheral drivers such as BMP280, AHT2x, DS1820, DHT11/22, PWM, UART, and NTP were tested with varying success; some required specific pin assignments or additional delays to prevent crashes. Deep sleep support was added without GPIO wakeup. The firmware uses the Espressif ESP-IDF SDK for ESP32 and plans for ESP8266 porting were discussed, noting SDK differences and RAM constraints. Continuous integration (CI) and online build availability were confirmed. Users shared flashing tools, partition table considerations, and debugging tips including esptool flash_id and efuse burning. The community actively tested and reported logs, crashes, and feature functionality, contributing to iterative fixes and enhancements. Generated by the language model.
TL;DR: 4MB stało się domyślną bazą dla OpenESP32, a autor poprawki napisał: "Now configured with 4MB by default". Ten FAQ jest dla osób uruchamiających OpenBeken na ESP32 i wyjaśnia, jak dobrać build, rozwiązać błędy partycji, bootloadera, OTA, UART i Wi‑Fi na C2, C3, S2, S3 oraz klasycznym ESP32. [#21220790]
Dlaczego to ważne: Błędny rozmiar flash, zły offset bootloadera albo niewłaściwy typ obrazu potrafią dać „invalid header”, bootloop albo bezpieczny tryb AP mimo sprawnego sprzętu.
Wariant
Typowy flash z wątku
Co działało najlepiej
Najczęstszy problem
ESP32-C3
4MB
Wi‑Fi, OTA, PWM, czujniki I2C
SuperMini miewa problemy z Wi‑Fi i DHCP
Klasyczny ESP32
4MB, czasem wykrywany jako 2MB
GPIO, OTA, Wi‑Fi po poprawnym flashu
błędy tabeli partycji i safe mode po reboocie
ESP32-S2/S3
4MB lub 16MB
DS1820, GPIO, AP/STA po poprawkach
stack overflow, problemy z temperaturą wewnętrzną
ESP32-C2
4MB
podstawowe funkcje, PWM
mało RAM, czułość na taktowanie i baud
ESP8266
1MB, 4MB, 8MB po swapie
eksperymenty po rozdzieleniu wątku
zbyt mały flash dla dual-OTA przy 8Mbit
Najważniejszy wniosek: Na ESP32 najpierw dobierz właściwy obraz do realnego flashu i układu, a dopiero potem diagnozuj skrypty, UART lub Wi‑Fi. W wątku większość „magicznych” awarii okazała się skutkiem złego rozmiaru flash, złego offsetu bootloadera albo użycia factory.bin zamiast .img. [#21221363]
Quick Facts
Domyślna konfiguracja ESP32 została przestawiona na 4MB flash, bo brakowało sdkconfig.defaults.esp32; to była kluczowa poprawka startowa całego portu. [#21220790]
Na ESP32-C3 poprawny boot pokazał partycje app0 0x10000, app1 0x100000 i LFS 0x1EF000, przy wykrytym flashu 4MB oraz SPI 80MHz/DIO. [#21221080]
Jeden z modułów ESP32-C5 pobierał przy starcie AP około 1,4 W / 0,3 A przy 5 V, czyli w przybliżeniu 0,5 A przy 3,3 V; to tłumaczy brownouty przy słabym zasilaniu. [#21648381]
Dla problematycznych płytek ESP32-C3 SuperMini obniżenie mocy Wi‑Fi do 10 dBm, a nawet 6 dBm, poprawiało łączenie z DHCP. [#21450268]
W sterowniku BP5758D padały konkretne prądy robocze: domyślnie 14 mA, w ESPHome 10 mA, a w praktyce dla GU10 sprawdzało się nawet 8 mA na kanałach. [#21246766]
How do I configure OpenBeken on ESP32 to use 4MB flash by default with sdkconfig.defaults.esp32?
Dodaj brakujący plik sdkconfig.defaults.esp32 i ustaw w nim wariant 4MB jako domyślny dla ESP32. To właśnie ta zmiana odblokowała poprawny start portu i autor podsumował ją krótko: „Now configured with 4MB by default”. Jeśli tworzysz także obraz scalony, dopasuj --flash_size 4MB, bo samo SDK nie naprawi błędnego merge bin. [#21220790]
Why does OpenESP32 factory.bin fail to boot with partition table errors on some ESP32 boards that actually have 4MB flash?
Najczęściej dlatego, że obraz factory.bin został zmergowany z nagłówkiem 2MB, mimo że płytka ma fizycznie 4MB. W logu widać wtedy SPI Flash Size : 2MB, a zaraz potem błąd typu partition ... exceeds flash chip size 0x200000. W wątku poprawka polegała na zmianie polecenia esptool.py merge_bin z --flash_size 2MB na --flash_size 4MB, bez zmiany samej płyty. [#21221363]
What is the difference between OpenBeken factory.bin and non-factory .img builds on ESP32, and when should each one be flashed?
factory.bin to obraz scalony z bootloaderem, tabelą partycji i aplikacją, a .img to zwykle sam obraz aplikacji do istniejącego układu partycji. Gdy układ startuje od zera, po erase_flash, albo masz uszkodzone partycje, użyj factory.bin. Gdy bootloader i partycje już są poprawne, często bezpieczniej użyć .img; w wątku klasyczny ESP32 ruszył po przejściu z factory na non-factory. [#21221359]
How can I erase_flash and reflash OpenBeken correctly on ESP32, ESP32-C3, and ESP32-S2 boards when GPIOs or boot behavior seem broken?
Najbezpieczniej wykonaj pełne czyszczenie i dopiero potem ponowny flash. 1. Uruchom erase_flash, aby usunąć stare partycje, konfigurację i błędne autostarty. 2. Wgraj właściwy obraz dla układu i realnego flashu: factory.bin przy czystym starcie albo .img przy istniejących partycjach. 3. Na S2 wejdź w boot przez przyciski RST i 0, a potem sprawdź log i AP przed testem GPIO. Ten schemat przywrócił poprawne działanie LED-ów i factory.bin na kilku płytkach. [#21221622]
Why did the ESP32-C3 merge initially fail with invalid header errors, and how does the bootloader offset at 0x0 vs 0x1000 affect flashing?
Bo przy merge dla C3 bootloader trafił pod zły adres. Autor poprawki napisał wprost, że „bootloader must be at 0x0, instead of 0x1000”, a wcześniejszy układ dawał serię invalid header. Na ESP32-C3 boot ROM oczekiwał bootloadera od 0x0, więc obraz z offsetem 0x1000 wyglądał jak uszkodzony mimo poprawnego flashowania. [#21221037]
What causes OpenBeken script timing to run too slowly on ESP32, and how do QUICK_TMR_DURATION, vTaskDelay, and esp_timer_get_time relate to the fix?
Problem wynikał z błędnego liczenia g_deltaTimeMS i z niepoprawnego użycia opóźnienia FreeRTOS. Poprawa miała dwa elementy: dla ESP-IDF czas zaczęto brać z esp_timer_get_time()/1000, a w wątku timera zmieniono vTaskDelay(QUICK_TMR_DURATION) na vTaskDelay(QUICK_TMR_DURATION / portTICK_RATE_MS). To ograniczyło dryf, który wcześniej dawał wynik około MAIN:Time 150 przy kanale zwiększonym tylko do 121. [#21221114]
How do flash encryption flags and eFuse settings on an ESP32-C3 device affect whether OpenBeken can boot after flashing?
Włączone szyfrowanie flash może zablokować start zwykłego obrazu, nawet gdy sprzęt ma poprawne 4MB i sam flash zapisze się bez błędów. W wątku jeden ESP32-C3 miał Flash Encryption: Enabled i nie startował jak zwykła płytka deweloperska. Po zmianie eFuse tak, by raport pokazywał Flash Encryption: Disabled oraz SPI_BOOT_CRYPT_CNT: 0x3, urządzenie zaczęło bootować OpenBeken poprawnie. [#21221080]
What is LittleFS or LFS in OpenBeken, and why do ESP logs sometimes say 'lfs is absent' even when scripts appear to work later?
„LittleFS” jest lekkim systemem plików flash, który przechowuje skrypty, pliki startowe i inne dane trwałe, a jego kluczową cechą jest praca na wydzielonej partycji flash zamiast w RAM. Log lfs is absent oznacza zwykle brak zamontowanej partycji LFS lub jeszcze nieutworzony system plików. W wątku ten komunikat pojawiał się przy starcie, ale później testy pokazały, że skrypty i zapis zaczęły działać po dalszych poprawkach partycji i flashowania. [#21221088]
What is TCA9554, and why is that I2C expander needed to run OpenESP32 on boards like the Waveshare ESP32-S3-ETH-8DI-8RO?
„TCA9554” jest ekspanderem I2C, który dodaje 8 linii wejścia/wyjścia GPIO, a jego główną cechą jest sterowanie dodatkowymi sygnałami przez magistralę I2C zamiast bezpośrednio z MCU. Na płytce Waveshare ESP32-S3-ETH-8DI-8RO ten układ steruje sekcją przekaźników, więc bez jego obsługi OpenESP32 nie potrafi przełączać wyjść. Dlatego w wątku wskazano, że TCA9554 jest wymagany, aby ta płyta miała sensowną obsługę pod OpenESP32. [#21640201]
ESP32-C2 vs ESP32-C3 vs classic ESP32 vs ESP32-S3 for OpenBeken — which one is currently the better choice for stability, Wi-Fi, sensors, and OTA?
Najbezpieczniejszym wyborem z wątku jest ESP32-C3 albo poprawnie zasilony ESP32-S3. C3 miał działające Wi‑Fi, OTA, PWM i czujniki I2C, choć wersje SuperMini wymagały czasem obniżenia mocy TX. Klasyczny ESP32 działał, ale częściej wpadał w safe mode, miał problemy z restartem i błędami partycji. C2 działał, lecz był bardziej ograniczony RAM-em; autor napisał wprost, że „ESP32-C2 is already struggling”. [#21223468]
How can I diagnose ESP32 reboot loops, WDT safe mode, or stack overflow crashes in OpenBeken after restart, OTA, NTP start, or saving pins?
Najpierw patrz na dokładny powód resetu i nazwę zadania z logu. Jeśli widzisz TG0WDT_SYS_RESET lub TG1WDT_SYS_RESET, szukaj blokującego kodu, a nie problemu RTC WDT. Jeśli log mówi o stack overflow w sys_evt, quick albo IntTemp, zwiększ stack albo znajdź pętlę rekurencyjną. W wątku restart rozbijał się o nieskończoną pętlę: WIFI_STA_DISCONNECTED wywoływało HAL_DisconnectFromWifi, które generowało ten sam event ponownie. [#21224554]
What is the best way to test UART on OpenESP32 with TuyaMCU, and why can UART receive still behave inconsistently even when transmit works?
Najlepiej testować UART na prawdziwym urządzeniu z TuyaMCU i osobno sprawdzić TX oraz RX. Autor portu podał, że nadawanie działało, ale odbiór wymagał obejścia: po UART_AppendByteToReceiveRingBuffer dodał vTaskDelay(3), aby uniknąć crasha. To stabilizowało pracę, ale przy większym strumieniu danych nadal mogło przepełnić bufor, wywołać flush wejścia i reset kolejki. [#21222660]
How do I reduce Wi-Fi issues on ESP32-C3 SuperMini boards in OpenBeken, including slow DHCP or failed connections, with commands like powersave 1 10?
Obniż moc nadawania i nie zakładaj, że domyślne 20 dBm będzie stabilne. Dla ESP32-C3 SuperMini w wątku zalecono powersave 1 10, gdzie 10 oznacza 10 dBm, a w jednym przypadku urządzenie połączyło się dopiero przy 6 dBm. To pomogło przy wolnym DHCP, braku adresu IP i niestabilnych połączeniach, typowych właśnie dla SuperMini. [#21450298]
Can I upgrade an ESP8266 or ESP-01 flash chip from 1MB to 4MB or 8MB for OpenBeken, and what should I verify with esptool afterward?
Tak, taka podmiana została potwierdzona praktycznie. W wątku wymieniono flash w ESP-01 z 1MB na 4MB, a później także na 8MB w innym module, po czym esptool flash_id poprawnie raportował nowy rozmiar pamięci. Po wymianie zawsze sprawdź producenta układu, kod urządzenia i Detected flash size, bo to jedyny szybki sposób potwierdzenia, że lutowanie i konfiguracja SPI są poprawne. [#21238166]
How can I create a global float variable or pulse counter in OpenBeken on ESP32-C3 for water meters when each pulse represents 10 liters?
W pokazanym fragmencie wątku nie ma gotowej, potwierdzonej implementacji globalnego floata ani licznika impulsów dla 10 litrów na impuls. Jest tylko pytanie użytkownika o taki licznik po uruchomieniu logiki addChangeHandler, bez dalszej odpowiedzi z działającym rozwiązaniem. Jeśli chcesz pozostać zgodny z tym wątkiem, jedyną potwierdzoną ścieżką jest dalszy eksperyment ze skryptami lub Berry, ale bez gotowej recepty opisanej w podanych postach. [#21798097]
