actually searches for local NTP servers and lets you set one. But come one… this is buried knee deep in code, api calls and the forum. How is a new user (like myself) supposed to find this.
I know, im opening a whole new can of worms here, but i have to learn through asking questions on the forum that there are API calls available and that it needs to be called from the “commandline”
Are these documented somewhere @danabw?
Well.. at least i was able to set it this way, thx again.
I still don't get why these aren't given real UIs in the main webapp workflow. The ZigBee device/routing table is another one that I always have to look up on the forum and new people wouldn't know to ask for.
Is it just easier to put stuff behind a secret endpoint vs creating the UI and documenting it? A resource bandwidth issue? I get putting quick and dirty debugging functions behind an endpoint, but once they prove valuable making them part of the main workflow would be much easier to use.
I would guess it’s because the vast majority of consumers don’t know what NTP is, nor why they would want to set it, and are happy to use the default. So if I were to put my UX hat on, I would say there is a possibility that a UI based NTP setting would just cause confusion and additional questions to be asked.
Buying into non mainstream smarthome solutions requires some knowledge and skill already.
Otherwise you would have bought a hue hub and lights as a set, or would have stuck to the Tradfri eco system (just as an example).
Then… if you get into automations and rules that are time depandant…. Or sunrise / sunset, and the hub goes out of sync for minutes a day… you learn fast what NTP is i guess.
And from the other perspective, already mentioned here, why have mainstream endpoints hidden from the UI. They are defaulted anyway, so exposing them doesnt change anything for the users that dont touch the settings, but do make it friendlier to those who want to…
Those of us who have been here longer would disagree. Over the years, there have been an innumerable number of support requests from users whose hubs stop connecting to Hubitat's cloud. The root cause of this is switching from DHCP to a static IP without configuring a list of accessible DNS servers.
Just in the last 4 days, I've counted over half-a-dozen here (leaving FB, Twitter, and Reddit out).
I think it is best that more esoteric settings be left as endpoints.
The UI should require DNS servers to be input, or a warning that if not provided connectivity will fail.
I still say all these settings should be in the UI. Wifi routers are a far more mainstream item and most of those have dozens of advanced options in their UI (often below advanced settings pages). Most aren't anything the average user would understand. They don't hide them behind magic endpoints.
Because there's something approaching an urban myth on this community that hubs should only configured by DHCP, whereas the real issue is a lack of DNS server configuration.
For a long time, my hubs were configured with static IPs with no issue because I pointed the DNS at a LAN instance of DNSMasq.
I really like your suggestion that the UI should require DNS servers to be input (if a static IP configuration is selected), along with the warning. Tagging @gopher.ny - hopefully it can be added to his long list of desirable things.
It feels like some of the network stack is kinda fragile. Configure static IP wrong and you're resetting the device. Have jumbo frames on your network and it locks up. Hubitat is the only device on my network that the network stack dies due to jumbo frames.
I realize that application level control of the Linux network stack isn't exactly easy (spent months working with it for my job, adding user facing UI and control for both wired and wireless) but its pretty important.
I'm adding network enhancements to my 2023 list of features that would really help solidify the product from my POV.
I tend to agree with this. Let me add the “link speed autonegotiation”
At fixed 100Mb the C7 is nice and responsive. After setting it to auto on my 1Gbs network switch (mainstream netgear device that works fine with all other devices) the hub becomes sluggisch (as if it dropped to 10Mps or a half duplex link).
Anyway, for me its a hobby and i like tinkering. Finding the optimal settings is a one time deal and for the most the C7 has some unique functionality that suit my usecase very well. Not trying to take anything away from the functionality of the Hubitat eco system, just trying to provide some constructive feedback and tips
To my knowledge this isn't directly a tcp/ip stack issue.
I've seen this reported off and with buggy kernel modules for some ethernet controllers. But fixes of this have been available for quite some time. I suspect the fix would be install a new kernel module for the ethernet controller. The reluctance to do so may arise out of the possibility of bricking a device by making it inaccessible if something goes wrong in the process.
I am in complete agreement that this should be fixed.
This was a known issue with some Netgear switches several years ago. Autonegotiation works fine with my unmanaged TP-Link and Linksys switches though. Before I bought my current Linksys setup, I had a Nighthawk router that seemed to cause issues as well. It also didn’t seem to do well with multicasting (always had issues with finding AirPrint printers, Airplay, etc).
I mean, I'd certainly call it a "best practice" to use DHCP for everything on your network, and reserved addresses for things that need to be consistent. Not because static IPs don't work in the moment (though the DNS issue for Hubitat is annoying), but because it means you have a single touchpoint to make changes in the future.
I'm not worried about getting the right DNS server today, I'm worried about getting the right DNS server 18 months from now when I change something.