Hello,
My device is getting disconnected when the agent makes a call. I’m running code that used to work fine and hasn’t been changed. Is anyone having the same problem?
Since I’m an absolute beginner, I’m still not sure what’s causing it but my device has stopped sending updates to lively.com on a few occasions.
Until I read your post, I’ve been blaming it on my setup which is still on a breadboard. Each time, it was quickly resolved by resetting the power to the circuit. I also wondered if the Imp was going into some kind of sleep mode and not waking up? I still have a lot to learn…
I tried resetting the power, but as soon as the agent makes a call to the device the device disconnects for some reason that I can’t figure out. I wounded what could cause a device to disconnect.
I think there is something wrong in my circuit, because I removed some code that turns on a pin and now the device is not disconnecting, I will keep investigating.
A lot of times devices ‘disconnect’ because of tight loops / infinite loops:
while(1) { // do something }
Infinite loops block execution of all other processes on the imp, including it’s wifi management. Do either of you have infinite (or very long running) loops in your code?
Have the same problem, and it is due to a tight loop. I’m toggling a pin and I can see it going on the scope, but the Imp is totally dead as far as connectivity. And it doesn’t even try to recover. So if you have an Imp deployed 1000’s of miles away you’ll have to hop on a plane to power cycle it AFAIK.
If the Imp disconnects due to a tight loop then it is poorly designed. What determines too tight?? They’ve done something wrong, and if things like this can happen, then what else?
It doesn’t matter how “tight” the loop is - it matters whether you let go of the thread of execution. Here’s what’s going on:
The imp has a single thread which it uses to manage it’s network connection, run user code, etc. If you have an infinite loop, your code will never give up control of the thread, so background tasks like managing it’s network connection never run, and the imp drops offline.
We are looking at changing this behaviour slightly in a future impOS release to prevent this.
In the meantime, if you’re coding infinite loops, here is the way to do it:
`i <- 0;
function loop() {
// schedule loop to run again
imp.onidle(loop);
// loop logic
if(i++ % 1000 == 0) server.log(i);
}
loop();`
@djohnson As beardedinventor says, this is by design.
Your user code gets the highest priority in the system, to prevent network traffic making things too “lumpy”. This means that if you never yield (effectively, falling off the end of your code), the network code never gets to run.
The upcoming changes will just rudely kill your code if it executes without yielding for too long - we are basically changing our assumption from “the user’s squirrel code knows best” to “that seems too long, something probably went wrong”.
@djohnson More details are at https://electricimp.com/docs/resources/eventprogramming/
@hugo I don’t see any commits made yet against that story, so it’s a bit premature to describe how it’s going to work 
Peter
