I've used getMACFromIP in an app for six months without issue, in order to take the hostname of another physical device on my local network (e.g., "upstairsheat" or "downstairsheat") and get the MAC address (which I need so that I can set a custom hubitat device's DNI to said MAC address in order to allow said device to post messages via HTTP to my hubitat device.)
This morning I suddenly started seeing this fail. Upon debugging I see that getMACFromIP is consistently returning null for every hostname I throw at it (all local devices on my network). If I manually look up that host's IP address (192.168.etc.etc) it works properly and gives me back the MAC address as it always has. Also, when I go to my Hubitat's network troubleshooting page, I am able to successfully ping these devices via both IP address and hostname -- so the Hubitat is able to resolve them. Also, "arp -a" on my windows box on the same network shows the MAC addresses of other devices, as I'd expect.
This might have started when I updated from 2.3.3.140 to 2.3.4.114 a few days ago, although I confess I am a bit surprised I didn't hit the error earlier. So maybe there is some very strange issue in my own router or network? Either way this is odd, but is anybody else seeing getMACFromIP working ok?
Same here, just went to integrate Nuki with a beta integration and bam it wouldn't work. Debugged it, getMACFromIP is now not returning what is was ;-( on both .117 and .119
One other thing I failed to mention is that I'm using WiFi instead of wired to connect the Hubitat. Given WiFi support is not guaranteed, maybe that's related.
@gopher.ny , I think the change @jkister mentioned was yours. Any idea if that could have broken this API? Is anybody else seeing the the API still working when passed a hostname instead of an IP address?
getMACFromIP was meant to resolve MAC for an IP address, as name implies. The fact that it worked with host names was coincidental. We changed the internal logic to reduce the number of arp calls and cache results better. We also explicitly got rid of DNS lookups because of how long they took to process and the traffic they generated. To make long story short, yeah, you'll need to resolve DNS name and pass an IP. The upside is the function should return faster most of the time.
Excellent answer, @gopher.ny , so thank you! (I mean, waaaaaahhhh, I want my bug back, but, seriously, it really it nice to know that not only was this intentional but also beneficial in other ways.) And thanks, @thebearmay, for the sample code; this is only to get the MAC of one of my own devices in a custom app, and I can change the logic to have it pass its own MAC, so I guess I won't need it, but still useful.
