Tempest is showing offline, even though WIFI is connected

IOS 13.5, I have tried mulitple times to set up my Tempest and hub, I can connect via bluetooth from my phone, but no matter what I do I cannot get it show online. I can see from the wireless DHCP that it sees the hub and shows it as "WeatherFlow’ and has an IP assigned, but it always shows offline. And I keep getting the message “YourStation has never reported over the network. Check your station’s WIFI setup”
I have tried different ssids with no luck and I have verified that is using 2.4 NOT 5.
Any suggestions how to trouble shoot this.
Device ST-00005963, Device ID 68573
Hub
StationID 20345
SN HB-00020285

I had this same issue setting it up on our company network. We have a very restrictive firewall and I had to basically assign a reserved IP for the hub. Then I set an allow all for outgoing traffic on that IP and in about 5 seconds my light turned from red to green and came online. I haven’t monitored the traffic to figure out exactly what ports it needs outgoing access to in order to communicate.

Welcome to the Weatherflow community cdkim,

I saw you were able at some point to configure hub and tempest as they show created but offline.

Normally powering the hub, wait till the led is green (means it can communicate with the servers) and then just powering up the Tempest and it should work now. Maybe the Tempest was a bit far from hub ???

I got it up, I had to open ports
UDP 50222
TCP 49209
TCP 1883
to destination 54.456.255.179
Figured it out with wireshark
Thanks for pointing me in the right direction

2 Likes

Glad you’re up and running

regarding opening ports, not sure the IP can’t change as it is cloud based and they might switch … but time will tell :slight_smile:

1 Like

Can you give me the IP range?
Thanks

IP range won’t solve it as it is hosted partly with Amazon so the range can be … large

instead here are the 3 url’s you need to whitelist

mqtt.weatherflow.com
api.weatherflow.com
s3.amazon.com

3 Likes

What is port 49209 used for? I don’t want to poke a hole in my firewall without knowing what I’m poking a hole for.

Thanks!

Just to followup on my question, port 49209 doesn’t appear to be important. I did not poke an outbound hole for it and connectivity seems to be fine with only ports 80/443/1883 allowed outbound.

Hi, I had an odd problem recently where both of my Hubs went offline due to an extended power outage (longer than my UPS could hold), and when power was restored, neither was able to connect to WF (red LED on the Hub). Both units were connecting to the wifi, and could be pinged from my network. The one that sends UDP packets to Weewx was sending the packets.

After a few days of futzing around with it, resetting the hubs (both the wifi settings only and the whole radio), and wondering what was going on, I decided to test them on a different guest network which uses a different DNS address, and they reconnected!

I’ve since changed my network’s DNS to the cloudflare 1.1.1.1 and google 8.8.8.8 which has brought both of the hubs back online, but those aren’t my preferred DNS servers, and I’d like to do some troubleshooting.

The DNS they were having a hard time with is the Mullvad public dns: 193.138.218.74 - I had changed to this DNS server several weeks ago, but the problem with the Hubs only showed up after the power outage (perhaps when they cleared cache or got a new DHCP lease?). No other devices have issues with this DNS.

What domains is the Hub trying to connect to? I’d like to do a little testing to see where in the chain the problem is occurring.

scroll a bit back and you find your answer

FWIW, 193.138.218.74 is only answering DNS queries via TCP, not UDP…

Thanks @eric, sorry I missed this existing thread.

FWIW, 193.138.218.74 is only answering DNS queries via TCP, not UDP…

Well that ain’t right…

I know DNS servers are supposed to reply on both, and I was under the vague impression that they should failover from UDP to TCP if the message content is too large, or if it just doesn’t work, but I don’t think any DNS server should only respond on TCP. I’m just not sure why the only of my ~20 devices that were impacted was the weatherflow hub.

I’ll try to get to the bottom of it and will reply here if I learn anything useful to other users, but it seems like a deficiency in the server, not something the hub is doing wrong.

> www.weatherflow.com

;; Truncated, retrying in TCP mode.

Server: 193.138.218.74

Address: 193.138.218.74#53

Non-authoritative answer:

Name: www.weatherflow.com

Address: 52.71.77.111

> www.weatherflow.com

;; Truncated, retrying in TCP mode.

Server: 193.138.218.74

Address: 193.138.218.74#53

Non-authoritative answer:

Name: www.weatherflow.com

Address: 52.71.77.111

> www.google.com

;; Truncated, retrying in TCP mode.

Server: 193.138.218.74

Address: 193.138.218.74#53

Non-authoritative answer:

Name: www.google.com

Address: 172.217.17.68

> community.weatherflow.com

;; Truncated, retrying in TCP mode.

Server: 193.138.218.74

Address: 193.138.218.74#53

Non-authoritative answer:

community.weatherflow.com canonical name = sws.hosted-by-discourse.com.

Name: sws.hosted-by-discourse.com

Address: 72.52.80.21

I only get 52.71.77.111 for both UDP and TCP if I run ‘host’ versus the google nameservers at 8.8.8.8

1 Like