Your question leads to the conclusion you did not search for that bug. Don’t worry, I did it for you:
So either delete your /userdata/org/…/network.config file and restart openHAB or put that pid line as a first line in your network.cfg.
It works, I’ve tested it.
maybe try @sihui’s suggestion. i know my way works heh, maybe i’ll try it too.
eta
binding.network:allowSystemPings=true
binding.network:allowDHCPlisten=false
binding.network:arpPingToolPath=arping
binding.network:cacheDeviceStateTimeInMS=2000
is my network config so this is not a problem for me… still no idea why the .thing file doesn’t work anymore.
If I understand you correctly you want my network.cfg:
service.pid=“org.openhab.network”
binding.network:allowSystemPings=true
binding.network:allowDHCPlisten=true
binding.network:arpPingToolPath=arping
binding.network:cacheDeviceStateTimeInMS=2000
Removing the file just recreates it at restart.
Regarding the ticket you sent, hasn’t this been resolved at 2017-08-12? I’m trying to run this at 2.4 that released just a few weeks ago?
As you haven’t provided any information about your operating system and your openHAB install method I can only guess:
Assuming you are using some kind of apt repo (including openHABian) you need to delete
/var/lib/openhab2/config/org/openhab/network.config (note the file ending: .config)
then populate your /services/network.cfg (note the file ending: .cfg)
with the correct content you want to have in your network binding configuration, for example
binding.network:allowSystemPings=true
binding.network:allowDHCPlisten=true
binding.network:arpPingToolPath=arping
binding.network:cacheDeviceStateTimeInMS=2000
Then put as a first line (just to make sure, it should not be needed in 2.4)
pid: org.openhab.network
so it reads:
pid: org.openhab.network
binding.network:allowSystemPings=true
binding.network:allowDHCPlisten=true
binding.network:arpPingToolPath=arping
binding.network:cacheDeviceStateTimeInMS=2000
Then restart openHAB.
If that is really the case (for your network**.cfg** file) you have a serious problem in your openHAB installation 
I’m running a raspberry pi 3b+
Raspbian with all the latest and greatest updates, installed arping and then installed opehab ontop of that.
Yes, I am deleting the network.config file.
When I reboot the PI it just recreates itself.
Is there no logs at all that I could read that informs me what goes wrong with the network binding?
Hello,
I’m having the same problem.
Please, can you help me?
I’m using Raspberry PI 3b+ with OpenHabian.
I deleted the network.config file from /var/lib/openhab2/config/org/openhab.
Then i created a network.cfg file in /services.
After restart OpenHab, i noticed that the file network.config was back there.
The contents is:
“felix.cm.newConfiguration=B"true”
service.pid=“org.openhab.network”
Other problem is that OpenHab complaint about the new line in the network.cfg file, the log shows:
2018-12-27 22:54:32.304 [ERROR] [g.dispatch.internal.ConfigDispatcher] - Error parsing config file network.cfg. Exclusive PID org.openhab.network found but line starts with binding.network.
Is there anything else i can do?
Thanks again.
Hi,
I’ve the same issue. There is a bug in OH 2.4. Network binding is not finding anything. The config file is recreated everytime you delete it.
Nevertheless when you make changes to the .cfg file it is reflecting in the paperui network binding settings.
Although I don’t see any errors in the logs, it is not working at all.
Thanks.
That is intended behaviour!
The settings your are putting into your *.cfg files are transferred to the *.config file.
The *.config files should never be touched manually, only the *.cfg files.
There was a bug in 2.3 a long time ago where the transfer from *.cfg to *.config did not work properly. Most likely you are seeing this behaviour because you never fixed that in your 2.3 installation.
My last idea: don’t use a network.cfg file at all, the system will use default values, then just define everything on things level, either through a text file or via PaperUI:
Put the network binding into debug mode:
log:set DEBUG org.openhab.binding.network
To go back:
log:set INFO org.openhab.binding.network
So now I think we are getting somewhere! 
This is the log of startup:
2018-12-28 08:50:52.388 [DEBUG] [org.openhab.binding.network ] - BundleEvent [unknown:512] - org.openhab.binding.network
2018-12-28 08:50:52.438 [DEBUG] [org.openhab.binding.network ] - ServiceEvent REGISTERED - {org.osgi.service.cm.ManagedService}={service.id=137, service.bundleid=237, service.scope=singleton} - org.openhab.binding.network
2018-12-28 08:50:52.446 [DEBUG] [org.openhab.binding.network ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={cacheDeviceStateTimeInMS=2000, service.id=138, allowSystemPings=true, service.bundleid=237, service.scope=bundle, allowDHCPlisten=true, arpPingToolPath=arping, service.pid=binding.network, component.name=org.openhab.binding.network.internal.NetworkHandlerFactory, component.id=28} - org.openhab.binding.network
2018-12-28 08:50:52.451 [DEBUG] [org.openhab.binding.network ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=139, service.bundleid=237, service.scope=bundle, component.name=org.openhab.binding.network.internal.discovery.NetworkDiscoveryService, component.id=29} - org.openhab.binding.network
2018-12-28 08:50:52.463 [DEBUG] [org.openhab.binding.network ] - BundleEvent STARTING - org.openhab.binding.network
2018-12-28 08:50:52.466 [DEBUG] [org.openhab.binding.network ] - BundleEvent STARTED - org.openhab.binding.network
2018-12-28 08:50:54.594 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2018-12-28 08:50:54.614 [WARN ] [g.dispatch.internal.ConfigDispatcher] - The file /etc/openhab2/services/network.cfg subsequently defines the exclusive PID ‘org.openhab.network’. Overriding existing configuration now.
2018-12-28 08:50:55.076 [WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 192.168.0.31
2018-12-28 08:51:00.750 [WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 192.168.0.31
2018-12-28 08:51:08.790 [INFO ] [thome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2018-12-28 08:51:10.765 [INFO ] [ternal.dhcp.DHCPPacketListenerServer] - DHCP request packet listener online
2018-12-28 08:51:11.079 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port ‘/dev/ttyACM0’
2018-12-28 08:51:11.147 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Serial port is initialized
2018-12-28 08:51:11.197 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2018-12-28 08:51:11.198 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
2018-12-28 08:51:12.826 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at http://192.168.1.203:8080
2018-12-28 08:51:12.830 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at https://192.168.1.203:8443
2018-12-28 08:51:13.164 [INFO ] [b.core.service.AbstractActiveService] - HTTP Refresh Service has been started
2018-12-28 08:51:14.997 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2018-12-28 08:51:15.822 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
Just me guessing, BundleEvent [unknown:512] - org.openhab.binding.network If this unknown:512 is pointing towards a line in the code we can see that in Network: Null type annotations. Fix property xml<-->code mismatch. (#… · openhab/openhab2-addons@46791d7 · GitHub change that a line in PresenceDetection.java was added:
ScheduledFuture<?> future = refreshJob; maybe this is the issue?
Also have you tested 2.4 last 20 days? since alot of changes seems to have been implemented.
If you are asking me: I’m on 2.5 Snapshot #1467
The problem persists in 2.5.0-SNAPSHOT Build #1480
Thanks, I learned something. I had a bunch of orphaned config files and files with old information in it that caused a lot of startup errors. For the first time in 2 years my startup is perfectly clean with no errors!
I’ll retry configuring network things via file to see if that is fixed later.
Same for me: clean new OH2.4 install on a brand new Windows 10 PC, ICMP ports open in firewall, created network.cfg and deleted network.config but nothing is discovered by the binding whereas it works like a charm in OH2.3.
Adding things manually works: they are pinged and channel are updated properly.
Network discovery is not working in OH 2.4. It might come back in a later OH 2.5 snapshot though.
2 Likes
ah ok, nice to know. 
I switched my router for a simple hub and could not understand why devices were not discovered anymore. Glad to see it is by design. I hope the feature comes back, just have to add the devices manually until then.
1 Like
Execution failed (Exit value: -559038737. Caused by java.io.IOException: Cannot run program "arping" (in directory "."): error=2, No such file or directory)
Arping installed. Binding stopped working after updating to 2.4.
You need to set the full path to your arping install.
Thank you, I do have full path specified. I’ll do debug.