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
https://docs.hubitat.com/index.php?title=Networking is the best that I know of.
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.
And, there are workaround for this (changing netmask) as well. @gopher.ny has posted the relevant endpoints multiple times.
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).
I'm going to guess it's this one, based on a quick search: [Release] Philips Wiz Color Light Driver
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.
new hubitat.device.HubAction(cmd,
hubitat.device.Protocol.LAN,
[type: hubitat.device.HubAction.Type.LAN_TYPE_UDPCLIENT,
callback: parse,
parseWarning: true,
destinationAddress: addr])
https://docs.hubitat.com/index.php?title=HubAction_Object
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.
It certainly wasn’t clear to me.
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.
this lookup method thanks to @thebearmay
def nsCallback(resp, data)
{
logDebug("in callback")
// test change
def jSlurp = new JsonSlurper()
Map ipData = (Map)jSlurp.parseText((String)resp.data)
def String newIP = ipData.Answer.data[0]
sendEvent(name:"dynamicIPResult", value:ipData.Answer.data[0])
// now compare ip to our own and if different reset and log
if ((newIP != null) && (newIP != ""))
{
def String currentIP = settings.macAddress
logInfo("Comparing resolved IP: $newIP to $currentIP")
if (currentIP != newIP)
{
logInfo("IP address has Changed !!! Resetting DNI !")
Map dni = dniIsValid(newIP);
// Update Device Network ID
logDebug("got back dni = $dni")
if (dni)
{
device.updateSetting("macAddress", [type: "string", value: dni.canonical]);
dniUpdate();
resyncSensors();
}
}
}
}
void DNSCheckCallback()
{
logInfo("Dns Update Check Callback Startup")
updated()
}
void updated() {
//
// Called everytime the user saves the driver preferences
//
try {
logDebug("updated()");
// Clear previous states
state.clear();
// Unschedule possible previous runIn() calls
unschedule();
// lgk if ddns name resolve this first and do ip check before dniupdatE.. ALSO schedule the re-check.
def String ddnsname = settings.DDNSName
def Number ddnsupdatetime = settings.DDNSRefreshTime
logDebug("DDNS Name = $ddnsname")
logDebug("DDNS Refresh Time = $ddnsupdatetime")
if ((ddnsname != null) && (ddnsname != ""))
{
logDebug("Got ddns name $ddnsname")
// now resolve
Map params = [
uri: "https://8.8.8.8/resolve?name=$ddnsname&type=A",
contentType: "text/plain",
timeout: 20
]
logDebug("calling dns Update url = $params")
asynchttpGet("nsCallback", params)
}
// now schedule next run of update
if ((ddnsupdatetime != null) && (ddnsupdatetime != 00))
{
def thesecs = ddnsupdatetime * 3600
logInfo("Rescheduling IP Address Check to run again in $thesecs seconds.")
runIn(thesecs, "DNSCheckCallback");
}
// Update Device Network ID
String error = dniUpdate();
if (error == null) {
// The gateway dni hasn't changed: we set OK only if a resync sensors is not pending
if (device.getDataValue("sensorResync")) ztatus("Sensor sync pending", "blue");
else ztatus("OK", "green");
}
else if (error != "") ztatus(error, "red");
else resyncSensors();
// Update driver version now and every Sunday @ 2am
// versionUpdate();
// schedule("0 0 2 ? * 1 *", versionUpdate);
// Turn off debug log in 30 minutes
if (logGetLevel() > 2) runIn(1800, logDebugOff);
// lgk get rid of now unused time attribute
device.deleteCurrentState("time")
}
catch (Exception e) {
logError("Exception in updated(): ${e}");
}
}
// ------------------------------------------------------------
I thought it was clear enough above. If it’s not important to the overwhelming majority of users, there hasn’t been a need to prioritize it.
I'm puzzled, why use Hubitat.com rather than 23.227.38.32?
Not providing a DNS lookup seems a purposeful omission and I can't understand why someone would choose to cripple a system by omitting essential functionality?
I defined the architecture for today's home networks 25 years ago when I was at Microsoft and it ever occurred to me that anyone would futz with IP addresses. And even if some people choose to, what possible reason could there be for not implementing a DNS lookup since it is trivial to implement?
Can you please explain the purposeful omission?
I’m guessing it’s part of the local first, zwave, zigbee focus philosophy. HE isn’t a wifi or internet hub. It’s about local control of home automation, wifi/lan connectivity is not the core focus, therefore DNS and networking becomes a secondary concern.
Note that my use of the DNS Is local first. I even shadow public addresses in some cases to avoid dependence upon external servers. Also, even Silicon Labs which owns Zigbee and ZWave is going IP with Matter.
OK ... history. What I can't understand is seeming hostility to using names and the idea that people like carefully managing hundreds of IP addresses manually. /etc/hosts ==> DNS is not exactly a recent thing.
There’s no hostility intended, more like apathy because this issue doesn’t appear to meaningfully affect anyone but you.
Not true .. with many devices and apps needing cloud access DNS makes sense as ipS can change.
And that effects many.people..it does bring up an issue how do you handle a response list. Default should be the first IP I guess.
Finding the Missing Bullet Holes | OneBite (onebiteblog.com)
I design products and services for millions of users -- the ones you don't seem to want as customers.
That said, given how fundamental and trivial to implement DNS is, I remain mystified by the lack of support.
@kahn-hubitat Thanks for the point though it's just as much about local IP addresses as remote ones. With nearly 300 endpoints I'm acutely aware of the challenges.
Download the Hubitat app
