My IotaWatt log shows an error every hour for timeSync: Failed to get NTPtime and checkUpdate: Invalid response from server. My IotaWatt is now installed in northern Michigan with Exede/Viasat satellite internet service. I did a speed test and the download was about 10 Mbps, upload about 5 Mbps and latency about 750ms. Is this slow internet connection likely causing the time and update errors? The IotaWatt seems to be running ok despite no time update since it was installed a week ago, but not sure if this will eventually cause a problem? Any suggestions on a way to test what’s causing the error or a work around?
(FYI, to test the IotaWatt, it was initially installed at my home in the Detroit area where we have much faster internet connection and didn’t have any issue with timeSync or checkUpdate)
This problem is similar to the timeouts that users down-under experience going to Emoncms.org - Australia to UK via North America. There is considerable latency and I increased the Emoncms timeout on retry, which has been a successful temporary solution.
They don’t have the same issues with NTPtime as the latency to a time server is presumably short, and the update server is in the USA on the west-coast.
While it’s not unrealistic to allow an http request to fester for a couple of seconds, there is a complication with IoTaWatt. The http support that I use is completely synchronous, so the device blocks for the duration of the transaction, meaning it does not sample power during that period. The solution is to use asynchronous TCP, which I have been working on and have a working cobbled together branch. I need to clean that up and build a somewhat general purpose http layer to drop on top, so that’s some time off.
With the satellite link, the initial latency exceeds the 500ms basic timeout for those services. I think once an update download gets going it will be OK, because the there is some overlap in the synchronous send/ack cycle, but you need to get it going first, which is going to be a catch-22 type problem.
I have no problem with increasing the timeout for these two services asap. They only come around once per hour, and an extra second of no sampling will have negligible effect, and no effect on users who are getting their requests serviced fine now.
I’ll put it in the next release, which will go to alpha this week. The problem you will have is the catch-22 of getting upgraded to the new release. You may need to connect the IoTaWatt to a terrestrial internet link in order to get that done. Surely there is a resource in northern Michigan - perhaps a library, or even an internet cafe. The download is completely secure as it is digitally signed. I’ll note in the IoTaWatt release status that it contains this fix when I post the new release.
Could you fire the data to a local machine first then upload it to emoncms? Stick in a $time value and any delay will not matter.
Not sure what problem this addresses. The subject issue isn’t about posting to Emoncms. It involves timeout accessing the NTPservers and the IoTaWatt updata server. I’ve got pretty high confidence in the proposed solution.
I did reference an old issue of timeout accessing Emoncms.org from Australia and New Zealand. Synchronization isn’t the issue as IoTaWatt always uses explicit time values in posting. The round trip latency is the issue, but with reasonably increased timeout intervals and more heroic measures employed on the retry, it seems to be under control until Async TCP can be merged in. An intermediary would seem an extreme solution and not something I could recommend.
Could you get the time off a local machine that does NTP syncs regularly?
Why not post to a local machine in these circumstances (low latency) and then forward from that machine.
I may be missing something, in which case I apologise, but if latency is important to one part, use a local stepping stone to get rid of it. If the link is less than reliable, you could also implement some buffering and or upload more data in one go.
Thanks Bob and Brian! I’m sure I can find a way to update the system on a faster internet connection (worst case I’ll bring it home with me to update). I do have several Raspberry Pis and a Synology Diskstation up north that regularly sync with the NTP servers, but Bob I’m happy with whatever is easiest for you (and I realize there’s a longer term solution in the works). Once again thanks for the great IotaWatt – really a nice and simple to use product with outstanding customer support! Brian