[Confirmed not fully functional]Network binding 2.4 does not work

Network binding does not work in 2.4 as in 2.3.
Did a fresh install of 2.4, did not get it to work, downgraded to 2.3 it works, with all the things added upgraded to 2.4 and now it doesn’t work again.

Not only me have seen the issue:

1 Like

Hi guys,

I have the same problem as mentioned above since i have upgraded from 2.3 to 2.4

any suggestions how to solve this?

regards

michael

Please provide relevant information, we don’t have any crystal ball to look into your config.

By the way, I’m using the network binding with 2.4 stable and 2.5 snapshot and don’t see any issues.

2 Likes

The crystal ball reveals:

/services/network.cfg:
allowDHCPlisten=B"true"
allowSystemPings=B"true"
arpPingToolPath=“arping”
cacheDeviceStateTimeInMS=“2000”
service.pid=“binding.network”

This is the initial config that gets installed, the exact same way I did in 2.3 where no changes were needed to get it working as intended(?)

You are seeing a very old bug in 2.3 stable which got fixed a long time ago. Unfortunately I cannot find the reference anymore, but I’m sure you will find it through the search button if needed.

Please configure your cfg file according to the docs and you should be good to go.

A very old bug in 2.3 that has been reintroduced in 2.4?
Tried with the config from the document page but did not solve it.
Only thing that has worked this far for me is downgrading to 2.3.

I’m new to openhab so is there any logs that I could look at? Cant find anything interesting in events.log or openhab.log.

I had to add the things through paper ui. the things file doesn’t seem to be working. i didn’t dig deep into it cause whatever, it works now. i would like to go back to the file based but w/e.

so, go to inbox. hit the +, click network binding, click add manually at the bottom and select the appropriate options in the following screen.

not ideal, but it works. maybe someone smarter will chime in as to why its not working any more

Thanks for your input, could you please verify that it works correctly by cycling one of your devices so it should show offline for a few seconds?

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 :grinning:

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! :slight_smile:
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 https://github.com/openhab/openhab2-addons/commit/46791d7e871305d60e9324535b0bb41134f2ed86#diff-2c651085cdf0c6a3a24a1b77e522fc02 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