Annex RDS forum

Sorry but your message is not very clear, probably you should try to write in your native language and then translate in English because, sorry for that, it is a little bit cryptic for me.
Is not clear for if is OK with the 2/4 MB modules or not

However, for what I understand, you have problems with the modules with 1MB.
You must consider that the module with 1MB has only ~250KB of disk space so it can become full very rapidly.
Writing and saving many times on this module can fragment the file system (spiffs) that could also generate problems.
Another problem with the 1MB modules is that, if you use the OTA, all the files present on the module will be lost, so you need to make a backup before and then reset all the parameters manually.

I remember that there were problems with a given brand of flash memory (maybe puya?), maybe there is another kind of memory that has the same problem ?

Are you flashing your modules in DOUT mode? This is the safest mode; you could also try to flash the memory at 40MHZ, that is also safe.

As the ESP8266 is obsolete, I did a last update recently and I do not plan to make other updates

It is not even possible for me one file
To open or write "socket china-ohnenusb.bas" with 723bytes in the editor.

The flash is almost empty. 1 .bas and a config is enough for me, 99% emty

With a "test.jpg" I tested whether the flash works.
It is generally possible to use the content.

The file system does not like certain content.
The ESP-02S uses the ESP8285 with 2MB.

We also do not read the Sample BAS from 8MB, the size is not problematic.

The new flashing is very unproblematic, always.
Problematic when using the Flash partition from Annex Editor,

I know, difficult to describe, maybe I do a cell phone video and try to share it with you.

Perhaps avoid translation problems by posting a (silent) video on youtube which demonstrates the problem(s).
No need for a long continuous uneventful recording, just edit together any bits that are relevant.

I try my best

The problem does not occur with every file,
for some more often, but always with the sample,
I see an interference of code lengths and errors,
With certain file sizes, the error comes,
Smal works and bigger too,

I tested different browsers


Of course there are better controllers,
But please from the hardware perspective,
There are millions of devices on the market
I don't know any ESP32 device, just test boards.
https://templates.blakadder.com/plug.html
https://templates.blakadder.com/relay.html
And now Ali sells compatible ESP boards for all Tuya devices, for soldering

Hi Oli, the videos and your commentary are helpful.

I can only suggest what I might do in similar circumstances.
Always start the device in a new window, to ensure the Editor page is created with the correct javascript code (the same goes for all device pages).
Understandably it would probably cause errors if loading an esp8266 script into an esp32 Editor window or vice versa.

Open the File Manager to create a backup zip on computer of all files from the device, then unzip them on the computer to check that all files can be loaded into a computer text editor ok, with no signs of corruption.
It is especially important to check that the bottom of the scripts are still intact ... because if a file Save fails for any reason, it can leave a partial incomplete file of that name, which may cause errors when trying to load, and certainly when trying to run.
That is why I always end my scripts with:
'-------- End ------
which makes it obvious if the end of the script is missing.

Assuming that the files all look ok on the computer, I would either Format the device files system from Config page, or re-flash the device again.
Then I would upload each required file one at a time, checking that each loaded into the Editor ok.

If any file failed, I would rename it from File Manager to prevent trying to save to that same area of file space again, then try uploading the same file again - after re-checking it loaded and looked ok on computer again... cos clearly something was either wrong with that file, or the file space.

And from bitter experience I have found that after any sort of problem, it always pays to remove and replace device power to do a complete clean startup again, so everything is refreshed... cos the interpreter can sometimes 'get its nickers in a twist'.

If I find a file that is causing a problem, it could be completely commented out so that it is inactive, then try loading it again - if it then loads ok, parts of it can be selectively un-commented until either some faulty code is found, or the script is eventually complete.

Or any particular file which may be causing a problem can be redone by adding a few lines at a time to the Editor and re-Saving.
But remember that any Save error will corrupt the previous file of that name, so Save each edit with a different suffix, ie: file3a, then file3b next, etc.
Keep the last few saves, but remember to keep deleting earlier unwanted files to avoid using up all of the precious file space.


There are only a few possible causes to diagnose:
Faulty hardware - try a different device.
Faulty or corrupt firmware or file system - try re-flashing with an older version.
Faulty file - redo the file from minimum, making any necessary correction.
User impatience - allow time for each operation to fully complete before clicking the interpreter to do more (file operations can sometimes be slow).

Hope that helps to find the cause of the problem.

I see that there are disconnections between the module and the WEB browser; this can be caused by several reasons :
- The power supply of the module is too weak or not stable
- There are "non standard" character transferred between the module and the browser
- The module is too far from the WIFI router (signal too weak)
- The Flash memory inside the module is not supported

Oli, what is the module that you are using?
Could you give the details of what are you using?
How it is supplied? (I mean in terms of power supply)
Have you tried with a "standard" ESP8266 module like a wemos or ESP01 ?
Have you tried to remove the special "non standard" ASCII characters from your program?

I saw that there are several ü ö .....
Maybe these character are not well handled by the ESP8266

One interesting thing that you can do is to open the browser in "inspect mode" (right click on the window and select 'Inspect') You'll have a debug page; look in the console tab and see if there are some error messages (In the picture below I voluntarily generated an error sending a bad character with wlog chr$(253) )

Try and let me know

Tested the program with standard ESP01 with 8MB memory.
Pasted the code into the editor window.
It would not even save (or saveas).
It saves and runs ok if the comments with accented characters are removed. Version 1.47

[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Tue Dec 19, 2023 10:37 am Tested the program with standard ESP01 with 8MB memory.
Pasted the code into the editor window.
It would not even save (or saveas).
It saves and runs ok if the comments with accented characters are removed.

The mystery seems to be solved then.

The problem comes from the accented characters present in the document.
This issue is not present on the ESP32 as, if I remember well, I did a fix to avoid this problem some time ago.

Well the mystery is deeper.
I have tried it on an ESP-01, 1Mb, and the only accented character that seems to stop the recording process is the u with an umlaut in the first word gerdückt. (it is &HFC in hexadecimal)
Try deleting just that ü and the program will save and run normally.
And it is deeper because I think it only affects the first u that appears, because the one on line 11 does not seem to affect it.
https://mega.nz/file/2e5UzLzQ#DHyb4Kv8E ... JnF6SiH6bA

Just for your information, the "special" characters are handled as UNICODE and are composed of 2 bytes (or more).

For this reason, when they are transferred from / to the module can be considered as a binary content and rejected by the browser.