my imp was apparently upgraded today, the message “imp os upgraded” appeared on the server log. Since then, the device is continuously switching from “Power state: online=>offline” to “Power state: offline=>online” (every 10 to 30 minutes)
I have rebooted the impmanually a couple of times in between, but no significant change in the behaviour.
The code which is running on the agent is waiting for external http request, it is also waiting for imp request coming every hour and pasing data to an external hosted file. The imp code if waking up every hour, or each time the agent is requesting something via an external web page, and delivering the requested data to the agent. All was working well till today…Any idea ?
Thanks
I thought I was the only one having those issues…
We’ve not seen this behavior with any of our imps. Can you post your code? If you are doing anything locally which prevents TCP processing, you could get marked offline.
Looking in the logs, your imp was not responding to pings, and so got marked offline.
Edit: Have found a server-side change which may have affected this. Stay tuned. It would only affect certain router configurations, we should have this fixed up later today.
I get this situation with the hannah temperature logger (without correction, needed for the new hannah), but the error is software handled (“I2C Read Failure”), so only online -> offline
@dolf, if you get a runtime error (red text in the log) then the expected behavior is offline->online as the imp disconnects and reconnects.
Are you seeing a runtime error?
no, code keeps running, just “I2C Read Failure” but that is part of the code
Tue Jun 18 2013 20:01:12 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Tue Jun 18 2013 20:01:12 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Tue Jun 18 2013 20:01:12 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Tue Jun 18 2013 20:01:12 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Tue Jun 18 2013 20:01:12 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Tue Jun 18 2013 20:01:12 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Tue Jun 18 2013 20:01:12 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Tue Jun 18 2013 20:01:12 GMT+0200 (West-Europa (zomertijd)): Power state: online=>offline
Tue Jun 18 2013 20:01:14 GMT+0200 (West-Europa (zomertijd)): Power state: offline=>online
Tue Jun 18 2013 20:01:14 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Tue Jun 18 2013 20:01:14 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Tue Jun 18 2013 20:01:14 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Tue Jun 18 2013 20:01:14 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Tue Jun 18 2013 20:01:14 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Tue Jun 18 2013 20:01:14 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Tue Jun 18 2013 20:01:14 GMT+0200 (West-Europa (zomertijd)): I2C Read Failure
Probably you should fix the i2c transaction erroring out… but the thing i’m talking about wouldn’t affect you here, because you’ve got constant traffic (albeit error logging) coming from the client side.
Link to the code you’re running?
Hugo, all is running verry well now, since this evening. There has been some trouble with my internet box this morning, did not really understand what…
Thanks for your attention.
Ok, so that code is not good if you’re running with the wrong temperature sensor; it sits there logging errors and doing imp.sleep’s, which prevent TCP traffic from being processed. Your imp doesn’t process pings from the server and hence we close the connection.
Here:
// Wait for conversion to complete
while(!sensor.isReady()) imp.sleep(0.05);
…ie, you need code that drives a TMP112, which is the sensor on the smartmaker Hannah, and you should be fine.
For some example code, see here: http://devwiki.electricimp.com/doku.php?id=jane&s[]=tmp112
…as Jane has a TMP112 on it.
ok, thanks, will look in to this.
Dimitri forgot to update the documentation and will fix this tomorrow, but maybe the imp reacts on this code (and maybe on some other faulty code) in a way that was not intended
Basically, the issue here is that there’s an infinite loop going on. You’d also notice the run button wouldn’t work - because it’s waiting for a sensor that’s not there to report “ready”.
Infinite loops are not good!
@cmetzger sounds like you had a local router issue, but the server-side change is in now and as I noted, may help on certain types of router.
I was experiencing this issue already before the release of the latest update.
For example, this is the code that we use to test the Break&Shield:
`
imp.configure(“GPIO Test”, [], []);
hardware.pin1.configure(DIGITAL_OUT);
hardware.pin2.configure(DIGITAL_OUT);
hardware.pin5.configure(DIGITAL_OUT);
hardware.pin7.configure(DIGITAL_OUT);
hardware.pin8.configure(DIGITAL_OUT);
hardware.pin9.configure(DIGITAL_OUT);
function PinsOnOff() {
hardware.pin1.write(1);
server.log(“Pin 1 up”);
imp.sleep(0.1)
hardware.pin1.write(0);
hardware.pin2.write(1);
server.log(“Pin 2 up”);
imp.sleep(0.1)
hardware.pin2.write(0);
hardware.pin5.write(1);
server.log(“Pin 5 up”);
imp.sleep(0.1)
hardware.pin5.write(0);
hardware.pin7.write(1);
server.log(“Pin 7 up”);
imp.sleep(0.1)
hardware.pin7.write(0);
hardware.pin8.write(1);
server.log(“Pin 8 up”);
imp.sleep(0.1)
hardware.pin8.write(0);
hardware.pin9.write(1);
server.log(“Pin 9 up”);
imp.sleep(0.1)
hardware.pin9.write(0);
}
while (1<2) {
PinsOnOff();
}
`
And you can see from the attached picture what happens quite often.
@Hugo, any suggestion about how to check the router?
Dimitri
You have an infinite loop there. This will cause the imp to drop offline, because it isn’t processing any server traffic. The user code takes priority over the networking code.
If you add this to the end of PinsOnOff:
imp.wakeup(0,PinsOnOff);
…then just call PinsOnOff once, it will run, then schedule a callback to run again immediately. If there are no network tasks (or other callback handlers) that need running, it will call back immediately, otherwise it will process the network traffic/other handlers then call back.
Wed Jun 19 2013 08:57:28 GMT+0200 (West-Europa (zomertijd)): Downloading new code
Wed Jun 19 2013 08:57:30 GMT+0200 (West-Europa (zomertijd)): Device configured to be "Hannah Test Rev3"
Wed Jun 19 2013 08:57:30 GMT+0200 (West-Europa (zomertijd)): Hannah Test Started
Wed Jun 19 2013 08:57:30 GMT+0200 (West-Europa (zomertijd)): Please make sure you are testing a Rev3 board!
Wed Jun 19 2013 08:57:30 GMT+0200 (West-Europa (zomertijd)): Temperature sensor OK
Wed Jun 19 2013 08:57:30 GMT+0200 (West-Europa (zomertijd)): string
Wed Jun 19 2013 08:57:30 GMT+0200 (West-Europa (zomertijd)): Accelerometer OK
Wed Jun 19 2013 08:57:30 GMT+0200 (West-Europa (zomertijd)): Color sensor OK
Wed Jun 19 2013 08:57:37 GMT+0200 (West-Europa (zomertijd)): Button 1 OK
Wed Jun 19 2013 08:57:39 GMT+0200 (West-Europa (zomertijd)): Button 2 OK
Wed Jun 19 2013 08:57:41 GMT+0200 (West-Europa (zomertijd)): Pot OK = 0.646403
Wed Jun 19 2013 08:57:41 GMT+0200 (West-Europa (zomertijd)): Hannah Test Passed
Wed Jun 19 2013 09:06:50 GMT+0200 (West-Europa (zomertijd)): Power state: online=>offline
There was no loop now, test was finnished.
and Hugo, can please you do something about that timestamp in the server log?
It takes more than half a screen…
Wed Jun 19 2013 09:06:50 GMT+0200 will do fine
in this case the card goes offline because the test code is set to set in sleep mode after get the OK:
local function pass(){ server.log("Hannah Test Passed"); ioexp_update_leds(0,40,0); while(1){ imp.sleep(100); } }
It’s just an infinite loop that keep the status at sleep so you can’t actually interact with the imp and I suppose this is why after few minutes goes offline.
noted that. This code has an infinite loop because anyway after a couple of cycles we switch off, as the only scope is to test the PCBs.
I was actually thinking that the server.log() keeps alive the connection, as there are information moving from the imp to the server.
Dimitri
thanks Dimitri,
I saw that statement but from the documentation about sleep():
This method causes the impee to enter a low power mode (“shallow sleep”) and stop executing code for the specified period of time expressed in seconds with a resolution of 1 microsecond (0.000001 seconds). The method will block for this period, and no other Squirrel code will run (e.g. timers, event handlers). The imp remains connected to WiFi while asleep, but does not process messages from the server.
so no supposed offline, and if offline, then it should be online in 100 seconds.
Or am I missing something??
– Edit—
I was missing something, it was about this:
while(1){
thanks.
I’ve added the imp.wakeup but I still get the device going offline.
I’ve noticed that this happen even in the first 60 seconds, when the imp001 shows the status of the connection with the green LED slowly flashing. Actually I’ve monitored the LED and it kept flashing green, but back to the monitor at the same time I had twice the device off and back. This with the imp.wakeup in the code, as you suggested.
I believe is something related to the network (as you know I run the tests from China) but I don’t really know how to properly debug the issue.
Dimitri