[REQUEST] Support for SMLIGHT SLZB-07 Zigbee Coordinator USB dongle

[Hedda]

Request support for SMLIGHT SLZB-07 Zigbee Coordinator USB dongle

https://smlight.tech/product/slzb-07/

https://community.home-assistant.io/t/smlight-slzb-07-zigbee-coordinator-usb-dongle-based-on-silicon-labs-efr32mg21-20dbm-radio-soc-mcu-9-98-launch-promotional-price-shipping-otherwise-14-99/625431

Does not look like they have a GitHub repo yet for the SLZB-07 model:

https://github.com/smlight-dev

Maybe they would donate an adapter to you if you ask?

Requesting hardware profile manifest support and unofficial experimental firmware test builds in your manifestjs-SL fork:

https://github.com/darkxst/silabs-firmware-builder/tree/manifestjs-SL

https://github.com/darkxst/silabs-firmware-builder/tree/manifestjs-SL/manifests

https://github.com/darkxst/silabs-firmware-builder/tree/manifestjs-SL/firmware_builds

[darkxst]

@Hedda thanks for organising that! yes these will get added.

[darkxst]

I have created test builds for SLZB-06M and SLZB-07, based on the information provided by Smart Light. These have not been tested yet, will do that once I receive my adapters.

They can be found in this branch: https://github.com/darkxst/silabs-firmware-builder/tree/manifestjs-SL

Will merge into main branch after testing is completed.

[darkxst]

Unfortunately the current SLZB-07 devices require signed firmwares. This requirement will be removed in the next production run though. I've also suggested they fix the EEPROM strings for auto-detection, since it currently using generic strings!

I've tested the SLZB-06M which is working well and this will get merged into the main branch shortly.

[Hedda]

Unfortunately the current SLZB-07 devices require signed firmwares. This requirement will be removed in the next production run though.

Can this be fixed on existing SLZB-07 devices by reflashing them for those that already bought them?

If so then I guess that they need to be reflashed via JTAG or?

[darkxst]

Can this be fixed on existing SLZB-07 devices by reflashing them for those that already bought them?

It should be possible for Smartlight to release a signed update that removes the restriction from existing devices.

If so then I guess that they need to be reflashed via JTAG or?

There seems to be test pads for SWD. so that would be the unofficial option.

[Hedda]

@MattWestb have you by chance bought SLZB-07 dongle from SMLIGHT and tried flashing it via JTAG interface using J-Link or?

https://smartlight.me/smart-home-devices/zigbee-devices/slzb-07-zigbee-usb-adapter-en

It is still sold for the low price of $9.98(US) but shipping is relatively high so only a good deal per unit if make one large order 😉

[MattWestb]

@Hedda No ! You can asking the devs for the pinout then they saying its "DYI PINOUT" friendly. https://smlight.tech/product/slzb-07/ And then build one new firmware for it.

[darkxst]

@MattWestb I have all the info and have built a firmware, but they failed to upload. Now their engineer says it requires signed firmware.

[Hedda]

its "DIY PINOUTS" friendly.

"SLZB-07 is a DIY enthusiasts friendly: it contains pinouts for EFR32MG21 chip"

hmm, sadly not DIY-friendly, nor plug-and-play flash, nor USB flashable, if it does not support unsigned firmware images.

[Hedda]

Posted question to SMLIGHT here (since they do not yet have a GitHub slzb-07 repository) -> https://github.com/smlight-dev/slzb-06-firmware/discussions/75

[MattWestb]

@MattWestb I have all the info and have built a firmware, but they failed to upload. Now their engineer says it requires signed firmware.

= not DYI friendly

[darkxst]

They are going to provide an updated bootloader to fix this, on existing dongles.

[darkxst]

SLZB-06M is not affected by this btw.

[darkxst]

"SLZB-07 is a DIY enthusiasts friendly: it contains pinouts for EFR32MG21 chip"

The pinouts are the same as SkyConnect, in fact the only difference is the zigbee chip is EFR32MG21A020F768IM32 vs 512KB flash version used in skyconnect.

[darkxst]

I have the updated bootloader image now, will test it shortly

[Tarik2142]

