I had the network binding installed before I updated to OH 2.x.
A thing was created for my phone and an associated item. It only showed the phone as online when was not sleeping.
Setting it up at the time was just an experiment, so didn’t bother with it after getting to that point.
Looking at the the binding in paperui it appears to have been updated to 2.5 binding.
Apparently, it is working with arping now since the phone shows up whether sleeping or awake.
I checked and arping is installed on the OH computer.
At the command line:
arping the sleeping phone from my laptop is successful.
arping from the OH computer with the phone awake or sleeping fails.
(Note: the OH log shows a latency change when the phone is awakened.)
My question is what magic am I missing that allows OH to see the phone, but not arping from the commandline?
arping on the laptop does fail to receive a response occasionally if the arping timeout is set to 5 seconds. Doesn’t appear to fail if set to 10 seconds.
On the OH commandline, arping immediately reports timeout, doesn’t wait the specified time before timeout.
So, I noodled around the arping man page and see that the wait time when specified with the -w is in microseonds (I did a cut and past from an article, so…caveat emptor )
When I specified it with the -W (in seconds) the sleeping phone responds about 30% of the time.
I adjusted the wait, etc. in paperui but, see no change in the presence of the phone when sleeping.
Ok, best I can tell OH has arping disabled. (The arp_state in the properties is Disabled. And uses_ios_wakeup is Yes. But, the device in question is an Android phone…guessing it knows nothing about ios wakeups. )
I adjusted the wait, etc. in paperui but, see no change in the presence of the phone when sleeping.
The network binding does not apply binding configurations without a service reload. The easiest way is an OH restart.
The next version will handle that differently.
The binding tries it’s best to use the installed arping. On windows there is one arping version that apparently does not work yet. But in general if you can call it from the command line, it should work from within openHAB as well (if you have given OH/java the correct permissions).
As far as I can tell (watching my net with Wireshark) there is never an arp to the phone.
If I do an arping from the command line on the pi, it is seen in wireshark.
So, is it a permissions issue n the pi? What does OH need? (From the command line I use sudo, does OH need to have sudoer? Not sure that’s a great idea… )
in my case it is not working either.
but from the host i can ping all device - but can’t find out how to use arping on the cli to scan the network.
arp-scan would fit better?
man arping
To check the address of MAC-A, use knowledge of MAC-B and IP-B.
$ arping -S <IP-B> -s <MAC-B> -p <MAC-A>
other options...
-w usec
Time to wait between pings, in microseconds.
-W sec Same as -w, but in floating point seconds.
Ubuntu man pages on the other hand don’t list a -W. Nor do the Linux man pages on the web.
So, -w is the standard and -W is maybe something added to the rasbian/debian/openhabian.
As @David_Graeff said, it should be in the documentation. So just make sure to read the docs next time to find out how to set things up for a binding
The problem here (I guess) is that there are different versions of arping around with different capabilities. They come from different packages and thus it depends what your arping is capable of and that also changes the behaviour of the wait time parameter which can either just be a small w or case sensitive w and W. If I am not mistaken the meaning of the small w parameter also changes unfortunately. But that should not be important since the binding takes care of that normally.
As I noted, the elevated permissions seems to have fixed my issue. Maybe I’m referring to the documentation as the readme?
I certainly agree about the RTFM comment. Even after a 45 year career as a software/hardware engineer, who’s made the same comment many times, I need to be reminded occasionally.
In this particular case trhough, I had read the documentation, but, I was focused on the bad behavior being the same as before the upgrade to version 2 of the binding and expected that some setting in the binding had not taken effect when the upgrade happened (and arping did work from the command line)…I brushed over the elevated privilege note.
Yes, this is apparently the case. especially between utilities that are available on windows and linux. Different or lacking arguments between OS’s are more prevalent with linux utilities implemented on windows (sometimes, windows just can’t do the same thing, or in some cases vice-versa). Not sure why this is the case between two debian derived distros…but, c’est la vie.
)
)
