-->
Page 1 of 7

{Stop] or Stop button?

PostPosted: Mon Apr 18, 2016 11:26 am
by Electroguard
If a running script is causing problems I don't know how else to stop it other than a reboot.
Might it be worth including a [Stop] somewhere on the Edit page to stop a script from continually running (even when it's being edited in the browser)?

Re: {Stop] or Stop button?

PostPosted: Wed Apr 20, 2016 3:22 pm
by Electroguard
More...
I've noticed that some errors may be flagged, but despite seeing an error the parser still continues parsing (as mentioned about the new serialinput example 'turkey' problem in latest News.
This even happens after flagging up an unknown branch error, so it's anyones guess where program flow could end up after that. I don't know anything about what's under the hood, but would it not be better for the parser stop on all errors if it was possible?

But that aside, it seems the parser keeps parsing indefinitely unless it comes to END or crashes and reboots. The ability to continually loop may be what is wanted - perhaps for continually monitoring an input pin etc - but it does pose a bit of a problem during development.

Lets say I want a continual loop to monitor an input pin (eg: gpio00 button).
I Save it, and Run it. But let's say something isn't right, so I click Back in the browser to return to the Edit screen and make changes... but the edits can't be Saved, because the ESP is still busy continually looping the parser rather be interested in listening to the browser Save command (or anything else for that matter). So I'm not sure that having a Stop or Halt button in the browser would be effective in such a loop situation, unless the parser can be made to periodically check for browser commands even when it's busy.

The only way I know of stopping the free-running parser at the moment is by doing a reboot and quickly saving the edits after reconnection before the program gets autorun into another endless loop again - it's certainly possible... but it's a less than ideal situation for unconfident newbies to find themselves in.
So is there a better way?

I suppose a quick-fix could be to monitor the gpio00 button, so it could be used to stop the parser when running as well as break out of autorun to prevent the parser even starting.
But that would prevent gpio00 being able to be used for anything else, which would be a shame. Perhaps a relatively simple? solution to that might be a gpio00 behaviour Dropdown on the Edit page which might allow users to assign required behaviour to the gpio00 button as needed, perhaps with options of Ignore, No autorun, Halt parser, No autorun and Halt parser - so the parser would check any appropriate behaviour flags that were set and adjust it's use of gpio00 accordingly.

Just some thoughts and ideas in case anything is helpful.

Re: {Stop] or Stop button?

PostPosted: Sun May 01, 2016 9:07 pm
by forlotto
you could add an end button or routine that you could use any time.

button "Stop" [Stop]
[Stop]
end

simply add this to your code for a stop button
or you could hook up a button to an unused gpio if you want and when that button is pressed have it go to the Stop routine through the use of an interrupt.

There is a reboot button.

In order to interrupt your code the stop button needs to be within your code unless espbasic editor just adds this for you automatically as the first lines of code and uses a 1px x 1px button so that it is hidden somewhat from the user. But if someone acceidently clicks on the pixel it will stop the code so maybe an alternate method would just be listing the routine and somehow having the button from the editor page access the routine through msg branch possibly or something similar.

This would mean that every code would have injected stop code in it there are some reasons possibly or people who may not want this IDK you may want to stick to implementing such a thing yourself possibly.

A stop button or stop message branch just because it is there does not need to be used.

this code would allow easy stopping

msgbranch [mybranch]
wait
[mybranch]
MyReturnMsg = "Not a valid msg received"
msgget "stop"
if stop == 1 then gosub [endpgm]
[endpgm]
cls
MyReturnMsg = ".............:::::PROGRAM IS HALTED!!!"
delay 3000
end

to call this it would simply require you to type the following in the web browser

http://192.168.x.x/msg?stop=1
or AP mode
192.168.4.1/msg?stop=1

This would stop your program dead in its tracks

Re: {Stop] or Stop button?

PostPosted: Mon May 02, 2016 8:11 am
by Electroguard
I'm afraid you totally got hold of the wrong end of the stick, forlotto.
The problem I was drawing attention to was the fact that the parser has an ON control but no OFF control.
And at the time of writing, the Alpha release was suffering mental instability problems and blundering blindly on regardless of mental ill-health, even after suffering terminal program errors... it was a mindless rampaging zombie without a an OFF control!

I had already mentioned tough self-defence measures of reboot and gpio button for stopping the program, but such weapons should only be considered desperation last-resort for use by asylum staff, not standard issue for the general public.

I have since seen mmiscool state that the parser is stopped when Run is pressed... but that's not really a Stop cos it's a certain re Run - or when Save is pressed... but sometimes (more often than not with my bloatware program) the parser is too busy doing it's own thing to even notice the Save being pressed (or doesn't respond to it anyway). This was more apparent in pre A17 when any Save that didn't return the ok acknowledgement inevitably required a reformat and reflash. In A19, ignored Saves can be re-clicked repeatedly and perhaps may eventually do a save and return an acknowledgement, but that can hide corruption which would only show up if clicking Edit first - and why would you be doing Edit if still trying to Save your previous Edits.

That same percentage of 'iffy' absent-minded Saves also seems to affect the running program, cos half the time some things that just worked don't work next time, but may work again the time after that. This is particularly noticable after viewing any of the ? doc pages.