@MattWestb @Hedda you can simply unlock bootloader, see manual https://smlight.tech/manual-slzb-07/ online flash tool https://smlight.tech/flasher/#SLZB-07

[morhimi]

any update on supporting these new dongles on the web flasher?

[morhimi]

Hi @darkxst Many 10x for adding support on the web flasher for this dongle 💯

That said, it seems the the served build for this dongle is using 230400 baud rate hence after flashing the dongle is no longer visible (same as https://github.com/darkxst/silabs-firmware-builder/issues/34) I managed to force upgrade to a 115200 from cli and now the web flasher sees the the dongle again.

I suggest to serve the 115200 variant for this dongle. I'm willing to help testing if needed, I have a few of these lying around

[darkxst]

That said, it seems the the served build for this dongle is using 230400 baud rate

Oops, seems I put the wrong link, I've fixed the link now to use 115200 for NCP.

Thanks for letting me know!

[jusicgn]

I have created test builds for SLZB-06M and SLZB-07, based on the information provided by Smart Light. These have not been tested yet, will do that once I receive my adapters.

They can be found in this branch: https://github.com/darkxst/silabs-firmware-builder/tree/manifestjs-SL

Will merge into main branch after testing is completed.

Hi @darkxst ,

you've mentioned the firmware for SLZB-06M in your Post above. I've just got my new SLZB-06M. Now wondering, how to get the rcp-uart-802154-v4.3.2-slzb-06m-460800.gbl file from the builds section on the device. The built in flasher doesn't accept the .gbl file. Any hint? Thanks in advance

Julian

[darkxst]

You need to flash it in USB mode. Also I havent yet tested rcp multipan in ethernet mode, it should work, however do note the SMLIGHT firmware has issues with it thinking unknown firmware installed.

[jusicgn]

Thanks for getting back to me on this, @darkxst . I'll see if I try the flashing in USB mode when I have "nerd time". What do you mean by "SMLIGHT firmware has issues with it thinking unknown firmware installed"?

[morhimi]

@Hedda I believe this issue can be closed now that it's supported and working fine

[wkelton]

I have a SLZB-06M and wanted to flash the multipan firmware. I tried the web flasher by clicking on the SLZB-07 and it tries to connect but eventually reports not being able to connect (I assume this is expected as SLZB-06M is not a SLZB-07). So, I tried using universal-silabs-flasher with the SLZB-06M in usb mode (as mentioned in this thread). I flashed rcp-uart-802154-v4.4.1-slzb-06m-460800.gbl without error with this command universal-silabs-flasher --device /dev/ttyUSB0 flash --allow-cross-flashing --firmware Downloads/rcp-uart-802154-v4.4.1-slzb-06m-460800.gbl. However, after switching the SLZB-06M back to ethernet mode, it would not show up on my network. I also tried rcp-uart-802154-v4.3.2-slzb-06m-460800.gbl and rcp-uart-802154-v4.4.1-slzb-06m-230400.gbl.

I figured that maybe it won't work in the ethernet mode with this firmware, for whatever reason. Went to test it with my home assistant in usb mode. But, I didn't realize that it requires installing an add-on to setup as a thread router (I assumed it was done similarly as zigbee (ZHA)). I use HA core run with Docker. And, the information I can find on running a container to manage the thread router compatible with HA is confusing.

If anyone has any ideas on any of this, I'd appreciate hearing it. I'm probably going to wait until thread/matter are stabilized with HA (and using it with core).

[tl-sl]

I tried the web flasher by clicking on the SLZB-07

My web flasher doesnt support SLZB-06M, and they are different images than SLZB-07

I figured that maybe it won't work in the ethernet mode with this firmware, for whatever reason.

It should work in ethernet mode, but the onboard SMlight Web UI wont recognise it properly. Also you will need to setup Multiprotocol to connect to the device. ZHA then connects to multiprotocol server.

I use HA core run with Docker. And, the information I can find on running a container to manage the thread router compatible with HA is confusing.

Both Multipan or Openthread firmware require addons, however there is a standalone docker project for Multipan/Multiprotocol: https://github.com/b2un0/silabs-multipan-docker

[wkelton]

I tried the web flasher by clicking on the SLZB-07

My web flasher doesnt support SLZB-06M, and they are different images than SLZB-07

👍

I figured that maybe it won't work in the ethernet mode with this firmware, for whatever reason.

It should work in ethernet mode, but the onboard SMlight Web UI wont recognise it properly. Also you will need to setup Multiprotocol to connect to the device. ZHA then connects to multiprotocol server.

Not being able to use ethernet for the SLZB-06M really hurts its purpose (being able to have it close to your devices).

I use HA core run with Docker. And, the information I can find on running a container to manage the thread router compatible with HA is confusing.

Both Multipan or Openthread firmware require addons, however there is a standalone docker project for Multipan/Multiprotocol: https://github.com/b2un0/silabs-multipan-docker

Yeah, didn't realize that when I started looking into setting up a thread network. I'm concerned that that docker project requires host networking and ipv6. More, I'm concerned about maintainability, how long will that project be maintained, will the docker image be updated close in time as the upstream image, etc (just adds more complications to keeping HA stable on recent versions).

I would like to setup a thread network, but it is not critical. I'll stick with my zigbee network until I have more time to understand how to best manage all this. Thanks for the info (and of course the firmware)!

[darkxst]

Not being able to use ethernet for the SLZB-06M really hurts its purpose (being able to have it close to your devices).

Like I said it should work in ethernet mode, the serial port will still be exported over the network, just some features in the SLZB UI wont recognise the firmware.

I'm concerned that that docker project requires host networking and ipv6. More, I'm concerned about maintainability, how long will that project be maintained, will the docker image be updated close i

I really can't speak to that. It is however largely based on the HA Addon, so should be easy for the maintainers to keep updated.

I would like to setup a thread network, but it is not critical. I'll stick with my zigbee network until I have more time to understand how to best manage all this. Thanks for the info (and of course the firmware)!

The recommended (stable?) way to add Thread to HA is to use an external border router either Apple or Google hardware to match your phone!

[darkxst]

docker project requires host networking and ipv6

This is a hard requirement of Matter/Thread support, ipv6 is mandatory and needs to be on the same subnet for broadcast traffic etc.

[wkelton]

Like I said it should work in ethernet mode, the serial port will still be exported over the network, just some features in the SLZB UI wont recognise the firmware.

Oh, misunderstood. Well, my SLZB-06M (with the 3 firmwares I tried) does not appear on my network (checked that it was in ethernet mode) - my router sees no device connected (the SLZB-06M ethernet activity light does light up though).

The recommended (stable?) way to add Thread to HA is to use an external border router either Apple or Google hardware to match your phone!

Yeah, but I can wait for things to be more stable with HA (core).

[wkelton]

docker project requires host networking and ipv6

This is a hard requirement of Matter/Thread support, ipv6 is mandatory and needs to be on the same subnet for broadcast traffic etc.

Thanks for the info. Going to have to read up on this. Just confusing to me. I don't understand why it would need addressing on my lan network. I would prefer these things to be separated. Guess even more of a reason for me to stay with zigbee.

[darkxst]

Oh, misunderstood. Well, my SLZB-06M (with the 3 firmwares I tried) does not appear on my network (checked that it was in ethernet mode) - my router sees no device connected (the SLZB-06M ethernet activity light does light up though).

This is odd, the zigbee firmware should have no effect on the ESP32/Web part of the device connecting via ethernet.

Yeah, but I can wait for things to be more stable with HA (core).

By all accounts using a Google/Apple border router is pretty stable and will work directly with HA Core. Where as running Thread directly and using the addons is still very much experimental and can be troublesome.

[darkxst]

Thanks for the info. Going to have to read up on this. Just confusing to me. I don't understand why it would need addressing on my lan network. I would prefer these things to be separated.

First of all unlike Zigbee, Matter and Thread are ipv6 based. The Matter server will run on your lan and needs to be able to speak to the LAN side of Thread border router. and via ipv6 routes directly to the thread device.

Now you could isolate all this in separate ipv6 subnet, however the commissioning process requires using your phone (atleast currently there is no other easy way to commission devices). You scan a QR code, you then need connectivity with the thread network (and matter server) for this process to complete.

[wkelton]

Thanks for all the info.

That just adds more complexity to isolate IoT devices (one of the reasons I like zigbee - not on my lan :) ). I'm more of a novice when it comes to networking, but sounds like I could setup a vlan with ipv6 on a different subnet than my lan (with isolation), create a wifi SSID on that vlan, connect my phone to that SSID when needed to commission new devices. But, I'd need the matter/thread servers to be on that vlan, not sure that'd be possible with my setup / gear (running HA core with docker on a server where I host many other services).

