I’m on openHAB 4.1.3 now. I think I’ve been running the Network Binding since version 2.0 and haven’t had any issues, but now it seems to start very slowly. Each thing slowly, one at a time, goes from uninitialized, to not yet ready, eventually to online (I might have missed some steps). I noticed this when I tried to reboot my system, and none of my things started. I first uninstalled the Network Binding when I noticed in my openhab log ‘Initializing handler for thing anetwork:binding:thing:channel takes more than 5000ms’. I believe I ran updates recently. All is fine if I keep the binding uninstalled, restart OpenHAB, then install the binding. Except the Network Binding is still very slow to load in the UI (~30 seconds to load) while all the other things load quickly. The Network Binding things are also still very slow to initialize. Any guesses as to what I could try? No big rush as it seems to be working anyway. Thanks!
I think the steps will be to:
- upgrade to the latest milestone or snapshot so ensure this isn’t a problem that hasn’t already been fixed
- put the binding into debug level logging
- collect relevant logs and open an issue on the add-on.
Given what the Network binding does, there isn’t any reason I can think of that it would be slow to come online.
I’m on 4.1.0 and this is working. But every update after that I get same result as above.
Windows 10 Pro
NUC whit 16/256
That’s interesting. I’m on a NUC as well. What NUC do you have? I wonder if it’s 7th gen, and if that’s more than a coincidence. Mine is a NUC7PJYH.
I haven’t tried non-release versions yet. This bug doesn’t bother me very much, but I’ll try some things eventually. I didn’t want to risk introducing less kind bugs. Knowing that I might not be the only one effected gives me a little more motivation though. I should open an issue if it hasn’t already been fixed. I turned on all the logs for that binding, but I didn’t see any helpful errors or warnings. It looked pretty much the same as another working instance I have running on a Raspberry Pi.
Mine is
NUC 7I7BNH
I have tried every milestone and rc including 4.2.0 all whit same delay so went back to 4.1.0.
Mine is
NUC 7I7BNHI have tried every milestone and rc including 4.2.0 all whit same delay so went back to 4.1.0.
Thanks for sharing. I’ll try another network adapter when I get a chance. If that works, I can look into our gigabit Intel network adapters a bit more. Since your rollback fixes it, we’ll probably need to submit an issue. Also, I’d imagine not much has changed in the kernel/drivers for these older NICs.
I am having the same issue running OH 4.2 inside a docker container using the host network. My testing also showed that this started in OH 4.1.1.
Yep… Same issue, but without docker. I happened to recently install docker, but I definitely was already experiencing this issue. I didn’t switch OpenHAB to a container either. I’m sure Docker didn’t help, but I’m sure it’s not the root cause in my case. I double-checked my logs to make sure I’m not going crazy. I started this thread a week before I installed docker.
I think it is related to the increased number of network interfaces that Docker adds to a host system. It doesn’t matter if your OH server is running inside a container.
That definitely seems plausible. I have several VPN interfaces, and those were there before I installed Docker. Already had only eth0 selected for all my things.
*tried to modify this as a reply…
Same here on a Ubuntu LTS 22.04 System without Docker or container. No problems with OH 4.1, but heavy issues with 4.2 like described here.
Is there already a solution found?
Little update since it’s been a while, and I’ve changed some things. The changes were unrelated and not helpful to this issue, but I thought they could answer some questions here.
I backed up and restored OpenHAB to a new instance on a Proxmox VM. Everything works fine, and that VM only has one network interface now. This issue persists. I even tried switching to an emulated Intel NIC for a bit.
Just to be clear, the recent 4.2 updates haven’t helped either. My issues started in 4.1.3, while 4.1.1 was fine.
Hello, same issue here for me with OH 4.2.2
I don’t know when it started but yesterday I need to replace a network binding thing (pingdevice) with another one (delete the old one and create the new one) and it took many minutes to display the new thing in UI (I use file based configuration).
I tried also to stop openhab and clean cache but it was a “bad action”. The following restart took hours to let all the things (not only network binding related) be created.
I think it is related to the network binding because I made other changes to my configuration in the past few days but I didn’t have any problem with them till yesterday
Same issue here. Migrated my old openhab 4.1 docker instance from an RPI4 to an intel based mini PC hosting proxmox with an openhab 4.3M3 lcx docker container. Issue started after the migration but is probably related to the version 4.3M3. Start of Openhab takes up to 10 Minutes and is seemingly stuck on the network binding. Attached some logs
Anonymized IPHostnames.txt (6.8 KB)
I don’t think it is related to 4.3M3 because I have the issue on my OH 4.2.2 Stable.
Maybe something happened between 4.1 and 4.2
I moved to a python script and MQTT things. I didn’t spend much time researching first, or writing the script, but I thought someone on here might find it useful and/or build on it. I already have MQTT running for other things, so adding this wasn’t much. It just pings a list of devices, reports to MQTT, and listens to send WOL packets. I just had to add some modules to my python virtual environment. You’ll probably want to set this up as a service, and this doesn’t need root for what it’s doing.
Devices should be added to the python script where nickdesktop and othercomputer are just names I used in MQTT topics. The timeouts, time between runs and ping counts are all just variables at the top. Perhaps I will add asynchronous processing at some point, but my needs are small.
For the Things, MQTT State Topic is:
pingable/devices/<name>/status
And MQTT Command Topic is:
pingable/devices/<name>/wol
The Python script:
#!/usr/bin/python3
# -*- coding: utf-8 -*-
import paho.mqtt.client as mqtt
from pythonping import ping
from wakeonlan import send_magic_packet
import time
pingcount = 2
timout = 3
timebetweenruns = 5
ipaddress_devices = {
'192.168.1.100': ['nickdesktop', 'de:ad:be:ef:ca:fe'],
'192.168.1.101': ['othercomputer', 'aa:bb:cc:dd:ee:ff']
}
mqtthost = "mqtt.mydomain.com"
mqttport = 1883
mqttkeepalive = 60
mqttusername = "mqttuser"
mqttpassword = "mqttpassword"
def on_connect(client, userdata, flags, reasonCode, properties):
# print("Connected with result code "+str(rc))
client.subscribe("scripts/somescript")
for device in ipaddress_devices.values():
# client.subscribe("pingable/devices/" + device[0] + "/status")
client.subscribe("pingable/devices/" + device[0] + "/wol")
def on_message(client, userdata, msg):
topic = msg.topic
payload = msg.payload.decode("utf-8")
print(topic, payload)
for device in ipaddress_devices.values():
if topic == "pingable/devices/" + device[0] + "/wol" and payload == 'ON':
send_magic_packet(device[1])
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
client.on_connect = on_connect
client.on_message = on_message
client.username_pw_set(username=mqttusername, password=mqttpassword)
client.loop_start()
while True:
client.connect(mqtthost, mqttport, mqttkeepalive)
for ipaddress in ipaddress_devices.keys():
pingresults = str(ping(ipaddress, timeout=timout, count=pingcount))
print(pingresults)
if pingresults.count("Request timed out") >= pingcount:
client.publish(topic="pingable/devices/" + ipaddress_devices[ipaddress][0] + "/status", payload="OFF", qos=0, retain=False)
print(ipaddress_devices[ipaddress][0] + " OFF")
else:
client.publish(topic="pingable/devices/" + ipaddress_devices[ipaddress][0] + "/status", payload="ON", qos=0, retain=False)
print(ipaddress_devices[ipaddress][0] + " ON")
time.sleep(timebetweenruns)
client.loop_stop()