The lack of consistency means there is nothing apparent to debug and no may to progress, so has forced me to abandon the udp network demonstrator program I was working on. I have included it below for you to try and see for yourself if you like, particularly as you mentioned the lack of udp examples elsewhere. There are web buttons that cause the node to BlinkIP it's IP address, Blinks blue led for node location purposes, toggle a relay, etc. All these functions can be triggered locally by web buttons, or remotely via udp instructions, or locally via udp instructions. Each works most of the time, but if a hiccup bug occurs somewhere it may not show up, and then the zombie parser thereafter stumbles blindly on regardless of errors, and can corrupt the flash memory which is not apparent just by doing a Save or Run, it only shows up by doing Edit, and then only fixable by doing an inevitable full reformat and reflash. I got to the point of trying to test the Ping Pong network interaction between to 2 network nodes, but was spending too much time constantly reformatting and reflashing, so I decided to call timeout and start writing a book!
Speaking of which, if you do try the script, click on the top left ? button for all the info you should need regarding the program. As I said, I don't know if interactive Ping Pong works between nodes yet, but the idea is that you send NAME SERVE (name can be a specific node name or ALL) in the msg window, and a receiving node would reply with BALL, and the 2 nodes then keep batting BALL between themselves, toggling the onboard blue led each type. ALL DELAY 1000 would add 1 sec delay between responses, and ALL STOP should end the interaction.

So it's not a matter of issuing public Stop weapons to take the rampaging zombie down, it's a matter of keeping the zombie contained and controlled to prevent it rampaging on the public. And I suspect that would be more a matter of making the zombie parser Stop itself on all errors, rather than stumbling blindly on past them. I also suspect it's only a noticable problem in a larger program with many alternative branch paths, but the present consequences mean that although examples are ok, any larger 'real-world' programs are currently impractical.

Code: Select allmemclear
let version = "v0.31f"
let localIP = ip()
gosub [stripIP]
let udpport = 5001
let localname="Node" & IP4 ' Over-ride this default by un-commenting the line below and changing to your own unique name
let localname = "MP3Player"  ' Unique node name, eg: Node99 or PIR4 etc. For ease of use, names are not case sensitive
let globalname = "ALL"     ' Allows addressing different system clusters of nodes separately if wished, eg: "All blinks"
let groupname  = "Some"    ' Allows addressing different groups of nodes if required. eg: "SOME blinkip"
let description = ""       ' Displays an optional node description if wished
let description = " Network-controllable Music Player,  valid commands are "
let description = description & upper(localname) & upper("  [Play] [Pause] [Next] [Previous] [Vup] [Vdown]")
let shoutmsg = "Hello world" ' The default msg shown in the broadcast msg window
let shoutmsg = "ALL SERVE" ' Broadcast this to start an interactive network Ping Pong demo session with another node
let lastmsg = " (last received msg) "  ' (Last received msg facility is unfinished and unavailable)
let buttonpin = 0          ' Onboard GPIO00 flashing button/jumper
let buttonstate = 1        ' Dwfault button off state
interrupt buttonpin [buttonpress]
let ledpin = 1             ' Onboard GPIO01 blue led
let ledstate = 1
po ledpin ledstate         ' Ensure led is off
let rly1 = 4               ' relay1 gpio
let rly1status = 1
po  rly1 rly1status        ' Turns off relay1
let ppdelay = 10
let debugmode = "clean"    ' Turns off sending udp debug msgs (can be viewed on cicciocbs udb_debugger util)
let nowait = 0             ' Behaviour switch to prevent wait(ing) in [blinkIP] if using automatic BlinkIP at startup
  ' Original intention was to automatically BlinkIP at startup, which can be done, but poses a catch22 problem of not
  ' being able send blink notification msg to screen during startup blink time for remote "comfort", so disabled
  ' print "Node " & localname & " is blinking the last address byte digits for identification"
  ' let nowait = 1 ' Flag to prevent wait(ing) in [blinkIP] subroutine
  ' gosub [blinkIP]

[home]
cls
let title = "EasyNet Demonstrator " & version & " - A simple flexible way for ESP_Basic nodes to interact with  "
let title = title & " each other  (tested on V2 Alpha 15)"
button "?" [usage] & " "               
html chr(9) & "    " & chr(9) & title   ' was trying to find a way to insert spaces, but doesn't work 
print
udpbegin udpport
udpbranch [udpmain]
html "<BR>"
html "NODE DETAILS  "
if debugmode == "dirty" then button "Edit" [editdetails]  ' hides some unfinished stuff
html "<BR>" & "<BR>"
html "Local name:  " & localname
html "<BR>"
html "Global name:  " & globalname
html "<BR>"
html "Group name:  " & groupname
html "<BR>"
html "Local IP address:  " & localIP
html "<BR>" & "<BR>"
if description <>"" then html "Description:  " & description
html "<BR>" & "<BR>" & "<BR>" & "<BR>"
gosub [sendmsg]
if debugmode == "dirty" then gosub [lastmsgin]  ' unfinished and unavailable
html "<BR>" & "<BR>"
button "Blinks" [blinks] ' blinks the led 5 times for quick visual location
html " "
button "Blink IP" [blinkIP] ' blinks the last IP bytes digits to show its address locally morse code style
html " "
button "Exit" [exit] ' shut down the node
html " "
button "Reset" [reset] ' reboot the node
html "<BR>" & "<BR>"
if rly1status == 1 then button "Turn Relay1 ON" [relay1on]
if rly1status == 0 then button "Turn Relay1 OFF" [relay1off]
html " (give time for  button status to update before clicking again)"
html "<BR>" & "<BR>"
print
html "<BR>"
html "Debug mode=" & " "
dropdown "clean, verbose, dirty" debugmode
html " "
button "Change" [debugchange]
html "<BR>"
if debugmode <> "clean" then html "Ramfree=" & ramfree() '  just for debugging purposes
html "<BR>"
if debugmode <> "clean" then html "Flashfree=" & flashfree()
html "<BR>"
wait

[relay1on]
let rly1status = 0
po rly1 rly1status
goto [home]

[relay1off]
let rly1status = 1
po rly1 rly1status
goto [home]