[darkxst]

one of the reasons I like zigbee

Lucky for you then Zigbee is not going anyway any time soon. There was even a 2023 update to the Zigbee spec. Sure some new devices maybe Matter/Thread only (especially from brands that previously focused on Homekit) but Zigbee options will exist for quite a long time yet.

Ipv6 changes alot compared to ipv4 networking, likewise Thread over Zigbee is a major architectural change (it just shares the same 802.15.4 radio link as Zigbee;) )

[MattWestb]

Ipv6 changes alot compared to ipv4 networking, likewise Thread over Zigbee is a major architectural change (it just shares the same 802.15.4 radio link as Zigbee;) )

Thread over Zigbee is not possible then Thread is using encryption in the 15.4 network layer and Zigbee is doing it in the next layer (ZigbeeNetwork layer) and must have raw 15.4 communication. But i think you is talking about the latest Zigbee Cluster Library Specification (ZCL) so its the latest for Zigbee (R8) one step behind the Matter one then matter is using the same cluster commands but transported over IPV6 but is called Application Cluster Specification and its also having Zigbee part implanted but is not implanted in latest ZCL R8 so likely is coming in R9 (IKEA shortcut bottom gen 3 is using matter Cluster commands but in manufacture cluster then its out of ZCL 8). https://csa-iot.org/developer-resource/specifications-download-request/

