Presence arrival using DHCPlisten possible?

Tags: #<Tag:0x00007f5c80f0e4c8> #<Tag:0x00007f5c80f0e388> #<Tag:0x00007f5c80f0e248>

(Lee Warner) #1

Hi all,
Is it possible to use the network binding in DHCPlisten mode only, no ping, arp, etc. (running OH2.2, network binding 2.2 (I believe)).

For context, when my sister arrives home with my disabled nephew, she wants the various lights/devices to turn on upon arrival, reducing the need to go back and forth to the house before she can take him out of the car.

The only detection device available is wifi on a mobile phone (android). Testing using the network binding with pingdevice works fine and the item goes online. But approx 7mins later, as previously noted in other topics, the sleep mode of the phone stops responding to ping and sets it offline. When the phone is “used” again, ping starts to respond and the item goes online again. The obvious problem with turning on lights based on an item going online is that they will be switched on every time someone uses their phone.

I don’t need to know if the phone is present once the device has been seen for the first time and the lights turned on, so my thought was to use DHCPlisten within the network binding as the should only occur once the phone reconnects to the network when returning home. If it drops offline after that, it won’t matter. I can see this detection in the logs so know it only occurs on first connection.

I thought the latest network binding would allow this if systemping was disabled, but it still goes back online once used - I’m assuming it uses java ping regardless? I think I’ve removed arp to prevent that seeing the phone going active as well.

I’ve ploughed through a lot of the topics but can’t see an answer to this anywhere. On my own setup I’m using fitbits with vreelyactive as per the guide that @rlkoshak pulled together from all the contributions previously (this works like a dream so many thanks for the effort by all), but fitbit bluetooth detection is not an option in this setup (and mobile bluetooth suffers the same sleep issue as wifi).

Can the binding be configured this way, or any thoughts as to how to use DHCPlisten to set an item state? Am I missing something really simple to achieve the same end result?

Cell Phone State keeps going to OFF
Presence detection by reading leases on DHCP server; it works!
(Garry Mitchell) #2

I would look at actually setting it up properly with arping, and setting a high value on the “retry” value.

With arping and a retry of 10, my phone is now being reliably detected as being Home or Away. Prior to setting up arping correctly, there were random times when it would show me as being Away for a couple of minutes - even with higher retry values of 20 or 30!

So - I would highly recommend setting up arping to work :slight_smile:

(Lee Warner) #3

Thanks for the quick response!

I’ll look into this but I’m not sure it’ll solve the underlying problem. My understanding of the way Doze works is it becomes more aggressive the longer the phone is unused, potentially not waking from sleep for a maintenance check-in for several hours. This would lead to the lights triggering at random times during the night I think when it briefly wakes and connects.

Even setting a high arp value wouldn’t negate this if the wifi is dropping into sleep and not acknowledging a poll? Or am I misunderstanding arp?

Actually, I wonder if setting an email client on the phone to a 5min pull request would prevent Doze from turning off wifi completely. This and an increase in arp value may get round the issue. When you say “…setting it up properly…” are you just referring to increasing the retry value or something more detailed?

(Rich Koshak) #4

It’s Android so my first approach would be to set up Tasker to turn ON/OFF an OH Item through the OH REST API when Tasker sees the home wifi.

I do not know if it is possible to completely turn off the ping behavior of the Network binding.

That being said, I agree with Garry. The whole point of arping is to detect the phone even when it has gone to sleep. I use an old hping3 script upon which the arping capability in the binding is based and it detects all our phones reliably enough that I’ve turned off all the BT detection stuff and just depend on that.

(Garry Mitchell) #5

If you’ve not got arp working, I’d certainly try that first. Been rock solid and 100% accurate for me once I set this up.

I’m running OH on Ubuntu, and I needed to get arping working outside of OH first, then it worked perfectly from within OH.

(Garry Mitchell) #6

Here’s a screenshot from Grafana of my presence over the last 14 days.

Can you guess when I got arping working right??

(Lee Warner) #7

@rlkoshak - ah, I hadn’t given a thought to pushing from the phone rather than looking for it. I’d rather not have to install anything on the phones involved, but this does look like it would solve the problem nicely. Thanks for the idea and link

@rlkoshak @Confused - I thought the hping3 thread was iOS specific so will re-read that and also look more closely at how arp actually works. Pretty clear that if you get it set up right, it does seem to work based on that graphic!

Thanks for the info guys.

(Rich Koshak) #8

ARP stands for Address Resolution Protocol. When a device on the network wants to connect to another device on the network that it hasn’t connected to very recently it sends out a “Who has IP address” request. This goes out to everyone and if necessary the router forwards the request to its router. The device who has that IP address, or if the router knows that a specific device has that address, it responds with “MAC address blah blah blah has address”

What the hping3/arp and Network binding does is first send a specially crafted packet to the phone that causes it to partially wake up, and then it sends an arp “Who has” message and because of that first packet, the phone responds with “I have blah blah blah” and you know the phone is on your network. I’m pretty certain that specially crafted packet is a standard thing (like the WOL packets) which is why it works across iOS and Android.

But I have to say, it has been quite awhile since the last time I studied this stuff in depth. I may have said something wrong.

(Lee Warner) #9

As an update/info for anyone coming across this thread later:

I now have stable presence detection of android devices running Nougat 7.1.1, and LineageOS 14, and Apple devices on iOS 10.3.3 using the network binding. As pointed out by @rlkoshak and @Confused, arp just needs to be correctly configured.

Setup is on a Rpi3 using the openhab(2.2) image.
The installed arping tool did not wake the 7.1.1 or iOS devices, but did wake the LineageOS. The iputils-arping tool woke one of the 7.1.1 but not the other or the iOS device. This was based on ping and arping tests from the command line.

Updated the arping tool to v2.19-3 (was 2.14) - tested again, and all devices responded to arping after going into sleep mode, despite not responding to ping (as expected).

For network binding to work:
Added sudo nopasswd permissions using “su visudo” then "chmod u+s /usr/sbin/arping"
On the network things, increased retry value to 10, and timeout value to 20000.

Tested overnight and all devices stayed active for 12+hours. Based on the logs, it looks like the 7.1.1 devices can stop responding for 4-6 mins so a retry value of 10 looks reasonable.

Thanks for the pushing me in the right direction guys,much better solution.

Network Binding - iPhone Presence Detection - arping Configuration question
(vossivossi) #10

Does anybody use the network binding successfully under Windows? Unfortunately there seems to be no recent arping implementation for windows and the current version of the network binding under Windows produces only wild fantasy states in OH (devices online which are not online for 2 days, devices offline which run 24 hours and so on).
My impression is that the network binding is at the moment useless in a Windows environment. Or has anybody better news and useful hints for me?