But this will not solve the issue if the device went to sleep and DHCP lease is expired.
How short is your DHCP lease then?
From what I’ve seen, iPhones wake up and do something on the network on average every 19 minutes or so at the least frequent - but arping should still respond with a successful response, even when the phone is in deep sleep, until the device is actually no longer in range of the network.
Setting retry to a value such as 10 should give you almost uninterrupted “Online” response, until the device actually leaves WiFi range (yes, there will be a lag of up to 10 minutes to detect that you are gone, but that doesn’t appear to be an issue here?)
Please actually try it before instantly dismissing it - it has worked successfully for quite a few people, I would be very surprised if it doesn’t work for you.
(You still haven’t answered the question of what operating system you are running openHAB on, by the way, which may be important to us helping you get a suitable solution)
Just a point about it working on the Android device and not iPhone, this will depend on the version of Android. From Lollipop (v5) onward, changes were made to battery management that prevented ping responses in certain situations. From Marshmallow (v6) onward, Doze was implemented that is far more aggressive in turning off WiFi and cellular connectivity and only waking periodically which prevents any ping responses once in “sleep” mode. From my experience, Android devices on KitKat (v4.4) or lower will respond to a ping regardless of state.
Also, when testing arping (assuming it’s a Linux based openHAB) be aware that iPhones (or iOS devices) can take 25-30 “arps” before waking and responding so set your count higher than the usual 4.
Even if DHCP has expired, it should still respond to an arp request as the device will use the last one assigned until told otherwise.
1 Like
Presence detection using the Network binding will not work if your phone disables the WiFi when going to sleep / power save mode. From what you posted I assume this is exactly what happens.
I have it working using a RPi3, detecting several android devices and a couple of iOS without issue IF the network binding is configured correctly. And by this I mean the arping tool is installed and accessible to the binding. On the Android devices, the “Keep WiFi on during sleep” is set to Always, but Doze still drops the WiFi connection when it wants to. I think this setting is just to keep it on when you initially turn the screen off.
It doesn’t seem that WiFi is fully powered off, only disabled for application use and ping. Arp requests are eventually acknowledged so the network binding should be able to function. However, like anything, I guess it will also depend on the specific device being polled and how that manufacturer has implemented things.
1 Like
I’m running OH on RPi3.
I will give arping a try as soon as I can…seems promising though. I’m not sure how long my DHCP lease is. I checked the router and not sure how I would check the length of DHCP lease.
Its funny, I got up this morning and was in the kitchen decided to check something on my phone and all of a sudden my lights came on, presumably because I “woke” up my iPhone.
This is definitely an iPhone thing. I can ping my wife’s android all day long and it always responds, no matter what state its in. my daughter and my iPhone’s will not respond 10 seconds after you lock the screen.
Thanks for all the info everyone.
arping should work just fine then 
Unless your DHCP lease is only minutes long, you really shouldn’t have an issue - although even if it is only minutes long, your phones should know that, and should wake up to renew their lease.
How do I install arp?
I did a google search to find out but cannot see anything resembling arping for RPi3? Is it an add-on in OH? I cannot find it bindings either, not sure how to proceed.
It is a Linux package - see details in the Network Binding documentation https://docs.openhab.org/addons/bindings/network/readme.html#arping
So I installed iputils-arping and I noticed that there are two locations for arp, one at /usr/sbin/arp and /usr/sbin/arpd.
Which one do I use? Is this the path put into the network binding for arping?
So long as you can run arping from the command line, and it works - openhab will find the right one to use.
So that is not working. If I type arping -c 5 192.168.1.10 it says “arping: Suitable device could not be determined. Please, use option -I.”
It appears that I am typing this command in wrong? I typed it in exactly as you did changing to my correct IP address with the same results. I tried to ping my wife’s android phone (which is always on) with this and got the same result, hmmm.
Which package should I have installed? I installed iputuls-arping.
If I type arp -a I can see my iPhone, with my correct IP and MAC address.
Any thoughts…
Thanks
Do you have multiple network interfaces - ie ethernet and WiFi? If so, you will need to use the -I option in addition, to specify which network interface to use.
I do have wired and wireless, but with the same router. So do I just add the -I or -I etho, which I believe is the name of the interface? I have only seen one interface listed so not sure on this.
so instead of this --> arping -c 5 192.168.1.10
I would do this -->? arping -I etho -c 5 192.168.1.10
Sorry I’m not at home so I cannot try this right now it will have to wait until tonight.
Thanks
he’s referring to the network interface of the device where you issue the command. In this case, where your OH is running. If your OH device has more than network interface, you need to use the one that OH is using (basically the same gateway as the device you’re trying to ping).
https://linux.die.net/man/8/arping
To know which interface you need:
ip link show
okay so at least im getting somehwere
I got this response:
[19:48:08] openhabian@openHABianPi:~$ arping -I eth0 -c 5 192.168.1.10
ARPING 192.168.1.10 from 192.168.1.22 eth0
Unicast reply from 192.168.1.10 [my phone MAC address] 45.494ms
Unicast reply from 192.168.1.10 [my phone MAC address] 73.369ms
Unicast reply from 192.168.1.10 [my phone MAC address] 200.381ms
Unicast reply from 192.168.1.10 [my phone MAC address] 18.723ms
Unicast reply from 192.168.1.10 [my phone MAC address] 54.717ms
Sent 5 probes (1 broadcast(s))
Received 5 response(s)So that means arp is working and can see the iPhone, so how do I get OH so use it?
The iPhone is still going to sleep and disconnecting from the network and OH is not finding it.
Within about 10 or 15 seconds of the phone screen going off the living room lights turn off. I guess because its disconnected from the network and OH thinks I left.
So if arping is working how do I get OH to use it?
Thanks
So I changed the retry intervals to 5 instead of 1 in the setting of my iPhone binding.
I also changed /arp to /arpd in the network binding. So far it seems to be working I check it periodically and it says the phone is on, the last seen is a few minutes old but I can live with that.
Hope it keeps working, I’ll update as needed…
Thanks
Hi William,
I’ve been working for quite some time (months) on detection of iPhone / Andriod mobiles on the local network. At the end I switched to IFTTT with location based detection, setting an OH Item status. Reason is that iPhone will fall into deep-sleep mode and doesn’t respond to arp requests. It doesn’t matter if you ping, hping3 or other methods as they will all fail if the iPhone doesn’t answer to the arp request. Had lots of false positives telling I’m not home, resulting in the alarm system being turned on while I was in the house.
Android did answers better, iPhone not due to deep-sleep mode.
This does not match my experience. I use the hping3 method primarily because the Docker image doesn’t come with arping and I’ve yet to have the iPhone not be reported as present when it was present. I do use some timers to prevent flapping so maybe that is hiding some switching between ON and OFF that I haven’t looked for in the logs, but even an undisturbed iPhone left alone for 12 hours, in my experience, still is detected.
In other threads, there are reports of getting very rock steady detection with proper arping settings. What those settings are I can’t say, I don’t use arping, but many have been very successful with both hping3 and arping.
There is also the iCloud binding which based on what I’ve read, works better than IFTTT or OwnTracks for geolocation tracking on iPhones.