admi
(n)
December 27, 2018, 3:33pm
4
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(?)
sihui
(SiHui)
December 27, 2018, 4:02pm
5
admi:
The crystal ball reveals
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.
admi
(n)
December 27, 2018, 4:52pm
6
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.
waspie
(scott dee)
December 27, 2018, 4:58pm
7
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
admi
(n)
December 27, 2018, 5:06pm
8
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?
sihui
(SiHui)
December 27, 2018, 5:06pm
9
Your question leads to the conclusion you did not search for that bug. Don’t worry, I did it for you:
opened 03:23PM - 19 Jan 17 UTC
closed 09:14AM - 12 Aug 17 UTC
bug
The relevant thread on the forums is here:
https://community.openhab.org/t/he… lp-im-ready-to-give-up/20006/93
The issue particularly impacts 1.9 bindings like Weather, MQTT, and HTTP where there can be repeated copies of one or more setting type (e.g. more than one broker config for MQTT, more than one weather location in Weather, more than one URL to cache in HTTP).
If, for example, a user decided they no longer need to poll a certain URL with the HTTP binding and remove it from their conf/services/http.cfg file, that parameter does not get removed from the corresponding userdata/config/org/openhab/http.config.
Even upon a reboot, the removed parameters persist in the userdata/config version.
As a user I expect updates to the services/binding.cfg file to apply, including additions, modifications, and removals.
If this is the wrong repo (e.g. this is really an ESH problem) let me know and I'll repost it there.
Thanks
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.
waspie
(scott dee)
December 27, 2018, 5:24pm
10
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.
admi
(n)
December 27, 2018, 8:07pm
11
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.
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?
sihui
(SiHui)
December 27, 2018, 8:32pm
12
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
admi
(n)
December 27, 2018, 8:53pm
13
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?
wcampagner
(Wcampagner)
December 28, 2018, 1:07am
14
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.
becksen
(Becksen)
December 28, 2018, 1:54am
15
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.
sihui
(SiHui)
December 28, 2018, 7:55am
16
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:
sihui
(SiHui)
December 28, 2018, 8:01am
17
Put the network binding into debug mode:
log:set DEBUG org.openhab.binding.network
To go back:
log:set INFO org.openhab.binding.network
admi
(n)
December 28, 2018, 9:23am
18
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.
sihui
(SiHui)
December 28, 2018, 10:51am
19
If you are asking me: I’m on 2.5 Snapshot #1467
11am
(Matt Kraus)
December 29, 2018, 12:55pm
20
The problem persists in 2.5.0-SNAPSHOT Build #1480
waspie
(scott dee)
December 29, 2018, 2:53pm
21
sihui:
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.
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.
wawa79
(Yann)
December 31, 2018, 2:08am
22
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.
wawa79:
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.
Network discovery is not working in OH 2.4. It might come back in a later OH 2.5 snapshot though.
2 Likes