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)
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.
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.
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.
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.
