Hey all, I just took delivery of a brand new Sky Connect I ordered in Denmark. Would you recommend I just leave it configured as it came until HA dev team releases a reliable multiprotocol firmware upgrade?
Meanwhile, if I’d get some zigbee + thread compatible light bulbs, can I just use them with the SC in zigbee mode and switch to thread later?
Thanks, Pete
PS When I go to Menu / system / hardware I see this:
Very tempting to tick this box…
Hi Peter,
I have had the exact same issue as you and been through all the same steps trying to fix my SkyConnect.
I will share that I have finally been able to fix the SkyConnect through an unconventional mehtod. Note, the online firmware tool and the SSH manual method did not work for me.
FIX:
I have an raspberry pi 3 laying around (my HA is currently running on a Synology DS918+ VM). I downloaded and installed a fresh HA OS onto the Raspberry pi 3 after fully booted into a fresh instance I plugged in the SkyConnect and opened the ZHA Integration. BOOM, the SC was fixed.
Not sure what is going in the fresh install that cannot be replicated in my other Synology instance of the Online Firmware Tool.
I hope any others feeling like they have a bricked SC find this helpful.
Well that’s great news! Can I send my brick to you to unbrick it? 
I did the same as you, albeit I started with a fresh VM image from Linux - Home Assistant
It seems not completely bricked, but it just can’t be flashed:
/dev/serial/by-id/usb-Nabu_Casa_SkyConnect_v1.0_xxxx....)
s6-rc: info: service universal-silabs-flasher: starting
[23:18:44] INFO: Checking /dev/ttyUSB0 identifying SkyConnect v1.0 from Nabu Casa.
[23:18:44] INFO: Starting universal-silabs-flasher with /dev/ttyUSB0
2023-05-09 23:18:45 homeassistant universal_silabs_flasher.flash[180] INFO Extracted GBL metadata: NabuCasaMetadata(metadata_version=1, sdk_version='4.2.3', ezsp_version=None, ot_rcp_version=None, fw_type=<FirmwareImageType.RCP_UART_802154: 'rcp-uart-802154'>, baudrate=460800)
2023-05-09 23:18:45 homeassistant universal_silabs_flasher.flasher[180] INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
2023-05-09 23:18:47 homeassistant universal_silabs_flasher.flasher[180] INFO Probing ApplicationType.CPC at 460800 baud
2023-05-09 23:18:52 homeassistant universal_silabs_flasher.flasher[180] INFO Probing ApplicationType.CPC at 115200 baud
2023-05-09 23:18:56 homeassistant universal_silabs_flasher.flasher[180] INFO Probing ApplicationType.CPC at 230400 baud
2023-05-09 23:19:00 homeassistant universal_silabs_flasher.flasher[180] INFO Probing ApplicationType.EZSP at 115200 baud
2023-05-09 23:19:06 homeassistant universal_silabs_flasher.flasher[180] INFO Probing ApplicationType.SPINEL at 460800 baud
Error: Failed to probe running application type
Now, I’ve no machine laying around, to install HA OS on, to exactly reproduce your specific setup. But I doubt if it would change anything?
NO, Pete, NO! It still looks like such a harmless ‘option’… I ticked the box, and now I’ve a blue table leveler and had to buy an other dongle.
I often install experimentals and beta’s, but this was a very expensive test.
I recommend to just not flash it and wait for succesful stories, and stable releases.
When they’re usable as zigbee devices, I would start with zigbee mode and wait for a while for the Thread / Matter integrations to become stable
You might be surprised with what the install of HA OS does.
When I download the ZHA diagnostics from the integration in my VM HA that the repaired SC is plugged into, I get the following when before I had the same problem as you:
"data": {
"config": {},
"config_entry": {
"entry_id": "67f9713ff15ecfde6e444fXXXXXXXX",
"version": 3,
"domain": "zha",
"title": "SkyConnect v1.0, s/n: 10a7ae78c742ed11936e45abXXXXXXX - Nabu Casa",
"data": {
"device": {
"path": "/dev/serial/by-id/usb-Nabu_Casa_SkyConnect_v1.0_10a7ae78c742ed11936e45abXXXXXXX-if00-port0",
"baudrate": 115200,
"flow_control": "software"
},
"radio_type": "ezsp"
},
"options": {},
"pref_disable_new_entities": false,
"pref_disable_polling": false,
"source": "user",
"unique_id": null,
"disabled_by": null`Preformatted text`
"metadata": {
"ezsp": {
"manufacturer": "Nabu Casa",
"board": "SkyConnect v1.0",
"version": "7.2.2.0 build 190",
"stack_version": 11,
"can_write_custom_eui64": true`
Previously when I used the Online Flashing Tool the SC was running 7.2.3.
If you can replicate it would be interesting to see what yours comes back with?
I had to use a USB dongle as drive, to be able to install HA OS on my NUC, while I couldn’t swap the NVMe drive for a SSD drive.
Not recommended while it is damn sloooowwwww, it took several hours before I could use the system
But, unfortunately, I got exactly the same behaviour and errors, so I think I bricked my SkyConnect better than you 
Anyone have any success on getting Matter + Thread working on Home Assistant Container + OpenThread Border Router?
I actually have quite a unconventional setup currently:
I (124318) chip[DL]: BLE GAP connection established (con 1)
I (124318) chip[DL]: CHIPoBLE advertising stopped
I (125088) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 112
I (125088) chip[BLE]: local and remote recv window sizes = 5
I (125098) chip[BLE]: selected BTP version 4
I (125098) chip[BLE]: using BTP fragment sizes rx 244 / tx 244.
I (125098) chip[DL]: Write request/command received for CHIPoBLE TX CCCD characteristic (con 1 ) indicate = 1
I (125118) chip[DL]: CHIPoBLE subscribe received
I (125118) NimBLE: GATT procedure initiated: indicate;
I (125118) NimBLE: att_handle=14
I (125198) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (125208) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 112
I (125218) chip[EM]: >>> [E:12954r S:0 M:14468822] (U) Msg RX from 0:688CB11788A4FC81 [0000] --- Type 0000:20 (SecureChannel:PBKDFParamRequest)
I (125228) chip[EM]: <<< [E:12954r S:0 M:96659770] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:21 (SecureChannel:PBKDFParamResponse)
I (125248) chip[IN]: (U) Sending msg 96659770 to IP address 'BLE'
I (125248) NimBLE: GATT procedure initiated: indicate;
I (125258) NimBLE: att_handle=14
I (125348) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication(con 1) status= 14
I (125348) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 112
I (125358) chip[EM]: >>> [E:12954r S:0 M:14468823] (U) Msg RX from 0:688CB11788A4FC81 [0000] --- Type 0000:22 (SecureChannel:PASE_Pake1)
I (125438) chip[EM]: <<< [E:12954r S:0 M:96659771] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:23 (SecureChannel:PASE_Pake2)
I (125448) chip[IN]: (U) Sending msg 96659771 to IP address 'BLE'
I (125448) NimBLE: GATT procedure initiated: indicate;
I (125458) NimBLE: att_handle=14
I (125538) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (125548) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 112
I (125558) chip[EM]: >>> [E:12954r S:0 M:14468824] (U) Msg RX from 0:688CB11788A4FC81 [0000] --- Type 0000:40 (SecureChannel:StatusReport)
E (125568) chip[SC]: Received error (protocol code 2) during PASE process: 38
E (125578) chip[SC]: Failed during PASE session setup: 38
E (125578) chip[SVR]: Commissioning failed (attempt 1): 38
I (125588) chip[BLE]: Releasing end point's BLE connection back to application.
I (125598) chip[DIS]: Updating services using commissioning mode 1
I (125608) chip[DIS]: Advertise commission parameter vendorID=65521 productID=32768 discriminator=3841/15 cm=1
E (125608) chip[DIS]: Failed to advertise commissionable node: 3
E (125618) chip[DIS]: Failed to finalize service update: 1c
I (125618) app_main: Commissioning window opened
I (126568) chip[DL]: Write request/command received for CHIPoBLE TX CCCD characteristic (con 1) indicate = 0
I (126568) chip[DL]: CHIPoBLE unsubscribe received
I (126578) chip[DL]: BLE GAP connection terminated (con 1 reason 0x213)
E (126568) chip[BLE]: no endpoint for unsub recvd
I (126588) chip[DL]: Configuring CHIPoBLE advertising (interval 25 ms, connectable)
I (126588) NimBLE: GAP procedure initiated: advertise;
I (126598) NimBLE: disc_mode=2
I (126608) NimBLE: adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=40 adv_itvl_max=40
I (126618) NimBLE:
I (126618) chip[DL]: CHIPoBLE advertising started
I (155598) chip[DL]: Configuring CHIPoBLE advertising (interval 500 ms, connectable)
I (155598) chip[DL]: Device already advertising, stop active advertisement and restart
I (155608) NimBLE: GAP procedure initiated: stop advertising.
I (155608) NimBLE: GAP procedure initiated: advertise;
I (155618) NimBLE: disc_mode=2
I (155618) NimBLE: adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=800 adv_itvl_max=800
I (155638) NimBLE:
I can see the network is formed in otbr web ui but this is how it shows up in home assistant
Thank you Peter, highly appreciated.
I resisted my temptation to proceed thanks to your previous posts but now I know this is the route you went that resulted in breaking your skyport.
I suppose this topic is the place to look for success stories.
Pete.
If I am already using a Sonoff coordinator for Zigbee with ZHA, is it possible to configure SkyConnect as a Thread router exclusively (ie, no Zigbee)? Is that still considered “multiprotocol”?
I’m not entirely sure, but I suspect that if you add the SiLabs multiprotocol Add-On, that HA may attempt to automatically reconfigure your ZHA to use the multiprotocol stack instead of your Sonoff.
There is however an alternative where you can use the “OpenTread Border Router” Add-On instead of the Multiprotocol Add-On. This should leave ZHA alone and let it run as is, and use SkyConnect only for Thread.
I just got my skyconnect ordered months ago. Since then I have installed a Sonoff P and Zigbee2MQTT is working perfectly. I see no need to redo everything just to use the Sky Connect dongle - especially since there is nothing really I can use with Thread yet! I have been researching an easy way to migrate my Z2M to use multipan, and it looks like the easiest is just to add each device again… but this OpenThread looks like the answer to have the SkyConnect as thread only and keep things separate, especially with the potential of upgrading sky connect in future as new firmwares are required to fix bugs, potentially botching my Zigee. I will try later and see what it does.
I did flash my Skyconnect for Thread only but then it wanted me to use a beta version of HA to support it, so I’m gonna hold off. I don’t have any thread devices anyhow, hah.
I flashed my skyconnect using chrome to the multi-pan, but then I decided to flash back to the ezsp zigbee firmware just to see what happens.
I then plugged into home assistant, and installed the OT Addon and selected the USB port… according to logs if detected the ezsp firmware and flashed it… I restarted and the thread integration picked it up.
Under My network, It now shows the OpenThread Border Router along with the two HomePod minis under Other networks (which were there previously). Have nothing thread yet, but it is ready now 
(As an off-topic side-note, I noticed my Sonoff 3.0 P had a firmware update released a few days ago, I removed and flashed too while I was at it)
I just received my Yellow box, installation went without a problem. Restore Backup from my iMac dito.
I set up the tread interface and wanted to connect to my trhead network (2 AppleTVs as Border Router) so that I can se my EVE devices in HomeAssistant.
Expected to see the “Make Preferred Network” under my HomeNetwork (as per the Mockup), but no avail. Have I missed something?
Anyhelp for a newbe would be appreciated.
Many thanks in Advance!
Only way that worked for me is using the pairing option from Apple Home and paired it to both Apple Home and Home Assistant. This seems to work fine but it is not actually using the Thread part in HA as it is still using the AppleTV I have as Home Hub for the Thread Border Router function.
Thanks Daniel, please allow 2 questions:
Many thanks in advance!
It needs to be done from a mobile device, won’t work from PC. I have done from iOS and iPadOS.
Steps are layed out for Android and Apple: Matter (BETA) - Home Assistant
I did the steps at SHARE A DEVICE FROM APPLE HOME.
Sometimes it failed for me and I needed to unplug/remove battery of the Eve devices and try again before it could pair. I have 12 Eve Door/Window sensors and 8 Eve plugs connected through both HA and Apple Home now. I have moved all my Automations to HA now and it reacts ok.
Thanks Daniel, can it be that all your Eve devices have been upgraded to Matter? Eve has not provided that update yet for Thermostats and Aqua. The procedure as described does not give the “ Turn On Pairing Mode” option in Apple Home. That only works for Matter devices and not Thread I believe.
Can anyone confirm my understanding?
Yes, this only works on devices with Matter firmware. The HomeKit firmware devices can only be paired to one ‘Hub’ at the same time. Thread works over Matter and HomeKit
So you could remove it from Apple Home and than add it to Home Assistant through the HomeKit Controller, as Home Assistant can now use your Apple Home Hub as Thread Border Router, at least it worked with the AppleTV 4K (2022 with ethernet).
Keep in mind you will lose some Eve specific features. With the Matter firmware only the Matter compatible data is given to Home Assistant, the rest is only visible through the Eve app.
Thanks, that’s what I did with the EVE Door/Window which I migrated to Matter. That worked fine.
My issue now is how to integrated the Thread Devices into HA. The HA Border router does not let me integrate the AppleTV Border router (or vice versa). See the screenshot in my post 74 of Aug. 5.