[relay1tog]
if rly1status == 0 then rly1status = 1 else rly1status = 0
po rly1 rly1status
goto [home]

[ledtoggle]
if ledstate == 0 then ledstate = 1 else ledstate = 0
po ledpin ledstate
return

[debugchange]
if debugmode == "clean" then verbose = 0 else verbose = 1
'html "<BR>"
goto [home]


[broadcast]
if instr(upper(shoutmsg),"LOCAL") == 1 then goto [local]
udpwrite netIP & "255", udpport, shoutmsg
wait

[local]
let msg = shoutmsg
'udpreply msg
goto [main]

[sendmsg]
html " Broadcast message  "
textbox shoutmsg
button "Send" [broadcast] ' broadcast the message
html "<BR>" & "<BR>"
return

[lastmsgin]
html " Last recognised message in "
textbox lastmsg
html "  ( Trying to show last recognised incoming udp msg, but don't know how to do it yet)"
html "<BR>" & "<BR>"
return

[udpmain] 
let msg = udpread()
let lastmsg = msg
[main]
if debugmode <> "clean" then udpreply localname & " msg received: " & msg 
let name = upper(word(msg, 1))
let command = ""
let params = ""
let pos = len(name)
if len(msg) > pos then command = upper(word(msg, 2))
let pos = instr(upper(msg),command) + len(command) + 1
if len(msg) > pos then params = mid(msg,(pos)) else params = ""
if debugmode <> "clean" then udpreply localname & " Name=" & name
if debugmode <> "clean" then udpreply localname & " Command=" & command
if debugmode <> "clean" then udpreply localname & " Params=" & params
if instr(upper(localname),name) > 0 then name = upper(localname) ' complete partial name to full name
if name == "LOCAL" then goto [local_commands]                    ' handle locally-sent commands
if name == upper(localname) then goto [local_commands]           ' handle localname commands
if name == upper(groupname) then goto [group_commands]           ' handle any group commands
if name == upper(globalname) then goto [global_commands]         ' handle any global commands
udpreply localname & " Error: NAME not recognised in " & msg
wait

[local_commands]
'let lastmsg = msg
'udpreply "Local commands " & msg         'For test purposes only
' Add any new unique local commands here (change the test udreply to gosub to your appropriate subroutine handler
if instr(command, upper("PLAY")) <> 0 then udpreply "Play"                                             
if instr(command, upper("PAUSE")) <> 0 then udpreply "Pause"
if instr(command, upper("NEXT")) <> 0 then udpreply "Next"
if instr(command, upper("PREVIOUS")) <> 0 then udpreply "Previous"
if instr(command, upper("VUP")) <> 0 then udpreply "Volume Up"
if instr(command, upper("VDOWN")) <> 0 then udpreply "Volume Down"
gosub [common_commands]
if debugmode <> "clean" then udpreply localname & " Error: COMMAND " & command & " not recognised in " & msg
return

[common_commands]
' Commands recognised by all nodes. Add any new common commands here
if instr(command, upper("Serve")) <> 0 then goto [pingpong]
if instr(command, upper("Ball")) <> 0 then goto [pingpong]
if instr(command, upper("Delay")) <> 0 then goto [pingpong]
if instr(command, upper("Stop")) <> 0 then goto [pingpong]
if instr(command, upper("Report")) <> 0 then goto [report]
if instr(command, upper("?")) <> 0 then goto [declare]
if instr(command, upper("Blinks")) <> 0 then goto [blinks]
if instr(command, upper("BlinkIP")) <> 0 then goto [blinkIP]
if instr(command, upper("Reset")) <> 0 then goto [reset]
if instr(command, upper("Relay1")) <> 0 then goto [getrly1param]
return

[group_commands]
' Sent prefixed by groupname.
' Add any new group-only commands here, eg: "Groupname  NewGroupCommand"
goto [local_commands]

[global_commands] 
' Sent prefixed by globalname, eg: "Globalname NewGlobalCommand"
' Add any new global-only commands here,
goto [local_commands] ' branch to look for local_commands

[getrly1param]
let tempstr = upper(params)
let params = ""
if tempstr = "ON" then goto [relay1on]
if tempstr = "OFF" then goto [relay1off]
if tempstr,"TOG") > 0 then goto [relay1tog]
udpreply localname & " Error: PARAMETER not found for command " & command & " in " & msg
goto [home]

[pingpong]
'udpreply "Acknowledged Reset of " & upper(localname) & " with IP address " & localIP
if debugmode <> "clean" then udpreply localname & " PingPong: " & command 
udpwrite netIP & "255", udpport, "PingPong"
if command == "STOP" then goto [home]
if command == "DELAY" then goto[setppdelay]
if command == "SERVE" then udpreply "BALL"
if command == "BALL" then udpreply "BALL"
gosub [ledtoggle]
delay ppdelay
'udpwrite netIP & "255", udpport, shoutmsg
goto [home]
[setppdelay]
if val(params) > 0 then let ppdelay = val(params)
udpreply "delay=" & ppdelay
let params = ""
goto [home]

[editdetails]
cls
html "EDIT NODE DETAILS "
html " * DO NOT USE * This is unfinished and has bugs! "
print
html "<BR>"
html " Edit node details below, then press Save or Cancel."
html "<BR>" & "<BR>" & "<BR>"
html "Local name:  "
textbox localname
html "<BR>" & "<BR>"
html "Global name:  "
textbox globalname
html "<BR>" & "<BR>"
html "Group name:  "
textbox groupname
html "<BR>" & "<BR>"
html "Description:  "
textbox description
html "<BR>" & "<BR>" & "<BR>"
'button "Save" [save] ' save details to persistent memory
html "   "
'button "Cancel" [home] ' don't save edits
html "<BR>" & "<BR>"
print
html "<BR>"
if debugmode <> "clean" then html "Ramfree=" & ramfree() '  just for debugging purposes
html "<BR>"
if debugmode <> "clean" then html "Flashfree=" & flashfree()
html "<BR>"
wait
return


