Network / presence binding update

Seeing that original network / presence binding is not update for some time I’ve made my own attempt of fixing / updating it. Looking for fellow open hab users who’s willing to do some testing and provide feedback. Available here:

Network binding (update)
Source code

I’ve made a lot of changes to original one, mostly related to ARP ping. After some research I’ve found this tool for Windows:
arp-ping.exe(not affiliated with the developer in any way)
and added support for it into the binding. Address issue 4751

Some other changes:

  1. Fix arpping tool by Thomas Habets detection for Linux system, I recommend to use the latest version 2.19. Thinking of removing support for older version, cannot test for it and don’t see why to support it. Address issue 3581
  2. Added new parameter for number of pings attempted for tools which support this (Linux and Windows).
  3. Fix command lines for all tools. New logic - attempt specified number of pings (20 default) within specified timeout (only for Linux/Ubuntu tool), exit after first reply received.
  4. Removed interface support for ARP tools, don’t see why it was introduced, tools can detect interface automatically, not all of them supports that. Address issue 3112
  5. Fixed logging and properties status. Address issue 3514
  6. Binding now works with Internet address using only regular ping (so it is possible to validate if Internet site or server is up).
  7. Discovery service fix Address issue #4793
  8. Other bug fixes.

I’ll really appreciate any feedback, bug reports and functionality notes.

K.

3 Likes

I’ll try that!!

I’m on Ubuntu server 18.04LTS - Zulu latest

So far so good.
A bit verbosy on the INFO logging… :smile:

A bit verbosy on the INFO logging…

That was the attempt, but I can raise it.

My “Prod” box is Ubuntu / “Dev” is Windows. What is your arp tool?

Thanks,
K.

2019-01-25 09:30:00.868 [INFO ] [g.network.internal.PresenceDetection] - ARP Ping has been enabled, ARP tool set to Thomas Habert ARPing tool
1 Like

You forked the code basically.
But everybody will profit from changes if they are part of the official distribution.

So maybe you could try get those changes in, one by one (which of course is now more work).

Also have a look at the open PRs. There is one already dealing with arp-ping improvements.

1 Like

Hi David, thank you for your response and all your contributions.

Yes I’ve basically forked your code and worked on the fork, the idea was to contribute it back to the main code. Actually not sure how to do that, I’m new to all this, any guidelines? “More work” is not a problem at all.

I’ll have a look on “open PRs”, thanks!

Upd: I’ve found some guidelines on the project main site, trying to follow them but would be glad for any suggestions.

K.

Hello,
I came from this page. I have new installation of OpenHAB 2.4.0 on Windows 7 and Network Binding didn’t work at all. Now I download version org.openhab.binding.network-2.5.0_c.jar and put it to addons folder. Network discovering works fine but added devices are not updated - latency and last seen values are empty. Devices are still online. When network discovering there are WARNs in log:

