[network] Network Binding things are slow to start from OH 4.1

[rheos13]

Since I upgraded from 4.1, without making any changes to my environment, I've started experiencing delays in initializing network stuff. I've checked all the binding information and it's all in accordance with it.
I have a feeling that it only affects OH installations of Windows, but I haven't found much information about complaints in the general forums.

Expected Behavior

In OH 4.1 and earlier, there were no delayed Initializing handler logs, and the full startup of OH was fast (2-3 min)

Current Behavior

Initializing handler is abnormally long. In this log it takes approximately 14 min

2024-12-20 21:15:39.092 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:movil_yol' takes more than 5000ms.
2024-12-20 21:16:20.347 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:movil_jesus' takes more than 5000ms.
2024-12-20 21:17:01.621 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:movil_camino' takes more than 5000ms.
2024-12-20 21:17:42.906 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:sony_bravia' takes more than 5000ms.
2024-12-20 21:18:24.162 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:aio_lan' takes more than 5000ms.
2024-12-20 21:19:05.440 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:aio_yol_wifi' takes more than 5000ms.
2024-12-20 21:19:46.730 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:portatil_yol_wifi' takes more than 5000ms.
2024-12-20 21:21:50.529 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:ps4_lan' takes more than 5000ms.
2024-12-20 21:22:31.803 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:ps4_wifi' takes more than 5000ms.
2024-12-20 21:23:13.066 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:tvbox_cine_lan' takes more than 5000ms.
2024-12-20 21:23:54.347 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:rm4_acsalon' takes more than 5000ms.
2024-12-20 21:24:35.637 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:rm4_gris' takes more than 5000ms.
2024-12-20 21:25:16.917 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:rm4_telecocina' takes more than 5000ms.
2024-12-20 21:25:58.206 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:rm4_marron' takes more than 5000ms.
2024-12-20 21:26:39.468 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:rm4_verde' takes more than 5000ms.
2024-12-20 21:27:20.740 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:rm4_telesalon' takes more than 5000ms.
2024-12-20 21:28:02.029 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:openmqttgatewaysensors' takes more than 5000ms.
2024-12-20 21:28:43.261 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:openmqttgatewaybeacons' takes more than 5000ms.
2024-12-20 21:29:24.502 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:openmqttgatewaybeacons2' takes more than 5000ms.
2024-12-20 21:30:05.808 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'network:pingdevice:xiaomicamera' takes more than 5000ms.

Possible Solution

1. Start OH 4.3 without network binding and install it after boot with an external script. This does not solve the problem but it does get the whole environment to boot quickly.
2. Stop using network binding an create rule using ‘actions.Ping.checkVitality’ If only use the network bindind for that.

Steps to Reproduce (for Bugs)

1. Install OH 4.3 for Windows
2. Install network Binding
3. Create network.things file with 20 things and items file.
4. start OH
5. Review the logs

Context

In versions higher than 4.1 it was annoying due to the warning logs, in version 4.3 until the initialization of all network bindings is finished it does not load the rest of the rules (this does not always happen). This means that a restart can last 2 minutes (without binding) or 12 minutes due to network binding.

Your Environment

I have performed all possible test combinations:
OH 4.2, 4.2.2, 4.2.3, 4.3
Toshiba Laptop - W10 PRO
HP PC - W10 HOME
Dell Thin Client - W10 PRO
HP Thin Client - W11 PRO
... in all cases with the same result.

[lsiepel]

Waht is your network configuration on your host? Are you using any virtualisation stuff (docker, hyper-v, vmware etc etc)

[rheos13]

I am not using any virtualization system Docker, Hyper-V, VMware, etc. The production and test installations are done on home computers (PCs or thin clients) with a standard Windows installation, with a LAN network interface and a WiFi one.

[lsiepel]

ork interface and a WiFi one.

Only 1 connected i assume? If not, does it make any difference if you disable one? When you put the log level of the network binding to trace, does it show anythingt usefull?
Can you show some network Thing configurations?

[rheos13]

In all the cases I have tested, I have always had only the LAN interface active. When I have put the trace mode I have not been able to detect anything useful (to my knowledge)
What network settings do you need exactly? I am sending you this:

################################### NETWORK ####################################
Primary address subnet (e.g. 192.168.1.0/24).

