Forgot to mention one caveat
The arp db /etc/ethers is not loaded by rasbian init scripts. You need to either manually do sudo arp -f /etc/ethers or put a line arp -f /etc/ethers in /etc/rc.local script (before exit 0 command in that file)
I have a fixed version of 2.3.0 network binding jar and source code here
Uninstall old one from PaperUI and drop org.openhab.binding.network-2.3.0.jar in your addons folder.
Fixes
- binding was out of sync with latest 2.14 version of arping tool options. the meaning of -w is now micro-seconds instead of seconds. maybe thats why it was unreliable
- when I recorded and printed STDERR of arping from Java invocation I got this strange error “arping: libnet_write(): libnet_write_link(): only -1 bytes written (Invalid argument)”. It was causing failure exit status. I have modified code to read STDOUT and see if any packet is successfully sent.
- added new thing config parm “mac”, optional. users having issues with certain androids can try setting this. there is no need to set static arp entry in Linux /etc/ethers.
- original binding was sending only one packet which is too optimistic. I have changed it to 4 for reliability, as per my testing with android 5 and 7 devices.
- binding will continue to work as before with old versions of arping. version and syntax detection adjusted for newer tool version. new features will activate only when newer arping is detected
To see whats going on, enable logs for logger “org.openhab.binding.network”.
In Karaf console:
log:set debug "org.openhab.binding.network"
Need to sleep now. 
2 Likes
Did you submit your changes to the main repo?
Right now in my google drive, link above. Its 2.3.0 version fixed. will check against 2.4.0-SNAPSHOT code tomo and then submit PR.
1 Like
I think I can further improve the reliability of arping invocation. I noticed that concurrent invocations are causing some issue in native code “arping: libnet_write(): libnet_write_link(): only -1 bytes written (Invalid argument)”. Maybe I can introduce some randomness in arping invocations across things. Meanwhile users can try different unique refesh intervals for different things. But despite the native error, the fixed binding works because it relies on STDOUT instead of exit status of arping, but that can still give unreliable results if you got lot of androids/ios devices to watch.
Do I provide the mac option in addition to the IP, or in place of the IP?
For example:
network:servicedevice:cerberos [ hostname="cerberos", mac="00:11:22:33:44:55:66", port=22, retry=5, timeout=5000, refreshInterval=10000 ]
or
network:servicedevice:cerberos [ mac="00:11:22:33:44:55:66", port=22, retry=5, timeout=5000, refreshInterval=10000 ]
Thanks for the updates! They are greatly appreciated.
I know it’s a Rules DSL design pattern, but perhaps you can create a Design Pattern: Gate Keeper to keep calls to arping from occurring too close together in time.
Mac will be an addition to IP. If you don’t provide it, binding will invoke arping without -t mac hint. For reliable results I would suggest providing mac too.
1 Like
When you update the docs for the binding make sure to make that clear. Thanks for the update!
I think we should have a library of such scripts / reusable Xtend/Kotlin code. Like Perl CPAN.
There really isn’t a good way to do it with Rules DSL. Certain architectural decisions were made very early on (no classes, global variables scoped to only a single .rules file) that makes creating a library of Rules very challenging. With the addition of Member of and triggeringItem it becomes a little more possible but still awkward at best.
This is one of the major driving forces towards the creation of the Experimental Rules Engine. Kai’s stated vision is that we will be able to deploy Rules libraries over the IoT Marketplace so rather than my just posting a bunch of Design Pattern postings that people must copy and paste from, people can download a library with the working code and just use it. So that is in work.
Rules engine produces/can consume a json based template I believe. That makes it primarility a UI only programming language. I am afraid it can go only so far as simple-to-medium use cases. We still need a solid/modern scripting language that can be used by people to produce cool apps for this platform. I think Apple also has a modern scripting language on top of native app programming lang Objective-C.
The platform artifacts / events should be exposed to app developer via this scripting glue layer, and the app must be having permission (granted by user at install/update time) to sniff those events. Its a lot of design and coding work I know. But it will be cool. Maybe the Kotlin work that I am planning can trigger some excitement on this.
Sorry for going off-topic here, guys.
BTW I feel we should also “humbly” ask arping developer Mr. Thomas Habets thomas@habets.se to keep backwards compatibility in terms of help output (that we use to determine tool capabilities), and to not change meaning of a parm like -w to mean micro-secs instead of secs in future. Otherwise we will need to maintain and distribute our own copy of tool to ensure no surprises like this occur in future when openhabian gets a new raspbian-lite core and Mr. Thomas Habets changed output formats.
FTR Binding jar 2.3.0 and source is also copied here on github
Google Drive seems not to work with wget easily
Will create PR once @grhosso and I work things out on his setup. The fixes already improved reliability on my setup with Android 5 and 7 devices.
Things pending before PR is filed
- introduce randomness to avoid / minimise parallel invoks of arping tool
- fix any other issues that come up with @grhosso setup
- extract latency from arping STDOUT
- code analysis compliance
- fast forward from 2.3.0 to 2.4.0-SNAPSHOT (master)
2 Likes
Thank to everybody and specially to @diyha , NOW IS WORKING 
My steps:
- Static ARP added in /etc/ethers
- Static IP setup.
- Unistalled binding
- Installed new binding from the repo above.
- NOW I CAN SEE the phone in INBOX and I have added as new Thing.
- I have setup param in the Thing with at least 3 retry, Refresh interval 60000, Timeout 5000.
- Network.cfg filed modified according to diyha indications.
I switch on off the wifi in the phone, and is detected properly.
2018-08-23 17:43:12.763 [vent.ItemStateChangedEvent] - Iphone_Sw changed from ON to OFF
2018-08-23 17:44:13.142 [vent.ItemStateChangedEvent] - Iphone_Sw changed from OFF to ON
2018-08-23 17:44:13.161 [me.event.ThingUpdatedEvent] - Thing 'network:pingdevice:192_168_2_160' has been updated.
2018-08-23 17:46:18.875 [me.event.ThingUpdatedEvent] - Thing 'network:pingdevice:192_168_2_160' has been updated.
2018-08-23 17:48:28.917 [vent.ItemStateChangedEvent] - Iphone_Sw changed from ON to OFF
2018-08-23 17:49:29.031 [vent.ItemStateChangedEvent] - Iphone_Sw changed from OFF to ON
2018-08-23 17:49:29.053 [me.event.ThingUpdatedEvent] - Thing 'network:pingdevice:192_168_2_160' has been updated.
2 Likes
I am still skeptical about all flavors of Androids, would request users to test this fixed binding, make sure you set mac parameter in thing config to your Android’s wifi mac. See if binding reports device offline after few minutes or few hours, even when Android device is set to keep wifi on when locked.
There might be extra-smarts on some Androids that turn network stack off completely after couple of hours, I have seen this on Android 5 phone, it does cut off wifi after 10 hours of locked state.
Reliable presence detection still remains an active battle. 
Well, yesterday I tested the binding works fine when I get ON OFF properly but after a 5-8 minutes, goes OFF automatically even with Android setup with keep wifi on when locked, and device still connected in wifi.
2018-08-23 18:13:34.635 [me.event.ThingUpdatedEvent] - Thing 'network:pingdevice:192_168_2_160' has been updated.
2018-08-23 18:15:44.659 [vent.ItemStateChangedEvent] - Iphone_Sw changed from ON to OFF
2018-08-23 18:16:44.791 [vent.ItemStateChangedEvent] - Iphone_Sw changed from OFF to ON
2018-08-23 18:16:44.797 [me.event.ThingUpdatedEvent] - Thing 'network:pingdevice:192_168_2_160' has been updated.
2018-08-23 18:20:51.751 [me.event.ThingUpdatedEvent] - Thing 'network:pingdevice:192_168_2_160' has been updated.
2018-08-23 18:23:01.776 [vent.ItemStateChangedEvent] - Iphone_Sw changed from ON to OFF
2018-08-23 18:30:32.916 [vent.ItemStateChangedEvent] - Iphone_Sw changed from OFF to ON
2018-08-23 18:30:32.937 [me.event.ThingUpdatedEvent] - Thing 'network:pingdevice:192_168_2_160' has been updated.
In red was automatically OFF when actually phone was conencted, screen locked and slept.
Then I click on the phone in order to wake up the screen and I got quickly ON.
However, I think I could work with rules while is solved this little issue (I guess). I could create a rule that says, if door has not been open and device goes OFF, this is a false OFF, so turn ON again, or something like that. Using a Timer or something.
You can try new build with more verbose logs, we will see what arping is doing
https://github.com/asvilabs/esh-oh-legacy/blob/master/org.openhab.binding.network-2.3.0.jar?raw=true
It is the same version that I have, 2.3.0
the number is same, but build is different. temporarily enabled some logs for debugging purpose, at INFO level.
You can drop new file over old file in openhab addons folder.
ok thank you. I let you know how is going…