Long term connection stability

I’m running a test where I try to keep a Hannah-Imp on line indefinitely to check out long term stability/reliability of the Temp Logger program and associated connection to my router.

I’ve got the program loaded and running, but with a change to the wakeup timer within the capture() function (line 128) to wake up every 10 minutes (i.e. 600.0 sec vs. the default 5.0 sec program setting).  Further, I’ve got it coupled to the HTTP Request to update a log file with the temp reading at every wakeup.  All works well … I note the impdata.txt log file on my server updating every 10 minutes as expected … all very good.  

A problem I observe however is that things run fine for several hours at a time, then just hang … i.e., no further updates to the impdata.txt log file are observed past a certain point.

I’m not sure if the program is just hanging, or perhaps I’ve lost (and not regained) connection to the router.  (Note: I’ve observed essentially the same issue whether the Imp is some distance from the router, or adjacent).  The other interesting to add here though is I don’t seem to observe anything other than the slowly blinking green LED, which would seem to indicate I remain connected.  (In fact, the really weird thing is I can now never seem to get the LED to change from the slow blink state, even if I move the Imp a significant distance from the router, where I surely receive no signal.  I had thought when I lost connection the LED was supposed to change to the fast blink RED state … I do not observe this).

I’m still looking into this and need to try a few more things, but I thought it might also be helpful at this point to tee it up for the forum to see if anyone might have any guidance or suggestions.  (I also realize that since it’s very early on on the game I might be expecting too much stability out of the unit for the extended connection test I’m trying to run).

Thanks in advance,
Larry

So, it’s possible you might be seeing a NAT timeout from your router, but every 10 minutes should be ok to keep things awake. This generally self-recovers in the case of the imp sending data, because the TCP connection will get reset and that’ll cause a reconnect. We just implemented server-initiated keepalives but are tweaking the behavior right now.


Can you ping the imp when it goes “into the weeds”?

As for wifi range, right now the only way you’ll see a red flashing light is if a transmit fails (try transmitting every second, or maybe doing a server.log(imp.rssi()) every second to send the current signal strength to the log).

The notifications of a lost wifi association are not yet propagated to the TCP stack level, so you don’t see an immediate “out of range” type indication. This will be in a future release, along with more detailed control on wifi roaming behavior.

Thanks for the quick feedback Hugo, and for the explanation re: the current lack of indication of lost associations.  Will try to cause the TX fail as you indicate to see what happens.

Will also try the ping you mention (good idea, I should of thought of that) when the unit goes “into the weeds” again.  Have just been running again, about 12 or so hours now, waiting for it to hang.

More later …

Thanks again,
Larry

Took a bit of time to replicate the situation, but I think I can add to the observation now that I am still able to successfully ping the imp even though the program has apparently hung and is subsequently unable to post updated data to the impdata.txt log file.

Thanks for the feedback, that’s most useful. We’ll contact you privately to see if we can work out what’s happening to your setup.