Place to put your Basic demos and examples

Moderator: Mmiscool

User avatar
By Electroguard
#56859 Much of the power of Esp_Basic comes from its connectivity capability. But breaking free from the safety of the normal ESP Access Point on 192.168.4.1 is a bit like removing the stabilizers when learning to ride a bike... you can expect some mishaps and frustrations.

So here is a rescue kit that can help make the transition much quicker and easier.

It's in the form of some interruptable Failsafe code to put at the top of Default.bas before you start messing with your network parameters. If your network changes cause it to disappear up its own backside and prevents you from connecting back up to it again... just reboot it and press the designated hardware abort button during the 5 seconds of flashing led. This will cause it's network settings to be reset wherever it may be lurking, then the device will be rebooted back up to accessible defaults.

It can be used in 2 ways, either include your own code inline underneath, or have it 'load' in a separate specified file, such as the \uploads\wifi.bas example given below.
If you are loading in your user script as a seperate file it requires no user script modification whatsoever, other than to name it whatever you have specified to load at the bottom of default.bas

Either way, the principle of operation is still the same: when default.bas is run it offers a 5 second opportunity to press an abort button and reset the wifi to defaults, otherwise it will time out and run your user code with your specified network settings.

Once you have confidence that your network parameters are ok you can remove the Failsafe code if you wish, or just keep it as insurance if the 5 second delay is no hardship.

Be aware that the abort is dependent on a hardware interrupt button, so you need to make sure that your designated gpio has a pullup resistor, else it won't register an interrupt. Some devices like Sonoffs already have a pullup on their button, but many others (such as the D1 Mini NodeMCU, I believe) require a physical pullup resistor to be added. Hopefully the ESP software pullups feature may be included into Esp_Basic eventually, but until then your hardware interrupts aint gonna work without physical pullups.

I've noticed an interrupt quirk... when the interrupt is disabled in the script it stays disabled if the script is re-run, so it does not function again until the device has been rebooted. It's not important when you know, but is worth mentioning just to avoid the perplexed confusion it has caused me.

There's also a quirk that seems to cause the interpreter to lose track of what script it's dealing with when one has been chained ('loaded') by another, so rather than getting its nickers in a twist, I found it more reliable to selectively choose to Edit a particular script from the File Manager list even if it appeared to already be loaded in the Edit window.

The gpio00 flashing button is used by default, but you can assign buttonpin = whatever you prefer at the top of default.bas, and likewise with ledpin = 1 (ie set to D3 for nodeMCU).

A wifi example is included at the end to allow the Failsafe operation to be tested - save it as wifi.bas and upload to your device using the Esp_Basic File Manager, or copy and paste into the bottom of default.bas script. A good test is to connect to an existing wifi with valid parameters but without running an AP, because that scenario gives nothing to connect to and can be frustratingly persistent... which is exactly the situation that Failsafe can quickly rescue you from. You'll need to connect to ESP because I haven't discovered how to read the MAC address yet in order to set the AP name to its original, but that's more a personal annoyance than an issue.
Remember that the device is being rebooted with barely a pause for reconnection or screen updates, so don't keep staring intently at the screen waiting for something to happen cos it probably won't. Once it's reconnected you can browse to 192.168.4.1 to see the last message sent to screen, but the best way of keeping track of what's happening is just to keep an eye on the led, cos it will show reconnections and 5 sec abort time etc.

Code: Select allmemclear 'WIFI Failsafe script - Requires ESP Basic 3.0. Alpha 58 or later
cls 'Pressing ESP button within 5 secs will cause reboot to wifi failsafe settings (ap name=ESP at 192.168.4.1)
'IMPORTANT: the button will only interrupt and failsafe an inaccessable program if its gpio has a pullup resistor
write("autorun","on") 'Failsafe script needs to autorun in order to reboot to failsafe settings.
write("starttimer",1) 'No point delaying Autorun because it can be aborted if wished
if read("Failsafe") == "rebooted" then
write("Failsafe","")
print "Device has been restarted with Failsafe wifi settings - connect to ESP and browse to 192.168.4.1<BR>"
end
else
buttonpin = 0
interrupt buttonpin, [PININT]
delay 1000
ledpin = 1
let blinkon = 200
let blinkoff = 100
timeout = 5000
start = millis()
do
 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
interrupt buttonpin 'disable the button interrupt
io(po,ledpin,1)
goto [CONTINUE]
endif   

[PININT]
if io(laststat,buttonpin) == 0 then goto [DEFAULTS]
wait

[DEFAULTS]
write("WIFIname","")
write("WIFIpass","")
write("APname","ESP")
write("APpass","")
write("ipaddress","")
write("subnetmask","")
write("gateway","")
write("listenport","")
write("wsport","")
'write("ShowMenueBar","on")
write("Failsafe", "rebooted")
reboot

[CONTINUE]
memclear
load "/uploads/wifi.bas"  '(or alternatively embed your user script from here)

I've found the following wifi example from somewhere and just tweaked it a bit to get it running on the current version, so load it as a file or embed it however you prefer, in order to easily screw up your network settings for testing out the Failsafe recovery.

Code: Select allmemclear
listWifis = ""
n = wifi.scan()
wprint "<BR>Number of wifi networks found = "
wprint n & "<BR>"
for x = 1 to n
listWifis = listWifis & wifi.ssid(x)
listWifis = listWifis & ","
next x
wprint "<br>Select SSID: "
dropdown selectedWifi, listWifis
wprint "<br>Password: "
passwordbox networkPW
wprint "<br>"
button "Connect To Wifi Router", [connectWifi]
html "<br><br>"
wprint "For standalone Access Point (AP) without connecting to your wifi use this! <br> Enter AP Name: "
textbox networkSSID
wprint "<br>Enter AP Password: "
passwordbox networkPWap
wprint "<br>"
button "Start AP", [StartAP]
wprint "<br><br><brWifi >"
button "Connect to Router AND Start AP", [StartBoth]
wprint "<br><br>"
wait

[connectWifi]
WiFi.off
wifi.connect(selectedWifi,networkPW)
wait

[StartAP]
WiFi.off
wifi.ap(networkSSID,networkPWap)
wait

[StartBoth]
WiFi.off
wifiapsta
wifi.ap(networkSSID,networkPWap)
wifi.connect(selectedWifi,networkPW)
wait
Last edited by Electroguard on Sun Oct 23, 2016 4:37 pm, edited 1 time in total.
User avatar
By Electroguard
#56871 Mmiscool, what are the differences between A58 and A59?

The Failsafe was ok on 1M A58 a couple of hours ago, but when I flashed to 4M on latest A59 to use it with my project, strange things are now happening. Like instead of obeying the reboot instruction the script jumps to execute a different part of code without doing a reboot, and things like the interrupt branch seem to be triggered without the interrupt, and I think it is also responding to flash variables queries differently. I can't find any rhyme or reason to it, except that perhaps it's getting branch names jumbled up. Any ideas?

EDIT: False alarm, was my device that needed the Format treatment to straighten it out, is Failsafing ok on A59.