-->
Page 1 of 1

Something big!

PostPosted: Tue Apr 26, 2016 2:42 pm
by Electroguard
I sort of got funnelled into this...

Our 2 wizards have been doing a magnificent job of pushing ESP_Basic to ever new heights, and I know they are itching to improve the browser Editor which has been a bit left behind, but perhaps this may reduce some of the urgency for that distraction.

I've just discovered that Notepad2 (and probably others) can offer a great ofline editor for ESP_Basic scripts.

It's not particularly useful for run-of-the-mill type stuff cos you're better off doing that direct in the browser editor - but if you've got an obscure problem somewhere, or have a big script with lots of text, the syntax-highlighting could be a god-send.

You need to see for yourself because words can't do it justice, so I've included a big 830 line script I'm working on to demonstrate things even though I'm not quite ready to publish it just yet... needs another bug-fix release of ESP_Basic to allow it to run and be stable before I can tidy it up enough to publish.
Feel free to try it though (if this one runs) if you wish, cos I think there may be things of interest to a lot of people.. just don't whinge that things like Blinks doesn't work (which got broke with the latest release).

What you might want to pay attention to are the self-contained Doc pages (click top left ? button), not just because they may have information of interest, but for the impressive fact that ESP_Basic let's you DO this sort of thing ... 10 full pages of text documentation included along with a wide variety of program functionality, and it could be even more except that I've maxxed out the available buttons (if you un-comment 'Bugs' entry in the Footer at bottom of script it crashes because 1 too many buttons being used).
And it runs on my dev module even when I re-format it as 512K.

Never mind the interactive network capability that's underneath... the screens and their navigation alone show what a capable power-house ESP_Basic has become.

Anyway, to get back to topic, perhaps now you will be able to appreciate just how useful a syntax-high-lighted offline editor could be.

I downloaded Notepad2 free from http://www.flos-freeware.ch/

Paste in the Basic script, select View / Syntax Scheme, then select VBscript or VisualBasic from the list, and eureka... syntax high-lighting for ESP_Basic straight out of the box!

Code: Select allmemclear
let version = "v0.31"
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 = "PING"     ' 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"
let lastmsg = " (last received msg) "  ' (Last received msg facility is unfinished and unavailable)
interrupt 0 [button]
let ledpin = 1       ' Onboard GPIO01 blue led
let ledstate = 1
po ledpin ledstate          ' Ensure lAed is off
let rly1 = 4         ' relay1 gpio
let rly1status = 1
po  rly1 rly1status  ' turns off relay1
let ppdelay = 10
let debugmode = "clean"
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 each other  "
let title = title & "  (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("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("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]
if name <> "PING" and name <> "PONG" then goto[home]
udpwrite netIP & "255", udpport, "PingPong"
if name == "PING" then shoutmsg = "Pong ball"
if name == "PONG" then shoutmsg = "Ping ball"
if command == "STOP" then goto [home]
if command == "DELAY" then goto[setppdelay]
udpreply "delay=" & ppdelay
gosub [ledtoggle]
udpreply "delay=" & ppdelay
delay ppdelay
udpwrite netIP & "255", udpport, shoutmsg
goto [home]
[setppdelay]
if val(params) > 0 then let ppdelay = val(params)
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

[button]
' Send a broadcast request for system nodes to declare themselves (Who's there)
'print "GPIO00 button pressed"
'let inpin = 0
'pi inpin
'if inpin == 1 then print "inpin = 1" else print "inpin = 0"
if debugmode <> "clean" then udpreply localname & " button pressed"
udpwrite netIP & "255", udpport, localname & " button pressed"
gosub [blinkIP]
wait

[declare]
if debugmode <> "clean" then udpreply localname & " Declare IP acknowledged "
udpreply localname & "   " & localIP
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 let numblinks = val(params) else let numblinks = 5
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)
' gosub [blink]
  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."
html " (click 'Think')"
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 does not work due to a bug in Alpha 15)."
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 called Ping and Pong"
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 called Ping and Pong, then send the command BALL from one to the other, eg:"
html " PING  BALL, then they just keep on responding to each other. "
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: PONG 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 " 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 "Tips" [tips]
button "Tips2" [tips2]
button "Tips3" [tips3]
button "Concept" [concept]
button "Think" [think]
button "Ideas" [ideas]
'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


Re: Something big!

PostPosted: Wed Apr 27, 2016 9:09 am
by viscomjim
Holy Cow thats a lot of lines of code! Glad to see that the esp can work with that much code. All the new features are really making this an awesome port! Another big thanks to the captains!!!!!

Re: Something big!

PostPosted: Wed Apr 27, 2016 10:18 am
by Electroguard
Yes, I think ESP_Basic is amazing... and I'm using just a fraction of its power and capability simply to achieve some useful functionality which I want to include in the EasyNet demonstrator program.

All those bloatware pages of info are just unnecessary fur coat... but they might just as easily be 10 different multi-functional and dynamic server web pages - which is a lot of potential server to be so easily stuffed into even a 512K ESP.

And 830 lines ain't actually that much compared to mmiscool's announcement a short time ago that cicciocb has increased the line capability to 2000... that's over double the size of my little bloatware.


So that's why I needed to let people know about the potential benefits of being able to use something like Notepad2 with it, cos it opens up the possibility of creating some seriously useful Servers and Apps with ESP_Basic.

The only 2 real limitations I've come across are imposed by the max limit of available buttons and other web components, but considering I've been deliberately pushing that limit to test it, in reality I don't think it's likely to be very restrictive very often. And if that does start becoming a problem, the guys could raise the limit if it became necessary.
The other limitation is that if you have long html pages you can fill up the buffer and cause problems, but it's simple enough (and usually preferable) to be splitting longer pages into more manageable shorter ones, assuming you have enough buttons left to be able to navigate the extra pages.

ESP_Basic is a different beast to what it was even a few weeks ago when I fortuitously stumbled across it, and I don't need to be a fortune-teller to say that it's also going to become a different beast in the future, cos I know there's so much more that the guys want to add when time permits, and when they get bored, I have some suggestions for them.

ESP_Basic is on an exciting journey, and it's nice to be along for the ride.

Re: Something big!

PostPosted: Wed Apr 27, 2016 10:33 am
by cicciocb
HI Electroguard,
as your nick suggest this is really "Electroshocking" code! :D

I'm very happy to contribute at this project, in particular the improvement removing the 255 lines limitation.

I think that the ESPBasic is now ready to do some "autonomous" tasks and not only used as a "satellite" or "peripheral" of other controllers such as Arduino, .... .
The language contains now all the elements permitting to write a complete program, control external peripherals, interface with other devices and so on.
The "big" program you wrote it's the evidence that this is possible and is thanks to people like you that, sharing their work, permit to discover this potentiality to others.

I hope that more and more people take interest into ESP Basic as this is the motivation that drives our efforts.

CiccioCB