Time() and server.connected()

Device Code
1

On the device, can I be confident that if server.connected() is true, then time() will have already received an NTP update from the cloud?

In other words, if I’m only concerned with realtime when the imp is connected, I won’t need to test for a time() value that’s close to 1 Jan 1970.

2

Yes, that should be true on all imp types.

Peter

3

Roger reminds me that this is not in fact guaranteed, especially on RTC-less imps (current imp005, and imp003s without 32kHz crystal). You need to wait for the next onidle() handler to run after the connection completes.

Peter

4

Thanks Peter. We are not using the 32kHz crystal as we don’t want the burden of batteries in our design. However, I am trying to buffer timestamped events in the device while it is offline. If the clock is not set (ie starts from 1Jan1970), the timestamps will be rubbish. I’ve decided to store time deltas (offset from Squirrel startup) instead of timestamps, which seems to be working.

What would have been useful is the ability to get notification when the time changes, like an imp.onrtcchange(handler) in the api. It would be called when the rtc is changed (not incremented).

I have another question about server.connected()

I notice that server.connected() goes false about 10 seconds after the loss of a wifi connection, even though it may take a further 50s before the handler for onunexpected disconnect is called. I assume that is because the imp is trying to reestablish the connection over that period. Is it safe for me to abort the connection prematurely (with server.disconnect()) after 10s, so I can direct the reconnection process myself?

5

Yes it’s safe to disconnect when server.connected goes false. 10s sounds like you’ve turned off a hotspot, that’s about as long as the wifi chip takes to decide that the AP has definitely gone away.