Since we spend a lot of time accessing the hub directly with hubitat it’d be nice if we could alter the default hostname (hubitat) so we could access the webUI from a customized URL and to support multiple hubs if one were a tinkerer/developer.
Also be able to define a FQDN so that dashboards and other links launch with the proper name though that probably only really affects a few of us who are running full DNS resolution internally. Most are probably just using the hostname to access hubitat. I know IP is the single easiest/most reliable way to tell customers how to get to their hub but it’s not always easy when sharing access to devices/dashboards.
If you are running full DNS resolution internally you could just set a custom hostname in DNS for the reserved IP address.
That’s what I do. But never the less, it is something we’ve discussed and I’ve added it to the feature request list.
1 Like
Thanks Patrick, I agree the work around is valid, and I’m using it but for the average home user who doesn’t want to remember an IP the option to customize the hostname and use it for access would be handy. 
1 Like
I agree, but the average home user and DNS and hostname resolution is very difficult. Heck even without a FQDN, most browsers are opting for searching for “hubitat” vs trying to resolve it locally first.
Its not an easy, just allow us to change the hostname and everything just works (trademark pending 
) and then it leads to additional support challenges, my hub name takes me to a google search (or bing)…
This is why we have the portal.hubitat.com and that will show you all your hubs on your local network. The goal was never to have to know the host name or ip address of your hub.
True story. Perhaps being able to mask the hub as portal.hubitat.com/%HUBNAME% would be helpful? Not great if the internet is out, which, is sort of one of hte upsides to Hubitat. Perhaps not a good option outside of the IP after all for the average user.
1 Like
I just added a bookmark! 
I’ll see myself out…
2 Likes
Definitely agree that there needs to be an local resolution for convenience. It's a minor thing, but every little thing helps for the end user.
2 Likes
+1 for a hostname please. I'm working on a couple of logging scenarios, and especially using syslog or the like, the specification calls for a hostname, not an IP address. Since I have a DNS server, that would be it's job to resolve the hostname back to IP.
Self-inoculating, I've got pihole as DNS and all kinds of Ubiquity including controller and USG for resolving. So I've got aliases, CNAMEs, and static IP addresses down cold. The issue is the hub doesn't know its own name.
Thanks!
2 Likes
+2 for settable hostname, which gets passed to DHCP server. I would argue it makes debugging easier too, as it would then show up on router/accesspoint DHCP client lists.
Hmm, which is my hub? Oh there it is, the one with no name...
Would like to request this enhancement again. Is it anywhere on a roadmap?
I see people having trouble accessing their hub from a non reserved dhcp address all the time.
Having a settable hostname that gets passed to the dhcp server for addition in the local dns scope would really help (and remove ip addresses from the discussion.). I use this feature on a large number of my other service type devices and clients.
I'm an embedded software engineer by trade if I can offer any of my services.
2 Likes
