Could this have been caused by the new delay introduced when there’s a missing config description or something. I’ve never looked into it closely but I really wish this delay didn’t exist.
I have had people complain when they use a docker image that restricts communications to networks and bindings try and use the network that is locked down in the docker. I know the user here is not using docker, however if they have a wifi adapter issue it may be doing something similar.
The latest 4.1.1 does now do extra network scans to find binding suggestions that have an extra config description if that is what your referring to (?), and these scans are being sent to all networks. So if 4.0 does not have a delay, but 4.1 does, then I would consider this.
In bindings I have had to restrict the discovery scans to the PRIMARY NETWORK address that people setup in the openHAB settings menus. However I know from reading github issues that the scans are not just sticking to the primary select address.
I am not saying this is the cause here, but it may be for some others that are using docker and hit issues when going to 4.1
1 Like
I think your guess is better than mine.
I haven’t looked at this addon finder feature. Do you know how to disable it (through a config file - perhaps runtime.cfg)?
Pinging @AndrewFG
I can’t remember how but it can be turned off
A guess is just a guess and I am often wrong. I suggest you always DIAGANOSE first and then take action. Doing the bubdle:list should hopefully show what bundle is starting up and which ones are successfully started. Also if you start openhab manually from the command line it may give some output that can give clues as to what has worked and what is loading when the delay occurs.
You are right, if issue comes from low level and shell is available then it can be diagnosed this way.
However, starting all bundles makes openHAB reach start level 10 out of 100 which assume system is fully operational.
Still… loading of things should happen shortly after that. 
Do you download your addons on every startup, maybe from an invalid source ?There’s a remote= option in addons.cfg and some corresponding UI switch, too.
Short of that, you should systematically search for the cause rather than guess along.
As I already replied you should enable debugging to that purpose to find a hint which area of oh to look after (I too guess not all your bundles start properly).
laughing in 32 bindings, 112 Things, 120 rules and 1119 items (with more than 20 updating at least every second or so). 
nope, the 4GB Pi4 is more than capable of doing that:
my startup is the usual 3mins or so until everything is settled.
2 Likes
Before removing and later adding all 21 bindings via add-on store:
Is there an easier way to remove/add again the bindings?
Maybe just disable them in some way?
YES! Keep the list of the addons in conf/services/addons.cfg
To remove them: comment out the line
To add them back: uncomment
Installing them one by one via the UI is way too tedious.
Do you have either a second SD Card or a second Pi handy? I would:
- backup your configuration using openHABian
- load a vanilla openHABian on a new SD Card
- put that into (the second) pi4
- start it up
- first try to add all 21 bindings and reboot
- if ok: restore the backup via openHABian
if at some point not ok=> great, if not, try again, but instead slowly adding one binding after the other.
That only applies if you used file-based configuration in the first place… otherwise you have to either edit the jsonDB (if you know, what you’re doing!) or do it manually via UI.
Either…
-
Via Main UI | Settings | Add-on Management | Show Advanced … but since you apparently never get to Main UI, probably you need to try option 2. below
-
By adding entries in the ‘openHAB-userdata/config/org/openhab/addons.cfg’ file as follows…
suggestionFinderIp=B"false"
suggestionFinderMdns=B"false"
suggestionFinderUpnp=B"false"
The Upnp and Mdns finders are probably NOT the cause of your issue since they are event driven on separate threads and therefore cannot block the main thread.
The Ip finder uses timeouts on its ping requests, so in theory it should also not block your system (at least not for an hour or more). However a) if the addon.xml for any binding had bad syntax on its finder timeout element it may fall over, and/or b) we are also discussing making the Ip finder more concurrent – see this. => So can you please do the following…
- Please give the full list of all installed bindings which you have defined in your system. EDIT: currently the KNX binding is the only addon that would use the Ip finder.
- Try
suggestionFinderIp=B"false"above and let us know the outcome.
Awesome, thanks!
Also suggestionFinderUsb=B"false" ?
I hope this will make its way to the official doc, if not already.
To get the current list of ALL installed addons (whether they were installed through UI or addons.cfg):
/path/to/userdata/config/org/openhab/addons.config
Just back up that file (copy it somewhere safe where it won’t get deleted, or copy paste it). It’s a plain text file with simple to understand syntax, basically almost identical to addons.cfg
While openhab is stopped (kill -9 if you have to), edit that file, remove the values after binding=, but leave the double quotes around, i.e. binding=""
Then rm -rf userdata/tmp/* userdata/cache/*
Also move everything inside your addons folder to a separate folder outside of it.
If you happen to use addons.cfg method of installing your bindings, comment out the corresponding lines too.
Then start openhab.
Voila - ALL bindings gone!
No. The Usb finder and resp. the Process finder look for hardware attached to, resp. processes running on, the local PC, so their scans are fast and without LAN involvement, so we deemed it not necessary to disable them.
I will check. EDIT: apparently ‘addons.cfg’ has absolutely no official doc for it. Or? So rather than just editing an existing file (which I could easily do), it would require creating a complete new page and linking it into the table of contents etc. => WDYT?
You should not directly edit this file in the userdata/config folder. Edit the addons.cfg file in the configuration folder services directory instead:
suggestionFinderIp=false
suggestionFinderMdns=false
suggestionFinderUpnp=false
@andrewfg Commented lines for this should be added to this file in the distro repo (with default true)
1 Like
I created a PR: Add suggestion finder parameters to addons.cfg by mherwege · Pull Request #1633 · openhab/openhab-distro · GitHub
Wanted to provide some settings:
EXTRA_JAVA_OPTS=“-Xms192m -Xmx768m”
Addons from addons.cfg:
binding=“mail,homematic,netatmo,systeminfo,tr064,telegram,amazonechocontrol,network,openweathermap,avmfritz,yamahareceiver,solarlog,gardena,astro,mqtt,squeezebox,hue,weatherunderground,zwave,exec,fmiweather”
Now I restarted openhab (without disabling any bindings), logged into karaf console and looked for bundle:list.
The result after 3 different bundle:list is here:
bundle_list.txt (60.5 KB)
It looks as if the Exec binding, the Exec transformation service and the JavaScript Scripting keeps waiting and does not become active.
I only have 2 items that use the Exec and/or JavaScript binding:
Number CPU_Uptime "CPU_Uptime [JS(uptime.js):%s]" <time> { channel="systeminfo:computer:work:cpu#uptime" }
// Number type does not yet work for exec binding
// Do a transformation of openhab uptime secs to show uptime: 1 day 15 hours 32 mins instead of 2372 min:
String OpenHAB_Uptime "OpenHAB uptime [JS(uptime_secs.js):%s]" <time> { channel="exec:command:uptime:output" }
I think I have this since openHAB 1.8 or at least since 2.4…
uptime_sh.txt (519 Bytes)