Thank you so much for the guidance. I saw the chatter about the ‘Tasker’ option, so I suppose I’ll look into it further. We also use Life360, and I see that someone has put together a solution based on that too. I hoped this would be simple enough, but guess not.
That’s just untrue. I’m happily using it and a number of others do as well.
Please don’t turn your personal experience into a general judgement that makes others refrain from trying to use it. It’s clearly preferred to use bindings instead of external tools such as tasker or IFTTT.
The OP’s problem also isn’t lack of reliability - it just doesn’t work for him at all, likely because of a setup error.
So arping isn’t located where it should be which is probably the reason of your problems.
Find out where it is and use that full path in your OH binding config:
[12:00:14] openhabian@openhabianpi:~$ which arping
/usr/sbin/arping
[12:06:24] openhabian@openhabianpi:~$
In that case the $PATH variable of the environment of the UNIX user that OH runs as will be used to find arping’s location.
BUT OH usually runs as user openhab, so those command outputs you show are irrelevant as they’re run as openhabian which is a different user, to have a different environment.
[I may be wrong in gussing here but you failed to explain the type of system and OS you’re running on]
Same here also, without problems. The only issue that I have found is if you use a node name instead hard coded IP address and the name can’t be resolved by dns, the bind will not work and you will get an error message.
Today, for the first time, I setup the network-binding by textual configuration and it is working so far.
I followed the instructions of the documentation, installed iputils-arping and didn’t have to change path or chmod.
It runs without sudo.
My setup is:
Platform: Raspberry Pi 3 Model B Rev 1.2
openHABian configuration [master]v1.4.1-411(ecf59c4)
OS: Raspbian GNU/Linux 9 (stretch)
[08:15:23] openhabian@openHABianPi:~$ java -version
openjdk version “1.8.0_152”
OpenJDK Runtime Environment (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 1.8.0_152-b76)
OpenJDK Client VM (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 25.152-b76, mixed mode, Evaluation)
openHAB 2.3.0-1 (Release Build)
Yes, Thank you all! The “which arping” command helped me find the path. it was installed in /usr/bin/arping, so it was missing the ‘s’ before bin…
But, even when getting it working, my phone I had several weeks ago (LGV20) would still not respond to ARPing in its ‘deep sleep’. I’ve since bought the Pixel3, and it, along with my wife’s Pixel2, both respond to regular ping and ARPing very reliably at all times. This presence configuration has been working very well for me these past couple of weeks. Thanks all!
Arping fails to return a response to the binding when a device is offline. The result is that a device that is offline is reported as online.
The underlying issue can be duplicated by adding a Thing (network pingable device) that is currently offline. Then, SSH into the openhab server (I am running openhabian) and run arping for that ip address.
/usr/bin/arping 192.168.1.6
ARPING 192.168.1.6 from 192.168.1.13 eth0
In the above example, the arping command generates an initial response showing the ip address polled (6) ran from the ip location of the openhab server (13) but does not complete the command. It freezes. When you kill the process, it then reports the number of probe attempts made (up to the time the process was killed):
Sent 26 probes (26 broadcast(s))
Received 0 response(s)
How can you force arping to limit the number of probe attempts, so it can return the result (device is offline) to the binding and Thing? By running the same command, but adding the -w flag and a small number. Now it will not freeze at the command line. From the arping man page:
-w usec Time to wait between pings, in microseconds.
So, how do you configure the binding so it processes the equivalent of:
usr/bin/arping -w 3 192.168.1.6
ARPING 192.168.1.6 from 192.168.1.13 eth0
Sent 4 probes (4 broadcast(s))
Received 0 response(s)
Thanks rossko57. Here is a link with step by step that fixed the arping issue for me, all within paper ui.
I think arping was not working because I created the items directly in the items section of Paper UI. This was not creating a functional channel. Instead, delete any existing items, then recreate them, this time from “inside the Thing”. This article has the specific steps and is explained very clearly. Highly recommended if you are a beginner like me and are having any presence issues with the network binding.
I also get “Disabled” in arp_state of the thing property.
I noticed that I have to issue “-I” option to the arping when running from command line.
Without it arping fails.
I suspect that the problem with arp_state disabled is with this interface specification option ("-I " flag).
Can it be the problem?
Can I also specify arping flags in arpPingToolPath config property? e.g. “/usr/bin/arping -I eth0”.
And finally here the log, did i misunderstood something here?
It looks like he’s doing ARP pings for every network and then doing a Java Ping?
Is this really necessary?
2021-11-03 11:31:02.594 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: veth128711e
2021-11-03 11:31:02.596 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: veth132adc8
2021-11-03 11:31:02.596 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: veth42e8be9
2021-11-03 11:31:02.598 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: vethf152500
2021-11-03 11:31:02.599 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: veth62ef3cf
2021-11-03 11:31:02.599 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: eth0
2021-11-03 11:31:02.602 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: be-openhab3
2021-11-03 11:31:02.601 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: app-openhab3
2021-11-03 11:31:02.605 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: vethf44c59c
2021-11-03 11:31:02.609 [TRACE] [g.network.internal.PresenceDetection] - Perform java ping presence detection for 192.168.3.26
2021-11-03 11:31:02.608 [TRACE] [g.network.internal.PresenceDetection] - Perform ARP ping presence detection for 192.168.3.26 on interface: docker0
2021-11-03 11:31:02.844 [DEBUG] [g.network.internal.PresenceDetection] - Getting latency from ping result PingResult{success=true, responseTimeInMS=null, executionTimeInMS=234.0} using latency mode false
2021-11-03 11:31:04.102 [DEBUG] [g.network.internal.PresenceDetection] - Getting latency from ping result PingResult{success=true, responseTimeInMS=null, executionTimeInMS=1448.0} using latency mode false
I would suggest to open an Issue in Github for the case that arp is executed but not shown.
Any Inputs welcome
but as if you can see the -I option already offers the interface.
In my case the default should then be without -I and only one instance of arping.
If someone likes to restrict then “arping -I eth0” could be used in the command.