I want to make sure I understand this correctly. My implementation is not working as expected.

Activity Listens to Pandora

Acivity functions:
CF.activity().onSleep = function() { socket.close(); }

CF.activity().onWake = function() {
  socket = new TCPSocket(false);
  socket.connect(IPaddr, 60128, 3000);// port 60128, 3000 s\msec
}

Jumps to display page:
if (socket.connected === false) {
     socket.connect(IPaddr, 60128, 3000);
  } else {
     doInit(); //sends queries for display data
}

socket.onConnect = function() {
   System.print("Connection to DHC 40.1 sucessful!");
   System.setGlobal("gIPaddr", IPaddr);
   System.print("gIPaddr onConnect= " + System.getGlobal("gIPaddr"));

  result = "";     //clear receive buffer
  replyMsg = "";//parse string 
  doInit();        //load up page
}

Then onData() and parse routines display the song/tack/time...etc.

But, Pronto goes to sleep while on the display page. onWake it should establish a new socket connection and upon connection begin the process again. It doesn't. I just see the same page as when it went to sleep.

Is it correct that the display timeout set the unit to sleep or is it different time out? I have WiFi set for 24hrs.

Thank you.

Inside onWake when you create the new socket, you must assign the onData and onConnect functions to the new socket. Note that with each socket instantiation, you MUST assign new callback functions. You cannot reuse a socket after it has been closed. If you replace an existing socket, you should first check to see if it is non-null and connected and if so, close it and assign null to the variable to release the underlying TCP resource (limited to 64 concurrent sockets IIRC).

Summary of activity script changes/validation

var socket = null;

function onSocketConnect() {
System.print("Connection to DHC 40.1 sucessful!");
System.setGlobal("gIPaddr", IPaddr);
System.print("gIPaddr onConnect= " + System.getGlobal("gIPaddr"));

result = ""; //clear receive buffer
replyMsg = "";//parse string
doInit(); //load up page
}

function onSocketData(){
// do your reads here...
}

function cleanupSocket()
{
if (socket && socket.connected)
{
try{socket.close();}catch(toIgnore){}
}
socket = null;
}

CF.activity().onSleep = function()
{
// close socket if connected and cleanup.
cleanupSocket();
}


CF.activity().onWake = function(){

// make sure to cleanup previous socket.
cleanupSocket();

socket = new TCPSocket(false);
socket.onData = socketOnData;
socket.onConnect = socketOnConnect;
socket.connect(IPaddr, 60128, 3000);// port 60128, 3000 s\msec

}

// make sure to cleanup previous socket.
cleanupSocket();

socket = new TCPSocket(false);
socket.onData = socketOnData;
socket.onConnect = socketOnConnect;

if (socket.connected === false)
{
socket.connect(IPaddr, 60128, 3000);
}
else
{
doInit(); //sends queries for display data
}

Also, try a search for try catch debug and you can find some examples where I've posted about using try/catch along with System.print to capture possible script errors that might be occurring.

You can wrap entire activity/page/button scripts with try/catch to allow you to debug them. Note that this approach does not trap things like mismatched braces or parentheses. These will cause compilation failures.

Without try/catch, if the script compiles but during runtime, encounter an error, you might not see things initialize properly or the System.print statements make it to a _PS_DEBUG_ panel. This approach is very useful with PEPv1 but has become less useful with PEPv2 and the Debugger Console. However, I still do most of my debugging in PEPv1 and use this quite often.

Lyndel,
Thank you for describing the proper way to handle TCP socket connections and reconnections. I will give this a go and report back. I understand it, pretty much.

Lyndel,
The TCP management scheme you provided works like a charm, thank you! It was very useful to study these prior to implementing.

I'm not sure why, but the Actions for this activity don't fire post script and before jumping to the page requested. All other activities do execute the actions OK. I'll keep looking into this and I plan to implement the TCP techniques into other activities.

Most appreciative...bob

Bob,

If you want to email me your file with a description of what you are trying to do and what is happening now (activities, pages, buttons that are being used), I will have a look.

I'm glad that the code example I posted was indeed helpful.

FYI, Barry Gordon has a document on Pronto Serial Communications at www.the-gordons.net that also contains a section on TCP/IP that you might also find interesting.

:-)

The Actions I'm refering to are just two IR commands with a short delay in the Action list at the Activity level.

All my Activities are straight forward in that from the home page they:
1) Jump to a page at the activity level
2) Activity level script runs
3) Activity level Actions execute
4) Jump/land on a page in the Activity
...scheduleActions() not required at the end of an Activity script.

But, I think this is all very typical and standard PEP behavior.

This Activity script is simply a list of definitions.

Personally, if I am running script in an activity, I code up my actions in a button and execute that button at the end of the script using scheduleActions vs using the Activity ActionList.

Yes, that's my next step. It's just confounding to me why it's not behaving the same in this Activity versus others...

It is all a matter of timing. Note that there is more than 1 thread running when you are doing all this. executeActions() runs on current thread. scheduleActions runs on a completely separate thread.