20:02:01.223 [INFO ] [ng.network.internal.PresenceDetection] - Hostname 192.168.0.106 resolved to /192.168.0.106
20:02:01.276 [DEBUG] [ng.network.internal.PresenceDetection] - ICMP Ping has been enabled, ping method set to Windows na
tive ping
20:02:01.332 [WARN ] [clipse.smarthome.io.net.exec.ExecUtil] - Execution failed (Exit value: -559038737. Caused by java.
io.IOException: Cannot run program “g:\Lib\Downloads\arping\arp-ping.exe” (in directory “.”): CreateProcess error=2, The
system cannot find the file specified)
20:02:01.337 [DEBUG] [ng.network.internal.PresenceDetection] - ARP Ping has been disabled, unknown ARP tool g:\Lib\Downl
oads\arping\arp-ping.exe has been provided
20:02:01.341 [INFO ] [ng.network.internal.PresenceDetection] - Hostname 192.168.0.107 resolved to /192.168.0.107
20:02:01.401 [DEBUG] [ng.network.internal.PresenceDetection] - ICMP Ping has been enabled, ping method set to Windows na
tive ping
20:02:01.458 [WARN ] [clipse.smarthome.io.net.exec.ExecUtil] - Execution failed (Exit value: -559038737. Caused by java.
io.IOException: Cannot run program “g:\Lib\Downloads\arping\arp-ping.exe” (in directory “.”): CreateProcess error=2, The…

…no matter what is in network.cfg,

binding.network:allowSystemPings=false
binding.network:allowDHCPlisten=true
binding.network:arpPingToolPath=arping
binding.network:cacheDeviceStateTimeInMS=2000

Path to arping.exe is in system PATH.

network.cfg will be overwritten by everything that you configure via Paper UI. So you might have set the path (or any other option) over there already.

You mean userdata\config\org\openhab\network.config? I just checked Paper UI and there is exactly same setting what is in conf\services\network.cfg. It looks like a bug, when settings is not propagated to the service. I don’t even have G:\ drive.

Oh I forgot about that old bug (because nobody reported that yet on Github): The network binding does not apply binding configuration changes. You need to restart openHAB.

The restart is not helping. It is still trying use “g:\Lib\Downloads\arping\arp-ping.exe” no matter if binding.network:allowSystemPings is set to true or false or binding.network:arpPingToolPath=c:\openhab\arping.exe.
Btw when I change the file network.cfg, there is a message in log:

21:33:42.910 [DEBUG] [org.openhab.binding.network ] - ServiceEvent MODIFIED - {org.eclipse.smarthome.core.thing
.binding.ThingHandlerFactory}={cacheDeviceStateTimeInMS=2000, service.id=132, allowSystemPings=true, service.bundleid=24
9, service.scope=bundle, allowDHCPlisten=true, arpPingToolPath=c:\openhab\arping.exe, service.pid=binding.network, compo
nent.name=org.openhab.binding.network.internal.NetworkHandlerFactory, component.id=19} - org.openhab.binding.network

Maybe the bug you mentioned has been fixed.

That path is my default test path on my development machine (which Windows), but it really shouldn’t matter as it is supposed to be overwritten by whatever’s configured. And I didn’t notice any issues 'cause it is working on my production box (which is Ubuntu). Seems like it is an issue only on Windows.

David, even that this fork is not really important now as we’ve integrated most of the fixes into master fork it is still could affect it if configuration cannot be set on Windows machines. I’ll do some more testing but it seems like the bug is somewhere in the code up above, never touched that part in my changes.

Update: I did a lot of additional testing and I see why updated configuration is not applied. After configuration change “modified” method is called on HandlerFactory and new configuration is updated but initialize on actual handler is never called and handler configuration stays the same. But that should be done by framework.

David, if you want I can raise a defect record, however I don’t know how to fix this, this is above this binding.

Maybe a hint: in PaperUI I can see configuration from the network.cfg file but when I open HABmin and Network Binding configuration, the input boxes are empty.
Could be my installation somehow corrupted, do I need to install a Persistence Add-ons?

Hard to say, my fork does not do anything to configuration and it works fine for me on Windows in my testings and on my production Ubuntu box. Make sure your config file is in proper format, have a look on network.config file to see if proper settings set there. I bet my default config made it’s way there and now in use, however don’t adjust network.config manually, do that through UI.

Hello, I did new observation and I’m sorry I missed it before. When I checked a network Thing in PaperUI, it has always “online” status. It has 3 properties: online, latency and last seen. When I link a channel to the online property, the channel behaves properly. I didn’t try link a channel before. Is it correct behavior? But still, there are errors in log and Network Binding config in Habmin is empty as I reported before.

Yes that’s correct. Unfortunate wording. But a Thing in openHAB is Online, when it is configured correctly. And your network Thing is “working” therefore Online. That has nothing to do with the peer device.

That should maybe clarified in the binding documentation, what do you think?

Well, I would prefer rename the status “Online” to something more suitable. Like you said: “configured” or “configuration”. But it is generic change, not network binding related.
Thank you for the support!

1 Like

Just one more thing: Can some one please test this case: Having network binding with pingdevice (I think without using arping) and configure a pingdevice with hostname.
Then have the device change his ipaddress (e.g. DHCP server gives them another address).
Is the device still shown as online?

I had this case some weeks ago and device showed as offline for days(!) despite a normal shell ping worked and pinged the new address. I then restarted OpenHAB and then device showed up as online again. So I concluded there might be an (implicit?) name resolution cache (which would be quite bad).

I just didn’t have time yet to try this again so I can do a bugreport - so maybe it’s already fixed with this update

Yes that’s fixed