org.openhab.network:primaryAddress=192.168.0.6/24

A broadcast address (e.g. 192.168.1.255).

org.openhab.network:broadcastAddress=192.168.0.255

Use only one IP address per interface and family.

org.openhab.network:useOnlyOneAddress=false

Use IPv6 Addresses if available.

org.openhab.network:useIPv6=true

##################################################################################

Thing network:pingdevice:movil_yol "Móvil 1" [ hostname="192.168.0.xx", macAddress="XX:XX:XX:XX:XX:XX", useIOSWakeUp="false" ]
Thing network:pingdevice:movil_jesus "Móvil 2" [ hostname="192.168.0.xx", macAddress="XX:XX:XX:XX:XX:XX", useIOSWakeUp="true" ]

I have also tried setting the parameter 'networkInterfaceNames=' , but I have not been able to do so on a Windows installation.

[lsiepel]

Not sure if it helps, but try disable ipv6 (useIPv6=false) if your home network is setup using ipv4 and limit to one address (useOnlyOneAddress=true). Be sure that the useIOSWakeUp is only set iOs devices.

In that case i think you have a proper configuration.

As this only happens at startup, it might be related to Thing discovery. Do you see anything weird in task manager, processes/threads running 100%?

Could you post the trace log (or send it private) that runs for those 12 minutes?

[rheos13]

Hi Isiepel!

After your second post about whether I found any differences when disabling any of the interfaces, I have performed a series of conclusive tests:

1. For the binding to start correctly, all interfaces have to be disabled (except the main one). Being inactive or not connected is NOT enough. It is necessary to disable them so that they do not appear in the network configuration.
2. I don't know if this "detail" is in the documentation, but I have not related it. In the OH 4.1 version, having more than one active interface did not affect it.

Two additional questions:

1. According to the documentation and verified behavior, the correct thing would be to put the networkInterfaceNames parameter for each network thing to bind it to the correct network interface. This way it would not affect having more than one active interface. Where do I get the correct name in the case of a Windows environment?
2. You have also recommended that I only set useIOSWakeUp on iOS devices, but the documentation indicates that by default, it is true. That is why I set false for those that are not. What is the correct way then?

Thank you very much for your help

---

TEST 1 Enable ethernet interface Only - Works perfect! starts in 2 minutes

Configuración IP de Windows

Adaptador de Ethernet Ethernet:

Sufijo DNS específico para la conexión. . :
Vínculo: dirección IPv6 local. . . : xxxxxxxxxxxxxxxxxxxxxxxx
Dirección IPv4. . . . . . . . . . . . . . : xxxxxxxxxxxxx
Máscara de subred . . . . . . . . . . . . : xxxxxxxxxxxxx
Puerta de enlace predeterminada . . . . . : xxxxxxxxxxxxx

TEST 2 Enable ethernet interface and Bluetooth interface - Works good! starts in 3 minutes

Configuración IP de Windows

Adaptador de Ethernet Ethernet:

Sufijo DNS específico para la conexión. . :
Vínculo: dirección IPv6 local. . . : xxxxxxxxxxxxxxxxxxxxxxxx
Dirección IPv4. . . . . . . . . . . . . . : xxxxxxxxxxxxx
Máscara de subred . . . . . . . . . . . . : xxxxxxxxxxxxx
Puerta de enlace predeterminada . . . . . : xxxxxxxxxxxxx

Adaptador de Ethernet Conexión de red Bluetooth 2:

Estado de los medios. . . . . . . . . . . : medios desconectados
Sufijo DNS específico para la conexión. . :

TEST 3 Enable ethernet interface and WIFI interface - Fail! starts in 9 minutes

Configuración IP de Windows

Adaptador de Ethernet Ethernet:

Sufijo DNS específico para la conexión. . :
Vínculo: dirección IPv6 local. . . : xxxxxxxxxxxxxxxxxxxxxxxx
Dirección IPv4. . . . . . . . . . . . . . : xxxxxxxxxxxxx
Máscara de subred . . . . . . . . . . . . : xxxxxxxxxxxxx
Puerta de enlace predeterminada . . . . . : xxxxxxxxxxxxx

Adaptador de LAN inalámbrica Wi-Fi:

