And the plot thickens... If your clock is off, and you are not making uploads to WU, or if your password is wrong, then the explanation (but no solution) is part of the below.
You may recall that I have left the WU stationID and password blank as I upload via a MeteoBridge instead. I reported in another thread that, nonetheless, the ObserverIP still contacts WU with a repeated (and failing) data request. After I reported this, the newer 3.1.6 firmware was modified to no longer do this in such a case.
Then I investigated that time issue. Contact with Ambient was very disappointing. By way of background: I have been reporting quite a few bugs in the product to them over the past 3 weeks, and in some sense over 2 years. None of these, except one, have been fixed, and I have been given signals they won't be.
Anyway, in this latest exchange I mentioned that I saw no way to configure NTP on the ObserverIP (so it would have the correct time), nor did I inspect any NTP traffic from the ObserverIP when I inspected network traffic. The response was that it does not use NTP, but rather takes the time from wunderground.com. The latter, of course, requires that requests to WU are being made, which I am not!
So did some more experiments and was able to confirm:
- The response to an upload request to WU includes a "Date" header in the response
- The time in there is, of course, nowhere near as accurate as any NTP supported time would be, and is merely reflection of what WU thinks that time as, further affected by network delays etc.
- This time is parsed to set the time in the LiveData screen, but only if the request to WU responds with the word "success"
- There seems to be an issue with the TCP/IP software stack in the ObserverIP causing every request packet to be retransmitted 6-8 times, resulting in unnecessary network traffic, up to 8 times more than needed. It also means that WU servers are being bothered with these re-transmits as well.
So, to get the time correct I have to make successful requests to WU, but I cannot use my stationID because I already upload data to it from MeteoBridge. That data has been processed after receiving from the ObserverIP and I could not send the raw ObserverIP data to the same station. I created a "fake" new station for testing, and confirmed time is now taken. I still do not want to pollute the WU "space" with a "fake" weather station, so I tried setting an incorrect password, hoping time would still be taken (as the time is present in the response), but it is not.
I was told that the product was only every designed, and sold to work with Wunderground and I was using it outside of spec and I should provide my own "time solution" to the applications that use the data from the "Live Data" screen (where time is clearly incorrect). Clearly, Ambient is not interested in fixing.
Nevertheless I reported the retransmit issue and suggested they take the time, even if the response reports an incorrect password. While I would still be forced to accept all the unnecessary traffic (in my case) just to get the correct time, it would be a workaround. The real solution, of course, would be implementation of NTP client software. We'll see what happens.