[save]
write localname
write globalname
write groupname
write description
goto [home]
return
[exit]
print "<BR>" & "Node " & upper(localname) & " with IP address " & localIP & " has been shut down."
udpwrite netIP & ".255", udpport, "Node " & upper(localname) & " has been shut down." & "<BR>"
for count = 1 to 5
po ledpin 0
delay 70
po ledpin 1
delay 200
next count
end


[reset]
udpreply "Acknowledged Reset of " & upper(localname) & " with IP address " & localIP
print "<BR>" & "Node " & upper(localname) & " with IP address " & localIP & " has been rebooted."
timer 3000,[jump]
wait
'reboot
return
[jump]
reboot
wait

[buttonpress]
let duration = millis()
if debugmode <> "clean" then udpreply localname & " button pressed"
if buttonstate == 1 then buttonstate = 0 else buttonstate = 1  'interested in button press but not button release
if buttonstate == 1 then goto [home]
udpwrite netIP & "255", udpport, localname & " button pressed"
gosub [blinkIP]
wait

[declare]
if debugmode <> "clean" then udpreply localname & " Declare IP acknowledged "
udpreply localname & "   " & localIP
goto [home]
return

[report]
if debugmode <> "clean" then udpreply localname & " Report request acknowledged "
udpreply "Sending data"  ' change to include whatever info needs to be sent back
return

[blinks]
if debugmode <> "clean" and name <> "LOCAL" then udpreply localname & " Blinks acknowledged "
if val(params) > 0 then numblinks = val(params) else numblinks = 5
udpwrite netIP & "255", udpport, localname & " numblinks=" & numblinks
let params = ""
'gosub [blink]

'[blink]
let blinkon = 1400
let blinkoff = 600
let blinkpause = 1200
po ledpin 1
delay blinkoff
for bl = 1 to numblinks
po ledpin 0
delay blinkon
po ledpin 1
delay blinkoff
next bl
if nowait == 0 then wait else nowait = 0
return

[blinkIP]
if debugmode <> "clean" then udpreply localname & " BlinkIP acknowledged "
let blinkon = 200
let blinkoff = 400
let blinkpause = 1400
let ip = val(IP4)
'let ip = 345 ' just for something more interesting to blink than my AP 192.168.4.1 single digit
po ledpin 1
delay 1000
let ipstr = str(ip)
let iplength = len(ipstr)
for pos = 1 to iplength
  let digit = mid(ipstr,pos,1)
  for bl = 1 to digit
     po ledpin 0
     delay blinkon
     po ledpin 1
     delay blinkoff
  next bl
  delay blinkpause
next pos
if nowait == 0 then wait else nowait = 0
return

[stripIP]
pos = instrrev(localIP,".")
netIP = left(localIP,pos)
IP4 = mid(localIP,pos+1)
return

'------------* End of program functionality, remainder are just 'doc' pages that can be removed if wished *------------

[usage]
cls
html "USAGE"
print
html "<BR>"
html " Syntax:  NAME  COMMAND  [PARAMETERS]"
html "<BR>" & "<BR>"
html "  eg: Node2  Relay1  On"
html "<BR>"
html "  eg: Porch Light ON"
html "<BR>"
html "  eg: ROUTER  Reboot"
html "<BR>" & "<BR>"
html " EasyNet offers simple UDP networking to make it easy for ESP_Basic nodes to communicate and interact with "
html " each other - no network knowledge is necessary because EasyNet takes care of all that for you, and no network "
html " configuration is required because all nodes use the same common framework configuration and communicate "
html " by NAME instead of IP address (click 'Concept' button below for an easy explanation)."
html "<BR>" & "<BR>"
html " Just assign an appropriate unique name of your choice for other nodes to address their messages to, "
html " then add your own functionality with accompanying commands to do whatever you choose"
html " (click 'Details' for instructions). "
html "<BR>" & "<BR>"
html " Name + Command + optional parameter msgs can be sent by nodes to each other, offering possibility for creating "
html " a cluster of automatically interacting nodes."
html "<BR>"
html " eg: various PIR nodes might send trigger alert msgs for appropriate RELAY nodes to respond to, "
html " and various strategically-located VoiceAnnouncer nodes could announce such events where wished."
html "<BR>" & "<BR>"
html " Commands may be manually sent to other nodes from the Broadcast message window if wished, or sent to themselves "
html " locally by using name 'LOCAL'."
html "<BR>" & "<BR>"
html " Names and Commands are not case sensitive, for ease of use."
html "<BR>"
html " Parameters are case-sensitive to avoid messing up your data, and are received into variable 'params' for "
html " you to deal with as you wish."
html "<BR>"
html " Example: sending ' LOCAL Blinks 20 ' from the Broadcast message window will over-ride the default of 5 blinks "
html " to blink the local led the specified twenty times."
gosub [docfooter]
wait

