If you assigned it in DHCP config (in your router) then its fine, no need to do anything on Android. But if DHCP config is not in your control, you can assign static IP in Android, one that is outside DHCP range.
We could probably get something close enough to be useful using download statistics. OH is download x times and Network binding is downloaded y times. Add some fudge factors and there could be a reasonable guesstimate. Close enough to make decisions on anyway. We don’t need to measure with a micronometer only to cut with an ax.
I’m not sure even those stats are captured though.
Did you mean micrometer?
Yes I did.
I would like following stats (sorry Juan its going off topic)
- what bindings are installed
- what bindings were uninstalled after they were installed
- how many things a binding serves
- how many exceptions are thrown by a binding shortly after being installed (may indicate poor docs and poor parm descriptions)
- how many exceptions are thrown by a binding in a given time
- how many exceptions are thrown by platform (may indicate popular platform issue)
- how often OH reboots
- how often rule engine throws errors (may indicate poor rue language VM and tooling)
Perhaps the work being done here (New Add-on bundle for Prometheus health Metrics) could be a start, or at least inspiration.
Guys, we are going a bit off topic here…
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.
- 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.
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.
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?
network:servicedevice:cerberos [ hostname="cerberos", mac="00:11:22:33:44:55:66", port=22, retry=5, timeout=5000, refreshInterval=10000 ]
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.
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 email@example.com 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)