This!
Now, if there were a way to define hostnames to MAC directly… Until then, there are two configuration items (hostname to IP, IP to MAC) in two separate configuration “databases” (DNS, Router). Until then, the HOME automation lay person has, avoidable, added complexity to deal with.
Mike
I might not have been clear enough.
Bindings should support autodiscovery wherever possible, so you don‘t need to know about IP or MAC-Address and don‘t need manual configuration of either one.
If autodiscovery is not possible, it is every developers own choice what config params a Binding needs.
Up to now, nowbody came up with a contribution of an IO-Bundle, doing network scans to provide a kind of a registry giving you access to MAC-Addresses and the according IP-Addresses.
Feel free to write such an IO-Bundle.
Ah, if only I had the skills.
This will never happen. MAC addresses are only visible and only usable on one physical seventeenth of a network. So, if you have two routers or gateways in your network, there is no way for a device connected to one router to see or communicate with devices connected to the other router by MAC. Heck, I can’t even use the Dash binding because I run OH in Docker and Docker containers are on their own virtual network.
The whole purpose of IP addresses is to deal with connecting to devices that may not share the same router. They are not just for convenience. This is fundamental for how networking works. You can’t just short circuit this because it feels more convenient. IP addresses are not arbitrary complications imposed on users. Certain things only work through IP (i.e. imcp packets, also known as ping, which is what the network binding uses to see if a device is online). DNS only works through IP.
It’s not more convenient except in this one tiny edge case which would only work for portion of OH users. And I question even whether it would be more convenient to those users. Most of the time you have to log into your router and look at the DHCP tables to find the MAC addresses for many devices anyway. So why not make the half dozen moose clicks to configure the DHCP server to give that Mac the same Ip?
Disable dhcp on your router, install dnsmasq on your pi running openhab. Et voila, you can configure mac, ip adress and hostname on a single line.
No need for any development inside openhab.
I was going to propose something similar (with ISC tools: DHCP & BIND using Dynamic DNS updates)
but… Michael will claim that this is not appropriate for the “mainstream user” 
he is replying now… wait for it
Ps: Mike… your case is not getting a lot of traction 
Ps2: I have some good news for you: There is already a similar discussion happening on a Github issue. You may want to support it. I will find the link.
Seems this is the consensus by those, it appears, MUCH smarter than I.
Just because something is so, does not make it ideal… nor permanent.
I know. I was being somewhat facetious.
But, again, THIS! This would definitely make home automation by lay people more accessible and achieve the quoted goals of the openHAB Foundation - “Smart Homes are our passion - and therefore we strive to make its benefits better known to the public”.
Regards.
Mike
But… the Network Binding already does this (autodiscovery) (but with ping instead of arp-scan)
You have been asking for the ability to set manually a MAC to identify a thing in the Network binding. Correct?
Practically, you would have to either “extend” the functionality of the Network binding to have a 3rd supported thing (like macdevice on top of the existing pingdevice & servicedevice) or modify the existing pingdevice and allow MAC as its configuration parameter (on top of the existing IP and/or hostname)
Polling its status would still need to use ICMP since a focused ping is much faster than an arp-scan.
Please don‘t mix the foundations goals with development.
The foundation is not involved in this area.
The development of openHAB don’t align with the goals of the Foundation? If not, maybe I ought to direct my contributions to the developers rather than to the Foundation.
The part that I was conceptualizing about was to “push” the information discovered by the Network binding into the configuration of Things whose interface is through other bindings. I suppose, rather than using a Python script (earlier post by @pallasch), one can use the Network binding discovered network devices to generate the configuration files.
What I was actually pointing out is that it would be ideal if ALL bindings interfacing to Things on the network incorporate auto-discovery. Network, Chromecast, Nest, TP-Link, … to name a few that I already use.
Mike
Quote from our constitution:
§ 2 Purpose
The purpose of the openHAB Foundation is to provide consumer advice and protection in regards to free software for home automation as listed under the principles stated in the preamble. Its purpose is also to support the free exchange of knowledge and equal access to such software as well as public education.
You will find no statement about development, coding or ruling the openHAB project itself in our constitution.
With your contributions to the Foundation, you allow us to provide infrastructur to fullfill the purpose, like running the forum server, demo server, and last but not least run myopenhab as a free service.
Not really, as not all vendors provide autodiscovery like UPnP or MDNS. So how should a Binding know that a certain MAC-Address belongs to it’s supported Things? You still need some manual configuration in those cases.
That python script is a poor attempt to hardcode the IP Address of a network host in a *.things file.
Using arp-scan and the known MAC, he extracts the IP and pushes it to the file. Very inefficient…
If you are using the Network binding, you shouldn’t need to play with *.things files. Use discovery and configure your things on PaperUI. If you want to make user configuration changes to Things, better use Managed Things and interact with them via the REST API.
Hans answered your last comment. I will only add what I wrote before: I haven’t seen any binding to “depend” on another binding. They all are using the core. The support for the functionality that you are basically referring to (discovery) already exists in the core framework. It just has to be implemented by the binding.
Then you need to go to the Internet Engineering Task Force and ask them to change how computer networking works. We are not in a position to change it.
The Foundation pays for the hosting of this forum, myopenhab.org, and other costs required to keep a project like this going. No one pays the developers except for a the very few who are lucky enough to have a job that will pay them to contribute to an open source project.
However, you are absolutely free to donate money to individual developers or set up a bug bounty. In this case, if you can find someone to work on it you are absolutely free to pay them to implement the code. But the Foundation is not that.
To elaborate a bit on what hmerk mentioned. All of those bindings that incorporate network autodiscovery use IP addresses and protocols that operate a the TCP/IP or UDP/IP layers of the network stack, far away from layer 1 of the network stack where MAC addresses are used.
Adding support for automatic discovery of MAC addresses, which is really problematic, doesn’t change that.
Let’s actually look at how ARP works, which is the protocol that uses MAC addresses.
OK, so what have we learned? We have learned that MAC addresses are only meaningful for devices that are still on the same physical network. We have also learned that they most of the ARP work is done when a computer wants to send a packet to an already known IP address. There is no way, without knowing the IP address a priori to do a scan for MAC addresses.
Now there is a special type of ARP packet called n ARP Announcement. This is a special ARP packet that a host can publish to “announce” it’s MAC/IP address pairing. Then all the devices on that same physically separated part of the network will update their table. But Not all devices will publish an ARP Announcement so you can’t rely upon it for detecting ALL devices.
There is also a special type of ARP packet called a Reverse ARP. This is the packet a device publishes to the DHCP server to get it’s IP address. This is how Dash buttons are detected. But only machines configured to use DHCP will publish reverse ARP and I think they are published straight to the DHCP server so you would have to set up packet sniffing in order to detect these packets. This is why one needs to run OH as root in order to use the Dash binding, so that the binding can sniff for packets that are not destined for the OH server. Running OH as root is, frankly, a REALLY bad idea from a security perspective.
And don’t ignore the fact that I keep saying “physical”. I’ve seen some networks where even on the same physical router/gateway, the two bands of WiFi and the physical ethernet switches are handled separately. Consequently, an OH server plugged into the wired ethernet wouldn’t see the Reverse ARP requests generated on on the the WiFi bands and a device on the 2.4GHz WiFi band wouldn’t see the Reverse ARP requests from the 5 GHz WiFi band.
We are not being obstinate. We just know enough to understand that all of this is WAY more complicated than the average user understands. The specific problem you are trying to solve has already been solved, use IP addresses.
I meant change on the path of least resistance - openHAB functionality and not the international standards organization.
Users won’t care the mechanism used to discover the devices initially. Once found, they grab identification information in the devices that makes the configuration immune from changes to their IP address. For example, my Nest thermostat and my TP-Link switches have had their IP address change over time… however openHAB continued to properly interface with them even though their IP address had changed… and it did so transparently. At the end of the day, this is what I desire. My point was that it seemed that IP addresses were more susceptible to change (without being forced to make it static) and thus a MAC address for a device on my LAN would be less susceptible. So, after it’s all said and done, I DON’T care about MAC addresses or IP addresses. I care that the setup is as stable as possible w/o having to keep up with multiple configuration “databases”.
Mike
In the Nest case this is because OH doesn’t directly talk with the Nest. It talks with the Nest cloud servers which it accesses by domain name.
I don’t know how TP-Link works but suspect it works the same or it uses some other discovery mechanism like UPNP (i.e. send out a broadcast message and the devices respond with “here I am”).
Nest and TP-Link are like an car and MAC addresses and the protocols around them are like the pistons in the engine that drives the car. You can’t expect an car to work without it’s pistons but you can’t expect the pistons to get you to the store all by themselves.
Then you need to continue to use and only use add-ons that work at a higher layer of the networking stack. Nest, TP-Link and all the rest of the add-ons that support automatic discovery operate at the Application Layer of the networking stack. the Network binding works at lower levels of the networking stack. It is unreasonable to expect to use the tools and APIs available at the lower levels of the networking stack to work the same as at the higher level.
I know what you want. It sure would be nice. But what you want is not technically feasible for the majority of users. It may not be feasible for you either depending on how your router/gateway works (see above). To make it feasible WOULD require working with the IETF to change how networking works. It’s not something we can solve in OH.
I’m not sure if TP-Link works with UPnP. I know that the Samsung TV and the Chromecasts do. I only know this because I was helping troubleshoot the Samsung TV binding and found that it’s auto-discovery was being “answered” by all my Chromecasts. I don’t recall seeing any of the TP-Link devices in the debug logging… but I may be forgetting. Regardless, the binding uses some mechanism to get a list of the devices. It may very well be querying the Kasa cloud using the TP-Link API. And thus the reason I’m slowly replacing my TP-Link devices. I had about a dozen… and now I’m down to two. One’s days are numbered (in lieu of a Shelly running TASMOTA). The final will be decommissioned eventually in due time 
Wow, this topic is BRUTAL!! Please don’t hate me as well, but I’ll casually vote & say adding via MAC does sound like a great feature. Yes yes I know it will be a volunteer dev that does it tho…
Anyways, stepping back quite a bit here, I don’t have access to my router/DHCP server that issues IPs, etc… So is there ANY people presence mechanism, that currently already exists that could work? (Peoples phones makes the most sense for the device openhab “detects”. But it should be automatic so nfc won’t work.). Maybe a different binding supports this? Mac came first to mind, but perhaps there are other solutions?
On a side note, let’s all try to be nicer with peoples passion for the openhab project! After all, that’s what drives this! We want to talk about edge-cases? Shit. That’s what every openhab user is, an edge case!!! 
Thanks!
BlueTooth such as using the BT binding or a separate system like reelyActive Smart Spaces Revisited. Or using FIND (personalized indoor localization).
Very cool. Thank you Rich!