Matter = Zigbee over Thead or WiFi on the command level only different way transporting the commands (IPv6).

I hope AH is opening the matter part for piping Zigbee cluster to it from ZHA and dont need struggling with crazy quirks for getting things working OK in the future.

[darkxst]

Thread over Zigbee is not possible then

I didnt meant that literally, more meant Thread vs Zigbee!

[MattWestb]

Matter = Zigbee over IPv6. If Zigbee was made today it shall have being IPv6 from start = Matter and no Zigbee 1.X or Thread without standard command. The good thing with Zigbee is autonomous network for not centralized devices as first ZLL and now Zigbee direct that is making one small private network with standalone device like IKEA kits with one lamp and one remote and can adding more lights and remotes to it without host system (its not part of the matter standard what i have seen but can being implanted in the device firmware like IKEA have doing with the parasoll (open/close detector) can steering lights on/off directly but not in centralized mode).

[jusicgn]

I just got a brand new SLZB-07 :) As I wanted to have it as a separate Thread stick, I flashed it to firmware ot-rcp-v2.3.1.0-slzb-07-460800.gbl So far it worked like a charm an HA OT addon recognised it flawlessly.

Now I wanted to try the ot-rcp-v2.3.3.0-slzb-07-460800.gbl or even ot-rcp-v2.4.1.0-slzb-07-460800.gbl firmwares.

But the webflasher didn't start the flashing process (kept staying at 0% forever).

I then tried the universal-silabs-flasher at command line. Got the following error outputs but can't figure what to do now. Even when trying to reflash the firmware already installed. Any help is much appreciated!