[concept]
cls
html "CONCEPT"
print
html "<BR>"
html " EasyNet nodes can be likened to people at a party... where some plonker turns out the lights just as you walk in!"
html "<BR>" & "<BR>"
html " You call out... Who's there?, and everyone responds by calling out their names. "
html "<BR>"
html " The response is deafening, so you call out again... It's ME, who is here from MY crowd? - and this "
html " time, only the friends who know you reply with their names. "
html "<BR>"
html " You heard your pal Fred, and know he always carries a torch, so call... Fred, flash your torch so I know where"
html "  you are, and Fred obliges by blinking an led."
html "<BR>"
html " You also heard your boss John, so you ask... John, who turned out the lights?, and he responds... "
html "someone called Wally! "
html "<BR>"
html " You reply... Ok, thanks John, then call out... Hey, Wally you plonker, turn the lights back on, and he obeys. "
html "<BR>" & "<BR>"
html " In that trivial example, messages were sent to specific Names, to a Group, and to Everyone... depending on "
html " needs. "
html "<BR>"
html "Instructions were given, information sent and received, and acknowledgements returned. "
html "<BR>" & "<BR>"
html " That's the sort of interaction EasyNet offers, enabling your ESP_Basic modules to party together."
html " It isn't the fastest or best way to communicate, but it's good enough for many purposes, "
html " and networking just doesn't get any easier than this."
html "<BR>" & "<BR>"
'html "<BR>" & "<BR>"
html " So if that didn't baffle you, then you can just as easily use EasyNet to make your ESP_Basic modules talk to "
html "  each other in much the same way. All modules will hear all messages, but only those modules that recognise "
html " messages intended for them will bother to heed the message and carry out the instruction if it is recognised."
html "<BR>" & "<BR>" & "<BR>"
html " You can effectively consider your networked EasyNet nodes just as black-boxes which can communicate using "
html " simple text messages. Some may be listening for instructions telling them to do whatever it is they do "
html " (no matter how complex that may be), and some may be broadcasting messages with instructions or info"
html " for others to recognise and respond to, and probably others may be doing both - but "
html " anything that is capable of issuing and responding to such messages can interact with all others irrespective "
html " of functionality, platform or architecture... and that simple interaction does not require any rocket science."
gosub [docfooter]
wait
return

[various]
cls
html "VARIOUS"
print
html "<BR>"
html " EasyNet nodes currently recognise the following common commands..."
html "<BR>" & "<BR>"
html " BLINKS - to blink the ESPs blue onboard gpio01 led for locating purposes. Defaults to 5 blinks, but can be "
html " over-ridden by sending optional number parameter. "
html "<BR>"
html " BLINKIP - to flash out the last IP address byte's digits for identification purposes, "
html " eg: IP address 192.168.1.74 would give a group of 7 flashes followed by a group of 4 flashes "
html " (you should already know the subnet address, but may not know the DHCP node address)."
html "<BR>"
html " EXIT - to shut the node down."
html "<BR>"
html " RESET - to reboot the node."
html "<BR>"
html " RELAY3 - which recognises parameters of 'ON' 'OFF' and 'TOGGLE' to control a gpio pin."
html "<BR>" & "<BR>"
html " These commands also have buttons on the web page offering browser operation if required. "
html "<BR>"
html " Relay3 is assigned to gpio at the start of the script, and can easily be changed or removed if wished. "
'html "<BR>"
html " Likewise, any or all of these embedded documentation pages can be removed... see 'Tips' below. "
html "<BR>" & "<BR>"
html " The onboard gpio00 flashing button/jumper can be used to locally trigger BlinkIP if needed. "
html " (this currently requires a pullup resistor to be added to gpio00)."
html "<BR>" & "<BR>"
html " The default local name 'Node' is suffixed with the last byte of the node IP address to prevent absent-mindedness"
html " causing multiple instances of the same default node name on the subnet, thus "
html " default-named nodes can be easily tracked down... just connect to their different 'Node(plusIP)' names to "
html " belatedly rename them."
html "<BR>" & "<BR>"
html " Broadcast message window allows msgs to be manually sent, but current ESP_Basic limitations don't "
html " yet give functionality for a scrolling window to monitor msgs. "
html "<BR>"
html " Use 'LOCAL' instead of target name to send commands to the local node from the Broadcast message window."
html " Messages may be manually sent, received, and monitored by using cicciocb's very handy UDP_debugger utility "
html " which he has kindly created and made available (or you could use a udp Processing script if you're a masochist "
html " with special needs!)."
gosub [docfooter]
wait
return

[think]
cls
html "THINK"
print
html "<BR>"
html " Think about some of the possibilities that EasyNet could offer... not just for networking your own "
html " modules, but also for allowing use of anyone elses."
html "<BR>"
html " As more and more people publish their ESP_Basic projects as EasyNet modules, a growing library of EasyNet "
html " functionality could start to grow... and all of them capable of interacting with each other!"
html "<BR>"
html " People might pick their choice of switch sensors nodes and PIR sensors and data collectors and data processors "
html " and joystick controllers and relay outputs and audio outputs and whatever else is available... then just network "
html " the chosen nodes together to create whatever sort of interactive system functionality they need."
html "<BR>" & "<BR>"
html " Well that's the hope and intention anyway, and (fingers crossed) it's beginning to look hopeful that the "
html " advantages of ESP_Basic may allow it to become a reality."
html "<BR>"
html " We shall have to wait and see... at the moment this is still just an on-going proof-of-concept "
html " project which still has some way to go yet."
html "<BR>" & "<BR>"
html " But here's some more food for thought... cos if the EasyNet concept does prove practical - and at the rate that "
html " mmiscool and cicciocb and others have been speeding ESP_Basic along - I wouldn't be surprised if some form of "
html " condensed and optimised EasyNet functionality made it's way into ESP_Basic itself, and what a nicely matched "
html " partnership THAT might offer!"
html "<BR>" & "<BR>"
html " And for dessert... if ESP_Basic is able lead the way in offering an easy non-technical method for nodes to "
html " interact with each other, then I wouldn't be surprised to see others want to come join the party! "
'html "<BR>"
html " If an inexperienced un-skilled hacker can fumble his way to do this in ESP_Basic, there must be plenty of better "
html " programmers capable"
html " of doing better equivalents for Arduino's and Rasp PI's etc, or anything else for "
html " that matter. At the end of the day, EasyNet nodes are only blackboxes that can recognise and send plain text "
html " messages between each other - and ANY platform is capable of doing that if wished - so it's quite "
html " possible that EasyNet interaction capability could become cross-platform. In fact I know it will for me, "
html " because I need one thing that I know ESP_Basic isn't capable of doing just yet, which is "
html " IR transmit and receive capability... but I know I can do it with arduino C++, and I'm fairly sure I should be "
html " able to do a basic (as in rudimentary) udp comms equivalent for the arduino (albeit without any fancy library) "
html " so my goal is to have arduino IR nodes interacting with ESP_Basic nodes. "
html "<BR>" & "<BR>"
html " In fact it was the need to split up an "
html " over-loaded arduino into a distributed functional equivalent that started the EasyNet idea in the first place."
'html "<BR>"
gosub [docfooter]
wait
return
 

