Online=>offline

Any idea what causes this?

Sun Apr 21 2013 20:04:31 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Sun Apr 21 2013 20:08:08 GMT-0700 (Pacific Daylight Time): Power state: offline=>online
Sun Apr 21 2013 20:17:38 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Sun Apr 21 2013 20:18:01 GMT-0700 (Pacific Daylight Time): Power state: offline=>online
Sun Apr 21 2013 20:45:33 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Sun Apr 21 2013 20:46:24 GMT-0700 (Pacific Daylight Time): Power state: offline=>online
Sun Apr 21 2013 20:55:54 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Sun Apr 21 2013 20:57:00 GMT-0700 (Pacific Daylight Time): Power state: offline=>online
Sun Apr 21 2013 21:06:32 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Sun Apr 21 2013 21:07:57 GMT-0700 (Pacific Daylight Time): Power state: offline=>online
Sun Apr 21 2013 22:11:52 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Sun Apr 21 2013 22:13:19 GMT-0700 (Pacific Daylight Time): Power state: offline=>online
Sun Apr 21 2013 22:32:20 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Sun Apr 21 2013 22:32:21 GMT-0700 (Pacific Daylight Time): Power state: offline=>online
Mon Apr 22 2013 01:28:05 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Mon Apr 22 2013 01:32:51 GMT-0700 (Pacific Daylight Time): Power state: offline=>online
Mon Apr 22 2013 02:27:53 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Mon Apr 22 2013 02:32:53 GMT-0700 (Pacific Daylight Time): Power state: offline=>online
Mon Apr 22 2013 03:09:26 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Mon Apr 22 2013 03:09:50 GMT-0700 (Pacific Daylight Time): Power state: offline=>online
Mon Apr 22 2013 03:28:22 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Mon Apr 22 2013 03:29:36 GMT-0700 (Pacific Daylight Time): Power state: offline=>online
Mon Apr 22 2013 03:48:10 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Mon Apr 22 2013 03:52:34 GMT-0700 (Pacific Daylight Time): Power state: offline=>online
Mon Apr 22 2013 04:29:16 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Mon Apr 22 2013 04:30:45 GMT-0700 (Pacific Daylight Time): Power state: offline=>online
Mon Apr 22 2013 05:07:21 GMT-0700 (Pacific Daylight Time): Power state: online=>offline
Mon Apr 22 2013 05:07:43 GMT-0700 (Pacific Daylight Time): Power state: offline=>online

Could it be the code? Setpowersave()?

function myloop(){ local v=hardware.voltage()*1.01; agent.send("update",v); imp.wakeup(60,myloop); } imp.setpowersave(1); myloop();

Testing with setpowersave(0);
Simplifying code to nothing…

Same problem with little code.
Conclusion:
It’s not the Code.

Could it be I need a stronger Wifi signal?

It works perfectly in the same location, same Wifi, with useful code instead of little code above. What am I doing wrong with the few lines above?

Are you logging your imp.rssi levels?
I’ve seen something like this when on the tip of out of range 89/90 dBm
http://devwiki.electricimp.com/doku.php?id=electricimpapi:imp:rssi

You may be unto something, BUT why does this only show up when there is LESS code, not more when I’m doing something useful?

Same issue, had it in the same spot for over a month, just randomly started doing this four days ago.

@mknippen your imp isn’t upgrading for an as-yet unknown reason. It should work fine now whilst we diagnose further (just power cycle it)

Hum I’m seeing this with RSSI of -75 what is wifi outage? different form old wifi error?

Thu Jun 20 2013 07:37:11 GMT+0100 (GMT Daylight Time): Power state: online=>offline
Thu Jun 20 2013 07:37:25 GMT+0100 (GMT Daylight Time): Power state: offline=>online
Thu Jun 20 2013 07:48:55 GMT+0100 (GMT Daylight Time): Power state: online=>offline
Thu Jun 20 2013 07:50:13 GMT+0100 (GMT Daylight Time): imp restarted, reason: wifi outage

Happens for me as well and have the latest firmware … IMP comes online, than quite fast offline, also communication between AGENT and IMP is broken (even while it’s “online”). It worked 3-4 hours ago. Now kinda nothing …

I believe is the same problem we discussed for a couple of days till few hours ago but it looks like not exist anymore… I’m getting lost.

