In my case typing the address with xxxx.local doesnt work either from the browser.
Ok, I guess possibly there’s some sort of network configuration issue with your network that means it’s not resolving as you should be able to access the dashboard.
I’m not sure if it’s possible to disable UPNP discovery, but I think if it’s enabled, it will always update the address. I’m happy to be proven wrong, but I don’t think the binding can change this behaviour (which I agree is not nice).
Upnp is disabled in my router
I don’t really know what that does, what router you have, or if it’s relevant at all.
The issue is really around the DHCP/DNS and how your system maps device host names to IP addresses since you seem to be unable to address the device by its host name. Normally the router should resolve this, but it’s normally also possible to configure the name->ip address statically in the router, but again, it depends on your router.
1 Like
I will need to do this when I have a bit time.
On the weekend I have uninstalled and re-installed the binding, connected the SLZB-06M and one tempeature/humidity Zigbee device.
Yesterday or Today it all disconnected after running well for some days. In the event.log it says
2025-01-14 19:55:56.042 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:ZigBee_ONE:00158d008b3d527b' changed from UNINITIALIZED (HANDLER_MISSING_ERROR): Handler factory not found to UNINITIALIZED (NOT_YET_READY)
2025-01-14 19:55:56.045 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:ZigBee_ONE:18fc260000b747ed' changed from UNINITIALIZED (HANDLER_MISSING_ERROR): Handler factory not found to UNINITIALIZED (NOT_YET_READY)
2025-01-14 19:55:57.539 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:ZigBee_ONE:00158d008b3d527b' changed from UNINITIALIZED (NOT_YET_READY) to UNINITIALIZED (BRIDGE_UNINITIALIZED)
2025-01-14 19:55:57.540 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:ZigBee_ONE:18fc260000b747ed' changed from UNINITIALIZED (NOT_YET_READY) to UNINITIALIZED (BRIDGE_UNINITIALIZED)
2025-01-14 19:55:57.666 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:coordinator_slzb06:ZigBee_ONE' changed from UNINITIALIZED (HANDLER_MISSING_ERROR): Handler factory not found to UNINITIALIZED (NOT_YET_READY)
2025-01-14 19:55:59.560 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:coordinator_slzb06:ZigBee_ONE' changed from UNINITIALIZED (NOT_YET_READY) to INITIALIZING
But it does not get online again. Also restarting the SLZB06M does not help.
I am running DHCP for all devices that are connecting randomly, like phones or laptops and have a reserved ip range for devices that are fixed, like the SLZB06M. I can connect via IP and ZigBee_ONE.local to the device when it is connected to the binding and also when it is not connected, so the network router-wise itself seems fine.
I will provide debug logs but need to figure how to get there first.
This looks more like the binding has been uninstalled for some reason - things like HANDLER_MISSING, and “Handler factory not found” are really low level binding problems rather than the SLZB06M connection (and when I say binding problem - I mean there is probably no binding).
Hopefully more logging will help understand what’s happening - was there any system update or anything like that?
Thanks for the feedback. I will look into it for possible solutions.
On the other hand, if coordinator Thing is online, the new zigbee device/ senzor should be listed in the autodiscovery of the zigbee binding (considering the new device is in pairing mode) ?
If YES , this is valid for Tuya devices as well ?
Hi Chris,
I just logged into console and checkt which bundles are active
266 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: OpenWebNet (BTicino/Legrand) Binding
286 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: IO :: openHAB Cloud Connector
287 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: IO :: Homekit
352 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: Astro Binding
414 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: ZigBee Binding
415 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: ZigBee CC2531 Bridge
416 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: ZigBee Console
417 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: ZigBee Console Ember
418 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: ZigBee Console Telegesis
419 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: ZigBee Ember Bridge
420 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: ZigBee Firmware Provider
421 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: ZigBee Serial Driver
422 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: ZigBee SLZB06 Bridge
423 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: ZigBee Telegesis Bridge
424 │ Active │ 80 │ 4.2.2 │ openHAB Add-ons :: Bundles :: ZigBee XBee Bridge```
I will check how to create an error logfile, re-install the binding and once the disconnect occurs post the logs. In parallel I will check what's in the existing logs that could be of use.I restarted the system and checked for the logs at startup.
Here, i found that there is an error message that I believe indicates some issues with Java:
java.lang.ExceptionInInitializerError: null
That is followed by many “at” and “caused by”, amongst others, there is:
at org.openhab.binding.zigbee.internal.ZigBeeDataStore.readNode(ZigBeeDataStore.java:134) ~[?:?]
at com.zsmartsystems.zigbee.database.ZigBeeNetworkDatabaseManager.startup(ZigBeeNetworkDatabaseManager.java:193) ~[?:?]
at com.zsmartsystems.zigbee.ZigBeeNetworkManager.initialize(ZigBeeNetworkManager.java:416) ~[?:?]
at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.initialiseZigBee(ZigBeeCoordinatorHandler.java:431) ~[?:?]
at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.lambda$2(ZigBeeCoordinatorHandler.java:557) ~[?:?]
caused by is not fully listed, it says “… 33 more”.
I am not sure if that is already the right trace.
In the event.log I find:
2025-01-19 11:51:37.182 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:ZigBee_ONE:00158d008b3d527b' changed from UNINITIALIZED (HANDLER_MISSING_ERROR): Handler factory not found to UNINITIALIZED (NOT_YET_READY)
2025-01-19 11:51:37.183 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:ZigBee_ONE:18fc260000b747ed' changed from UNINITIALIZED (HANDLER_MISSING_ERROR): Handler factory not found to UNINITIALIZED (NOT_YET_READY)
2025-01-19 11:51:38.057 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:coordinator_slzb06:ZigBee_ONE' changed from UNINITIALIZED (HANDLER_MISSING_ERROR): Handler factory not found to UNINITIALIZED (NOT_YET_READY)
And the zigBee connector does not leave “initializing” and after a while goes to “error”
I would suggest to remove the files in the userdata\zigbee folder and see if this helps. I’m not sure what is causing this, but possibly one or many of the files there are corrupted. Battery devices may struggle to regenerate these files, but mains devices should be ok.
I’m pretty sure this has nothing to do with the SLZB06M.
I have deleted the files. The SLZB06M was discoverable again. I added the device. I re-started the system. It again gets stuck in initialising mode.
I deleted all ZigBee devices, unistalled zigbee binding, checked if everything was deleted from the path.
Then I restarted the system, re-installed the zigbee binding. I added the SLZB06M which connected. I added to sensor, worked. I restarted the system. SLZB06M gets stuck in initialising mode.
i wil now unistall all zigbee devices and bindings, install again and see how long it stays online.
I am wondering if there’s something strange with your system. As above, I don’t think this is anything to do with the SLZB06M - the errors your getting are around the loading of files from the file system - this code is common to all coordinators, not just the SLZB06, so if this was a more general problem, it would occur for every user.
So I’m assuming that again this is throwing an exception when loading these files. It works when the device is first added, but it can’t restore the information from these files when the system restarts. This again shows that the SLZB06 is working ok or the device wouldn’t add, but there’s something preventing this information being restored from the file system.
I also took the files from the Zigbee folder and compared them. It doesn’t seem to be a file system issue.
What is strange is that if it is the OH system, why does it work for the other bindings with approximately 90 things after restart.
What do you suggest? Set up OH again freshly? In this case, I would completeley reset the windows host computer just to make sure nothing caused by windows or java.
Sorry - I’m not sure I have any good suggestions. I’m reasonably confident that the issue is not with the SLZB06 connection - that appears to work fine when you first start it, but the binding is failing on restart when trying to read these files.
Who knows, but I don’t know that “other bindings” means too much here as we don’t know the cause. The code that reads this data is common across all coordinators, so as above, if there was a bug here we’d see it in every users system. One point is that not many bindings store data in the addons folder…
Sorry - I appreciate I’m not being very helpful, but I don’t really have much information to go on and I’m not sure what else might help 
Thank you, Chris. I greatly appreciate your assistance in helping us narrow down the issue. Based on the current analysis, we are working under the assumption that the connector is not the source of the problem. I will test a second connector in parallel to increase reproducibility. If the issue persists, I plan to reset the entire system, including Windows. While this will require some effort, most of the configurations I have made are based on text-based files ( .rules, .things, .items and such), so I can easily reapply them as needed.
Would you be interested in staying updated on the next steps, I will post the results here? If there is anything specific you would like me to focus on or collect, please let me know, and I will be happy to share that information.
1 Like
Sounds like a good next step 
Yes - I’m definitely interested. This isn’t something I’ve come across before, so understanding it better is useful, and while I don’t think it’s an issue with the SLB06M code, or probably even a general problem with the binding, that’s not to say that something couldn’t be improved if we can nail down a root cause.
Thanks.
Thank you
Hi Chris,
After reinstalling the binding, connecting the slzb06m and adding two temp/humidity sensors, I have found the following entries in the openhab.log
2025-01-19 21:52:30.925 [WARN ] [ee.slzb06.internal.Slzb06NetworkPort] - SLZB06 'ZigBee_ONE.local': Processing received data event: Serial buffer overrun [0:0]
2025-01-19 21:52:30.925 [WARN ] [ee.slzb06.internal.Slzb06NetworkPort] - SLZB06 'ZigBee_ONE.local': Processing received data event: Serial buffer overrun [1:1]
2025-01-19 21:52:30.925 [WARN ] [ee.slzb06.internal.Slzb06NetworkPort] - SLZB06 'ZigBee_ONE.local': Processing received data event: Serial buffer overrun [2:2]
2025-01-19 21:52:30.925 [WARN ] [ee.slzb06.internal.Slzb06NetworkPort] - SLZB06 'ZigBee_ONE.local': Processing received data event: Serial buffer overrun [3:3]
2025-01-19 21:52:30.926 [WARN ] [ee.slzb06.internal.Slzb06NetworkPort] - SLZB06 'ZigBee_ONE.local': Processing received data event: Serial buffer overrun [4:4]
2025-01-19 21:52:30.926 [WARN ] [ee.slzb06.internal.Slzb06NetworkPort] - SLZB06 'ZigBee_ONE.local': Processing received data event: Serial buffer overrun [5:5]
2025-01-19 21:52:30.926 [WARN ] [ee.slzb06.internal.Slzb06NetworkPort] - SLZB06 'ZigBee_ONE.local': Processing received data event: Serial buffer overrun [6:6]
2025-01-19 21:52:30.926 [WARN ] [ee.slzb06.internal.Slzb06NetworkPort] - SLZB06 'ZigBee_ONE.local': Processing received data event: Serial buffer overrun [7:7]
2025-01-19 21:52:30.926 [WARN ] [ee.slzb06.internal.Slzb06NetworkPort] - SLZB06 'ZigBee_ONE.local': Processing received data event: Serial buffer overrun [8:8]
2025-01-19 21:52:30.926 [WARN ] [ee.slzb06.internal.Slzb06NetworkPort] - SLZB06 'ZigBee_ONE.local': Processing received data event: Serial buffer overrun [9:9]
2025-01-19 21:52:30.926 [WARN ] [ee.slzb06.internal.Slzb06NetworkPort] - SLZB06 'ZigBee_ONE.local': Processing received data event: Serial buffer overrun [10:10]
2025-01-19 21:52:30.926 [WARN ] [ee.slzb06.internal.Slzb06NetworkPort] - SLZB06 'ZigBee_ONE.local': Processing received data event: Serial buffer overrun [11:11]
2025-01-19 21:53:06.982 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: THS1_Humidity
2025-01-19 21:53:09.731 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: THS1_Humidity
2025-01-19 21:53:15.197 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: THS1_Humidity
2025-01-19 21:53:15.197 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: THS1_Temperature
2025-01-19 21:53:20.393 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: THS1_Humidity
2025-01-19 21:53:20.393 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: THS1_Temperature
2025-01-19 21:53:20.394 [WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: THS2_Temperature
2025-01-19 21:53:31.180 [ERROR] [.zigbee.slzb06.handler.Slzb06Handler] - SLZB06: retreiving API information: Invalid URI host: null (authority: ZigBee_ONE.local)
the last ERROR appears every 30 seconds since January 19. Though, luckily, Temperatures and Humidities are updated and shown without any issues.
I will let it run for some more days and then try a restart. I will also try the other slzb06m afterwards and keep you posted on the installation steps and the results.
When you have the SLZB-06M connected, first try to access it via your internal network over the web browser. If that works, and hat I have done before auto discovery is to set the stick into ZigBee mode. It will automatically download the required drivers and install them on the stick. This will take 2-3 minutes and it will reboot automatically. After that you will see the zigbee coordinator mode being active.
then go to OH into things, hit the + at the bottom right, select the zigbee binding and hit “SCAN”.
The SLZB-06M will then appear below the scan button and you can activate it. After a shot time you will see 2ZM/ZAH going from white to green and you will be able to connect further zigbee devices.
So there are two things going on here. Firstly, the zigbee connectivity, and secondly the binding requests some status information from the SLZB06M. The status information seems to be what’s failing here - this is non critical - it’s just stuff that you see in the dashboard like the uptime and it won’t impact the zigbee connectivity.