[ideas]
cls
html "IDEAS"
print
html "<BR>"
html " EasyNet is still only a proof-of-concept test project, but I have already built up sufficient confidence "
html " during development and testing to be happy that it should provide the connectivity I need. "
html "<BR>"
html " So when opportunity permits, I'll start trying to do the various node functionality I require, and will publish "
html " whatever I can get done for the benefit of others who might find anything useful for their own purposess."
html "<BR>" & "<BR>"
html " I hope to do a 'PTZ controller' node that will receive commands from things like PIR nodes "
html " and send the appropriate RS485 commands to steer an appropriate ptz cctv camera at a specific trigger location."
html "<BR>" & "<BR>"
html " I also hope to do a 'Supervisor' node if possible, which could act as an intelligent system controller for other"
html " nodes (this is all venturing into the unknown of course)."
html "<BR>"
html " It could receive all trigger alerts, and according to "
html " the senders name, would parse out a list of appropriate responses from a corresponding name entry in a config "
html " file. The responses would just be other commands to be sent to other appropriate nodes to action, such as tell "
html " an audio node to announce the alert, and tell different relay nodes to turn specific things on and off. "
html "<BR>"
html " Give it an RTC and SD card and it could log events, or carry out timed actions."
html "<BR>" & "<BR>"
html " One of the first to be done should hopefully be an 'audio voice announcer' node for speaking selected "
html " pre-recorded msgs. It's already part way there in the form of a music player which was previously published, "
html " but which I'm not yet able to integrate due to various ESP_Basic release issues."
html "<BR>" & "<BR>"
html " Also to be included in EasyNet will be a trivial network Ping Pong example for using 2 nodes "
html " to keep 'bouncing' a 'ball' message between each other to turn on and off their leds. It will serve to "
html " demonstrate interactivity, but also to give an idea of the real-time udp response performance between nodes. "
html "<BR>"
html " The plan is to have 2 EasyNet nodes, then send the command BALL from one to the other, eg:"
html " Node2  BALL, or ALL BALL, then they just keep on responding to each other, until sending NAME STOP. "
html "<BR>"
html " Will probably try to give Ping and Pong an additional DELAY (value) command for slowing down down their "
html " individual reaction times, "
html " eg: NODE1 DELAY 3000. "
gosub [docfooter]
wait
return

[details]
cls
html "DETAILS"
print
html "<BR>"
html " Add your own subroutines to do whatever you wish (most likely copied from your original working stand-alone "
html " project), then add an appropriate entry in EasyNet [local_commands] to recognise your new command "
html " and branch to your appropriate new subroutine to deal with as you choose "
html " (copy and modify one of the existing PLAY or PAUSE example entries if you like)."
'html "<BR>"
html " If a node needs to transmit commands or info or acknowledgements to other nodes, then put an appropriate "
html " transmit command entry (udpreply, udpwrite, etc) into any relevent subroutines which need to transmit. "
html "<BR>" & "<BR>"
html "NOTES:"
html "<BR>"
html "  Names and Commands are NOT case-sensitive (a concession for us memory-impaired!), "
html " so if a specified node name or command exists it will be "
html "  recognised irrespective of CaSE,  ie: blinks or BLINKs or BlinkS or bLiNkS are all recognised as the same."
html "<BR>"
html " Parameters ARE case sensitive, to avoid messing with your data - so remember that small but important difference."
html "<BR>" & "<BR>"
html " If an incoming command is not recognised in [local_commands] "
html "  it will be looked for in [common_commands]."
html "<BR>"
html "  To have even got that far proves that the NAME was recognised ok, "
html " so if the COMMAND is not being recognised it means "
html "  that either something must be wrong with the command spelling being sent to the node, or else somthing "
html " is wrong with the receiving nodes instruction that was added to look for it in [local_commands]."
html "<BR>" & "<BR>"
html " Additional flexibility is offered by ability to address nodes by GLOBAL name and/or GROUP name if wished"
html " These don't have to be used, but allow convenient differentiation of groups of nodes if needed. Your wifi "
html " subnet probably has potential for 254 nodes (1 being the router), therefore you may want more than one EasyNet"
html " system on it - eg: HomeAutomation and Security and Dev clusters etc. - so the Global and "
html " Group names offer a handy way to address just the appropriate system or group of nodes that you are "
html " currently interested in, eg: sending DEV BLINKS could cause just your DEV nodes to blink to show their locations."
html "<BR>" & "<BR>"
html " It's also possible to send msgs to ambiguous local_node names if wished. Assuming you had PIR1, PIR99, PIRdoor "
html " and PIRlounge nodes, you could send PIR BLINKS to blink all pir type nodes with names beginning with PIR."
html " So it's worth giving some thought to your Local, Global and Group naming conventions - rather than later "
html " changing any names and then realising you must change all those corresponding names issued by all other nodes "
html " which need to address the renamed node."
gosub [docfooter]
wait
return

