Timeout policy and digital_in_wakeup

Device Code
1

Hi - I was wondering if I can get someone to help me

I am testing the imp to wakeup on a trigger on pin 1 and write data to the server. If it has no connectivity, I want it to store the data in nv (that part is working) and send the data when connection is established. What I have noticed is that this works when I use the default suspend_on_error policy, but when I try return_on_error, the imp goes to sleep seemingly permanently with nothing (neither the timer nor the wakeup pin) seems to wake it up.

I have posted the functional code below. Please help!

`
sense ← hardware.pin1;
sense.configure(DIGITAL_IN_WAKEUP);

local dataread = 25;
local sleeptime = 20;

function bootup()
{
local reasonString = “Unknown”
switch(hardware.wakereason())
{
case WAKEREASON_POWER_ON:
reasonString = “The power was turned on”
sense.configure(DIGITAL_IN_WAKEUP);
break

    case WAKEREASON_TIMER:
        reasonString = "An event timer fired"
        sense.configure(DIGITAL_IN_WAKEUP);
        break
        
    case WAKEREASON_SW_RESET:
        reasonString = "A software reset took place"
        break
        
    case WAKEREASON_PIN:
        reasonString = "Pulse detected on Wakeup Pin"
        sense.configure(DIGITAL_IN);
        break
        
    case WAKEREASON_NEW_SQUIRREL:
        reasonString = "New Squirrel code downloaded"
        break
        
    case WAKEREASON_SQUIRREL_ERROR:
        reasonString = "Squirrel runtime error"
        break
    
    case WAKEREASON_NEW_FIRMWARE:
        reasonString = "impOS update"
        break
    
    case WAKEREASON_SNOOZE:
        reasonString = "A snooze-and-retry event"
        break       
}

server.connect(function(reason) { transmitter() } )

server.log("Reason for waking/reboot: " + reasonString)

}

function transmitter()
{
if (server.isconnected())
{
// At this point we have WiFi connected so try to add dataToSend to TCP send buffer

    local outcome = agent.send("postdata", dataread);

    if (outcome == 0)
    {
        // Record successful addition of data to impOS buffer by zero-ing dataToSend
        // This can be used to indicate dataToSend is free for more data

        dataread = dataread+1; //change the data to see if it has cycled through this section

    }
    else
    {
        // Couldn’t add dataToSend to the buffer OR
        // WiFi has been lost OR some other failure
        // RETURN_ON_ERROR in force so we need to re-connect before
        // attempting to add dataToSend to the buffer again
        
        imp.wakeup(10.0, transmitter());

    }
}
else
{
    // WiFi is disconnected, so attempt to reconnect as per RETURN_ON_ERROR
    // Whatever the outcome, we come back to transmitter().
    // We can't schedule transmitter() directly as server.connect()'s
    // callback expects a single parameter to take outcome indicator integer

    server.connect(function(reason) { transmitter() } )
}

}

//run time

server.setsendtimeoutpolicy(RETURN_ON_ERROR, WAIT_TIL_SENT, 10);

//server.setsendtimeoutpolicy(SUSPEND_ON_ERROR, WAIT_TIL_SENT, 10);

bootup();

imp.onidle(function() {

server.log("Data read was" + dataread + ", now going to sleep");

server.expectonlinein(sleeptime);
imp.deepsleepfor(sleeptime);

});
`

2

It appears that nesting the imp.onidle within a imp.wakeup does the trick. Now I need to figure out why! :-?

3

BTW, you can use

server.sleepfor(sleeptime);

in place of

`server.expectonlinein(sleeptime);
imp.deepsleepfor(sleeptime);`

and save yourself a line.

4

When do you return on error, the connect is in progress when your imp.onidle() fires sending the device directly to sleep.

ie, it does:

bootup(), which starts a connect (whose callback calls transmitter, upon connection)
then registers the onidle handler
then fires the onidle handler… which sleeps. The server.log won’t be seen as the connection is not up at this point.

Suggestion would be to only register the onidle handler in the server.connect callback.

…except also you are not specifying the parameters to server.connect() correctly, which may be firing a runtime error. It takes 2 parameters when used in return on error mode - the connect timeout (I’d suggest 30 seconds) and the callback.

5

That seems to have fixed it. Much more elegant than me trying to keep the poor thing awake for longer than it needs to!

Thanks Hugo.

Yes Smittytone - I was experimenting with both to see if it made a difference.