Avoid flash wearing by altering behavior originally introduced by Espressif (the inventor of the ESP8266)

[warren]

To be fair, adding an optional parameter, or an additional function that is not available in all ports, keeps the API backward-compatible, but makes the new code incompatible between the ports.

The only confusion would potentially be for someone using the 'newversion' function on a port other than ESP8266. The extra parameter would have no effect because the 'not saving to flash' functionality would not be available there. Calling it 'incompatible' is overstatement - it would just do nothing.

At worst, it would be 'misleading' if someone tried to use it to tell a WiPy (for example) not to save the config.

Would this be such a bad downside compared with the existing ability to trash the ESP8266 flash?

Actually, it is not just about prolonging flash memory. We are advised on this forum that using the ESP8266 implies adopting a planned 'reboot schedule'. But these devices use significant percentages of the reboot cycle time reconnecting to the last good network. Also when they are attempting to auto-connect, it is harder to 'get their attention' (even CTRL-C on REPL isn't always immediately successful).

Equally, there are plenty of IOT apps where you only occasionally need to 'phone home' - at present the only power-saving option is deep sleep - totally frustrating!

It would be terrific if you could just tell them to reboot and not do any network operations until subsequently told to!

[kfricke]

That's why I think that section...

... doesn't save SSID and PSW to flash (reads only and compare) if saved information is identical to function parameters.

Thanks for joining this discussion profra. Your guesses are very optimistic and please let me tell you the following facts.

Code: Select all

<interface>.connect(ssid, psk)

Explicitly writes the config to flash before connecting to the AP.

Code: Select all

<interface>.active(state)

Does set the interface state and writes this to flash.

The linked method calls to the ESP SDK, which write to flash, have variants to perform the desired operation without writing to flash. So your guess would make half of the ESP SDK methods pointless.

[profra]

@kfricke Thank you for your reaction. I will try to answer. I will start from the end...

So your guess would make half of the ESP SDK methods pointless.

I don't agree with this argument. I think that both groups of functions (DEFAULT and CURRENT) have different mission. DEFAULT set is for setting up the "initial conditions", under which the given application starts and works most of the time and which shall be set up by user during first run of program BOOT.PY. CURRENT set is for dynamic change of parameters within the program run and can be useful e.g. in MESH networks.

Just to make it clear, I would like to mention here that my comment to this discussion is related to the following information only:
a/ physical saving to flash memory is not applied if the information to be saved is the same as the information already saved in flash memory,
b/ I have been aware of the fact that in your application, as you described it, physical saving to flash memory is done because you change the parameters of function wlan.active(),
c/ at the same time I would like to mention that by using suitable strategy of the whole program application it will not be saved to flash memory more than once, even in case of first run of program BOOT.PY; other restarts of program only confirm stored parameters and that's why it's not physically saved to flash memory.

The philosophy of your approach is not optimal because you need to active the function wlan.connect(ssid,psw) anyway and it doesn't matter (with respect to energy of battery), if it happens during boot or some time later.

CODE: SELECT ALL
<interface>.connect(ssid, psk)
Explicitly writes the config to flash before connecting to the AP.

CODE: SELECT ALL
<interface>.active(state)
Does set the interface state and writes this to flash.

Your links to source code don't prove anything because it's been still valid that these functions will always execute the saving to flash memory only in case, if the information to save is changed. This bit of information is mentioned at each function in notes of ESP8266 Non-OS SDK API Reference.

From the above mentioned you can see that the requirement of API change is not as urgent at this moment as you present it. We can find suitable solution if you have a look from a different angle. To show how I really mean it, please see my program BOOT.PY as an inspiration which has proven in my applications and solves everything in the above described way.

Code: Select all

#aps_truseted.py ... 
APS = {
    "ssid_1":"psw_1",
    "ssid_2":"psw_2",
		....
    "ssid_n":"psw_n"
}


# boot.py ... Create connection to trusted AP
from aps_trusted import APS
from network import WLAN, STA_IF, AP_IF
from esp import osdebug
from time import sleep_ms

def try_connection():
    t = 10
    while not wlan.isconnected() and t > 0:
        print('.', end='')
        sleep_ms(500)
        t = t - 1
    return wlan.isconnected();

osdebug(None)
ap=WLAN(AP_IF)
ap.active(False)
wlan = WLAN(STA_IF)
wlan.active(True)
print('connecting to last AP', end='')
print(try_connection())
if not wlan.isconnected():
    ## find all APs
    ap_list = wlan.scan()
    ## sort APs by signal strength
    ap_list.sort(key=lambda ap: ap[3], reverse=True)
    ## filter only trusted APs
    ap_list = list(filter(lambda ap: ap[0].decode('UTF-8') in 
              APS.keys(), ap_list))
    for ap in ap_list:
        essid = ap[0].decode('UTF-8')
        if not wlan.isconnected():
            print('connecting to new AP', essid, end='')
            wlan.connect(essid, APS[essid])
            print(try_connection())
print('station configuration\n',wlan.ifconfig())
import gc
gc.collect()

I don't want to force anything to anybody, I have only tried to find a different angle and positive solution. I would be glad if my opinion will be understood well and if it inspires anyone.

Note:
I would like to suggest (to @pfalcon) not to activate default softAP but to make it during WEBREPL activation. I think it's useful because I can see a room full of attendees during a training with fresh flashed MicroPython who shall solve the task BLINK_LED, while there is the air full of RF smog with e.g. activated 10 APs..., which are useless at that moment. When the trained people reach WiFi topics, they will be able to activate necessary functions.

[kfricke]

...
a/ physical saving to flash memory is not applied if the information to be saved is the same as the information already saved in flash memory...

Is this a fact or a guess?

[profra]

@kfricke It was my logical thought at the beginning, I personally would solve it this way.
But today, I argue that it is a fact. I found lot of evidence of this fact in official documents from ESPRESSIF.
Attached are some sample pictures from their documentation.

[kfricke]

Sounds plausible then and does only mean, that two of the three methods do wear flash for my application.

[ernitron]

I think I have found another use case were using the actual active and connect API will lead to unstable behavior. Look at this thread
http://forum.micropython.org/viewtopic.php?f=16&t=2697

I think we definitely need a method that does not only write into flash but it does not retry to reconnect to WiFI AP looping and stuck to a non existent SSID. Application should recover testing the actual state of connection and try to connect again with the credentials stored in the code and not those in the flash.

Of course this could be a different problem but I guess we would design better and more resilient applications if we have these methods.