[bugs]
cls
html "BUGS & THINGS TO DO"
print
html "<BR>"
html " NOTE - Not been updated for a while because there's not enough web buttons available to display this page. "
html "<BR>" & "<BR>"
html " Setting Debug mode to 'dirty' on the home page will display some of the unfinished or buggy features."
html "<BR>"
html " Some of the remaining issues simply haven't been addressed yet, but others are due to bugs or limitations "
html " that I haven't been able to find my way around yet. "
html " I'm learning on the hoof, so some may not be much of an issue, but any improvements offered by others "
html " would be very welcome."
html "<BR>"
html " Not everything may be possible of course, but I expect future releases of ESP_Basic will fix some issues. "
html "<BR>" & "<BR>"
html " It's all been done on a steep learning curve, but if this proof-of-concept works I will eventually "
html " do a complete rewrite... unless someone more capable does something better first. I would add that I  "
html " I have been deliberately adding the 'bloatiness' of these 'doc' pages to see how far ESP_Basic "
html " could be pushed, and quite frankly I'm amazed with what it copes with. The biggest - and only - real problem "
html " I've had has been caused by me leaving out the end double-quote off an html line. The trouble is that doing "
html " so is almost guaranteed to cause the wee beastie to crash and reboot... which gets very wearing after the first "
html " few dozen times (and I've lost count of how many times my impatient carelessness has caused it to happen)."
html " Perhaps I should add that the script is now so big that it takes half a minute for each save and load. "
html "<BR>" & "<BR>"
html " I expect the guys will probably be able to mitigate the rebooting to a less drastic error response when "
html " they get an opportunity, but until then I would not recommend typing in this sort of quantity of html text. "
html "<BR>" & "<BR>"
html " If you have the skills you might want to invest an hour or so creating an 'offline' utility that could take "
html " a block of normal text and split it into approptiate length lines and add the approptiate html header and "
html " doublquotes automatically for subsequent pasting into the script... cos believe me, I've wasted a lot of time "
html " from fixing simple errors. It has proved to me that it's perfectly viable to display multiple pages if "
html " needed, but it doesn't like the pages to get too long."
html "<BR>"
html "<BR>" & "<BR>"
html " Textbox is adding unwanted + characters into the message."
html "<BR>" & "<BR>"
html " Cannot find a way to insert spaces to screen, always stripped down to just 1"
html "<BR>" & "<BR>"
html " Cannot find a way to display a confidence msg in the browser while the node is doing something; ie: blinkIP"
html "<BR>" & "<BR>"
html " Would be nice to add hyperlink branching to text, if possible"
html "<BR>" & "<BR>"
html " Hello_World button and window to list the responders would be good, but such a window is not possible yet."
html "<BR>" & "<BR>"
html " Be good to have a window showing the last arrived msg sent specifically to the node."
html "<BR>" & "<BR>"
html " Be nice to provide a network time sync facility to synchronise any RTC nodes for time/date stamping of logs etc."
html "<BR>" & "<BR>"
html " Need to do broadcast_query and request_info and request_acknowledgement subroutines, which if no response after "
html " timeout period expires, will try to resend repeat number of times, before giving up and flagging an error."
html "<BR>" & "<BR>"
gosub [docfooter]
wait
return


[tips]
cls
html "TIPS"
print
html "<BR>"
html " I've purposely stuffed in more than necessary knowing it is easier for anything unwanted to be "
html " removed by some poeple than it is for others to add in."
html "<BR>" & "<BR>"
html " Be aware that the 20 available buttons in Alpha15 have been maxed-out, so if you want to add any new buttons you"
html " will need to remove some unwanted ones first - or else ESP_Basic will crash and reboot. "
'html "<BR>"
html " It will also crash and "
html " reboot if you try assigning a gpio pin that isn't listed on the right of the [VARS} page - and for a whole host "
html " of other reasons - but just remember that you obviously must have done something different to cause the symptom,"
html " so you must back-track to remove that problem else it will keep rebooting until you do. "
'html "<BR>"
html " For those with hair, here are some tips to prevent pulling it out! "
html "<BR>"
html " I should mention that they are just simple things I've learned to do for myself to make life a bit easier "
html " because I don't know any better."
html "<BR>" & "<BR>"
html " I've learned to always do CTRL A and CTRL C on the script before Running or Saving cos you never know when "
html " things may go wrong to cause a crash and reboot - and if recovery requires a reflash, the script is wiped from "
html " memory... which isn't much of a problem if you can do Edit to load the clean page then CTRL V to paste the "
html " script back in."
html "<BR>" & "<BR>"
html " For similar reasons, I always copy and paste the script to a text file every 3 to 5 Saves, because sometimes "
html " ESP_Basic can get its nickers in a twist when Saving a big file (and this one is BIG and takes half a  "
html " minute to save)... and the only recovery is by doing a reformat and reflash. "
'html "<BR>"
html " I always save the text file with Save As, and change it's end 'version' letter to avoid overwriting "
html " the last known good copy with the latest can of worms!"
html "<BR>" & "<BR>"
html " If you click Save and it doesn't eventually pop up the Saved confirmation, you'll probably also find the Edit "
html " window is no longer responsive. It's not the end of the world if you just did Ctrl C beforehand - but the "
html " ESP is now dead, so if you haven't already saved your edited script you are on the brink of losing it."
html "<BR>" & "<BR>"
html " But take heart - it is possible to rescue the script from the browser even though the ESP is dead, as long as"
html " you don't panic and dig a deeper hole for yourself... just click Back in the browser, then Forward, "
html " and now the Edit window should be responsive again, allowing you to do a belated Ctrl A and Ctrl C."
'html "<BR>"
html " You can even first undo your previous edits which caused the problem."
'html "<BR>"
html " A reformat and reflash may be inevitable, but at least you can salvage your script. "
'html "<BR>" & "<BR>"
gosub [docfooter]
wait
return

