Page 3 of 3

Re: Autorun delay

PostPosted: Mon Oct 17, 2016 12:11 pm
by Electroguard
Thanks, that should let me do the job.

Something I noticed:
String subnetmask = LoadDataFromFile("subnetmask");
String gateway = LoadDataFromFile(F("gateway"));

Perhaps that last "gateway" entry is deliberately different because it alone is being passed through a F() function, but the difference does make it stand out from the crowd.

Re: Autorun delay

PostPosted: Mon Oct 17, 2016 4:06 pm
by Mmiscool
The f() is a memory saving tool part of the esp8266 gcc stuff. It probably should be used on the other stings also.

It makes no diference except in binary size/ram consumption.

Re: Autorun delay

PostPosted: Wed Oct 19, 2016 11:51 am
by Electroguard
To detect if autorun is enabled use the following command.

if read("autorun") = "ON" then print "Autorun mode is turned on"

This setting could also be manged with the write() function too set a different value.

I've been getting in a right pickle over this.

I tried combining them together:
Code: Select allif read("autorun") = "ON" then write("autorun","OFF")

but it doesn't change the 'Run default.bas at startup:' on the SETTINGS page.
Similarly I had no success trying to change the 'Display menu bar:' checkbox on the SETTINGS page.

I tried many different 'case' combinations of ON, Off, YES, No, "" (nul) etc, but nothing seemed to work.

And then I wondered if maybe it was changing the actual settings without reflecting the changes in the SETTINGS page checkboxes.
Which made me concious of the fact that ESP_Basic does not have a similar CheckBox web component available for use in a script.
Which got me wondering if perhaps there were technical problems that prevented a Checkbox component from being added to the ESP_Basic armoury, or perhaps it might already exist but has managed to slip by under the radar. As may have happened to the MAC address setting, which the interpreter is obviously aware of, but is not on the list of accessable settings, therefore prevents doing a write() restore of the original ESP+MACaddress AP name (the AP name is simply reset to "ESP" in the following code).

Code: Select all[DEFAULTS]
if read("autorun") = "ON" then write("autorun","OFF")
html "<BR><BR>"
delay 5000 'to allow flash writes to complete

'Continue original program from here

To invoke the [DEFAULTS] subroutine originally, at the top of the script I used:
Code: Select alltimer 10000, [CONTINUE]
button "Defaults", [DEFAULTS]

The intention was that autorunning could be aborted by clicking the Defaults button in time (sufficient time to allow for browser button access) to cause the program to branch to reset wifi settings back to defaults then reboot the device. Obviously the auto-abort facility could be removed once confidence in correct network operation was established.

But on reflection, that seemed an ass-backwards way of doing things. It would be better to only intervene if or when necessary, and the only practical way of doing that was to use the gpio00 autorun-abort button... which couldn't be used as a flag to modify script operation until after the script had autorun.

So now the intentention was for the script to autorun and then flash the blue led for a few seconds while giving opportunity for the gpio00 button to be pressed in time to cause an interrupt branch to reset wifi to defaults, otherwise it would just continue on after the timeout.

Code: Select allledpin = 1
buttonpin = 0
interrupt buttonpin,[DEFAULTS]
timeout = 5000
start = millis()
let blinkon = 200
let blinkoff = 100
 if io(laststat,ledpin) == 0 then io(po,ledpin,1) else io(po,ledpin,0)
 if io(laststat,ledpin) == 0 then delay blinkoff else delay blinkon
loop while millis() - start < timeout

Seemed like a reasonable idea... but in practice it doesn't work on ordinary out-off-the-box ESPs unless they have have a physical gpio00 pull-up resistor added. As I've mentioned in the past, even though the ESP startup code enables the ESPs software gpio00 pullup, the ESP_Basic interpreter has no software pull-up implemented, so the re-flash/autorun-abort button which works during bootup no longer works for user input after bootup. And in addition to the practical difficulties of adding a physical resistor to many devices, it is not something recommended for devices with close proximity mains such as Sonoffs and Electrodragons etc.

So at the end of the day (a very long couple of days actually) I'm not really much closer to easily and consistently recovering from a 'bad' wifi reconnection that doesn't give browser access - which can even persist through a V2 reformat followed by V2 reflash followed by V3 reflash - but it does offer some interesting food for thought...

Would a Checkbox web component be a practical possibility?
Is user script access possible for the MAC address variable?
Could the ESPs software pullups facility be made available to ESP_Basic?
Could the gpio00 autorun-abort button behaviour be modified to load and run a "failsafe.bas" script (if available) when pressed, instead of "default.bas"?
Could script access be possible for invoking the interpreters wifi reset routines? (rather than needing to include something like the above [DEFAULTS] script.

I reckon there are several opportunities for potential improvements which might offer a silver lining.

Speaking of improvements, the wifi examples need updating to make them work... just need to pre-fix the wifi commands with "wifi."


Re: Autorun delay

PostPosted: Wed Oct 19, 2016 4:38 pm
by Mmiscool
It is case sensitive and you are comparing strings.

When comparing strings you must use the double == signs.

The flowing will work for detecting autorun state.
Code: Select allif read("autorun") == "on" then write("autorun","off")