Tried multiple browsers and still cant see it
It’s really weird unless there is some setting in tempest that brings up the link as it doesn’t matter what browser or computer I use it doesn’t appear
1 Like
Maybe Australia is excluded from WU for some reason.
Does it have anything to do with the fact that your station has been offline for quite some time?
1 Like
I have two stations and one is online and it doesnt have the link on the webpage
This question was moved from a different topic as the issue did not match the title.
cheers Ian 
That maybe the case that stations in Australia cant post data to WU as the link is certainly not there. Is anyone else in Australia able to send their data to WU
My station (old sky and air) is still uploading to Weather Underground and I am in Australia.
My station in Australia is not a Tempest, it is a Sky and an Air and does not update very well sometimes 15 min between updates but roughly works. I decided not to rely on weather underground because it is not accurate or up to date.
Using the weatherflow web page or my own data from the API is much better.
cheers Ian 
1 Like
Thanks for the replies, unfortunatly for me I am trying to put up the data on a display using a site called Dakboard which needs the data feed through WU so I might have to do some more work to try and find a way around it
There are several options. First contact Weatherflow support and ask them if they can do anything. Second look at alternate programs that can load your data to Weather Underground. There are several options to do that such as weewx.
I dont know how Dakboard works but I solved my issues by creating python programs that call the Weatherflow API to get my data and turn it into what I want.
If Dakboard can display an iframe then that might be another option by displaying your Tempest web page in an iframe.
Good luck cheers Ian
1 Like
Just had a look at that Dakboard, it can read json directly, not sure how but since WeatherFlow has its api in json … this might be a direct way. Just need to see how it works under the hood to be sure. You can get a free account seems to fool with on a regular computer and options.
1 Like
Seeing over 20 minutes now between updates. Are there plans to get back to a reasonable update interval or should the feature just be removed from the product?
1 Like
I completely agree. While I completely understand updates to Weather Underground are not (and should not be) a priority for WeatherFlow, I find it somewhat troubling as to how slow the updates have gotten for at least some of us. I am regularly seeing updates at every 20 minutes if not every 25 minutes.
It would be fantastic if these updates could be done every minute (if not even faster). Although I could be vastly underestimating the amount of work their servers are constantly doing, I would think updates every five minutes would be attainable.
Weird… My ambient station is updating every 15 seconds or less.
1 Like
Yes - Ambient Weather Stations can be configured to update Weather Underground in two different ways: 1) via the user’s local hardware (specifically, via the display’s wi-fi unit), or 2) via Ambient’s Servers (presumably similar to the WeatherFlow Servers).
In the first case, the user’s local hardware can usually update Weather Underground once every 15 Seconds. In the second case, Ambient’s Servers can usually update Weather Underground once every minute or two. Needless to say, that is still far superior to the every 20 to 25 minutes being performed by WeatherFlow. 
I have asked this issue to the server admins and Weatherflow is sending out the data in a fluent way. There is a bottleneck somewhere else outside the WeatherFlow network. Knowing the huge amount of data that is send via 1 channel maybe there is throttling on the receiving end. I also see this since I send via 2 options (1 rapid fire and 1 via the WeatherFlow system) and indeed it is horribly slow but not always at the same rate. Something like 5 mins and then it can jump to 15 mins. I think someone reached out to WU but no reply. Will try to bring it up again but know it is not sending side that is having an issue.
1 Like
Although it is nice the weatherflow server admins believe they are sending out the data correctly, I think many of us realize from working in the technology industry that problems are often not found until they are discovered by others. In that regard, I would ask them to review the below material.
In addition to actual weather data, I believe a proper weather underground update consists of the following http get request where “xxxx” and “yyyy” are the ID and PASSWORD of a weather station:
GET /weatherstation/updateweatherstation.php?ID=xxxx&PASSWORD=yyyy&dateutc=2022-01-12+21%3A56%3A54&action=updateraw HTTP/1.1
Host: weatherstation.wunderground.com
Questions:
- Does weatherflow always use a properly url escaped version of this string?
- Does weatherflow always specify “action=updateraw”?
- Does weatherflow always specify “HTTP/1.1”?
- Does weatherflow always specify “Host: weatherstation.wunderground.com” and send this entire request to and wait for a response from “weatherstation.wunderground.com”?
- Does weatherflow ever instead specify “Host:rtupdate.wunderground.com” and send this entire request to and wait for a response from “rtupdate.wunderground.com”?
- If weatherflow does use “rtupdate.wunderground.com”, do they also specify “&realtime=1&rtfreq=zzz” in the request?
- Does weatherflow open and close a socket to weather underground for each and every different weather station it is trying to update? Or - Does weatherflow pipeline some number of get requests (which correspond to different weather stations) for each open socket to weather underground? How many requests are pipelined for each open socket?
- Does weatherflow correctly monitor the weather underground http responses to ensure the connection is still persistent if pipelining requests? In other words, does weatherflow ensure that the http response states “Connection: keep-alive” rather than “Connection: close”?
Needless to say, I think it should be easy to see there are numerous ways in which the weatherflow servers may not be sending data to weather underground in the most ideal or most optimal manner. It is certainly possible all of the slow updates may be caused by the weather underground servers, but there are probably just as many if not more ways the weather flow servers may not be executing the http get requests in the best way possible to ensure the fastest update speeds possible!
I think at some point you need to trust the WF backend admins and software devs when they say they’ve worked directly with WU.
That said, I’d suggest (yet again) that you spin up weewx, turn on rapidfire mode, and check yourself to see if you think it’s WU where the problem is (because history is proving it’s always WU with the problem).
You can use the weewx sources to see what it’s sending and the logs to see how often.
3 Likes
Yes, I have run these experiments. For example, I have written a low-level windows socket program to obtain the weatherflow udp data and upload it to weather underground. Although I did encounter some upload issues during initial development of this program, I eventually found they were all due to my own programming issues (i.e. incorrect formatting, improper allocation/deallocation of socket or ssl structures, etc.). After resolving these issues, I have not observed any problems whatsoever in uploading my data to weather underground in a correct and consistent fashion for well over a month (which is obviously not a huge amount of time, but is vastly different to the daily update behavior of WeatherFlow).
In my humble opinion, WeatherFlow’s engineers (like any other good engineers) should be open to any and all possible ideas. WeatherFlow’s engineers should be able to tell us where these unexpected delays are occurring within the process of performing these updates. Specifically - Do they see this delay when attempting to open a socket to Weather Underground, or when switching to an ssl connection, or when sending the get requests (pipelined?), or sometime else? Or is it the case that they always receive immediate responses to all of these requests on their end (which seems incredibly unlikely, but still possible) and that for some reason this delay exists completely within the processing of this data within the Weather Underground Servers?
In other words - Are the WeatherFlow servers successfully performing all of the network traffic they need to perform in order to update all of their weather stations in x minutes (where x is much less than 20 or 25 minutes)? Or is it sometimes taking them 20 or 25 minutes to perform all of the network traffic necessary to update all of their weather stations (which takes us to the above questions).
With one major exception, there should be absolutely no difference between the behavior of my low-level windows socket program and the behavior of the WeatherFlow Servers. Obviously, the exception is that my program (and other programs like weewx) is trying to update only one weather station per time period while they are trying to update many weather stations (100s? 1000s? 10000s?) per time period.
Although I still love my Tempest, it kills me that most if not all of the other much more inferior weather stations are always able to successfully perform fast updates to Weather Underground.