This device will provide a āstandardā zigbee dongle for the zigbee binding. You donāt need MQTT installed (at least not for the SLZB-06.
If not already autodetected, you should be able to go to the Things page to add a new coordinator⦠Select the zigbee binding, then add a thing, and you should find the SLZB06 in the list. Set the IP address (or hostname) and you should be good to go I think.
Depending on if the adaptor has been initialised previously, you might need to create the zigbee network. To do this in the config, select Advanced, then click initialise network (I forget exactly the terminology used) and save.
Iāve been using the SLZB06 for 4 or 5 months and itās worked well with a medium size network (35 or so devices at the moment).
I had to switch off and on the Zigbee Coordinator switch in the web interface of the SLZB 3 times and reinstall the firmware. Now it works and recognises Things which I can add now via Scan.
Thanks for enforcing that it should work. I would have given up after fiddling around for hours. The Coordinator switch was on initially and I would not have thought that it requires 3 installs of the firmware to actually getting it to work.
Strange. I think mine installed pretty easily from memory.
Iām not 100% sure what the coordinator switch does - I would have thought it does nothing given that in the mode the OH uses, the SLZB06 is basically just an IP connected dongle - the same as any other Silabs Ember dongle. Therefore this sort of configuration is all controlled by the bindingā¦
Iāll ask the company that makes it - they were pretty responsive when I was implementing support for this. It might be that they can improve the interface to make it clearer that when Z2M/ZHA mode is not used, I think some of these settings are also not used⦠Hopefully, with your feedback, and some input from them Iāll try and make the OH doc a bit clearerā¦
Hi, after I finally got it to work I had to reboot the windows computer where OH4 runs. Now it getās stuck in initializing status. Rebooting the SLZB-06M does not help. What helps is removing it from things, run through autodetect and re-scan to connect all things that have been connected to the coordinator. I have not idea why it does not initialise. I will contact the vendor. If anybody has an idea why that happens and how to fix it, would make me happy.
yes, I have initialized the device over show advanced, reinitialise controller and save. It works until I restart the openHAB installation. Then it tries to initialize and then the log says offline. I can access the devicesā web config through the network without any problems. It seems the only way to get it back into openHAB is to delete it completely and reinstall through autodetect. Then it it connected again until I restart openHAB. Any second reinitialisation does not connect the controller back to openHAB.
the log says: 2024-12-08 21:23:16.095 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing āzigbee:coordinator_slzb06:SLZB-06Mā changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR)
I have also tried to change it from .local to the actual IP in the network. In the Dashboard of the controller the SLZB-06M is in Zigbee mode.
Since I am still playing and not really using before I am confident it really works, I have deleted the thing.
Then I have re-installed it by auto-detect after I have reset the coordinator to factory setting and re-activated the Zigbee Coordinator function over the web interface.
When I detect in in OH4 and initialise it shows 2024-12-08 21:41:44.345 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing āzigbee:coordinator_slzb06:SLZB-06Mā changed from UNINITIALIZED (DISABLED) to INITIALIZING in the log. But it sits there now since 30 minutes at INITIALIZING and nothing more happens.
We need to get detailed loging to find out what is happening. Ideally log:set DEBUG com.zsmartsystems.zigbee in the console should do this.
Without the logging itās hard to know whatās going on. If you can enable this log, and restart the binding, or reinitialise the thing (something to get it to start initialising again) that shoild be a good start. We may also want to reinitialise the network, but letās try and get logging going first.
Note that this will generate a lot of data - many megabytesā¦
Hi, having same issue with SLZB-06 using PoE. Also had to update the IP manually after autodiscovery. Mine never comes ONLINE and fails on a communication error.
It seems it cannot retrieve EZSP version. Enabling DEBUG shows the following:
2024-12-14 11:55:23.184 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - Sending EZSP transaction timed out after 10 seconds
2024-12-14 11:55:23.185 [DEBUG] [systems.zigbee.dongle.ember.EmberNcp] - No response from ezspVersion command
2024-12-14 11:55:23.186 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EZSP Dongle: Version returned null. ASH/EZSP not initialised.
2024-12-14 11:55:23.187 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - Network state is updated to OFFLINE
2024-12-14 11:55:25.842 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Reconnect
2024-12-14 11:55:25.843 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameRst []
I read here in the manual that my device should be running z-stack and not ezsp (which openhab is asking the version for) but Iām not too familiar with the differences.
Yes, the problem seems to be that you have the SLZB06, and not the SLZB06M. The M part is quite important as itās a completely different Zigbee chipset inside - it has the TI chip, and not the Silicon Labs chip. These communicate completely differently and currently the zstack version is not supported.
Hi,
I recently purchased the SLZB06M and observed that the Thing went offline when OH was restarted , or the SLZB06M. THe reason for that in my case is that in OH the āServer Network Addressā was changed (overwrite) from the actual IP to xxxx.local. After changing back to the actual IP, the Thing came online again.
Anyhow, what would be the solution to prevent this change and keep the IP or the MSDN format to work?
I am seeing the same thing, that the IP is not kept by OH. It should not make any difference for the connection?
I am also getting other errors when it is connected but did not have any time to collect the info properly.
Just mine does not reconnect.
This is probably changed by the discovery system. In principal, it should not make any difference, and in general, using the name rather than the IP should be better and more robust since the IP address may change (depending on how your system is configured).
I guess itās interesting that it is not working with the name - possibly thereās something strange going on with your DHCP server not resolving this correctly? If you type xxxx.local into the browser, does it come up with the SLZB06M dashboard?