Changed the last letter of the IEEE to from an “a” to a “b”, and it now works!
Is the IEEE the same as a MAC-address?
Seems there is one more octet in the IEEE than what the MAC has, or is that not used, since it is 00?
If it is indeed a MAC, how does one pick a new one? Or is it totally random? On other devices, the MAC will point to the manufacturer. From googling, it would seem to start with “00:12:4b” for all or most zigbee dongles, so I assume it is differently built.
Functionally the same as a mac. Not sure of any nuances of length and format.
The TI chips allow the ieee they use to be changed at will.
With the SI Labs chips the ieee can only be changed a single time and there is no going back, so you’re SkyConnect will now always have the ieee of your old dongle. Likely not an issue unless you want to migrate again at some point.
Good to know! This might have puzzled me if I had made changes in the future!
Any idea why it can only be changed once on the SkyConnect? Seems short-sighted and stupid, looking at how people might want to play around, and might therefor cause one or more migrations!
For the CC2652 adapter see https://www.zigbee2mqtt.io/guide/adapters/flashing/copy_ieeaddr.html
Yep, that is what I did! Used the zigstar tool! Had to re-write the firmware at the same time though, just like your reference points out! It is now connected!
I just tried migrating Z2M via zzh CC2652R1 stick over to Skyconnect using multiprotocol add-on and then ZHA integration and although I got it working, there was a huge delay in device status changes…up to 15 seconds for a motion sensor to show triggered in HA so I went back to my old setup. I had a lot of re-pairing to do…
FYI, multiprotocol firmware is not recommend. Recommend is instead to flash it with NCP firmware.
Read and make sure that to try following these best practices → Zigbee networks: how to guide for avoiding interference + optimizing using Zigbee Router devices (repeaters/extenders) to get best possible range and coverage (which is more detailed than these general tips → https://www.home-assistant.io/integrations/zha#zigbee-interference-avoidance-and-network-rangecoverage-optimization )
While not always, those types of problem symptoms that you describe are most commonly symptoms of EMF/EMI/RMI interference and/or not having enough Zigbee Router devices with good reception in the Zigbee network, as Zigbee uses low-power signals to send very short message RF reception can be extremely sensitive so having issues with either or a combination those can cause such problem symptoms. It is therefore always best to take basic actions to alleviate all those concerns first as doing so will make further troubleshooting easier. Following the best practice tips from this guide is the most easily achieved of a set of tasks that will have the greatest overall effect on Zigbee communication reception → Zigbee networks: how to guide for avoiding interference + optimizing using Zigbee Router devices (repeaters/extenders) to get best possible range and coverage
Summary of setup questions that you need to answer to take action on:
You might also want to consider upgrading Zigbee Coordinator NCP firmware
The whole pupose of getting HA Skyconnect stick was for Thread support for Matter devices. As for Zigbee only, I was perfectly happy with my Electrolama zzh (CC2652R1 - External Antenna) stick…
Zigbee only firmware
The whole purpose of getting Skyconnect adapter was to support Thread devices.
Otherwise, I was perfectly happy with my Electrolama zzh zig-ah-zig-ah! (CC2652R1 - External Antenna) for Zigbee…
So I should do this on the Skyconnect then?
Why not flash your skyconnect with rcp-firmware ? (=Thread only firmware)
One reason multiprotocol firmware is not recommend : The radio switches to Zigbee, listens a few milliseconds, the radio switches to Thread, listens a few milliseconds, switches to Zigbee …
If you use Zigbee only or Thread only firmware, that does not happen.
Keep Zigbee on your CC2652, and use skyconnect for Thread 
I understand the concept for multiprotocol and how it works. It’s too bad though the theory isn’t working in practice! I was envisioning a slight induced delay due to “multitasking” but wasn’t expecting near instant actions to now have a 10-15 second delay.
Could you save me some “google search” time??
Thank you for the links!.
OTBR add-on installed and Slyconnect flashed with rcp firmware. OTBR Integration discovered and added. Added the Matter (BETA) integration added which auto-installed the Matter Server 5.4.1 official add-on.
In the Thread integration I’m seeing my Amazon Echo but I read somewhere that it’s kind of proprietary. I’m seeing two ha-thread-xxxx threads for some reason - one with a TBR (the new one I just added?) and one without:
Sorry, I was editing my last post with new info…
ha-thread 076c might be left over from the multi-protocol add-on
That is fine, I only meant that you should not use Zigbee AND Thread on the same single radio adapter dongle. The problem is with multi-PAN (several Private Area Networks concurrently) on a single radio adapter. That is, do not use Zigbee AND Thread simultaneously on a single SkyConnect.
The multi-PAN/multiprotocol feature has only ever been experimental on the EFR32MG21 based SkyConnect and now the new/latest recommendation is to not use it any longer and instead migrate to having one dedicated radio adapter/dongle for Zigbee (running Zigbee NCP firmware) in combination with a separate dedicated radio adapter/dongle for Thread (running OpenThread RCP firmware).
“our current recommendation for Home Assistant Yellow and Home Assistant SkyConnect is to use the Zigbee firmware to power your Zigbee network. This is a stable solution that has worked reliably since the introduction of these products and offers a great experience.” → The State of Matter - Home Assistant
This is what most people here in the community have always recommended anyway, but now it is a formal recommendation coming from Nabu Casa, and the Home Assistant developers that have declared that multi-PAN is not working well if you have more than a few devices so they have decided to not actively continue the development pursuit of stable multi-PAN/multiprotocol support. So the feature will not be removed, but it will no longer be actively developed and no longer recommend.
Also note that using the SkyConnect adapter/dongle (or Home Assistant Yellow) as a Thread radio is still under development at this point, is still listed as experimental, and is only recommended for the more technically experienced users. If you want to use Thread for Matter today then the recommendation is currently instead for iOS users to use a HomePod Mini or other Apple border router, placed near their Thread devices to get the required Thread coverage, similar Google Home can use Google Nest Hub or Google Nest Hub as Thread Border Routers, (alternatively, you can stay with only using WiFi-based Matter devices).
All this was also clearly stated in the recent videos from Home Assistant about Matter and Thread → https://www.youtube.com/@home_assistant/videos
Hence, using multi-PAN (multi-protocol) should be considered deprecated.
