of course there is!
https://www.openhab.org/docs/developer/contributing/contributing.html
1 Like
That sounds very weird, the DHCP server is the only one knowing it’s a static lease, the client doesn’t know.
1 Like
It’s about solving the problem, not to chat about good/bad cellular phones or routers :-/
yeah, like the virus… after it damages one cell it moves to the next one…
A very rough script (for the cron-job) might read like this, just to get the idea:
Blockquote
// #!/bin/sh
TARGET_DIR=$OPENHAB_CONF
MY_MAC=“00:38:f6:31:76:eb”
PART1=‘Thing network:pingdevice:myPhone MyPhone [ hostname="’
PART2=‘", retry=1, timeout=5000, refreshInterval=50000 ]’
// for (later) error correction
BogusIP=“192.168.0.255”
IP=arp-scan -l | grep -i $MY_MAC | cut -f1
echo $PART1$IP$PART2
// # echo $PART1$IP$PART2 > $TARGET_DIR/things/myphone.things
exit 0
1 Like
The error correction (WLAN device not present at all aka out of home, with no positice result via “arp-scan”) might be something simple like:
if [ -z “$IP”]; then
IP=$BogusIP
fi
This way the device is still listed, but set offline due to unused IP-Adress in the local network
Clear statement of my position: I’m strongly on the side of MAC based declarations. In other words, I agree with Chris (@pallasch).
In fact, rather than a work-around, an alternative where those who like the extra step of assigning their MAC to a static IP using a system outside of openHAB (i.e., their DHCP router) continue to do that. However, if there are those that prefer to keep details of their deployment all within openHAB, why not have the mechanism of “assigning” openHAB elements to a MAC address be within openHAB itself?
Although I appreciate Chris’ workaround of an external script to generate a Thing declaration file, that’s definitely a kludge. But, if that’s the only alternative presented, then that may have to suffice. What I suspect is that there are brilliant folks who know a ton about networking AND a ton about openHAB/Eclipse coding and its inner workings (i.e., not me by any stretch of anybody’s imagination) that could come up with an elegant solution which is built-in (i.e., not a workaround).
In fact, the Amazon Dash Button binding uses the MAC address of the button to declare its Things. Works wonderfully. Perhaps this could be the model for how a MAC based assignment mechanism could be incorporated across openHAB?
Respectfully,
Mike
Perhaps, from your side of your keyboard 
All I know is that I barely have a grasp of Rules DSL and am continually banging my head against the nuances it presents (particularly data typing). Don’t get me wrong, it’s very powerful, but it’s very complex (to me, at least).
Mike
You can always: https://github.com/openhab/openhab2-addons/issues
it’s pointless to debate this stuff here… who exactly are you guys trying to “convince” anyway?
If you want a new Feature to be implemented, you can always open an Issue on github and describe your request
You should consider 2 more aspects as well:
- Other priorities of the (volunteer) developers
- Impact of change request and application “breadth” (if it is for an edge case… well it won’t stand on firm ground)
Imho, the forum is working sometimes as the “proving ground” for github… and your case is not strong enough to survive github as an issue. A PR is a different story… it has more chances to survive.
But… don’t listen to me… You are always free to open it up and see the reaction of that part of the community.
Angelos,
Are you making the point after saying that’s not the point?
I think the point of the community voicing its opinions on a FORUM is for this very kind of debate. As you say, a proving ground. I think a stronger case for my position was actually made earlier in this post by people much more informed than I am. I was just adding my voice to the “MAC side” of the debate.
I know that openHAB development is volunteer based. To that end, I contribute on a monthly basis to assist, even in my small way. What I know is that I am not as experienced as many on this forum such as yourself (a Foundation member). As such, I can’t make a case as “technically eloquent” as is perhaps required.
In the home page of the openHAB Foundation, one of its focus statements states “Smart Homes are our passion - and therefore we strive to make its benefits better known to the public…”. I would venture to guess that I am solidly in their target group - the public. What I also believe is that the public targeted by openHAB is not always as technically savvy as the great minds that develop this fantastic software.
I do realize that openHAB is not for the faint of heart. But I also believe that the goal of the folks that provide this automation platform, and what they strive for, is to make it as easy and simple for the masses to adopt.
Regards.
Mike
My point is that you shouldn’t waste your time in the forum trying to convince anyone.
You should have a plan with a goal set and use the forum to improve your plan.
You should be proposing a change and asking people for new ideas on how to improve your Feature Request that you are about to open up on github.
I don’t see this… I see some edge cases where the problem is not addressed at its root-cause but the solution is sought in other areas with no consideration of impact, priorities, etc. I would go as far as calling this selfish.
But again… go ahead with your plan and your goal (to implement a change to the Network binding via github)
@Dim - TL;DR agree to disagree?
My position is that stating this is an edge case is an opinion. The fact that a large percentage of openHAB users aren’t asking for MAC level configuration is not proof. I believe most of us attempt to diligently follow the instructions. And if the instructions say use an IP address, we try to use an IP address. But if instead the instructions say use the MAC address, users would do that. And with that, the percentages would shift and this might not be an edge case. I don’t have survey data. It’s just my gut. If there is data to prove that using MAC addresses is an edge case (having been given an option to use them), then you will have put me in my place. I suppose an argument can be made that using static IP addresses is the “standard” way of doing things. I don’t believe that to be the case. I know DNS is there to provide a “readable” mnemonic rather than numeric gobbledygook, but the textual to numeric DNS assignment is very dynamic since IP addresses are actively changing (i.e., not static). Yes, assignment of static IP addresses is definitely a need at times. But, in my opinion, this is the edge case. Otherwise manually assigning IP addresses would be the standard means. We’d just maintain a MAC to IP table and not need DHCP at all.
Not accounting for spoofing (which I doubt the lay openHAB user uses), MAC addresses are “permanently” assigned to the physical Thing. Requiring that an additional “ID” be permanently assigned to the Thing (i.e., a static IP address), is replication of effort… in MY opinion.
One might argue that a MAC can change if one swaps out a device. This is true. But if that is the case, a configuration change would be required, somewhere. One argument is that the configuration ought to take place in the router. This way openHAB sees the same IP address for the device and goes on its merry way. The other point of view is that the configuration change take place in openHAB (i.e., change the MAC assigned to the Thing) instead.
My argument for using MAC addresses has two main points:
- We already make numerous configuration declarations within openHAB so specifying the “ID” used to point to the Thing can be consolidated within openHAB along with the rest of the parameters required to fully declare the openHAB elements.
- There are many “home” users who receive their networking equipment from a carrier or ISP. In many cases, for whatever reason, those vendors restrict the ability to make configuration changes. Many ISPs do not allow access to the management functions of routers they provide (probably in an attempt to idiot-proof them and avoid support issues). Or, as Chris (@pallasch) mentioned, their carrier supplied/attached device “flips out” at pre-assigned IP addresses and thus do not have the option to assign a static IP address. Who knows why. But tossing a several hundred quid device in the bin and changing carriers is not really a viable alternative.
I’ll also confess that I let DNS provide an abstraction layer on my LAN. And I’m not manually maintaining a hostnames file. My openHAB server runs on a Raspberry Pi and I use it’s assigned host name in configuration files (e.g., MQTT broker) rather than making its IP address static. Many of my smart switches run TASMOTA. I address them either by their MQTT topic or via their assigned host name. I’ve had to swap out some of my devices… and addressing them by their host name rather than having to make changes in the router has been very convenient. Yes, the devices have configuration parameters in them. But I have to set that up anyway. I just make those abstractions there. Once. And I don’t have to touch my router when that happens. If I relied on a static IP address, each device swap brings a new MAC address. Abstracting via host name or MQTT topic even makes MAC addressing irrelevant. I 'm thankful that I am not required to make many IP assignments… other than for many openHAB declarations.
So yes, I suppose a feature request is in order. But if the feature is opposed to on an open discussion forum where the average Joline and Joe weigh in, I can imagine that our foolish request will be suffered even less as a feature request. However, if a community of Joes and Jolines can progressively improve their argument through this dialog, perhaps a succinct and defensible feature request can eventually be made.
Cheers!
Mike
1 Like
Yeap, we disagree 
Anyway… you should go ahead with the request.
Last note: more and more “modern” gateways (even those supplied by ISPs) are starting to have DDNS support for LAN, so the mainstream user can also use hostnames in the network binding and let the DHCP modify IPs over time while updating the hostname entry dynamically on the local DNS.
OK, I think I like where this is going. Is there a way to use the openHAB Network binding as an abstraction layer? Once an “element” is defined via the Network binding, one can use a “name” to refer to the “element” in other openHAB bindings? If so, can you elaborate?
Mike
What would be a use case scenario that would require such implementation?
One aspect is the Network Binding and the way you can configure it to use IP or hostname (currently) or MAC in the future to identify a remote host. I think that this has been the main topic of the discussion on this thread also.
Another aspect is the “interaction” between bindings. I haven’t seen anyone “calling” from within a binding the Things of another Binding. Each binding has its own method of discovery and/or identification of the endpoints/gateways that it supports.
What I have seen are rules which use the Channel '' triggered ... stuff and/or the Items which are bound to the Network binding Thing’s Channels.
Guys, you might have overseen my earlier comment, so I repeat it again.
It is every Binding developers choice on how to identify a certain device.
There is no reglementation and there never will be.
Wherever possible, a Binding should support autodiscovery, so there is no need for fixed identification.
If you have a special use case / Binding you would like to see mac based identification, you‘d better discuss it as a feature request with the Bindings developer.
This sounds workable, assuming you can’t get your DHCP server to send out a static IP. As Dim says, you would have to work the scripts to make it happen but the approach over all send sound.
This doesn’t make sense. You are saying that if you edit the DHCP server settings on your WiFi gateway and leave the phone configured for dynamic DHCP configuration it doesn’t work? This is what Dim it’s telling you to do and as far as the phone is concerned there is no difference. It is still being assigned an IP dynamically. It’s least that you configured the DHCP server on the router to always assign the same IP to the phone.
Just to be clear. You configure the router to serve out the same IP to that Mac address. You leave the phone with standard DHCP settings.
Dash works very differently and takes advantage of how the Dash works when you press the button. Phones works differently and would not work for the network binding. And frankly, the way the dash button binding works is a hack. If Amazon had created them to be used as we use them the Mac address would not be used.
All I can recommend is to come it yourself or find someone to come it for you is you feel strongly about it.
From a networking perspective, there is a reason IP addresses exist instead of using MAC addresses everywhere. Trying to use a hardware layer concept at the networking layer or above is not likely something that you will get anyone who actually works with this sort of code to agree to do. It brakes the strict layering which is fundamental to how this all works.
It is an edge case because they’re already exists standard ways to solve this problem. You are asking for oh to implement a way to solve this problem in a non-standard way. Assuming pallasch’s router doesn’t let him assign an IP to this device in the router, this is a problem with his router. It is indeed defective and should be replaced or at least factory reset. Adding this capability to the network binding to fix a defective router is an edge case.
Using the MAC addresses is never going to be the first thing recommended for the network binding. It is not-standard networking, has severe limitations, and it actually went work very well.
I recommend reading up on the network stack, how it works, and why it uses layering. Then you might start to understand why using something designed for layer 1 or layer 2 to do something that is supposed to be done at layer 3 is problematic.
These two links can get you started.
Indeed and network binding supports dns. But most home users do not have their own dns server. But every home user has a DHCP server.
That’s what the DHCP static assignment does. It’s a table of Mac to IP addresses that the server users to assign the same address to the same device.
See the later links above.
I would be one to make that first argument. Network configuration belongs in the networking devices, not OH.
This is how it is supposed to work. Use hostnames where you can. The network binding supports using hostnames. Where you can’t, use IP address, configure your DHCP server in your gateway to assign the same IP address to a given device every time. If you can’t do that then, if you can’t replace the gateway, assign static IP addresses at the device. If you can’t do that then and only then should messing with Mac addresses even be considered. And even at this point, you are better off spending the time and money to get the DHCP and/or dns working properly than trying to work around the problem with your network devices then trying to make it work with MAC addresses.
1 Like
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
1 Like
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.