Estado de los medios. . . . . . . . . . . : medios desconectados
Sufijo DNS específico para la conexión. . :

Adaptador de LAN inalámbrica Conexión de área local* 2:

Estado de los medios. . . . . . . . . . . : medios desconectados
Sufijo DNS específico para la conexión. . :

Adaptador de LAN inalámbrica Conexión de área local* 3:

Estado de los medios. . . . . . . . . . . : medios desconectados
Sufijo DNS específico para la conexión. . :

TEST 4 Enable ethernet interface, Bluetooth interface and WIFI interface - Fail! starts in 10 minutes

Adaptador de Ethernet Ethernet:

Sufijo DNS específico para la conexión. . :
Vínculo: dirección IPv6 local. . . : xxxxxxxxxxxxxxxxxxxxxxxx
Dirección IPv4. . . . . . . . . . . . . . : xxxxxxxxxxxxx
Máscara de subred . . . . . . . . . . . . : xxxxxxxxxxxxx
Puerta de enlace predeterminada . . . . . : xxxxxxxxxxxxx

Adaptador de LAN inalámbrica Wi-Fi:

Estado de los medios. . . . . . . . . . . : medios desconectados
Sufijo DNS específico para la conexión. . :

Adaptador de LAN inalámbrica Conexión de área local* 2:

Estado de los medios. . . . . . . . . . . : medios desconectados
Sufijo DNS específico para la conexión. . :

Adaptador de LAN inalámbrica Conexión de área local* 3:

Estado de los medios. . . . . . . . . . . : medios desconectados
Sufijo DNS específico para la conexión. . :

Adaptador de Ethernet Conexión de red Bluetooth 2:

Estado de los medios. . . . . . . . . . . : medios desconectados
Sufijo DNS específico para la conexión. . :

[lsiepel]

Two additional questions:

1 According to the documentation and verified behavior, the correct thing would be to put the networkInterfaceNames parameter for each network thing to bind it to the correct network interface. This way it would not affect having more than one active interface. Where do I get the correct name in the case of a Windows environment?

Linux user here, can't tell.

2 You have also recommended that I only set useIOSWakeUp on iOS devices, but the documentation indicates that by default, it is true. That is why I set false for those that are not. What is the correct way then?

Perfect, setting it explicitly or d3ependingin on the default doesn;t matter, the result is the same.

Maybe i look into the root cause, maybe we can filter the network interfaces on the state (ifUp)

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/network-binding-things-are-slow-to-start-and-slow-to-load-in-the-settings-ui/157001/22

[rheos13]

Maybe i look into the root cause, maybe we can filter the network interfaces on the state (ifUp)

Ok lsiepel Thank you for your time!

[jsetton]

This is related to #16810.

I still have the same issue with OH 4.3. I have stopped using the network binding since then. The binding seems to interact with every interfaces configured on the OH server during its initialization regardless of having the networkInterfaceNames parameter configured at the thing level.

As I mentioned here, something changed between OH 4.1.0 and 4.1.1.

[lsiepel]

There is a small difference, in the other thread docker is used and disabling interfces did not help. In this case, it is about a reguler host with 2 NIC's and disabvleing helps.

Nevertheless the interface filtering should work, did not have time today to look into it.

[lsiepel]

Ok, looked at the code.

1. You are right that the parameter networkInterfaceNames is not used during discovery. This is probably because it is a parameter bound to the thing and not to the binding. Hance it is not available during Thing discovery.

2. The discovery uses some methods that leads to NetUtil.getAllInterfaceAddresses() wich does filter interfaces for being up.

Question:
Regarding the trace log you got earlier, can you share it? I would be interested in the line that has "Scan of {} IPs successful" and if that differs when you have the wifi interface enabled or not (if im not mistaken your lan interface is actually connected)

Edit: Can you try this jar https://1drv.ms/u/s!AnMcxmvEeupwj49DlPN-znfkoxHM6w?e=wGfqko it should work on 4.3.0. During discovery, the networkInterfaceNames is empty and all names are determined form your system without checking ifUp. So added that check.

1. Make sure you have openHAB 4.3.0
2. uninstall network binding (does not affect your configuration of items/channels etc)
3. drop the jar file in your addon folder
4. report back your results regarding discovery. if there are still issues, please add a trace log.