NTP hardcoded?

📢 Feedback Feature Requests
1

It seems that the google ntp @ 8.8.8.8 is still hardcoded if i am to believe the Hub Information driver gives me;

afbeelding

Now i am using the NTP driver as a virtual device that @dan.t created and this works fine, but apparently this does not overwrite the internal ntp settings of the C7.

My suggestion would be, following the closed post of @guessed to change this to a selectable option so users are free to choose any ntp server, or even their local / personal one. Cant be that hard…

1 Like
2

Using a user-specified NTP server has been available since platform version 2.2.4.x

There are endpoints available to retrieve the current NTP server in use, as well as to set a custom NTP server. And to scan the local network for NTP servers.

Please see the following post for details:

2 Likes
3

Thanks @aaiyar.

#http//<hub.ip.address/hub/advanced/ntpServer/

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.

1 Like
4

It could also implement DHCP more fully, and take the option from there.

This avoids the need for custom installed parts, or manually (on device!) configured work-arounds.

I currently remap the bad/hard coded values HE uses in my router, to something more resilient/local.

This means that all HE boxes on my network get the benefit, centrally configured (like DHCP option 042 / RFC 1769 - 1995 gives)

3 Likes
5

Good point. The only way is by asking …

There may be a post that documents all available endpoints.

1 Like
6

@aaiyar

Well…. The keyword “endpoint” helps…

Look what i found

Thanks to @Hasty1

2 Likes
7

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.

4 Likes
8

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.

3 Likes
9

I would tend to agree.

However, I think the hub's networking stack should respect an NTP server configuration sent as a DHCP option.

2 Likes
10

I think we have definitions of “regular” users.

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…

1 Like
11

Ha!

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.

6 Likes
12

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.

3 Likes
13

Agreed.

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.

1 Like
14

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.

4 Likes
15

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

1 Like
16

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.

2 Likes
17

Some tricks including NTP for future reference…
I edited some of the entries over the last few days to update the initial [Wiki]

1 Like
18

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

2 Likes
19

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.

5 Likes
20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.