- Sun Apr 17, 2016 6:49 pm
#45660
Hi, thanks for the new hoard of goodies!
I think there may be a biggy problem with the variables though.
The udp script I've been working on has a couple of Textboxes for udp msg IN and OUT (still don't work yet), and a Dropdown to select Debug mode (clean, verbose, dirty).
When not in 'clean' mode it displays Ramfree and Flashfree on the bottom of all screen pages (over 10 of them), and those values which remained fairly stable on Alpha10 are now hopping all over the place in A13, but generally trending downwards. Eventually I start getting strange error msgs showing on the bottom of the window (fault in IF statements etc,) even though the script is still running and switching between screen pages.
I noticed that if I select something different from the dropbox, it gets displayed in both the textboxs also, even though they should all be different variables.
When I checked on the VARS page, I found that it wasn't the actual values that were wrong, it was the names of the variables themselves that were being corrupted, and presumably not being usable to the web components. It was also creating entirely new 'extra' variables with partially garbage names that were obviously corruptions of the original 'lost' variable.
I've included the script so you can see for yourself - it's big, but deliberately so for stress test.
Run it, then select 'dirty' from the Debug mode dropbox at the bottom of the page, then the Change button next to it.
That will show the Ramfree value lower down but also a couple of Textboxs midscreen, which will now incorrectly show what the Dropbox should be showing (dirty) but instead is still showing its previous 'clean' value.
You can see how things are affecting Ramfree by cliclkng the top left ? button then hopping through some of the different page buttons.
Back on the Home page, click Send button with different edited text a couple of times, then check the [VARS] page, and you should see some obvious corruption.
I think there may be a biggy problem with the variables though.
The udp script I've been working on has a couple of Textboxes for udp msg IN and OUT (still don't work yet), and a Dropdown to select Debug mode (clean, verbose, dirty).
When not in 'clean' mode it displays Ramfree and Flashfree on the bottom of all screen pages (over 10 of them), and those values which remained fairly stable on Alpha10 are now hopping all over the place in A13, but generally trending downwards. Eventually I start getting strange error msgs showing on the bottom of the window (fault in IF statements etc,) even though the script is still running and switching between screen pages.
I noticed that if I select something different from the dropbox, it gets displayed in both the textboxs also, even though they should all be different variables.
When I checked on the VARS page, I found that it wasn't the actual values that were wrong, it was the names of the variables themselves that were being corrupted, and presumably not being usable to the web components. It was also creating entirely new 'extra' variables with partially garbage names that were obviously corruptions of the original 'lost' variable.
I've included the script so you can see for yourself - it's big, but deliberately so for stress test.
Run it, then select 'dirty' from the Debug mode dropbox at the bottom of the page, then the Change button next to it.
That will show the Ramfree value lower down but also a couple of Textboxs midscreen, which will now incorrectly show what the Dropbox should be showing (dirty) but instead is still showing its previous 'clean' value.
You can see how things are affecting Ramfree by cliclkng the top left ? button then hopping through some of the different page buttons.
Back on the Home page, click Send button with different edited text a couple of times, then check the [VARS] page, and you should see some obvious corruption.
Code: Select all
memclear
let version = "v0.23b"
let localIP = ip()
gosub [stripIP]
let udpport = 5001
let localname = "default" & IP4 ' Over-ride this default by uncommenting the line below and changing to a 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 blink"
let groupname = "Some" ' Allows addressing different groups of nodes if required. eg: "SOME blink"
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 recognisedmsg = " (last recognised msg here) "
let ledpin = 1 ' Onboard GPIO01 blue led
po ledpin 1 ' Ensure led is off
broadcastmsg = "Hello world"
let debugmode = clean
'let verbose = 1
let nowait = 0 ' Flag to prevent wait(ing) in [blinkIP] subroutine
' 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]
' cls
[home]
cls
let title = "EasyNet " & version & " - A simple flexible way for ESP_Basic nodes to interact with each other "
let title = title & " (tested on V2 Alpha 10)"
button "?" [intro] & " "
html chr(9) & " " & chr(9) & " " & title ' doesn't work - need to find a way to insert spaces
print
udpbegin udpport
udpbranch [udpmain]
html "<BR>"
html "NODE DETAILS "
if debugmode == "dirty" then button "Edit" [editdetails]
html "<BR>"
html "<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>"
html "<BR>"
if description <>"" then html "Description: " & description
html "<BR>" & "<BR>"
html "<BR>" & "<BR>"
if debugmode == "dirty" then gosub [sendmsg]
if debugmode == "dirty" then gosub [lastmsg]
html "<BR>" & "<BR>"
button "Blink 5" [blink5] ' blinks the led 5 times for quick visual location
html " "
button "Blink 99" [blink99] ' blinks the led 99 times long enough to hunt for it
html " "
button "Blink IP" [blinkIP] ' blinks the last IP bytes digits to show its address locally morse code style
html " "
button "Spare" [button] ' spare test button, currently just triggers [blinkIP]
html " "
button "Exit" [exit] ' shut down the node
html " "
button "Reset" [reset] ' reboot the node
html " "
'print "Want to do a network time sync if possible"
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
[debugchange]
if debugmode == "clean" then verbose = 0 else verbose = 1
'html "<BR>"
goto [home]
[sendmsg]
html " Edit message to broadcast "
textbox broadcastmsg
button "Send" [broadcast] ' broadcast the message
html " ( Not yet working properly, keeps+adding+unwanted+plus's+between+words)"
html "<BR>" & "<BR>"
return
[lastmsg]
html " Last recognised message in "
textbox recognisedmsg
html " ( Trying to show last recognised incoming udp msg, but don't know how to do it yet)"
html "<BR>" & "<BR>"
return
[editdetails]
cls
html "EDIT NODE DETAILS "
html " * DO NOT USE * This is unfinished and has bugs! (adds+unwanted+plus's+between+words)."
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
[intro]
cls
html "INTRODUCTION"
print
html "<BR>"
html " EasyNet offers a simple UDP network framework to allow ESP_Basic nodes to easily communicate and interact with "
html " each other - no network configuration is needed because all nodes use the same common framework configuration, "
html " and no network knowledge is required either, because EasyNet takes care of all that for you (press Easy buttom "
html " below for reassurance)."
html "<BR>" & "<BR>"
html " All you need do is assign an appropriate unique name of your choice for other nodes to be able to address "
html " messages to, then obviously add whatever command functionality you wish the node to recognise and respond to "
html " (How2 button explains how). "
html "<BR>" & "<BR>" & "<BR>"
html " Usage syntax is NAME [COMMAND] [Parameters]"
html "<BR>" & "<BR>"
html " eg: MP3Player PLAY"
html "<BR>" & "<BR>"
html " or: ROUTER Reboot"
html "<BR>" & "<BR>"
html " or: Porch Light ON"
html "<BR>" & "<BR>" & "<BR>"
html " Name + Command + optional parameter msgs can be sent by other nodes, offering possibility for creating a cluster "
html " of automatically interacting nodes. Eg: various PIR nodes might send trigger respone msgs to control appropriate "
html " RELAY nodes, and various strategically-located VoiceAnnouncer nodes could announce such events where wished."
gosub [docfooter]
wait
[party]
cls
html "PARTY"
print
html "<BR>"
html " Think of EasyNet nodes as like 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 " But there's too many replies, so you call out again... It's ME, who is here from MY crowd? - and this "
html " time, only friends who you know tell you 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 that EasyNet offers... it allows 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 that recognise their name "
html " at the beginning of a message will bother heeding the message and carry out the instruction if it is recognised."
html "<BR>" & "<BR>" & "<BR>"
html " You can consider your networked EasyNet nodes as effectively just 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 " (whatever that may happen to be), and some may be broadcasting messages with instructions or info"
html " for others to recognise and respond to, and most likely some will be doing both - "
html " but irrespective of any module complexity, their interaction is simple and not rocket science. "
gosub [docfooter]
wait
return
[plus]
cls
html "PLUS"
print
html "<BR>"
html " Currently, EasyNet nodes recognise the following common commands..."
html "<BR>" & "<BR>"
html " BLINK5 which blinks the ESPs blue onboard gpio01 led 5 times for quick spotting purposes."
html "<BR>"
html " BLINK99 which blinks the ESPs blue onboard gpio01 led 99 times for tracking down location purposes."
html "<BR>"
html " BlinkIP which flashes 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>" & "<BR>"
html " These commands also have buttons on the web page offering browser operation when necessary. "
html "<BR>"
html " "
html " Spare is an example test button (currently just invokes BlinkIP) to show how you could just as easily be "
html "turning relays on and off if you wished. "
html "<BR>"
html " I planned to use the onboard gpio00 flashing button/jumper to locally trigger BlinkIP if needed, but "
html " now that it's already being used in ESP_Basic I need to check that situation with cicciocb first."
html "<BR>" & "<BR>"
html "To help avoid absent-mindedness causing multiple instances of the same default local node name on the subnet, "
html " the default local name is suffixed with the last byte of the node IP address, allowing un-named duplicate "
html " default-named nodes to be easily tracked down - just connect to their different default(plusIP) names to "
html " belatedly rename them."
html "<BR>" & "<BR>"
'html "<BR>"
html " Nodes will eventually be able to manually send msgs and show incoming msgs, but both these have bugs at "
html " the moment and are normally hidden away (perverts can ogle them by changing the bottom-left debug-mode to dirty "
html " if they really must)."
html " In the "
html " meantime you can manually send messages using cicciocb's very handy UDP_debugger utility that he has kindly "
html " created and made available (or you could use a udp Processing script if you're a masochist with special needs!)."
html "<BR>"
html " The bottom left debugger mode doesn't just hide skeletons, it shuts up verbose udp prattle when in clean mode... "
html " (now if only people had such a button!)"
gosub [docfooter]
wait
return
[yummy]
cls
html "YUMMY"
print
html "<BR>"
html " Pause to think about the possibilities that EasyNet might 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 connect "
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 the plan anyway, and (fingers crossed) it is starting to look hopeful that the "
html " advantages of ESP_Basic may allow it to become a reality."
html "<BR>"
html " But we shall see... because 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 equivalent functionality for Arduino's and Rasp PI's etc (and even Supercomputers 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 could become cross-platform for hackers. In fact I know it will for me, "
html " because I need the 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 intention 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 " So when opportunity permits, I'll start trying to do the various node functionality I require, and will publish "
html " whatever I get done for the benefit of others who might find anything useful for their own purposess."
'html "<BR>"
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>"
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). 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 " 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 pre-recorded "
html " msgs. It's already part way there in the form of the music player which is included as an example within EasyNet."
html " Also included in EasyNet is a trivial network Ping Pong example, using 2 nodes called Ping and Pong to keep "
html " bouncing a Ball message between each other and turning on and off their leds. It serves to demonstrate "
html " interactivity, but also gives some idea of the real-time response performance possible between nodes "
html " (set Debug mode on bottom-left of the Home page to 'clean' to prevent broadcasting unnecessary debug msgs)."
html "<BR>"
html " Just name 2 EasyNet nodes as Ping and Pong, then send the command BALL to one of them (eg: PING BALL). "
html "<BR>"
html " Ping and Pong also accept DELAY (value), so you can slow down their individual reaction times "
html " (eg: PONG DELAY 3000). "
gosub [docfooter]
wait
return
[how2]
cls
html "HOW TO"
print
html "<BR>"
html " Add your own subroutines to do whatever you wish (most likely copied from your original stand-alone project), "
html " 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 enter an appropriate "
html " transmit command (udpreply etc) line into any relevent subroutines which should 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: blink or BLINK or Blink or bLiNk 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 transmitted to the node, "
html " or else somthing is wrong with the 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 BLINK 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, "
html " PIRshed, PIRlounge nodes, you could send PIR BLINK 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 " change any names and then realise 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
[docfooter]
html "<BR>" & "<BR>"
print
html "<BR>"
button "Home" [home]
button "Intro" [intro]
button "Party" [party]
button "Yummy" [yummy]
button "How2" [how2]
button "Plus" [plus]
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
[udpmain]
msg = udpread()
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 ))
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)
if name == upper(localname) then goto [local_commands] ' handle localname commands
if name == upper(groupname) then goto [group_commands]
if name == upper(globalname) then goto [global_commands]
udpreply localname & " ERROR: Name not recognised in " & msg
wait
[local_commands]
recognisedmsg = 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 & " cannot recognise command " & command
return
[common_commands]
' Commands recognised by all nodes. Add any new common commands here
if instr(command, upper("Report")) <> 0 then goto [report]
if instr(command, upper("Blink5")) <> 0 then goto [blink5]
if instr(command, upper("BlinkIP")) <> 0 then goto [blinkIP]
if instr(command, upper("Reset")) <> 0 then goto [reset]
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
[broadcast]
udpwrite IP1 & "." & IP2 & "." & IP3 & ".255", udpport, broadcastmsg
wait
[exit]
print "<BR>" & "Node " & upper(localname) & " with IP address " & localIP & " has been shut down."
udpwrite "192.168.4.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 the print "inpin = 1" else print "inpin = 0!
if debugmode <> "clean" then udpreply localname & " button pressed"
udpwrite IP1 & "." & IP2 & "." & IP3 & ".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
[blink5]
if debugmode <> "clean" then udpreply localname & " Blink5 acknowledged "
let numblinks = 5
gosub [blink]
[blink99]
if debugmode <> "clean" then udpreply localname & " Blink99 acknowledged "
cls
let numblinks = 99
html "<BR>" & "<BR>"
print "WARNING - If you confirm to Blink 99 times the node will not be able to respond to anything else during that time"
html " and I don't know of any way to prematurely abort, so press confirm only if you're sure, else press cancel."
html "<BR>" & "<BR>"
button "Confirm" [blink]
button "Cancel" [home]
html "<BR>" & "<BR>"
wait
[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]
let tempIP = localIP
let dot = instr(tempIP,".")
let IP1 = left(tempIP,dot - 1)
let tempIP = right(tempIP, len(tempIP)-dot)
let dot = instr(tempIP, ".")
let IP2 = left(tempIP, dot - 1)
let tempIP = right(tempIP, len(tempIP)-dot)
let dot = instr(tempIP, ".")
let IP3 = left(tempIP,dot-1)
let IP4 = right(tempIP, len(tempIP)-dot)
return
