DNS lookup

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.

2 Likes

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.

4 Likes

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.

1 Like

Thereā€™s no hostility intended, more like apathy because this issue doesnā€™t appear to meaningfully affect anyone but you.

1 Like

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.

Just to clarify, I donā€™t work for Hubitat. All I can say is this doesnā€™t seem to impact me as a user. There donā€™t seem to be many others clamoring for it either. You seem unwilling to consider the possibility you appear to be an extreme edge case.

1 Like

I understand - I'm the one who isn't willing to put up with unnecessary hassles because I know they are unnecessary or worse. I only do things that no one is asking for ... and then they can't imagine it wasn't always around.

So how do we get Hubitat to hear the many voices I represent?

Ask them to chime in too?

2 Likes

To continue beating this dead horse that is resurrected every couple of months. Iā€™ll repost my excessively long reply a couple of months ago.

It doesnā€™t come up for most, probably because the majority of network based integrations are done over HTTP (which can do implicit DNS lookups), with a small minority that use other communication methods. It seems OP uses a UDP based one and HubAction doesnā€™t support both IPs and domain name inputs.

OP would have probably had better luck with his thread had there been less back and forth and unnecessary minutiae and a more succinct request (which I feel like I covered pretty well for him in the linked post). But thatā€™s just one guyā€™s opinion.

2 Likes

Succinct -- support DNSLookup.

Implementing DNS lookup would take a lot less effort than arguing over it. It's one of those things so obvious that ... sigh.

If your millions of fans add their voices to your feature request, Iā€™m sure Hubitat staff will take that into consideration.

1 Like

Did you follow the link above to the story of protecting the not-holes?

You will not hear a single voice because those are the people who do not use Hubitat.

I did not. Cool picture though. Thanks for sharing. And I look forward to hearing from the silent majority you represent nonetheless.

2 Likes

No point in us arguing about it.

Hubitat will see this, and review whether it makes sense for them to add it or not. @bravenel @gopher.ny

Nuff said?

3 Likes

What exactly is the ask?

Simple ask - allow me to use a (DNS) name instead of an IP address as is the norm. And provide a DNSLookup function.

A secondary ask would for Hubitat to register its name when requesting an IP address.

A bonus would be to support mDNS.

1 Like

Allow to use a DNS name where exactly? DNSLookup function with what parameters? The more specific, the better. I have a feeling there's a specific issue where you ran into some limitations. Let's start there.

Edit: destinationAddress in HubAction is internally passed to java.net.URI as "http://destinationAddress". It may or may not have port. If there is no port, it will assume 80. I don't see any code that assumes destinationAddress must be an IP address (as opposed to DNS name).

3 Likes