P.S. I get the same issue with imp002 up to date with the r25

I suppose the timeout between server and imp is too low again and when the internet get’s busy, timing is stretched and the result is =>offline. I hope it will be fixed but it’s kinda annoying to develop from Europe with this issue … In US everybody is sleepin so no fixes till tomorrow and also this timeout issues are more frequent over the ocean :slight_smile:

@controlcloud looking in the logs, your device failed to respond to a ping and was marked offline at 07:37 BST and at 07:48 BST (pretty much every online->offline transition is because of an imp being sent a ping by the server, and not getting a reply back within 10 seconds).

Even if wifi was up, “internet weather” between your network and the imp server can cause the new “wifi outage” message - this possibly could be better worded, but it means that for whatever reason, the imp couldn’t get to the server after a minute of trying - could be wifi, could be broadband, could be routing - and went to sleep for 9 minutes before trying again. In this case, that’d correspond to the network going out at about 07:40 for 1 minute+, then coming back some time before 07:50, when the imp reconnected.

If you add wifi off handling to the code, you get to override this default behavior, and could store (then log later) times the network wasn’t responding.

Were you using the internet at that point? From this end it looks like a sporadic outage in your routing. Previously, you wouldn’t have seen the wifi outage error, just the offline and online transitions but now once the connection has come back, the imp tells the server that it couldn’t reach it.

@ituner/etc if you would like more analysis, please PM me with details of your issue (logs, mac address at a minimum). I’m looking into these reported issues case by case because it’s obviously important that any bugs are found and fixed. Some of them (eg Smartmaker’s hannah issue) were simply squirrel errors and nothing to do with the imp.

We have a UK office so things do work well from Europe (obviously with some latency, but nothing of the scale which should cause things to be marked offline).

@Hugo, I would suggest to post a piece of code you propose that anyone can run being sure that the issues, if present, are related to the network and not to the code itself.

If you make available to all of us the same code, then we can for sure eliminate any doubt about it and we can keep checking the rest of the chain.

A kind of “network’s reliability script”. I believe the problem is basically on our side and, as you are checking the issues one by one, it could be quite useful to have all the data based on the same piece of code.

Thinking about my case, for example, I’ve removed the loop and I still get the problem, random, sometimes after less than a couple of seconds.

Dimitri

Hm - it was squirrel in my case too - a too fast callback …
function main()
{
imp.wakeup(0.01, main);

}
caused probably crashing of the device (still blinking green which confused me)

I need a fast cycle which reads and writes data on SPI so I need a callback to do fast stuff whenever it’s possible - no exact timing is needed but be fast as possible when having free MCU time. What’s the best solution for that without overwhelming the squirrel engine? Should I use the onidle somehow?

@Hugo This imp needs to be up all the time so no sleeping.
How about onNetworkError() returns the error then store in nv

Were you using the internet at that point?
Not sure if I was online but I’ve got uplink speed about 8 to 10meg latency of 30ms
Have you tested with BT HomeHub3

@smartmaker example code:

imp.configure(“online test”, [], []);

…and that’s it. This should stay online forever, barring network issues.

@controlcloud you can already do this, see http://devwiki.electricimp.com/doku.php?id=electricimpapi:server:onunexpecteddisconnect

If you set the timeout policy (see http://devwiki.electricimp.com/doku.php?id=electricimpapi:server:setsendtimeoutpolicy ) to RETURN_ON_ERROR the imp will not sleep if it blocks on a network operation and can’t get hold of the server for any reason.

An imp.wakeup(0.01, …) should still be fine, though we have seen issues occasionally. Maybe lengthen it to 0.02 and re-test.

The question about using the internet was whether you would have noticed if there was a small outage at that time - not about whether your link was busy (the imp hardly uses any bandwidth). We have not specifically tested with an HH3, but likely have many customers using them as they’re obviously popular in the UK.

Hugo thanks I still get confused where some of the server. API calls run e.g imp, agent or both in some of the wiki you use A or I it would help if this was done for each of the server. APIs

Thanks as always

Anything in the device code runs on the imp; the commands that start with “server” generally involve talking to the server (eg, server.sleepfor() tells the server the imp is going to sleep, so it knows when it should be checking back in, then locally sleeps).

The A/I labels are to show which commands are accepted where - eg device.on is only a recognised command within the agent.