[tips2]
cls
html "TIPS2 - Crash-recovery"
print
html "<BR>"
html " Ater you've tried cutting corners a few times by only doing a reflash - and found that it still doesn't work "
html " - you'll soon learn to bite the bullet and avoid wasting more time by always doing a reformat first."
html "<BR>" & "<BR>"
html " During reformat and reflash, the blue led should be banging away - and if it isn't then it's not uploading, so "
html " you'll need to redo the operation again. "
html "<BR>" & "<BR>"
html " After reformat, the ESP does not automatically reboot, so you need to reboot using gpio00 to boot it back "
html " into flash mode again prior to reflash, then wait about 30 secs until the led briefly blinks before rebooting, "
html " then wait the recommended 2 minutes after the reformat reboots before starting the reflash."
html "<BR>" & "<BR>"
html " After reflash, the ESP does automatically reboot, so make sure any gpio00 jumper is already removed or the "
html " ESP will boot back up in flash mode, and your reflash could be corrupted before you even get to use it. "
html "<BR>" & "<BR>"
html " If the crash occured during a Run because of program error, autorun could cause it to happen again after the "
html " reflash reboot. You'll know it's rebooting if you see the ESPs blue led give a series of blinks (13), pause, "
html " then give a couple of winks as it re-negotiates wifi reconnection - so you need to press gpio00 flashing button "
html " 'toot-sweet' after that to prevent the program from autorunning again and causing another crash and burn before "
html " you can fix things (note: from Alpha 16 on, autorun can be disabled in SETTINGS. "
html "<BR>" & "<BR>"
html " Once the script isn't auto-running, you can take time to consider what to do next. Clearly there was a problem,"
html " but at this point you may not be sure whether that was due to script error, a wayward ESP, or a hormonal "
html " release of ESP_Basic."
html "<BR>" & "<BR>"
html " Invariably I can never be 100% sure if I did actually save the script last thing before the crash - and I "
html " don't like depending on the last saved text file in case that was also a crasher for previous reasons - plus "
html " it wouldn't be the first time I've done a CTRL C to file instead of CTRL V and ended up losing the latest"
html " version in both file and browser! - so I prefer trying to keep hold of the browsers last Edited script if "
html " possible... (continued in Tips3)."
gosub [docfooter]
wait
return


[tips3]
cls
html "TIPS3 - Crash de-bugging"
print
html "<BR>"
html " After a crash, trying to do a Save - only to discover that the ESP isn't responding - put's you right"
html " back to square one. So the first thing I do after waiting until it looks like the ESP is back up "
html " online, is to try to access the [SETTINGS] page. "
'html "<BR>"
html " If that doesn't work then nothing else will, so a reformat and reflash will be needed, but at least you can "
html " browser Back to the Edit screen and make sure your script is safely copied before going any further. "
html "<BR>"
html " If [SETTINGS] access's ok it proves the ESP is accessable again, so Edit and Save should hopefully also be ok."
html "<BR>" & "<BR>"
html " Now is a good time to pause and concentrate about what's to be done next... you need to do CTRL A and CTRL C on"
html " the Edit page script to be 100% sure, then press Edit to make sure ESP_Basic brings up a virgin Edit screen, "
html " then CTRL V your precious script into the new Edit window, then add 'end' command to the beginning of the script,"
html " then Save it. It aint difficult, but there's several ways to cock things up if you're not careful about it."
html "<BR>"
html " Adding 'end' at the start of the script prevents accidental re-running or autorunning of a problem script "
html " to prevent unnecessary repeated crashes and reboots until you can root out the problem."
html "<BR>" & "<BR>"
html " Once you've got the ESP active and stable, you need to find the culprit, and just because you can't find "
html " anything doesn't mean it's time to start blaming ESP_Basic bugs... if it wasn't rebooting before the last "
html " reboot then it waa obviously caused by something you've done, so you need to track the problem down. "
html " Even if it is an ESP_Basic bug, it has still been introduced by something you've changed, so you need to "
html " back-track through your previous edits."
html "<BR>" & "<BR>"
html " If you are not confident of having found the problem(s), the consequences could be repeated crash and burns, "
html " so my advice is to stick an 'end' command at the top of your script, then run the script to at least make sure "
html " the ESP isn't crashing due to some other cause. "
html "<BR>" & "<BR>"
html " Then if the script exits nicely with a 'done', keep walking the 'end' deeper into the script until it eventually "
html " crashes again... once you've recovered from that crash you should have a fairly good idea of where the "
html " cause of the problem must be, even if it still isn't obvious. "
html "<BR>"
html " The final conclusive proof of the offending line is to comment it out and the crashing then stops."
html "<BR>"
html " It's worth keeping an eye on [VARS] from time to time, cos that can show up var errors and corruptions that "
html " you wouldn't otherwise be aware of. "
gosub [docfooter]
wait
return

[docfooter]
html "<BR>" & "<BR>"
print
html "<BR>"
button "Home" [home]
button "Usage" [usage]
button "Details" [details]
button "Various" [various]
button "Concept" [concept]
button "Think" [think]
button "Ideas" [ideas]
button "Tips" [tips]
button "Tips2" [tips2]
button "Tips3" [tips3]
'button "Bugs" [bugs]
html "<BR>" & "<BR>"
if debugmode <> "clean" then html "Ramfree=" & ramfree() '  just for debugging purposes
html "<BR>"
if debugmode <> "clean" then html "Flashfree=" & flashfree()
html "<BR>"
wait
return