Note that you are pointing to the suggested settings for static IP. DHCP is well-defined and I can't imagine they got that wrong so I presume it is using the proper DNS server which is my local one. (The comment on static IP is only for Ethernet makes no sense but that's another issue).
And HTTP might very well use names but hubaction apparently doesn't. That is a very simple bug to fix.
But native support would include a call to resolve a hostname to an IP address using the DNS (and, perhaps, other means). I would argue that the absence of such a call means there is no support.
It may be possible to implement such a function in Groovy (as I did in c# In 2003) but it really needs to be part of the platform library for apps and drivers to rely on it.
Then there is no support for that feature I guess.
If the hub doesn't support a feature you want, please email support and make a request for the functionality. Posting in here may/may not get developer attention, but an email to support certainly will.
Thanks. I will do but I've tried in the past. I figure if the community chimes in that it's an important feature it would help.
Perhaps the issue is that I see it as so obvious and fundamental I don't know what else to say. I ran into this while trying to explain that you don't keep trailing names in identifiers because .... but made little headway.
At least I learned about the Google https: DNS resolve even if it didn't solve my problem here.
As I stated, things may have changed in subsequent releases… but as I recall, the hub ignores the DHCP assigned DNS server and simply uses 8.8.8.8 unless the user overrides it.
Again, it is possible this behavior may have changed in a subsequent release, but I don’t recall seeing that change.
250 wifi bulbs in one home is kind of an edge case for this hub. I think I understand why this would be useful for you, but there just may not be many other users that would find it to be similarly valuable.
If it indeed uses 8.8.8.8 that is a serious and strange bug. Is this behavior documented anywhere? Given that DHCP provides it along with the gateway information why would that behavior exist? Does that mean I have to first set a bogus static address to change it and then go back to DHCP? Is there any place that this is documented?
For @marktheknife -- yeah. That's why I treat Hubitat as a bridge and address most devices directly. So I'm only doing about 70 lights and a few others that are registered. I do LIfx and Shelly myself and plan to do more.
But it is a leading indicator. Now that the gear is become less expensive Hubitat needs to upgrade to handle a world in which 100% of the devices are connected.
Oops, I missed "Subnet mask is fixed at 255.255.255.0". C'mon, you gotta be kidding me. Why self-inflicted harm? Can anyone explain why such egregious violations of basic practice?
That has just been the way Hubitat has always worked, from my recollection. Other users have brought this issue up in the past, and the additional network settings page was added in response.
I believe you can simply use the endpoint URL as was described in the post I linked above.
Using a direct endpoint: http://hubs.ip.address.here/hub/advanced/resetResolvConf?nameserver=8.8.8.8
Again, there are plenty of threads here in the community where other users have brought up the exact same concerns. Please search for those to see what the Hubitat responses have been in the past.
At this point, I'll just accept that Hubitat has its limits.
I did try to try the workarounds but no sense that they worked. Fortunately, the Maker API exists and that alone is the value of the Hubitat. Getting more stuff to work is a bonus but not fundamental.
What puzzles me is that some of this is so simple to fix but I'll I raised the issue and will move on.
Just to actually be comprehensive here, as the question was never answered about what driver you are actually using.. And as it seems the thread went down into a rabbit hole of the Hub's DNS settings (granted that could also be relevant).
Quick scan of the code, looks like it is using HubAction and is sending UDP packets. Given a lot of API driven devices make use of some sort of HTTP based API, the driver/device using UDP and HubAction is a critical piece of information to have as I'd argue that is non-standard for most wifi devices, thus why we were asking for the driver being used.
So looking at the HubAction docs, it is clear the the method supports only a ip:port combo, which is different from the HTTP methods that I'd argue most devs use to interact with devices, which do in fact support either IPs or domains (as mentioned above). I'm not super familiar with HubAction, perhaps destinationAddress already supports a domain, that's something you or someone else would have to test, but the wording suggests that it is expecting an IP.
So not really a bug, something isn't broken, it's just a feature that doesn't exist as is evident by hubitat's docs. I'd also argue that there doesn't really need to be a unique method to make DNS requests in drivers (and the lack of that method doesn't indicate that the hub doesn't support DNS), the feature request IMO is that HubAction should support either a destinationAddress or a destinationDomain or something similar.
Probably could have had a much shorter and more efficient discussion, had the driver just been shared or as you appear to be aware that the driver used HubAction, a peak at the wiki would have indicated what options that method supports.
Now in terms of the feature request, I'll give @gopher.ny a tag, perhaps he can add to his long list of requests, an addition to the HubAction method, the ability to specify a domain in addition to the current option of destinationIP/port.
I have officially devoted way too much time to a device I don't own and will never own....
I'm not sure actually what is the issue with DNS from DHCP, but it is the weekend and the engineer who could address this is not around -- I don't know personally. We haven't put a lot of energy into network settings in large part because it's a pretty small subset of customers who have needed them. Finishing them up is on our list -- it just hasn't been very high priority.
Perhaps tomorrow you could get a more comprehensive answer to your questions.
Thanks. Sorry about getting sidetracked into workarounds though I wanted to make sure I understood what was happening. I look forward to learning more.
Also, when the engineer is in can you ask about registering the hub name (or "Hubitat" when using DHCP to get the address assigned?
I thought I was clear about the problem being that HubAction did not appear to take a name and that there was no DNS lookup call which is needed in any case. While my example did show the Wiz light, the issue is relevant for all drivers.
The whole DNS IP and mask is a separate issue and I suspect that, in fact, it is properly implemented but can't determine that. But it did get us off track.
Just to be precise, it’s relevant for all drivers that use HubAction. But for drivers that utilize other mechanisms to make network connections, specifically HTTP requests, domains can be used.
Just checking in on whether there has been any response to the issue of DNS support as well as registering the hub name with DHCP. These are serious issues when scaling beyond the simplest cases. It makes it very difficult for me to recommend Hubitat to others.
I've become interested in using Tasmota devices so, again with the address resolution.
@zranger1 Can impose on you to do a short writeup on your implementation of setIPAddress so other driver writers can implement it?
For that matter, I wrote a simple DNS lookup in 2003 in C# which could be converted to Groovy - it sends a UDP request and waits for a response. rfc1035 describes the protocol which is relatively simple. The static friction of my re-implementing it in Groovy is high but I can help. Is there a mechanism for sharing such a routine across Hubitat apps? The lack of a DNS lookup in Hubitat is one of those baffling commissions but if it's not going to change we need to be the change.
) standard that I’m playing with (and Google supports) but don’t have it working the way I want yet.
