[FW] Disable UDP Broadcast and Allow a Local MQTT Broker

Everyone reading this, please vote for this. It will improve your network.

Hello,

The two items in this request are related, thought it would be ok to combine them.

Broadcasts are generally frowned upon in networking and are typically only used for occasional device discovery, DHCP, etc., and not transmitting data on a regular basis. Broadcasting data is typically avoided because every broadcast packet is sent to every device on the network which not only causes the delay of all other data but also adds to the processing load of each device receiving the packet.

This is especially bad since the hub is on wifi which generally has slower data rates than a wired ethernet network and most people can not easily VLAN their wireless to a separate broadcast domain.

Reviewing the logs for my home network, the tempest hub is broadcasting six times more packets than the average device and three times more than the next most “chatty” device on the network. For total data sent, it’s sending 60 times more data than the average broadcast device and nine times more than the next closest.

Anyone can view this on their own network by installing Wireshark using the interface filter “broadcast and multicast” then going to statistics then endpoints on the menubar.

Here is a screenshot with the broadcast data from my network. You can see the Tempest hub is the most “chatty” device by far.

My recommendation is to give users the ability to disable UDP broadcasts so they can remove this burden from their network.

Also, it would be good to give users the ability to send data to a local MQTT gateway instead. MQTT is far more popular than sending data via UDP broadcasts in the home automation scene.

One more thing, management should seriously think about the option for a hub with a wired ethernet port. Only giving users WiFi is a poor choice and only compounds the issue noted above. Not only this but the tempest hub only communicates at slower data speeds which causes all other wireless devices to drop to this slower speed as well. Ethernet should always be the first choice when interconnecting devices and WiFi should only be a fallback.

I agree, a switch to enable or disable UDP would be better. (but I have no votes left).
btw it would probably be better to split your requests so people can independently vote (udp switch, MQTT support, ethernet connection)

Although I do use MQTT, I think a REST API would be the most beneficial.

REST API is already available, just click in the top right of this window on API.

In a modern network exactly how much of a ‘burden’ is it ? Really ?

How many MB/day does it broadcast via UDP ?
How many MB/day does it unicast to/from the WF servers ?

Lets see some numbers please.

1 Like

the problem isn’t the amount of MB/day, I couldn’t care less if it was a lot, the real problem is how many packages are lost. Remember UDP doesn’t automatically resend the data. TCP does. We are not talking about packages lost from tempest UDP, but how many other devices loose, because of an extra chatty tempest. I don’t have numbers for you, as I don’t have other equipment that cares.

I’m calling baloney on this one.

There is far more likelihood that other devices will be unstable because of channel interference on 2.4GHz from misconfigured neighbors than anything else. If your wifi setup is bad, everybody suffers including anybody within hundreds of feet of your AP. If it’s good, everybody works.

And I was I think one of the first who asked for a ‘wired’ ethernet way back when the Air+Sky started years ago.

Many of us did tests years ago measuring whether any Hub broadcasts were being missed and on a good network without 2.4GHz channel misconfiguration nobody could find any missed broadcasts when you captured data with a ‘wired’ ethernet device (to take ‘that’ device’s wifi out of the variability possibilities).

Regarding numbers, I think if you checked you’ll find as many DNS lookups on your network from your Internet-connected devices each day as the number broadcasts from the Hub. I know my pihole shows that kind of volume as tablets+phones and anything IoT are FAR more chatty than the Hub.

That said, I generally always agree with on/off switches for the user to have the ultimate control on what’s going on within their network.

3 Likes

I agree. Even if UDP broadcast doesn’t (excessively) tax the network, why have it enabled if it’s not needed or used? A simple software switch in the firmware shouldn’t be all that difficult to implement. Also love the MQTT idea and yes, on a $330 device, the ethernet port is IMHO a glaring omission.

1 Like

Agree on the base station not having Ethernet, glaring omission. Mine is literally one foot from a managed switch and can be easily connected.

What’s the likelihood Ethernet is added? Pretty small. On the other hand, the two other recommendations can be implemented in software and are relatively easy for them to add.

The simple fact is that there is no reason for every device on the network to receive weather data. And yes this could have an impact on other devices because while these packets are being sent all other traffic has to wait. Users could have switches chained together and this would clog uplinks. This can be especially impactful on wireless networks where only one device can transmit at a time. Say you have twenty wireless devices (many people have more, especially businesses) this one piece of data has to be retransmitted twenty times, again halting all other traffic.

Just because network speeds have increased doesn’t make it ok to carelessly clog it up. If every manufacturer transmitted data this way your network would grind to a halt. Simply no need to broadcast this to every node on the Lan and it should be able to be disabled.

My guess is they are broadcasting this weather data so it’s easier for them to do dedicated weather status screens that no one uses anymore. It’s probably a holdover from these outdated screens.

Also DNS lookups are totally unrelated. They use unicast packets and aren’t broadcast to every node on the network.

Trust me, broadcasting needlessly is not good. Used to manage the network for pharmaceutical customer. Received complaints that one of their smaller networks with only about 50 devices was slow. Took a quick look at the switch and all the ports were blinking in unison. Sniffed the network and found one of their IT guys setup a monitoring program that was broadcasting data. Disabled it and it fixed the issue.

Never heard of a neighbors malfunctioning wireless network causing issues. Congestion absolutely but it’s very rare rare that their malfunctioning device would cause issues on your network. Just switch to a different channel, AP’s do this automatically. Microwave ovens or old cordless phones sure but I’ve been in IT for thirty years and never come across that.

Happens all the time. Misconfigured neighbors set to channels that overlap who use wide bands on their access points can cause all kinds of unstable results on their poor neigbors who can’t ‘not’ hear their networks. There are literally no 2.4GHz channels here that I can move things to that have no overlap from multiple misconfigured non-English-speaking neighbors. Add in those (adjective deleted) people channel hopping and bouncing around too and the whole 2.4 GHz spectrum is a mess.

So for me here I go wired when possible (not on a Hub, sigh) and 5GHz when I can’t go wired (not on a Hub, double sigh) so all I could do was I switch to a Ubiquiti AcLite access point and basically out-radiate them. Those AcLite APs can reach Mars !!!

That said, I did networking for 40+ years and broadcasts like the Hub do aren’t hurting anything, other than I’d agree an off switch would be nice to have. I have 20+ wireless devices here and it has never caused an issue.

WF doesn’t broadcast anything to their servers, they unicast to them and set up a persistent connection to them for sending data and receiving tunings from them.

1 Like