Thanks for this - I think it’s definitely worth a go, especially as I’m not actually using the wifi for 99% of the time!
@Hugo Just a couple of thoughts here: Regularly disconnecting from the server ends up with continuously logging lines like this:
2013-12-09 10:17:25 UTC-5: [Power State] Power state: offline=>online
Any plans to allow some or all message logging to be suppressed? Also, in this case, I am not powering off, or sleeping the Imp (at least not when I send the server.disconnect). Perhaps server.disconnect could pass more info, like why wireless was disconnected? Deep sleep, user instantiated, ect. Just some thoughts.
Agreed, this would be handy
++1 for server.disconnect could pass more info,
I’m afraid the power state logs are there because they’re generally useful things to have… suppressing them could make stuff hard to debug.
If you disconnect, then the server is just indicating that you’re offline - there’s no longer a connection from the imp to the server?
I’m not disconnecting though. I’m sometimes just seeing…
2013-12-08 17:33:35 UTC+0: [Power State] Power state: online=>offline 2013-12-08 17:33:36 UTC+0: [Power State] Power state: offline=>online
…appearing in my logs. This to me says that the Imp powercycled. I know I’m being a bit pedantic here, but a “Power State” implies something to do with the Imp’s power. Surely something like “Connection to Imp: online => offline” would be more accurate? It doesn’t necessarily have anything to do with power at all.
As I said, it’s a bit pedantic, but sometimes it does feel like flying blind. Somehting like this would be awesome:
2013-12-08 17:33:35 UTC+0: [Connection to Imp] state: online=>offline 2013-12-08 17:33:36 UTC+0: [Connection to Imp] state: offline=>online 2013-12-08 17:33:38 UTC+0: [Imp LastOfflineReason] wifi connection lost
The problem with reasons is that we often don’t know what it is. With a real wifi outage, we do - but it could just be a failed key rotation which caused association to be lost, for example, which may or may not affect other devices on the network.
Things we can’t really diagnose, but can recover from, include packet loss, NAT table resets, NAT timeouts, upstream IP changes, etc. When you start trying to indicate why something like this happens it gets problematic as it’s not something that can be determined from the imp.
Hi @Hugo
That makes sense I guess. Still not convinced that “Power state” is the best catch-all term though!
Back to the original issue, I looked to have resolved it by disconnecting and reconnecting wifi when I want to send data, so it looks as though something to do with having wifi enabled while taking readings was causing these issues approx once per day.
I did have to make sure that when I did server.disconnect() I actually delayed it, because any agent.send statements just prior to disconnecting often didn’t get through. Ended up using:
function delayDisco() { server.disconnect(); }
with
imp.wakeup(5, delayDisco);
Seems to be working well so far!
EDIT: could probably have used an anonymous function there…
That’s strange, because server.disconnect() flushes the TCP connection.
server.flush(timeout_in_seconds) also works, but appears to have lost its documentation. We’ll fix that. It will attempt to flush (get a TCP level ACK from the server for data in the buffer) for the number of seconds specified. Returns, I believe, 0 if flushed ok.
I’m just going from what I was seeing in the log. My code uploads every 5 minutes. When server.disconnect() was being called directly after the agent.send() bit, I’d only irregularly see entries make it through to the agent - maybe once every 15 mins or 30 mins, instead of every 5 mins. Adding the delay in means I’m getting the data sent to the agent every 5 mins, without fail.
Will take a look at flush and see if it fits the bill a bit better!