➜  ~ universal-silabs-flasher --device /dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_8e08878fa63bec1183b39e957a0af07f-if00-port0 flash --firmware config/ot-rcp-v2.3.1.0-slzb-07-460800.gbl --force                          
2024-03-29 12:48:12.911 a0d7b954-ssh universal_silabs_flasher.flash INFO Extracted GBL metadata: NabuCasaMetadata(metadata_version=1, sdk_version='4.3.1', ezsp_version=None, ot_rcp_version='SL-OPENTHREAD/2.3.1.0_GitHub-e6df00dd6' (2.3.1.0), cpc_version=None, fw_type=<FirmwareImageType.OT_RCP: 'ot-rcp'>, baudrate=460800)
2024-03-29 12:48:12.912 a0d7b954-ssh universal_silabs_flasher.flasher INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
2024-03-29 12:48:14.926 a0d7b954-ssh universal_silabs_flasher.flasher INFO Probing ApplicationType.SPINEL at 460800 baud
2024-03-29 12:48:14.947 a0d7b954-ssh universal_silabs_flasher.flasher INFO Detected ApplicationType.SPINEL, version 'SL-OPENTHREAD/2.3.1.0_GitHub-e6df00dd6' (2.3.1.0) at 460800 baudrate (bootloader baudrate None)
2024-03-29 12:48:15.459 a0d7b954-ssh universal_silabs_flasher.flasher INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
Traceback (most recent call last):
  File "/usr/bin/universal-silabs-flasher", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
         ^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/click/decorators.py", line 33, in new_func
    return f(get_current_context(), *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/universal_silabs_flasher/flash.py", line 40, in inner
    return asyncio.run(f(*args, **kwargs))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/asyncio/runners.py", line 190, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/asyncio/base_events.py", line 654, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/universal_silabs_flasher/flash.py", line 408, in flash
    await flasher.enter_bootloader()
  File "/usr/lib/python3.11/site-packages/universal_silabs_flasher/flasher.py", line 281, in enter_bootloader
    await self.probe_app_type(types=[ApplicationType.GECKO_BOOTLOADER])
  File "/usr/lib/python3.11/site-packages/universal_silabs_flasher/flasher.py", line 235, in probe_app_type
    raise RuntimeError("Failed to probe running application type")
RuntimeError: Failed to probe running application type

[darkxst]

Not being able to use ethernet for the SLZB-06M really hurts its purpose (being able to have it close to your devices).

Turns out there was a bug with baudrates over 115200 in ethernet mode. A fix for this should be released soon.

[darkxst]

Now I wanted to try the ot-rcp-v2.3.3.0-slzb-07-460800.gbl or even ot-rcp-v2.4.1.0-slzb-07-460800.gbl firmwares.

Seems openthread firmware is not resetting into bootloader, as it was missing some patches on the backported firmware builds (2.3.1 - 2.3.3). You will need to force bootloader per instructions on SMLIGHT website to reinstall (using universal-silabs-flasher).

I running a rebuild of affected firmware now...

[jusicgn]

You will need to force bootloader per instructions on SMLIGHT website to reinstall (using universal-silabs-flasher).

Thx! To be sure: You mean the "scissors hack"?

[darkxst]

You mean the "scissors hack"?

Yes

[jusicgn]

Do you know if it has to be done the whole time while flashing or just while plugging in the stick? Edit: Never mind. Figured out that it has to be connected the whole time.

[jusicgn]

@darkxst I managed to put my SLZB-07 into recovery bootloader mode and reflashed firmware.

But even with the ot-rcp-v2.3.3.0-slzb-07-460800.gbl from today it still shows this as probe output 2024-03-29 15:07:30.594 a0d7b954-ssh universal_silabs_flasher.flasher INFO Detected ApplicationType.SPINEL, version 'SL-OPENTHREAD/2.3.3.0_GitHub-e6df00dd6' (2.3.3.0) at 460800 baudrate (bootloader baudrate None)

And I can't flash again without putting it into recovery bootloader mode.

Stick works fine so far with 2.3.3.0 for HA OT addon.

[darkxst]

Seems there was still some issues with the backport builds, just uploaded another 2.3.3 that should reset properly.

It also seems that the 2.4.1 builds are completely broken, so stick with 2.3.3 for now.

EDIT: 2.4.1 should be fixed now also.

[jusicgn]

@darkxst that looks very good so far. Just put the SLZB-07 back into recovery and flashed your new 2.4.1. After that I was able to reflash same version without putting the stick into recovery mode. Thread Network and the Matter Devices coming back within seconds 👍 I'll report here if there a any glitches on the long run. Thanks for your great work. Just bought you a coffee :) Happy easter!

[darkxst]

@jusicgn Thanks for the coffee ;)

Good to hear its working well!

[darkxst]

The latest release (v2.1.0dev) of core firmware for SLZB-06M fixes baudrates above 115200. So it should now work with MultiPan and Openthread firmware over ethernet. Just make sure to select the correct baudrate on the Z2M/ZHA page.