- Sat May 28, 2016 2:32 pm
#48165
All I can offer are my own observations and what steps I would take if in your place.
I've spent days trying to get MsgBranch working how I needed it to on Alpha 24, but in the end I have had to give up.
I could see in [VARS] that msgs were being sent and received ok, but [mybranch] was never actually being invoked properly by the msgs, because I could put anything I wanted in there which was never actioned, ie: 'end' never ended the program.
No point logging it as a bug because version 2 is history anyway, so it's a matter of being patient for the guys to release version 3 then see if that works properly.
In the meantime you might want to reformat and reflash your ESP, because I have had several occassions where an error has caused partial flash ram corruption such that things appeared to be working correctly except that branches and variables were being tangled up with each other and going to the wrong destination or returning the wrong value.
In your case - and I am only guessing and surmising - I'm wondering if your 'a' variable might be the equivalent of an 8 bit 'C' signed integer in which case it's possible that your 1 per sec 'a' count might have rolled over past it's max value after a few hours which could have caused corruption. Preventing subsequent rollovers would not undo any existing corruption, nor would a reflash, so you would need to do a reformat to clear it.
Your script is not sending any info back to the browser, so there is no effective way of knowing what is happening under the skin.
That situation is quite easy to correct, and could offer you an alternative means of remote control to the msgbranch, if you used udp network commands to send control info and receive feedback from the esp using cicciocb's udp_debugger utility.
I am in the process of doing a tutorial which covers exactly this sort of scenario, but in the meantime add these initialisation lines to the beginning of your script...
let udpport = "5001"
udpbegin udpport
udpbranch [UDPMAIN]
then add a...
[UDPMAIN]
let msg = udpread()
if msg is this that or the other then go do whatever you need to do
wait
... subroutine which effectively does the same as your existing msgbranch subroutine.
You then just need to send your appropriate instructions/variables from the udp debugger utility instead of the msg? browser strings.
You can add...
udpwrite "192.168.4.255", udpport, "Return msg info=" & returnmsg
... anywhere in your script to send back whatever info you wish to the udp debugger utility.
Obviously if you are not in AP mode you will need to replace the first 3 bytes with whatever your subnet address is, but the last byte should always be 255 (broadcast address) instead of the actual nodes address.
I've spent days trying to get MsgBranch working how I needed it to on Alpha 24, but in the end I have had to give up.
I could see in [VARS] that msgs were being sent and received ok, but [mybranch] was never actually being invoked properly by the msgs, because I could put anything I wanted in there which was never actioned, ie: 'end' never ended the program.
No point logging it as a bug because version 2 is history anyway, so it's a matter of being patient for the guys to release version 3 then see if that works properly.
In the meantime you might want to reformat and reflash your ESP, because I have had several occassions where an error has caused partial flash ram corruption such that things appeared to be working correctly except that branches and variables were being tangled up with each other and going to the wrong destination or returning the wrong value.
In your case - and I am only guessing and surmising - I'm wondering if your 'a' variable might be the equivalent of an 8 bit 'C' signed integer in which case it's possible that your 1 per sec 'a' count might have rolled over past it's max value after a few hours which could have caused corruption. Preventing subsequent rollovers would not undo any existing corruption, nor would a reflash, so you would need to do a reformat to clear it.
Your script is not sending any info back to the browser, so there is no effective way of knowing what is happening under the skin.
That situation is quite easy to correct, and could offer you an alternative means of remote control to the msgbranch, if you used udp network commands to send control info and receive feedback from the esp using cicciocb's udp_debugger utility.
I am in the process of doing a tutorial which covers exactly this sort of scenario, but in the meantime add these initialisation lines to the beginning of your script...
let udpport = "5001"
udpbegin udpport
udpbranch [UDPMAIN]
then add a...
[UDPMAIN]
let msg = udpread()
if msg is this that or the other then go do whatever you need to do
wait
... subroutine which effectively does the same as your existing msgbranch subroutine.
You then just need to send your appropriate instructions/variables from the udp debugger utility instead of the msg? browser strings.
You can add...
udpwrite "192.168.4.255", udpport, "Return msg info=" & returnmsg
... anywhere in your script to send back whatever info you wish to the udp debugger utility.
Obviously if you are not in AP mode you will need to replace the first 3 bytes with whatever your subnet address is, but the last byte should always be 255 (broadcast address) instead of the actual nodes address.
