Imp does not run local code after it fails to find a wifi

Hi,
I have built a temperature sensor that can read the data and store it in persistent flash memory before sending it to my server at periodic interval. However, if it could not connect to the wifi, it stops running the code, no data is saved to flash and hence I lose the data and kills the basic purpose my device. I’m using the default connection/reconnection behavior of imp, basically suspend_on_error.

Can someone point me to a connection mechanism or example which I can use to run the code after the imp fails to connect to wifi.

Many thanks.

Tony is working on a document to lead people through this, but the basic thing you need to do is to change the default behavior (otherwise every time you get to a server.log() then you’ll cause the imp to hang until it’s connected as it’s trying its best to send the log message like you asked it to).

See the second example on this page: http://www.electricimp.com/docs/api/server/connect/

So…point of clarification. Does the imp hold its code through a power cycle? I’m looking at a particular application where an imp might lose power and when it regains power, not be able to find WiFi. Does it retain its last program and restart it when it regains power?

The clarification with the server.log() is really important, as I had not understood an imp would hang on this–I guess I assumed it was a non-blocking call.

Are server.log() posts available after an imp has been blessed? In other words, will I be able to see those or are they only for debug purposes?

I apologize if these topics are covered elsewhere, but this forum is getting so big (great!) that it’s often a challenge to find prior posts.

Yes the imp holds code through a power cycle. At cold boot, the imp will attempt to connect for 10 seconds (to verify the code is correct) before it gives up and runs the stored code - this is to prevent you bricking the device by mistake (eg by putting code in there which sleeps immediately, preventing it from ever checking to see if you modified the code after that point).

If the stored code then sets the right connection policy (or doesn’t try and do any network stuff) it’ll run fine.

After a device has been blessed, server.log()'s are dropped on the device side (they never go over the network). You can re-enable logging on the fly for specific devices in the field using command line tools if required.