File upload brokes somtimes #20171
Replies: 13 comments 27 replies
-
|
The usual log level 3 or 4 may provide additional details of what Tasmota is doing. And also what curl is saying, like if it counts up to the expected number of bytes. |
Beta Was this translation helpful? Give feedback.
-
|
if the error appears again, i will check |
Beta Was this translation helpful? Give feedback.
-
|
uploading failed. console with syslog 4 do not react or output anything on triying uploading with curl |
Beta Was this translation helpful? Give feedback.
-
|
now i was live on cosole while first failed upload. console output (syslog 4): normaly it should shows: |
Beta Was this translation helpful? Give feedback.
-
|
Detail messages in the console are not elicited by setting log level for syslog (syslog server), but for weblog (web UI console). |
Beta Was this translation helpful? Give feedback.
-
|
Same here on Tasmota 13.3.0(tasmota32).
When it works (one or more reboots) log shows: for this command: Can it be related to #20340 ? |
Beta Was this translation helpful? Give feedback.
-
|
I had happy flow uploading multiple files via browser when always uploading from “ufsd” path, as opposed to “ufsu”, where you are redirected after successful upload of first file. The issue still seems to be in upload error handling code, but web UI seems to trigger it specifically. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps I misunderstood your solution, but when I type:
I get no errors but nothing new is in my Lanbon
and then the html-code of the Manage File system page is displayed. |
Beta Was this translation helpful? Give feedback.
-
|
I have the same problem on my Lanbon L8 with Tasmota 13.3.0(lvgl-haspmota). |
Beta Was this translation helpful? Give feedback.
-
|
Hello, any news? |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! However, on this board or in this build, Bluetooth is not activated. But I did activate Zigbee. I was hoping to get it working as a Zigbee gateway as well. ( in future) hier is my the actually Program Version is: 13.1.0(tasmota32) |
Beta Was this translation helpful? Give feedback.
-
|
Again, you are pushing it too hard memory-wise. This is not related to why your available RAM is that low. However, I have a Zigbee bridge running having 150 KB free heap visible in the STATE payloads, and what you posted above shows around 60 KB. That's on the very low side for transferring files of that size, due to risks of fragmentation. Beware that if your board has ESP32-S2 (not recommended for "large features"), available RAM is significantly lower. I'm mostly using boards with PSRAM if I want to have headroom for more than small-ish Berry programs. I'm also using "real" modules designed to be manageable building blocks, with their own encapsulated function. That also leads to just not creating large source code files. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you.
I'm already considering a more modular setup or perhaps a customized board. However, I still want it to feature a changeable and fast ESP32.
|
Beta Was this translation helpful? Give feedback.
-
|
IMO, trying to do everything on a single board is not a great strategy, when it is really not expensive with a few standard devices instead. And custom boards are best if you enjoy the pain. I'm using a finished device with ESP32 and CC2652(Zigbee), but without trying to do everything else on the same device, and no PSRAM even if I'd have liked this - but no problem. I'm also using ESP32-S3 dev boards with large flash and PSRAM where I have "large features", like displays or automations in Berry. To be clear, ESP32-S3 as such does not give a huge step up, but you can get ESP32-S3 chips with both flash and PSRAM on the same chip, and therefore pretty small boards. Note that ESP32-S3 does not have on-chip Ethernet support, but you can get a separate Ethernet add-on module if this is what you want. |
Beta Was this translation helpful? Give feedback.
-
|
i repowered the board and get this no script loaded.
I understand your point in using seperate boards. But my intention was to have basic functions for controlling home lighting even when no internet or WiFi is available. I also didn't want to unnecessarily add or maintain additional WiFi clients. |
Beta Was this translation helpful? Give feedback.
-
|
now i got this error with a board with PSRAM. Auto-configured as Sunton 5Inch display. So only the
|
Beta Was this translation helpful? Give feedback.
-
|
i don't know why, but now, |
Beta Was this translation helpful? Give feedback.
-
|
I noticed the same occasional issue with uploading reporting a failure and not performing the upload operation. The Tasmota version is the latest master commit a5610ee. My observations were:
The WebLog shows different output for each case:
Digging through the code it seems that
So I came up with a working solution which is simply to download the root directory contents before uploading a file. Works perfectly. Here my script for updating the changed files in a defined set of files: #!/bin/bash
set -e
# see tasmota/tasmota_xdrv_driver/xdrv_50_filesystem.ino
# shellcheck disable=SC1102,SC2215
MAX_FNAME_LEN=45
base_url='http://192.168.3.43'
curl_opts=(--silent)
#curl_opts=(-vv -i)
files=(
display.ini
pages.jsonl
*.be
assets/*.font
)
for f in "${files[@]}"
do
fname="$(basename "$f")"
if [ ${#fname} -gt "${MAX_FNAME_LEN}" ]
then
echo "File name '$fname' is too long (actual: ${#fname}, allowed: ${MAX_FNAME_LEN})"
elif [ -f "$f" ]
then
if diff -q "$f" <(curl "${curl_opts[@]}" "${base_url}/ufsd?download=/$fname") >/dev/null
then
echo "File '$fname' unchanged"
else
echo -n "File '$fname' changed -> uploading "
# need this to persuade the server that the subsequent upload is going to be a UPL_UFSFILE type
# see https://github.com/arendst/Tasmota/discussions/20171#discussioncomment-11735457?target=https://github.com
curl "${curl_opts[@]}" "${base_url}/ufsd" >/dev/null
fsz=$(stat -c "%s" "$f")
if curl "${curl_opts[@]}" "${base_url}/ufsu?fsz=$fsz" --form "ufsu=@$f" | grep -q 'Successful'
then
echo "successful"
else
echo "failed"
fi
fi
else
echo "Local file '$f' does not exist"
fi
doneI somehow have the impression that this could be a bug not yet reported, so ideally someone would create a bug report!? |
Beta Was this translation helpful? Give feedback.
-
|
Hi , facing the same issue on several different tasmota platforms (esp32S3 and esp32 , on v 15.3 , got the same issue on 14.6 , im trying to find a previous version where its working . here the log : note that i always have the Multicase rejoined appearing exactly in the same manner. |
Beta Was this translation helpful? Give feedback.
-
|
@sfromis , do you think this is plausible and the quality of this draft is worth transforming it to an issue , file upload is impossible on all devices i tested on tasmota 15.3 even the smallest file ( 52 bytes ) is crashing tasmota |
Beta Was this translation helpful? Give feedback.
-
|
When "steps to reproduce" does not reproduce, posting a lot of AI fluff is not too useful. I'm not seeing trouble using the web UI to upload a file. And saying "crash" without any symptoms of what you mean by "crash" does not add much either. |
Beta Was this translation helpful? Give feedback.
-
|
crash means the whole tasmota stops working, web not accessible , no ping , no serial logs , no serial access , need to reboot the device |
Beta Was this translation helpful? Give feedback.
-
|
it occurs every time after the upload of a file , the file itself is written most of the time but then i have to reboot ( mean power cycle) to get the device alive |
Beta Was this translation helpful? Give feedback.
-
|
That is not really a "crash", but better with the word you already used, "freeze". Never mind. Anyway, what was important was "steps to reproduce", where I with current Tasmota instead simply saw the upload work, and normal operation afterwards. One risk factor is issues with availability of sufficient stable power. |
Beta Was this translation helpful? Give feedback.
-
|
tried downgrade with tasmota 13.4 , dont have this weird behavior. |
Beta Was this translation helpful? Give feedback.
-
|
I doubt that the freeze is linked to multicast, it seems more like a hallucination due to the presence of the log line. Or do you see something in the logs that makes further uploads to freeze ? |
Beta Was this translation helpful? Give feedback.
-
|
@ s-hadinger i digged manually into the code and it could be related to some issues with UDP from passage from core 2 to core 3 , , there are some issues that were related and mentionned also 13.4.0 was working despite 14.0.0 was not , #21470 is interresting in this regard. the log i got saying its reactivating UDP is definitely not hallucination, and i think this UDP code has issue with change of methods for flushes between core 2 and core 3 , and for maybe no reason after uploading files , the udp code is called and i guess this triggers the log message : i couldnt understand which part of the code is triggering this. |
Beta Was this translation helpful? Give feedback.
-
|
@s-hadinger if the USE_EMULATION compiled in the base tasmota firmware in this case i think its when the AllowInterrupts function is triggered when the UploadServices is called by the file upload completion : line 1364 of xdrv_50_filesystem.ino , leading to reconnect the UDP then creating the issue that is linked to the change of Core2 to core 3 and the way of flushing udp sockets. i would in this case not use a condition of USE_EMULATION but maybe check if its really activated by the options on the firmware , what do you think ? |
Beta Was this translation helpful? Give feedback.
-
|
I'm trying to reproduce the bug, but the thread is getting too long. Being on Macos I try the following command: No crash, no freeze. However I notice that the file is not actually written until I open the "Manage File System" UI, which is some weirdness I already observed in the past. |
Beta Was this translation helpful? Give feedback.
-
|
@s-hadinger "Weirdness" with treating ufsu as an API is an old thing, when using curl (etc) instead of the web UI. The "usual" workaround is to access the "Manage File System" URL first, as this seems to give a state allowing the non-documented endpoint to work. However, ouinouin states to be using the web UI already, meaning that the stateful issue should not apply. Still would make sense to get fixed, to allow ufsu to be an actual API with predictable behavior. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, still I can't reproduce the problem. I confirm though that |
Beta Was this translation helpful? Give feedback.
-
|
i will check if this issue is not triggered by the fact i m in a setup where i have many wifi access points to roam around, could this have an impact ?
Le 2 mars 2026 10:14:33 GMT+03:00, s-hadinger ***@***.***> a écrit :
…Thanks, still I can't reproduce the problem.
I confirm though that `UPP: Multicast (re)joined` is shown at each uploaded file which seems odd
--
Reply to this email directly or view it on GitHub:
#20171 (reply in thread)
You are receiving this because you commented.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
@ouinouin @s-hadinger Try with a version build with this framework / Platform: Reason behind. Multicast behaviour has changed. See espressif/arduino-esp32#12408 |
Beta Was this translation helpful? Give feedback.
-
|
Hi , not yet compiled this specific version , but i did a test by establishing an accesspoint and not connecting to the network with multiple roaming possibilities , and guess , the problem disappeared ( at least tested for now in V14 that was the first version to be trouble some) . so there might be a link with maybe an under the scene managment of the roaming while in multiple AP environment and most likely the multicast , does this ring a bell to people with goos knowlgedge of espressif dev kit issues ? @Jason2866 ? @s-hadinger ? edit : tested also with tasmota 15.3 , upload is fully functional with single accesspoint (no roaming possibility) . interresting logs while booting and connecting to the network with multiple AP with same ESSID name, we can see that the routine is to check wifi every 20 seconds, so maybe this could be the cause of the crash ... I also notice that if the tasmota device is in good reception of all the APs , browsing its web interface is painfully slow, whereas when i try to hide it , i supposedly minimise the number of APs where it can roam, ans web interface is much much faster. |
Beta Was this translation helpful? Give feedback.
-
|
So I think this problem has nothing to do with the initial problem. I don't recall that roaming is checked every 20 seconds, but I'm not deep in roaming handling in Tasmota |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
it seems to be a problem with file upload.
Sometimes, upload is broken. Than no files are uploaded. Either with promt cmd curl -F "file=@C:\Dev\Tasmota\path\filename.be" "http://192.168.xx.xx/ufsu" ,
nor with the webinterface.
rebooting do not fix this reliable. I just needed 3 reboots to be able to upload files again. What kind of information can i offer?
I see no special output in console while file upload is not happend.
Can i activate some log options?
Beta Was this translation helpful? Give feedback.
All reactions