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 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
@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.
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
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
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.
